読者です 読者をやめる 読者になる 読者になる

カイゼンにっき。

@hyokota です。主にtwitterに呟いていますが、twitterに書ききれない事をここに綴って行こうかと。

私がアジャイル崇拝をやめてウォーターフォールを愛するようになった7つの理由

アジャイルがダメだと思う7つの理由 - arclamp
にインスパイアされて、自分なりの考えをまとめてみました。一部SI前提で書いています。

制作(および詳細設計・結合テスト)フェーズの全体スケジュールを見通しやすい

確かに、全体スケジュールの完全なコミットメントは不可能です。しかし、少なくとも、信頼性の高い見通しは必要です。そもそも予算が下りません。顧客側組織の予算編成・執行体制を変えるべきだ、何て寝言を言えるはずもありませんし、見通しもなしに予算を出すべきだとも思えません。

ウォーターフォール型の開発プロセスでは、開発プロジェクトの大部分を占める制作(および詳細設計・結合テスト)フェーズの全体スケジュールを、先行する計画・設計のフェーズでじっくりと吟味します。

ウォーターフォール型の開発プロセスは、問題があった時に調整が効かないかのように言われています。しかし、ウォーターフォールにはフェーズゲートがあります。想定よりも制作が難しいようであれば、単に制作フェーズに進まなければよいだけです。もし技術的な不確定要素があるならば、設計フェーズにおいて「スパイク」を行ったり「重要なユースケースを1, 2個実装」したりすればよいはずです。

アジャイルな開発では、実際に数イテレーション回した結果としてのベロシティと、リリースまでに実現したいストーリーポイントの総計を元に、全体スケジュールを立てる形かと思われます。しかし、ベロシティは所詮「まだ作っていないフィーチャ」とは直接関係のない実績にすぎません。作っていないフィーチャについては、まだ大した設計すら行っていないのです。想定していなかった技術的な困難が存在しない保証は、どこにもありません。

必要充分なアーキテクチャを吟味できる

システム全体の段階的詳細化を繰り返せば、必要充分なアーキテクチャを構築することが可能となります。必要以上に緻密でもなければ、YAGNIと無責任に叫んで、明らかに必要な部分を後回しにするわけでもありません。

アジャイル型の開発では、アーキテクチャを充分に吟味する前にいくつかのフィーチャを構築しがちです。これらは後々技術的な「sunk cost」となり、最適なアーキテクチャの実現を妨げる可能性があります。

もし実際に実装を行ってみないとアーキテクチャの妥当性が分からないのであれば、事前にコアドメインだけを実装してみる、などの手段もとれるはずです。

ステークホルダ間の利害関係の調整をじっくり行うことができる

ステークホルダ間の利害関係の調整は、非常に重要かつコストも高く、失敗しやすいポイントです。じっくりと調整し、明文化し、何度も推敲と議論を重ね、全体のコンセンサスを得る必要があります。そして、そのコストの高さから、何度も行うのは得策とは言えません。

アジャイルな開発では、この困難な部分を、お金を支払う顧客(PO)に一任し、短いタイムボックス毎のアップデートを要求します。「ステークホルダ間の利害関係の調整」を「(例えば)2週間おきに」「顧客が」行う。これは現実的とは思えません。

開発チーム側に顧客プロキシを立てる、といった代替案もありますが、社外の人間が利害関係の調整を行うと、ますます調整のコストは高くなります(というより、大抵は不可能ではないでしょうか)。

責任の分担・階層化ができる

システムの全体が見通せて、必要な仕様が決まっていれば、適当な単位で各チームに責任を分担出来ます。問題が発生した場合も、どのチームが何をすべきか/すべきだったかは明確です。また、これによりオフショア・ニアショア開発が可能になります。これは大きなメリットと言えるでしょう。

特に大規模な開発では、このような分担なしには、プロジェクトのカオス化を防ぐ事は困難です。「自己組織化チーム」の集合では、プロジェクト全体として上手く回っているかどうかは、誰が担保するのでしょうか。プロジェクトリーダーでしょうか。各チームに自律的に行動してもらっているのに、どうやって担保するのでしょうか。カオスに陥りそうです。うまく回るイメージがわきません。

出来る人もいるのかもしれません。しかし少なくとも、自分がこのプロジェクトリーダーになると思うと、胃に穴が開きそうです。

並列度を高めることができ、完成された製品を素早く提供できる

前項と関連しますが、分担出来れば開発の並列度を上げることができます。これにより、完成した製品をいち早く顧客に提供することが出来ます。

※もちろんチームが増えるほど複雑度は増すので、CIや全体での定例mtgなどは必要で、線形オーダで効率が上がる事はないでしょう。

よく言うアジャイル型開発の「迅速なデリバリー」は、全体の一部分のデリバリーに過ぎません。エンタープライズなシステムは、一部分だけでは利用価値がない場合がほとんどです。また一部分だけを先行導入してしまうと、後々データ移行等が苦しくなります。そもそも、先行導入したシステムの運用は誰が行うのでしょうか。その後、インクリメントがリリースされるたび、運用方法が変わって行くのでしょうか。

リーンスタートアップのbuild-measure-learnのループを回す、という話もあります。しかし、エンタープライズなシステムで、短いループで「システムの価値」を継続的に検証していく必要があるのでしょうか。事前の検証で十分な場合の方が多いのではないでしょうか。

洗練された形式知が手に入る

ウォーターフォールのフェーズゲートは、ほとんどの場合「形式知(大抵は仕様書などのドキュメント)」を要求します。フェーズゲートをくぐりぬけるうち、これらの形式知は何度もレビューされ、洗練されていきます。

「洗練された形式知」の存在は、人やベンダーを交換可能にします。これは属人性・べンダーロックインの問題を解決します。また、プロジェクト毎にこのような「洗練された形式知」が生成されることは、標準化の実現や、ノウハウ・ベストプラクティスの蓄積など、組織としての成長を支援します。

アジャイル型の開発では、知見はチームメンバーの中に暗黙知として蓄積します。確かに暗黙知形式知よりも「帯域幅」が広く、近視眼的には効率もよいです。しかし、上記の理由から、大抵のSIerでは「洗練された形式知」を選ぶのではないでしょうか。

というより、大抵のSIerには既にこのようなノウハウが蓄積されています。これらを放り投げてまで、新しい開発手法を適用するほどの価値があるのでしょうか。

専門分野の単位で作業分担ができる

アジャイル型の開発を行うのであれば、開発チームはユースケース単位(あるいはストーリーでもフィーチャーでも呼び方は何でもよいです)で開発することが必須といえます。よって、コンウェイの法則から、チームは職能横断型であることが望ましい、という結論が導かれます。

しかし、職能横断型のチームというのは、基本的に組織として管理しづらいです。メンバーが抜けたらどう補充するのでしょうか。それに、薄く広く知っている開発者よりスペシャリストの方が、ある特定分野では明らかに技量が上です。こういったスペシャリストの個性を活かすことこそが、組織の強みにつながるのではないでしょうか。

追伸

はてなブログに若干悪戯されましたが、本日は4月1日です。私の中に新しいペルソナを生み出して記事を記述してみました。とはいえ、(若干知ったかぶり感はあるものの)内容は真面目に書いています。