プロセスを正しく理解していますか？

ひとりでは作れない

ソフトウエア開発を楽しんでいますか？ひとりでコツコツ作っているのが楽しい。他の人と一緒にわいわいと作っているのが楽しい。人それぞれかと思います。いずれにしろ、仕事で作るソフトウエアの多くはひとりでは作ません。好き嫌いに関係なく、何らかのチームに所属して仕事をしていることでしょう。

チームで仕事をしていると困ることがでてきます。図1に要点をまとめました。

一つは「情報の共有」です。情報とは、要求、設計、課題、ノウハウ、計画、進捗などを指します。チームの人数が増えるに従って、情報の共有が難しくなります。難しくなる理由の一つとしては、人の個性が関係します。価値基準、物事のとらえ方、理解の仕方、得手/不得手、好き/嫌いなど様々なことが違います。そのため、作成した文書やコードは作成した当人以外にとっては理解が難しいものです。他人の作成した文書やコードを見て「なんでこんなに分かりづらく書くんだ？」と疑問に思ったことはないでしょうか。自分の作成した文書やコードも他人から同じように思われているかもしれません。

次に、「品質の確保」があります。雑に大胆に仕事をする人がいれば、細かく丁寧に仕事をする人がいます。すると、同じ仕事をしたとしても完成した成果物の品質はまちまちです。しかし、製品として品質を確保したいわけです。どうしたものでしょう。

さらに、プロジェクトの「進捗の把握」が困難になります。ここでも個性が影響してきます。余裕を持って進捗を答える人がいれば、希望的観測で答える人もいます。これでは、プロジェクトが順調に進んでいるのか分かりません。もし順調に進んでいないなら、何らかの手を打たなければなりません。収入より支出が多くなってしまえば生活できなくなります。これは個人でもプロジェクトでも同じです。プロジェクトが終了した時点で「収入より支出が多くなってました」では困ります。個人の話で例えるなら「好き勝手に生きていたら借金まみれになった」と言うのと同じことです。そうならないためにもプロジェクトの進捗を把握したいのです。

これらの問題を大きくする要因として、“人数”と“個性”が挙げられます。人数が増えれば困難さは増し、チームメンバが個性的であれば困難さはさらに増します。

開発プロセス定義 〜標準による統一

チームで仕事をする時に発生する問題を解決するために「標準を定めて統一しよう」という考え方が生まれました。作成する成果物の形式や内容を定めることで、誰が作っても同程度の品質を確保できるようにし、情報の共有を容易にしようと考えました。また、タスク（仕事の単位）とタスクの順序を統一することで進捗を把握しようと考えました。言い換えると、「誰が」「いつ」「何をして」「何を作るのか」を定めることで解決しようと考えたわけです。そして、これらを定めて整理したものを開発プロセス定義と呼びます。すなわち、プロセスとは「誰が」「いつ」「何をして」「何を作るのか」という過程（仕事の流れ）そのものを指します。

開発プロセス定義により標準化するという試みが、効果的に機能していることもあれば、効果的に機能していないこともあります。効果的に機能している場合には、本来意図していたことが達成できます。しかし、効果的に機能しない場合には、プロセス定義の意図がチームメンバに理解されず形式的にだけ実行され、結果的に無意味な仕事が増えています。また、プロセス定義がプロジェクトの性質とは合致せず、期待した効果が得られないということも起きています。プロセス定義がチームメンバの個性と合致せず、プロセス定義が足かせとなってチームメンバの進行を妨げてしまうこともあります。

開発プロセスを標準化する試みでは、プロジェクトの目標（品質、予算、期間）を達成するために個性を消していく傾向にあります。管理の手間を減らすには個性を消して数字で管理できるようにするのが効率的です。しかし、管理が効率的になる一方でチームの生産性は低下し、プロジェクトの目標を達成することは叶わずにいます。