プロジェクトマネージメント特性比較 シミュレーション比較 総括

　Table 44 は、それぞれのシミュレーションの結果のシステムとトラブルを示したものである。5か月後はアジャイル型がシステム開発数が多く、20か月後は PDM のレベルが低い場合を除いてウォーターフォール型のシステム開発数が多くなる。（ただし、その PDM が低い場合も、28か月後にはウォータフォール型がアジャイル型のシステム数を抜く。）

　開発一つ一つを見ると、アジャイル型は早期に開発出来るが、開発にはバグがつきものであり、開発は一回で終わらず長く続く。そういった前提から考えると、ウォーターフォール型が安定して開発を継続でき、これらの特徴を把握したうえで開発スタイルの選択を行う必要がある。つまり、開発システムが短期的で開発すれば終わるというプロジェクトである、もしくはトラブルが出ないプロジェクトであるという想定であれば、アジャイル型が選択肢となる。一方で、長く運営しトラブルも起きる想定であればウォーターフォール型が選択肢になる。また、PDM、Arc、Dev、QAのレベルのどれかが下がった際の影響を比較すると QAのレベルが下がった際に最もシステム開発に影響が出ることが分かった。このことは、欠陥比率の表にもその結果が表れている。(Figure 42 )

　Figure 43 は、これらのシミュレーションを一歩進め PDM、Architect、Dev、QA のレベルはそのまま PDM、Architect、Devの作業のリズムを合わせることでアジャイル型が飛躍的にシステム開発が伸びることが分かる。シミュレーション上変更したのは、Equation 7、Equation 8 のようにTest1、Test2、Test3 の全部が揃った時にシステム開発が進む設定をどれかのリズムに合わせるという設定に変えた。これは、実際には開発のどこかでも前に進んだらそれに他の組織も合わせるという前提に基づいたものである。このような事を実際の開発プロジェクトで行うことが出来れば、並行して開発が可能となるため、アジャイル型の開発速度は非常に早くなる。それを最大限行える取り組みが看板方式やスクラム方式である。しかしながら、実際に開発のリズム取りは難しく、遅い箇所に合わせるため変更前の設定が現実的ではある。ここにアジャイル型の難しさと改善を重ねて開発速度を速められる可能性がある。

　また、もう一つの改善としてトラブル対策を行うオペレーションを開発から分離する方法がある。そこで、トラブルがなかった場合を仮定して観察した (Figure 44)。この場合も、アジャイル型の方がウォーターフォール型よりも20か月までは完成するシステム数が多いことが分かる。システム全体の理解、組織の人材、効率性を考えて、Dev-Ops と言われるような開発とオペレーションを一緒にする方法が議論されているがシステムの開発効率性だけを見るのであれば開発とオペレーションを分割する事が効果的ではある。

　次回からは、実際の開発現場で何が起きているかを見るためにブロックボールゲームを使用した実験を行う