改善型開発のメリット(^-^)

以前参加しているプロジェクトは、管理体系は厳然たるウォーターフォール型であった。きっちり予定をたて、その予定通り進むのが仕事だと信じている人たちが管理しているプロジェクトである。予測できない未来を予測し、日々沸き起こる新たな問題をどのように管理体系に盛り込むかを悩む時間を強要し、問題が起きるたびにその問題対処予定と方針が決まっているかどうか、それが予定を崩すことになるかどうかだけを管理することに使命を燃やす人が管理しているプロジェクトである。

いまさらながら、こんなプロジェクトがあるというのは驚きである。自分は厳然たる管理が生み出すムダが大きな足かせとなるプロジェクトをたくさん見てきたし経験してきた。そんななか、繰り返し型開発がかなり世の中には浸透し、リスク回避を試みているプロジェクトが多く存在すると思っていた。が、このプロジェクトは厳しく管理すればすべてがうまくいくと信じている人たが権限を振り回し、回りに迷惑をかけムダを助長しながら進めているプロジェクトである。

自分の直属のマネージャはアジャイルに造詣が深い人ではあるが、その管理体系を変えることを試みることはしていない。というかできないのであろう。巨大な企業の品質管理体系の中に組み込まれ、それを遵守することがプロジェクトの評価につながるとしか判断されない状況の中では、急に繰り返し型を採用することはかなり難しい、と思っているのだろう。私も、規律で縛りつけた管理体系がプロジェクトを成功に導くと信じきっている多くの年配者たちを説得し、繰り返し型を採用させることはおそらくできないだろう。この日記でもよく書いていたが、人から言われたことは(特に年配になると)それだけで拒否反応があり、自分で調べて知った内容なら納得できても、人から言われただけで納得できなくなる人も数多い。自分で気づかない限りおそらく改善はされないだろう。

なので、少しずつ意識の改革を進めてもらうため、こちらも少しずつ繰り返し型開発のメリットを間接的に見せていく、というのが賢いやり方だろう。

なので、まずは機会をうかがい、機会がきたらその時に効果的に相手に響くように内容を伝えていく能力を養うことが今の自分には必要なのだろう。で、最近の私は繰り返し型というよりは改善型開発というほうが、相手に響きやすいのではと感じるようになっている。

そこでまずは繰り返し型と改善型開発に共通する特徴を挙げてみよう。

  • 早い段階でリリースレベルのサービスを提供するため、さまざまな問題を早期に知ることができる。
  • 早い段階で動くソフトウエアを確認することができるため、顧客も要求が実現できているかを早期に確認できる。早期に確認できれば、
    • 要求と異なっていれば早めに変更することができる。
    • 要求が正しく実装されていれば、安心する。
    • 要求が正しくても、動くソフトウエアを確認することにより、新たな気づきが起きる場合もある。また要求も早期に変更したくなる場合もあるが、その要求に早く気づき、早く実現することが顧客のビジネス価値を高めることにもなる。
  • 繰り返しを継続することで、進捗予測がより高い精度で行えるようになる。要員計画も立てやすい。
  • 従来型では一部が動かないために、すべてのサービスを提供できない場合も多かった。繰り返し型では一部サービスを除いてもサービス提供ができる。
  • 動くソフトウエアを作り続けることで、メンバのモチベーションの維持、緊張感を継続できる。
  • タイムボックス概念により、集中力も高まる。
  • 開発メンバにスキルがたまりやすい。同じメンバで上流から下流まで担当できる。(コーディング時にプログラマの大量増員、受け入れテストで減員などがおきにくい)
  • 特化したスキルではなく、全体的にシステムを理解しスキルを身につけることができる。たとえば分析者は業務分析しかできない、ということは無く、分析からテストまで一気に行うので、ある程度はアーキテクチャへの理解も深まりやすい。
  • 不測の事態でプロジェクトが中止されてもスキルや資産が残る
  • 何度もテストを流すので、安定したシステムを提供しやすくなる。

もちろん、ウォーターフォールのほうがよい部分もある。特に繰り返し型で気をつけなければいけない点を上げる。

  • リリースレベルまで完成しても、日々改造は行われることを意識しなければいけない。たとえば日次ビルドは必須だし、ドキュメントの修正も必須だ。
  • 終盤になり、想定しない大きな問題がでることもある。(これはどちらにもいえるが、あらかじめ先に分析設計していれば、その時点で早めにわかることができる問題もあるかもしれない。)
  • 機能や実装の修正が発生する場合、テストの修正も必要。テストの自動化や対象範囲が適切でない場合、テストコードの維持に非常なコストがかかる場合がある。テスト範囲、テスト対象、自動化がきちんとできなければいけないが意外とできていないプロジェクトが多い。
  • ウォーターフォールのほうが古い考えの管理者が安心する。また自分の存在価値を見出せる。(逆に言うと、古い考えで新しい考えを拒否してきた管理者は繰り返し型になると不安を助長され、自分がいる場所が無くなり、ストレスを溜め込んでしまう。)

こんな感じだろうか。そしてこれにプラスして改善型開発の特徴を挙げてみよう。

  • 保守になるので、予算が平準化し、システム投資が行いやすくなる。(従来は開発時にドカンとコストがかかり、保守時から維持費が減り、また機能追加や新規開発時にドカンとコストがかかっていた。単なるリースやレンタルと同じように毎月いくらという金額でシステム開発を継続することができる。)
  • 保守のため、毎回リリースする。そのため、顧客も責任と緊張感をもってプロジェクトに参加する可能性が高くなる。
  • 従来の繰り返し型では開発が終了するとメンバーは離散することが多いが、改善型では同じメンバでの継続がしやすいため、効率よく開発をすることができる。
  • 受注側も売り上げ予測が立ちやすく、安定して組織を維持しやすくなる。(安定していれば、教育などにも投資をしやすくなる。)
  • 繰り返し型で陥りやすい落とし穴に落ちにくくなる。(受け入れてストをしないで繰り返すなどのケースは少なくなるはず。)
  • 繰り返し型では、「最後に動けばいいんでしょ。」と考えてしまう人も多かったように思うが、改善型の場合、そのような考えに陥りにくくなる。
  • 同じようにドキュメント作成、維持も同じような緊張感をもち、高いレベルを維持しやすくなる。


しかし、こんなことを考えていても、今のプロジェクトでの実現は非常に難しい。まあ、あせらず少しずつ考えをしんとうさせていくしかないだろうな。