中止する勇気

メソドロジに書かれているべきこととして、中止の原則がある。
中止という判断を明示していないメソドロジは開発手順でしかなく、メソドロジに昇華されていない駄文である。

　プロジェクトの選択肢が続行しか無いのはおかしい。

実際には、プロジェクトのスタートは小人数で可能性を検証しているはずであり、メソドロジはそれについても触れている必要がある。
ただし、SIベンダが持っている開発手順にはそこが無い。
プロジェクト立上げの前の事前準備、個人的には前始末と呼んでいるが、準備段階についての理解が無い開発手順は進めることしか考えさせない。

　進めることしかないことは、危険な状況である。
　中止するという選択肢を持つことで、設計は幅を持ち、活きる。

必要の無いシステム、過度の機能を備えたシステム、無駄なシステムを作らなくて済ませられるのは、止めても良い、そんな選択肢を知っていることから提案できる。
ユーザに接する時はいつも提案活動であり、無駄な投資をさせないことを信条としているならば、止めましょう、という提案ができるはずである。

プロジェクト駆動エンジン

開発標準に最初に触れたのは、某メーカ系ソフトハウスだったが、工程とそこにおける成果物の作成方法の羅列であり、スキルセットの変遷とか、成果物継承の概念が見えなかった。
これを押し付けられては、SEも「メソドロジ」は嫌いになるしかないだろう。

今でこそ開発手順、メソドロジにより、メンバにもゴールが示されるのが一般的になってきているが、まだまだ活用されていないのがメソドロジの現状である。
大規模開発だけではなく、小規模な開発にもメソドロジを用いることは、リスクヘッジでもあり、品質担保でもあり、大切なことなのである。
首尾一貫した考えがそこにあるのだから、それを上手く利用すれば良い。