« 開発案件の「適正サイズ」を考える | トップページ | 「仕様の的確さ」と「アプリ品質」のバランスをはかる »

2016.07.29

アジャイルではなく「プロトタイピング」を

◆ボトルネックは「的確な仕様」の確立

 業務システム開発の一般的なボトルネックは、プログラミングやテストやプロジェクト管理ではなく、「的確な仕様を確立すること」にある。どんなに優れたプログラマやPMを起用しようと、的外れな仕様のまま突っ走ってはクタビレ儲けにしかならない。反対に仕様が的確でありさえすれば、プログラミングやプロジェクト管理に問題があっても、立て直せる可能性はずっと高い。

 それなら優れた設計スキルを持つ要員を起用すれば安泰かというと、話はそれほど単純ではない。まずは、クライアントによってシステム要件がクリアに表明される必要がある。それを手がかりにして整合性のあるシステム仕様を創案することは簡単ではないが、この後にさらに困難な過程が続く。「クライアントがその仕様を理解し、妥当性を評価すること」だ。けっきょく、優れた設計スキルといえども、的確な仕様を確立するための必要条件ではあるが十分条件ではない。以下の手順が確実に遂行されることでしか、仕様の適切さは担保されない。

(1)クライアントによる要件の表明
(2)開発者による整合的仕様の創案
(3)クライアントによる仕様の評価

 これらを着実にこなすためにはどうしたらいいのだろう。ヒントは、業務システムが「一品モノ」の注文生産品である点にある。しかもそれは「自転車」程度ではなく「惑星探査機」のような、多数の部品が統合された「誰も見たことがない複雑で大規模な一品モノ」である。そういうものが現実にどのように開発されているかを想像してみればよい。

 他でもない。その種の構築物は「プロトタイピング手法」で開発される。設計し、これにもとづく試作品を作って検証し、その結果を設計にフィードバックする――それを何度も繰り返すのである。

 このやり方は「アジャイル手法」ではないかと思われるかもしれないが、両者は似て非なるものだ。違いは「全体の扱い方」と「モデルの位置づけ」にある。それぞれを検討しよう。

◆「常に全体を扱う」ということ

 アジャイル手法では最初の計画段階で、システム要件をざっくりまとめたうえで、開発範囲をいくつかに分割してリリース計画を立てる。分割された単位で設計と試作とレビューが繰り返され(イテレーション)、最終的に全体が出来上がる。いっぽうのプロトタイピング手法では、最初から最後まで「全体」が同時に扱われる。「全体の設計とレビュー」が繰り返され、つづいて「全体の試作とレビュー」が繰り返される(図1)。

▽図1.進め方の違い(色の濃さは仕様の的確さの度合い)
20160724a

 図中で色の濃さ(仕様の的確さ)が向上してゆく様子に注意してほしい。「動作するソフトウエア」を用いて仕様の的確さを向上させようとする点で両者は似ている。しかし、1回のイテレーションで用意される「動作するソフトウエアの大きさ」が違っている。アジャイル手法では「一部」で、プロトタイピング手法では「いくつかのサブシステムを含む全体」である。

 自転車や単純なソフトウエアであれば、アジャイル手法でも通用するだろう。全体をざっくりとスケッチしたうえで、いくつかの部分に分割して設計と実装を繰り返せば、最終的にはうまくまとまりそうだ(そもそもじゅうぶんに小さければ、分割せずに進めることも可能だろう)。

 しかし、惑星探査機や、複雑なDBを核とする業務システムが相手では通用しない。なぜか。図で示したように、数回のイテレーションでブロック毎の仕様の的確さが確保されたとしても、最終的に各ブロックをうまく統合できるかどうかわからないからだ。つまりアジャイルの問題は、「良き部分の集積が良き全体になる」という誤った信念(合成の誤謬)にある。結果的に、アジャイルプロジェクトはしばしば、設計と実装を何度繰り返しても全体としてうまく統合されない「終わりなきイテレーション」に陥る。うまくいったとすれば、最初から最後まで「全体を俯瞰する目」が行き届いているはずなのだが、それは口で言うほど簡単なことではない。

 ではなぜアジャイルでは、開発単位を小さなブロックに切り出そうとするのか。それが「短期間(2週間前後)でプログラミング可能なサイズ」だからだ。アジャイル手法はプログラマのコミュニティで発展したもので、その感情的基礎は「プログラミングの喜び」や「チーム開発の楽しさ」にある。私はプログラマなのでそこらへんを共感できないわけでもないが、残念ながらプログラミングの一本槍では生産性が悪すぎる。結果的に開発単位を分割して、多人数で手分けする羽目にもなる。

 いっぽうのプロトタイピング手法で常に「全体」を扱えるのは、実装技術が発展したおかげだ。テーブル数50本程度のシステムであれば、ドメイン特化基盤(超高速開発ツール)を使えばプロトタイプを1~2週間で用意できる。これにリアルなデータを登録してレビューし、その結果をモデルとプロトタイプに反映させる。その過程には部分的なプログラミング作業が含まれるので「プログラミングの喜び」はあるが、ひとり(またはごく少数)で進めるので「チーム開発の楽しさ」はない。基調となる感情は「自分で構想したモノを自分で作って、それが誰かの役に立つ喜び」である。

 思うに、アジャイル手法は「プログラミングの喜び」に縛られているのではないだろうか。実装技術の発展にともなって、(狭義の)プログラミングの必要性は自然に減ってゆく。代わって重要度を増すのは計画やモデリングだ。ところがそのような趨勢を力説しても、アジャイル手法に惹かれている「とっととプログラミングしてしまいたい技術者」の耳にはなかなか届かない。そのことが結果的に、手法が扱えるソフトウエアの規模や複雑さの上限を規定してはいないか。そうであれば残念なことだ。

◆「モデル駆動」であること

 じっさい、プロトタイピング手法が「モデル駆動」である点も、実装技術が発展した結果である。レビューされたデータモデルや機能モデルが手元にあるからこそ、プロトタイピングの効果が上がる。それは、作るべきモノの全体像が明らかであるだけでなく、モデルを修正すればプロトタイプの動作がダイレクトに変化するからだ。まさにモデルと実装が表裏一体になっている。だからこそ、的外れなモデルが的外れであることがアカラサマになる。

 ただし、プロトタイピングによってモデルが的外れであることを「確認」するのは簡単だが、的確かつ全体がうまく統合されたモデルを「創案」するのは簡単ではない。図2のグラフは、この手法で「仕様の的確さ」がどのように向上してゆくかを概念的に示したものだが、初期段階でじゅうぶんレベルアップされていなければいけない。そのため、実践者には優れたモデリングスキルが求められる。そしてプロトタイピングは、モデリングの稚拙さを補うものではなく、的確なモデルをさらに良いものに仕上げるための「ダメ押し」だ。

▽図2.「仕様の的確さ」が向上する過程
20160724b

 つまり、最終段階のプロトタイプは、的確なモデルが確立された後に残った「出汁ガラ」のような副産物でしかない。プロトタイピングが完成させようとしているものは「動作するソフトウエア」ではなく、「動作検証されたモデル(的確な仕様)」なのである。いったんそれが出来上がれば、本番システムを「出汁ガラ」から仕上げてもいいし、モデルにもとづいてあらためて開発してもよい。進め方はアジャイルでもウォーターフォールでも何でもよい。システム開発のボトルネックである「的確な仕様」が既に確立されているからだ。

 なお、この手法に対して、「誰がやるかによって、出来上がりに違いが出そうだ」という意見があるかもしれないが、批判であれば的外れである。業務システムというものが「誰も見たことがない複雑で大規模な一品モノ」であるからには、起用される開発者によって出来上がりが違って当然だ。その違いは、モデリングスキルの巧拙によって生じるだけでなく、じゅうぶんに訓練されている開発者同士でも生じ得る。同じ要件でもコルビジエとライトの仕事が違ってくるのと同じ話だ。

 実案件で著しい効果を上げているこの新しい手法の勉強会を、2016/08/12(金)に大阪で開催する。拙作のOSS製品を設計・実装ツールとして用いながら進めるが、他のツールを使った場合にも応用できる。的確な仕様を効果的に探れるだけでなく、桁違いの生産性を叩きだせるという事実を、自分の目で確認してほしい。何よりも「自分で構想したモノを自分で作って、それが誰かの役に立つ喜び」の一端を味わってほしい。お盆シーズンで暑いだろうから、勉強会の後は皆で暑気払いのビールを味わう必要もありそうだ。

|

« 開発案件の「適正サイズ」を考える | トップページ | 「仕様の的確さ」と「アプリ品質」のバランスをはかる »

コメント

いつも勉強させて頂いております。
「アジャイル開発と言っても色々ある」で結論ついてしまうのですが、例として挙げられております、イテレーションごとに部品開発を行い最後に結合するというアジャイル開発はあまり見た事ありません。
プロトタイプ開発と記されている方が、知っているアジャイル開発に近いです。

論点の主軸については大いに賛同なのですが、読み手によっては、その主軸がズレてしまうかなと思いコメントさせて頂きました。

投稿: Kawakawa | 2016.07.29 11:15

規模がじゅうぶんに小さければ、全体をイテレーションできるでしょうから、どんな案件でもプロトタイピングっぽくなりそうですね。テーブル50本以上では、アジャイルではブロック別に扱わざるを得ないと思います。Kawakawaさんが目撃した案件はどんな規模だったのでしょうか。

投稿: わたなべ | 2016.07.29 16:24

長らく返信できぬご無礼申し訳ありません。
先日直接お話しさせて頂いた事で回答済みと思っておりましたが、サイトご覧の方には知りえぬ話であり当コメント欄でも返信すべきでした。

私が実際に見た案件は2件。両方ともテーブル数50以下、6人月ほどで小規模の開発となります。
規模が大きい場合、全体をイテレーション出来るかのご指摘に対しては、ご指摘通りアジャイルでもブロック単位ででの開発になると思います。

しかし本質は、どうブロック分けするのか、どの程度の完成度でブロック同士を連結していくのが問題であり、それはプロトタイピング手法と同様と考えております。

投稿: Kawakawa | 2016.09.12 01:47

コメントを書く



(ウェブ上には掲載しません)




トラックバック


この記事へのトラックバック一覧です: アジャイルではなく「プロトタイピング」を:

« 開発案件の「適正サイズ」を考える | トップページ | 「仕様の的確さ」と「アプリ品質」のバランスをはかる »