こんにちは。ハイベロシティ CTOの和泉 裕臣です。
いきなりですけど皆さん、アジャイルしてますか？
アジャイルっていうと、ドキュメントなしで、とにかく実装スタート！！そんでもって、実際のプロトタイプを動かしながら仕様もバグもフィックスしていこうぜっていう軽いノリのイメージがありますよね、やっぱり。ちょっと前までは、「それこそがWEB2.0時代の開発スタイルだ！」なんて豪語しているスタートアップがわんさかありました。
まあ、こういうわりと軽いイメージでも、自主開発ならなんとかなっているところも多いのかもしれないですが（これはこれで問題ですが）、明確なクライアントが存在する受注開発だとそうはいきませんよね。お客さんにかなり協力要請しなければいけなくなるっていう問題もあるんですが、それ以上に、最初に詳細設計をしないわけだから、とにかく見積もりが出せない。
これ、これが最大の問題なんです。
なので、見積もるというより、予算枠内で収まるように開発を進めるってことで、成果物の全体像も曖昧なままで、全ステークホルダーに同意してもらわないといけないわけです。こうなると、「説得」ではなく、「信頼」をベースに話を進めなければいけないので、長年付き合ってきたお客さんならともかく、新規では難しいでしょうね。
ソーシャル時代の開発スタイルっぽくはありますけども。
▼アジャイル開発の大前提
とはいいつつも、最近では、IBMさんなどもアジャイル、アジャイル言うとりまして、いわゆるエンタープライズ系のITベンダーさんも本格的にアジャイル開発を取り入れようとしていらっしゃるようなのです。
アジャイル開発を支援するソリューションプロダクトのセールスのためにセミナーなんかも積極的に開いてます。（参考 http://www-06.ibm.com/software/jp/rational/agile/）
IBM Innovate2012
実際、10月にIBM Rational Innovate 2012というセミナーが開催されてまして、私も参加してきました。
中でも日本IBMソフトウェア開発研究所のマネージング・コンサルタントである藤井 智弘さんのセッションがとても印象的でした。
今回、彼のセッションからインスパイアされて開発プロセスについて思うところがあったので、諸々の定義はさておき、アジャイル開発の本質に主眼を絞って、スタートアップにおける最適な開発プロセスについてちょっと考えてみたいと思います。
アジャイル開発で最も大切なこと、それは、、、
方向性の共有
藤井さんもおっしゃってましたが、これ、これがどれくらい出来ているかがとても大切なんです。
開発者同士は当然ながら、利用者のニーズとシステム要件が合ってるかどうか、そこが最大の問題なので、ステークホルダーも含めた共有の成否こそ、アジャイル開発の成否を左右していると言っても過言ではないんですよね。
なので、出来るだけ細かい機能に細分化した上で、利用者と開発者が相互にチェックしながら、開発を進めて行く。そうした上で、最終的な仕様をフィックスさせていくわけです。
つまりは、状況に応じて流転するニーズ駆動型開発とも言える開発プロセスなので、当然全体像は最初には決まらない。
だから、業務内容が最初から明確な業務システムなどとは異なり、コンシューマ向けのWEBサービスなどとの相性はとてもいいと思います。Facebookなどのソーシャルメディアも、実際のユーザーの声を聞きながら、次から次へと機能を追加したり、改善したりしているわけですが、最初に答えが決まっているものではない以上、とても理にかなった開発スタイルだと言えます。
▼ドキュメントはいらないのか？
でも、アジャイル開発だからといって、ドキュメントが全くない状態で進めてしまうと、今度は修正したり、新しいメンバーと開発コードを共有したりする場合に困ったことになります。
三菱電機HPより
ドキュメントがないだけではなく、ソースコードにコメントなども書いてない場合が多く、実装した本人ですら何をどうしたのか忘却してしまうなんてことも現場では日常茶飯事です。
だから大抵の場合、アジャイル開発という名を借りた、やっつけ開発になっているだけの現場が多いのではないでしょうか。スタートアップの現場では特に。
全く手探りの状態でプログラミングするのは仕方ないとしても、どんなに実装機能を細分化したとしても、大きな「手戻り」は発生してしまうもの。それを何でもアジャイルっていう魔法の言葉で正当化されても開発者は困っちゃいますよね。
もちろん、アジャイル開発とはニーズ駆動開発ですから、実際の利用者の声を聞いて、戻りつつ改善していくのは当然なんです。だから開発はスパイラル、漸次的に進んでいく。
しかし、それ以前の問題で、ただの手戻りが発生している現場が多いのではないでしょうか。
まともな開発者なら、サービス仕様が変わるのはいいとしても、全体のアーキテクチャまで変わることは許容できないはずです。仕様変更がアーキテクチャにまで影響を及ぼすとすれば、それはそのプロダクトが、仕様はおろか、方向性自体も決まっていないことを意味しているからです。
例えば、ニュースサイトを作っていたはずなのに、突然、画像共有サイトに変更なんて言われても困りますよね。どんな理由があろうとそういう変更は許容できるものではありません。全て一から作り直しになりかねないからです。
なので、方向性、これだけは絶対に共有しなければいけないと同時に、大きく変更してはいけないわけなんですよね。そうでないと、どんな開発プロセスでも破綻するでしょう。方向性をしっかりと共有し、ステークホルダー全員が誤解がないように開発を進めなければいけない。
この大前提がうまく機能してこそのアジャイルなのです。
でも、クライアントやフロントサイドとの共有であれば、プロトタイプベースで問題ないかもしれませんが、開発者間だとそうはいきません。一人で開発しているならともかく、チーム開発の現場では、開発自体の方向性を共有する必要がある以上、プロトタイプベースで共有なんてできるわけがありません。
そう、ドキュメントはステークホルダー間というより、開発メンバー間でこそ必要になるのです。
▼アーキテクチャと「余白」
では、アジャイル開発の現場における最適なドキュメントとはどんなものでしょうか。
一冊、書籍をご紹介しつつ、この中の概念をヒントに考えてみましょう。
『システムアーキテクチャ構築の原理』（ニック・ロザンスキ、イオイン・ウッズ 翔泳社 2008）
システムアーキテクチャ構築の原理
この書籍は、いかにステークホルダーの満足のいくアーキテクチャを構築するか、というプロセスを「ビューポイント」と「アーキテクチャパースペクティブ」という概念を中心的に利用して展開している書籍で、かなり定評のある書籍です。
元来、アーキテクチャというものは、どちらかというと中央集権的で、ウォーターフォール開発と相性がいいと思われがちですが、この書籍の中でもアジャイル開発とアーキテクチャについて次のように述べられています。
「アジャイル手法が集中するのは、有用なソフトウェアを素早く納品し、構築中のまま常にその妥当性を確認することであり、どちらも好ましい結果である。その一方で、問題を徹底的に理解したり、目指す方向を考慮したりせずに大規模開発に着手することは、早期の設計でもっと配慮すれば回避可能だった大量のやり直しにつながりかねない。・・・この手法が奨励する技術的プラクティスは、割合と容易に変更することができる単純で信頼できるソフトウェアを作成しやすくしてくれる。これが悪いわけがない。・・・アーキテクチャは、構築のインクリメントの上にうまく収まり、反復のためのコンテクストを整え、システム全般の統一性と技術的完全性の維持に役立たなければならない」（同書 p.86-87）
もちろん、実装以前に包括的で詳細なドキュメントを提供しようとすれば、アジャイルとは相性は限りなく悪くなります。
要は、構築を中心に据えながらも、方向性を見誤らず、手戻りを抑え、しかも統一的に仕上がっていけばよいわけです。
しかし、最初から完全性を担保するのではなく、それを目指しつつ、しかし状況に応じて改変しつつ進めるのであれば、それにふさわしいドキュメントのあり方が必要となります。
この書籍の中心概念である「ビュー」と「アーキテクチャパースペクティブ」から考えてみましょう。
・ビュー
「ビューとは、一人以上のステークホルダが抱いている一つまたはそれ以上の関心事に、アーキテクチャがどう対応するかを示す、アーキテクチャの一つ以上の構造的側面を表現したものである」（同書 p.30）
・アーキテクチャパースペクティブ
「アーキテクチャパースペクティブとは、多数あるシステムのアーキテクチャビュー全体にわたって熟慮を必要とする、関連した品質特性の特定セットを、システムが提示すると保証するために用いられているアクティビティや戦術および指針の集まりである」（同書 p.39）
使い古された言葉で言えば、「機能要求」と「非機能要求」となるでしょうが、ここでのビューの場合は、システム-機能的な実装レイヤのみならず、運用の件やテストの件なども含まれています。つまり、目当ての機能が欲しい、ちゃんと動いてほしい、落ちないでほしい、セキュアであってほしい、、、などなど、プロダクトに対する数々のニーズです。
パースペクティブとは平たく言えば、そういった様々なビュー（ニーズ）を実現するために必要な周辺的な技術、たとえば高可用性や高パフォーマンス、セキュリティなどの観点です。ニーズを実現するためには、そのニーズを実現するための知識と経験を持ち合わせてなくてはなりませんが、そういった知識や経験をパースペクティブと呼んでいるようです。
つまり、システムの全体像は、ビューとパースペクティブによって決まるので、資料なりプロトタイプなりをステークホルダーと漸次的かつ反復的に握っていけば、システムもまた漸次的かつ反復的にフィックスしていくことになります。
そうなると、アーキテクチャそのものが道標としての役割を果たしていくことになるわけですね。
しかし、アーキテクチャとは全体の仕組みを提供するものでなければいけません。
この書籍にもありますが、アーキテクチャとはそもそも「記述可能なもの」でなければならないからです。（注 アーキテクチャ記述という概念が展開されていますが、今回の主旨とはズレますので、詳しくは書籍をご覧になってください）
となると、アジャイル開発とは矛盾するとは思いませんか？
そう思うのだとすると、やっぱりアーキテクチャというものが静的かつ包括的で詳細なものだという先入観がありますね。
むしろ、アーキテクチャとは極めて簡潔な数々の構成要素（モジュール）によって構成され、そのそれぞれが「余白」を予めデザインしたものでなければならない。
余白とはこの場合、そのモジュールが拡張しうる可能性と方向性を意味しています。
変動するニーズに合わせて開発していくということは、まさに最適な「余白」デザインをアーキテクチャ記述に巧く含めることができるかどうか、その一点だと考えています。
モジュールの可能性、方向性こそが記述されなければならない。そして、この記述こそが、ドキュメントとして反映され、ひいてはシステムとして実現されていくべきでしょう。
▼スタートアップにおける最適な開発プロセスとは？
しかし、スタートアップでこの書籍に書いてあるようなことを全て実行することは現実的ではないし、チーム開発といっても少人数の場合がほとんどだったりします。基本的にアーキテクトとプログラマも兼任のケースがほとんどです。
また、ほとんどの場合が自主サービスでしょうから、いわゆるステークホルダーはそれほど多くはなかったりしますよね。
「失敗から学ぶスタートアップのイメージ作り」より
では、そのような現場において、アジャイル開発を実践していくとすると、具体的にはどういった開発プロセスが最適なのでしょうか？
アジャイルの本質、そして前述の書籍の方法論を踏まえた上で、考えてみたいと思います。
先にアーキテクチャには「余白」が必要で、それこそがドキュメントとして巧く反映されなければならないと言いました。
具体的にはどうすればいいのでしょうか。
端的に言えば、、、
詳細を過剰に詰めず、可能な限り簡潔に記述すること
これです。
最初から完璧を目指すことほど悪しきことはありません。
ドキュメントとは基本的に、実装が仕上がる前段階のフェーズのものですから、ここで詳細に記述してしまうと、システムそのものが固定化され、今後の拡張や修正に耐えられるだけの「余白」をもたなくなってしまいます。
一回納品すれば終わりで、最初に全体像が明確に決まっているプロジェクトであれば、ウォーターフォール型開発で何もかも最初に確定した上で進めればいいのかもしれません。
しかし、たとえ最初にどれだけ厳密に要求定義と詳細設計を経たとしても、実際には実物を見て変わることのほうが多いのではないでしょうか。
受注開発であったとしても同様で、お客さんとはそういうものですよね。
だから、ガチガチのエンタープライズ系であったとしても、アジャイル開発を導入しようという動きは分からないでもないのです。
では、簡潔なドキュメントとして、実際の開発の現場ではどのようなものを用意して実装を進めればいいのでしょうか？
先の書籍の中で、「スコープ」と「シナリオ」という概念に光を当ててみましょう。
この書籍で触れられているスコープとは、簡単に言ってしまえば、いわゆる「ユースケース」のことです。
・ユースケース
「ユースケース（Use Case）とは、ソフトウェア工学やシステム工学でシステム（あるいはシステムのシステム）の機能的要求を把握するための技法である。各ユースケースは、何らかのビジネス目標/機能に関するシナリオでのアクター(actor)と呼ばれるユーザーとシステムのやりとりを描いたものである。ユースケースのアクターはエンドユーザーの場合もあるし、別のシステムの場合もある。ユースケースでは技術専門用語をなるべく使わず、エンドユーザーやそのビジネスの専門家に分かり易い用語を用いる。」（Wikipediaより）
必ずしも、エンジニアがソフトウェア工学を修めているなんてことはないはずなので、使ったことがないだけではなく、言葉すら聞いたこと無いエンジニアも多いかもしれません。
まあ、いわばドラマのプロットのようなものだと思っていただければと思います。
何を作るにしても、全体のイメージがないと作品作りなんてできませんよね。
開発だって同じなんです。
どういった役者がいて、どういったストーリーが展開されて、どこに向かって行くのか。
そのイメージが必要です。
そして、シナリオとは、このドラマの台本と言ってよいでしょう。
・シナリオ
「アーキテクチャシナリオとは、本番環境でシステムが直面する可能性の高い状況に関して明瞭で簡潔な記述に、システムに要求される応答の定義が付けられたものである」（同書 p.119）
こう言ってよければ、開発とは「ドラマトゥルギー（劇作法）」であって、優れたアーキテクトは優れた脚本家でなければなりません。
『太田隆文監督の映画「ストロベリーフィールズ」監督日記』より
スコープ（ユースケース）は、その機能の利用者と実現すべき目的が記述されていなけばいけないし、シナリオはその利用者の場面毎の振る舞い、果たすべき役割が記述されていなければいけません。
シナリオというと、どうしてもテストシナリオのことばかり思い浮かべてしまうかもしれませんが、必ずしもテスト目的だけで利用するのではありません。
先の書籍でも触れられていますが、実装パターンの漏れや矛盾点を発見したり、事前に開発者間の誤解を訂正したりするのに有用だったりします。
それだけではなく、シナリオを想定することで、ユーザーエクスペリエンスなどの問題にも気づき、その改善にも役に立つかもしれません。
それこそ簡潔に、あくまでも実装の手引き、そして機能一覧としてメンバーと共有することを目的として作成すると良いでしょう。
実際のスタートアップの現場に導入するのであれば、ウォーターフォール型開発時に作成するようなガチガチのテスト仕様書を作るのはやめておいたほうがいいですね。
そんなことをやっていたら、全体の目的を見失いかねませんし、そもそもスタートアップにそんな時間も余裕もないでしょうから。
さて、これを踏まえると、スタートアップにおける最適なチーム開発プロセスとはどのようなものになるでしょうか？
最低限のドキュメントとして、このユースケースとシナリオを導入することで、開発の戻りや、実装の矛盾や誤解、そしてバグなどを最低限に抑えることができるのではないかと思われます。
あくまでも一例となりますが、私が直接指揮をとっている事業部では、以下のプロセスを採用しております。（ここでは、参加者を開発メンバーに絞っております。プロジェクトを進めるにあたって、フェーズごとに参加メンバーを特定することはとても「共有する程度」という意味でとても重要になります）
まず、プロダクトの構成要素を可能な限り小さい単位に区切って開発者をアサインすることから開発がスタートします。
1. ユースケースを作成して、画面遷移等を確認しつつ機能全体を設計する。
2. シナリオを作成して、実現すべき機能を整理する。
3. シナリオに沿ってテストしながら実装する。
4. メンバー間で実装をリファクタリングする。
大きくはこの四つのプロセスで開発を進め、ところどころに開発チームでのレビューを差し込みます。
問題がある場合はそれぞれのフェーズに戻りつつ、スパイラルで開発を進めます。いわゆるテストも、シナリオベースなので開発と同時にやってしまいます。大抵の場合、開発一機能がそれだけで完結した機能だったりするので、単体テスト＝結合テストとなります。可能な限りモジュール間が粗結合で独立構造になっているかどうかも、余白をデザインするアーキテクチャにとっては重要なことです。
また、4番目のリファクタリングは特に大切で、コード整理による共通化だけではなく、コメントが正しいか、嘘になってないかなどもチェックしています。他人のコードを触ることほど難儀なものはなく、そうなった場合にコメントに嘘があると本当に混乱しますからね。ちゃんと整理していくことで、プロジェクト全体は、たとえ初速に時間がかかっても、ロケットエンジンのようにみるみる加速していきます。
・リファクタリング
「リファクタリング (refactoring) とはコンピュータプログラミングにおいて、プログラムの外部から見た動作を変えずにソースコードの内部構造を整理すること。いくつかのリファクタリング手法の総称としても使われる。・・・リファクタリングはオブジェクト指向設計と深くかかわっている。リファクタリングのほとんどはオブジェクト指向の性質に沿ったものであり、オブジェクト指向のコードの再利用性を最大限に引き出すことができる。オブジェクト指向プログラミングを行える言語であれば、プログラミング言語の種類にかかわらずリファクタリングを適用できる。リファクタリングを行うことで、開発が停滞してしまうのではないか、という心配をされることも多い。リファクタリングを行っている間は、何の機能追加も行われない。しかしたいていの場合は、設計が向上することで機能追加やバグフィックスをしやすくなり、開発のスピードは安定するばかりか、速くなることもある。また、すでに機能しているコードを危険に晒すべきでない、とする意見もあるが、手順を守りテストを十分に行えばある程度危険を減らすことができる。」（Wikipediaより）
アジャイル開発では、とにかく方向性の共有が大切で、関係者（この場合は開発者）は全員参加が基本です。ユースケースとシナリオといった最低限のドキュメントを用意することで、アーキテクチャの漸次的な洗練、戻りやブレの抑制はもとより、以後カスタマイズなどがあった場合も再検討しやすくなるでしょう。
ドキュメントを作り出すと、とかく猥雑になりがちで、しかもいつの間にかそれ自体が目的になってしまうことがありますが、あくまでも特定のメンバーとの共有目的で作成していけば、ドキュメント作成が形骸化することはないと思います。
自主サービス開発だと、どうしても自分たちだけの裁量となってしまいますから、ドキュメントはおろか、初回設計もいい加減。
作れば作るほど、コードは迷宮状態になり、気づいた頃にはもはや手遅れで、一から作り直さないとどうにもならない状態になる。
スタートアップを経験されたことのある方であれば、そんな場面に遭遇された方は多いのではないでしょうか。
たとえ少人数の自主サービス開発の現場であっても、最低限のドキュメントを用意することは有効だと思います。
一人で作ってしまう場合でも、ドキュメントをベースにしてアーキテクチャの方向性をブラさずに実装していれば、チームを増やし、開発メンバーをスケールすることがとてもスムーズになります。
▼結論
皆さんはどういった開発プロセスで開発されてますでしょうか？
一般に出回っている方法論だとスタートアップには大掛かりで複雑すぎるし、いきなり実装スタートではやっぱり後で痛い目を見るケースはとても多い。
なので、アジャイル開発の本質をちゃんと踏まえた上で、自分たちの現場に最適な開発プロセスを実践していくことをオススメします。
スタートアップだからといって、最初期のプロダクトは作り直すことが常識だなんて思わないようにしましょう。アーキテクチャを作り直すことなく、そのままスケールできるようにすることが、遠視眼的には最もローコストで、ちゃんと資産化されていくことになります。
方法論に縛られず、問題の本質を見据えて臨機応変に対応すること、それこそが開発に限らず、すべての業種の極意ではないでしょうか。
方法論を適用するのを目的にするのではなく、問題を解決する為に方法論を利用しましょうね。
そうして育まれた開発プロセスこそが、あなたの現場にとっての最善の開発プロセスとなるでしょう。
