[#TiDD] プロセスアスペクトでプロセス改善

プロセス改善という言葉が普通に使われていますが、そのポイントはどこにあるのでしょうか？私はプロジェクトの実践ノウハウにプロセス改善の本質が隠れていると思います。それをプロセスプログラミングに当てはめるなら、クラスである標準プロセスではなく標準プロセスで記述しきれないクロスカッティングコンサーン(横断的関心事)であるプロセスのアスペクト(ノウハウ)の蓄積がプロセス改善のポイントだと思うのです。

開発標準に感じる違和感

CMM以降、プロセス改善というと標準プロセスの規律(開発標準)を中心に語られることが多くなりました。標準プロセスの規律とは以下のような考え方に基づくものです。

• 良いプロダクトは良いプロセスから生まれる
• 良いプロセスのメトリクス(測定値)は一定の範囲に収まる
• 基準を満たさないプロジェクトには対策を実施する

このような考えから、標準プロセスではそこで実施すべき作業と共に、合格ラインが定められてその条件を満たすように開発することが求められてきました。これはハンフリー氏が言われるような、訓練によって安定した開発ができるような組織を構築すること、を目指していました。

標準プロセスが実現するのは、作業の漏れの防止と組織の未成熟です。ソフトウェア開発では納期のプレッシャーが強く、品質確保のための作業(たとえばコードレビューなど)を端折ってしまうことを考えてしまいがちです。しかし、そのような作業のショートカットは目先の課題に目をつむって未来のリスクを増大するだけです。

標準プロセスを定めてそのメトリクスの基準を決めることで、端折ることなく作業が実施され、しかもそれが想定された程度の作業であることが確認できます。レビュアーが未熟であったり、チェックリストが整備されていない場合には、メトリクスは合格ラインに達しません。そこで、再レビューの実施などの対策が行われて、プロダクトを一定の品質に保つと共に、求める品質が保たれる組織に成熟するように訓練されるのです。

この方法は、類似のソフトウェアを開発する組織には、とても有効でした。すべてのプロジェクトに品質保証作業が手抜きされることなく、一定の品質で実施されるのですから、組織の底上げが実現できました。また、新しい技術を組織的に導入することも可能で、組織を成熟させることができます。

CMMのブーム以降、多くのプロセス改善の集まりができました。最初は勉強のための情報収集が目的だった企業も、成果を発表することで先人のコメントを得るようになりました。具体的な成果が発表される中で気づいたのは、議論の中心が開発標準ではなかったことです。

そもそも良いプロセスというものが定義できるなら、標準プロセスで定めるべき開発標準の話になったはずです。しかし、標準プロセスをどう広めるか、とか、さらに品質を良くするにはどのように取り組めばよいか、といった人にまつわる話や品質にまつわる技術的な話が議論の中心を占めていました。

インスタンスの個別性

このような違和感は、ソフトウェアプロセスとコンピュータ言語の違いからくるものです。コンピュータ言語であれば、クラスをインスタンス化する際のパラメータは限定的であり、インスタンスごとの違いも限定的です。しかし、実際にプロセスのパラメータともいうべき、対象業務の差、構成メンバーの個人差、集団になった際の特徴の差、は大きなものだからです。

インスタンスの個別性を生むものの最も大きなものは対象業務の差でしょう。それ以外にも、個人の特性のほか、その関係であるコミュニケーション、技術力、そして結果としてのモチベーションです。これらはプロセスのコミュニティでたくさん議論されています。

プロセスをある程度の品質に保つには開発標準は有効でした。しかし、さらにプロセスを改善するには、標準プロセスに表しにくい内容を充実させる必要があります。標準プロセスの開発標準は、プロセスが一定の範囲からはみ出さないようにコントロールするものでした。しかし、その範囲の中でそのように実践するか、より良いプロセスへの方向付けが必要だったのです。

クロスカッティングコンサーン

より良いプロセスへの方向付けは、関心事(コンサーン)ごとに議論されています。プロジェクトファシリテーションやテスト技術などがそれにあたります。

プロジェクトファシリテーション(PF)とはチーム作りhttp://www.objectclub.jp/community/pf/のことです。プロジェクト内のコミュニケーションやモチベーションと言っても良いかもしれません。PFは特定の方法論のものではなく、あらゆるプロジェクトにおいて応用が可能です。

テスト技術というと下流工程だけの議論のようにも聞こえます。しかし、より良いテストを実施して品質の高いソフトウェアを開発するには、プロジェクトの開始時から品質向上に向けての取り組みをしなければなりません。対応する上流工程でテスト設計をするWモデルではもちろんのこと、そうでなくてもプロジェクト計画時にきちんとテストのことを計画しておかないと、品質の向上はできません。

すでに、PFとテスト技術、それぞれにコミュニティがあります。PFがプロジェクト全体を対象とするほか、テスト技術の議論においても、テストの方法論を議論しているように見えて、仕様をどのように分析するかという議論が行われていることもあります。

プロジェクトの成功は、プロジェクトのイメージが描けるかどうかにかかっていると言われています(アジャイル・チャリティイベントの前川さんの発言)。従来の方法では、標準プロセス(クラス)から実際のプロジェクトの計画(インスタンス)を作成する際にテーラリングといわれる開発標準の手直し作業が行われ、その際にイメージできるかが重要でした。

しかし、プロジェクトは生き物であり、メンバーの状況や外部環境の変化によって、様々な対応が必要になります。作業の入れ替えや計画の見直し、など動的に計画を変更する必要が出てくるでしょう。その際にもやはり全体のイメージをきちんと描けるかどうかがプロジェクトの命運を握ります。

このプロジェクトのイメージをきちんと描くということは、プロジェクトの主要な関心事の観点で、すべての工程、すべてのメンバーについて、イメージが描けるということです。

残念ながら主要な関心事で考えられる作業をすべて実施することは困難です。プロジェクトのリソースには限界があるからです。そこで、どこにどの程度注力するかを決める必要がありますが、うまくいくかどうかは関心事の知識に依存します。多くの対処法の知識や経験によって勝敗が決まるのです。

そのような標準プロセスとすることが困難な、従来はノウハウと呼ばれたものを、私はプロセスアスペクトと呼んでいます。工程や作業をまたがる横断的な関心事(クロスカッティングコンサーン)だからです。

チケット駆動開発は複合的なプロセスアスペクト

ここでチケット駆動開発を見てみると、多くのクロスカッティングコンサーンを内包することに気づきます。

チケット駆動開発は

• タスクをBTSのチケットで管理する
• チケットのないコミットを許さない(No Ticket, No Commit!)

という2つのルールによって、プロジェクトをチケット中心に回します。そして構成管理ツールと障害管理ツールが連携することで、チケットを通して作業の結果である成果物の状況を、様々な視点によって確認することができるようになります。

その結果、プロジェクトを通して実現すべき関心事が支援されます。

• タスクマネジメント(計画の動的な変更と進捗管理)
• 見える化(プロジェクト内の情報共有と問題の明確化)
• ツールによる自動化
• 外乱の除去(作業への集中とリズム)

プロセスアスペクトを中心としたプロセス改善

CMMブーム以降、プロセス改善はプロセスのクラスである標準プロセスの整備を中心に進められてきました。その結果、多くの企業で開発標準が整備され、その実践ノウハウがコミュニティで共有されました。そのノウハウは技術的な内容のほか、コミュニケーションやモチベーションなど、工程や作業を横断した様々な関心事です。

このようなプロセスアスペクトに注目して議論をし、ノウハウを蓄積すれば、プロセスの動的な変更を容易にし、柔軟かつ堅牢なプロジェクト運営を可能にします。すでにプロジェクトファシリテーションやテスト技術はコミュニティができており、実績を上げています。今後はチケット駆動開発に関しても多くの議論を通じてノウハウを蓄積していけば、たくさんの実績をあげることができると思っています。