分散開発とアジャイル開発は、水と油か？

コンプライアンス＆プロセス

　昨今は、各種の法規制や標準への対応が開発組織にも求められています。ちょっと前までは日本版SOX法、純粋に技術的にはCMMI、最近では工事進行基準あたりがホットなキーワードではないでしょうか？従来、開発組織がフォーカスしていた生産性や品質向上とは別の観点ですが、これらはシステム開発をビジネスとする以上避けて通ることはできません。

　問題なのは、これらのルールの多くが、ウォーターフォール型プロセスを暗黙の前提に定義されているかのように見えるか、あるいはそれを運用する側の認識が新しい技術に対応できていないということです。残念ながら、「認知はされても定着したとは言いがたい」のが、日本におけるアジャイルな開発スタイルの現実です。私たちは、アジャイルのメリットを損なわないようにしながら、この“ビジネス上の要求”にも同時に答えられるよう、微調整を続けていかねばなりません。

　また、開発標準を運用する組織では、規定されたルールが明文化されている、というだけでは終わりません。「品質保証部」といった類の部門が、開発標準に準じて作業が行われているか、出荷するに十分な品質であるか？などをチェックするようなプロセスが同時に運用されている場合が多くあります。

　この、「すでに実績があり、安定的に運用され、一定レベルの成果を出し続けているプロセスやポリシー」を相手に、新しい開発スタイルを導入するのは、かなり骨の折れる仕事です。筆者たちがお客さまの開発標準策定のお手伝いをする際には、この種のプロセスやポリシーの運用がどの程度柔軟か、その度合いを指して「お客さまの文化」と呼ぶことがあります。

作業グループ＆ガバナンス

　プロジェクトの人数が多くなったり、オフショアなどで他社との協業が増えてくれば、作業グループの構成も重要な考慮すべきポイントとなります。各作業グループのメンバーが持つ技能の特殊性や、自社の社員か否かによって異なる「アクセスできる情報の範囲」が、各グループの役割や責任を規定することになります。

　筆者は仕事柄、品質向上のために何をするか？を、お客さまと議論する機会が多いのですが、最近多くの組織で判を押したように挙げられるのが、「開発の見える化」です。これは裏を返せば、「自分たちはプロジェクトの状況を逐一把握できていない」という不安感の表れであり、「見えれば対処できる」という思いの表れと言えます。この方々と話を続けていくと、トップダウンのプロジェクト運営を品質向上の決め手と考えておられるように見受けられます。ここで言う、“トップダウンのプロジェクト運営”とは、「詳細な手順を決めて予定と実績との差をにらみつつ、問題があれば“解決者”として管理者がチームにどんどん首を突っ込んで手を出していく」というイメージです。

　それに対して、アジャイルは現場に多くの権限を委譲し、裁量をゆだねます。このように、ガバナンスのモデルの違いが、アジャイルなスタイルに対する不安感を醸成しているように思います。