標準プロセスやプロセス改善といったトピックに関しては、話題は尽きないのですが、本連載も要求管理、構成管理の連載同様、第3回をもって完了します。
第2回の「開発プロセスは継続的かつ段階的に改善すべし」では、組織と人、プロセス、技術(ツール)のバランスを取りながら、段階的、継続的に改善していくことでしか成長はあり得ない、ということをお伝えしました。これは、一度でも開発プロセスの定義と実践運用を経験した方であれば、身に染みてお分かりのことだと思います。
今回は、標準プロセス策定をする際には何から始めるか? ということについてお伝えする予定でしたが、少し予定を変更して、どのようにしてこれらの活動を進めていくかについてお伝えしたいと思います。
何かを行う場合には、2つの大きな要素があります。それは、(1)心構え、考え方という“あり方”と(2)方法論、テクニックという“やり方”の2つです。以下、前半部分では主に(1)について述べ、後半部分では主に(2)について述べることにします。実は(1)が非常に重要なのですが、求められるのは(2)ばかりという残念な状況をよく見かけます。この場ですべてをお伝えすることはできませんが、ポイントだけでも伝わればうれしいです。
もしもあなたが、開発者数名のパッケージソフト開発会社の経営者だというのであれば、比較的簡単に標準プロセスを定めて、それを実行することができるはずです。しかし、大きな会社組織で、1つのプロジェクトを実行するのに関連する部署の数も3つ、4つ、5つと増えてくると、それを鶴の一声で作らせれば終わりとはいきません。なぜでしょうか? それは「これは自分で望んでやっているのではない」という人が増えてくるからです。
ここで、“望んで”というところがポイントになります。いくら頭では理解して納得していたとしても、それだけではきちんとした取り組みはしてもらえません。人は理屈ではなく感情で行動します。ですから、いくら筋の通った話でも、不快に感じれば聞きたくもないし、ましてやそのために自分が行動を起こすということはしません。理屈、理論を解釈した結果、なんらかの感情が沸き起こり、その感情によって行動が決定するということです。これは自分のことを振り返ってみれば明らかですね? ですから、標準プロセスを策定して、それが実際に使われるようにするには、感情として「使いたい」、あるいは「使わなければ大変なことになるぞ」、というふうに感じてもらわなければなりません。そして、そこから行動に移ってもらわなければなりません。正直にいうと、標準プロセスを策定するだけなら簡単なのです。実際、あなたの組織にも使われないプロセスが、ドキュメントとしてゴロゴロ転がっていませんか?
私は、「もうずいぶん古いプロセスだからいまは使われていない」ということを聞くと、意地悪心というわけではないのですが、「以前はちゃんと使われていたのですか?」と聞くことがあります。すると、たいていは予想したとおりの返事が返ってくるのです。残念ながら、まともに現場で使われている標準プロセスは非常に少ないようです。
(1) 初めから現場と協調する
きちんと現場で使ってもらえる開発プロセスを定義するには、現場に提供する段階で初めて知らせるのではなく、開発プロセスを構築する最初の段階から現場関係者との連携が必須になります。これによって、「自分たちがその必要性および期待される効果に合意したうえで作った開発プロセス」という認識を確立することができます。
(2) マイルストーンごとに現場を含めて合意を取る
初めに合意を得たからといって、後は勝手にプロセスを作り上げるというようなことをすると、現場に提供したときに、「自分たちが期待していたのは、こういうプロセスではない」という事態に陥ることが多いのです。多くの人は、変化を嫌います。たとえ変化、改善の必要性を頭で理解していても、今、生死の狭間にでもいない限りは、それらを拒絶する傾向が強いですから、「合意していない」といういい訳の余地ができるだけないようにした方がよいのです。ですから、次のステップに進むためのマイルストーンごとに逐一合意を形成しておくことが大切です。
「業務命令だから使わなくてはいけない」ということは簡単です。ただ、それで望む結果が得られるケースは少ないということです。命令して使ってくれるなら、こんな簡単なことはありません。
(3) 失敗はなく、結果があるだけと認識する
ここであなたは、いくら「合意を取りながら進めましょう」といっても、なんとなくうまくいかないような気がしていませんか? そのとおりです。これだけではうまくいかないでしょう。 なぜでしょうか? 一番大きな理由は、「失敗することへの恐れ」が残っているからです。いくら納得しながら作り上げられた開発プロセスであっても、それで本当に成功するかどうかは分かりませんから、「やってみてうまくいかなかったらどうしよう」と考えると怖くなるわけです。“怖い”という感情は、「やってみてうまくいかなかったらどうしよう」という思考から生じるということです。ですから、「失敗なんてものはない。ただやってみた結果が出るだけ」と考えて、“どんな結果が出るか楽しみだ”という感情を導くようにした方がよいのです。それでも、あなたは「そんなこといっても……」と思うかもしれません。それでもとにかくやってみませんか?
余談になりますが、「ただ結果が出るだけ」といっても、その結果が望まない形のものであった場合に、1回の結果でプロジェクト全体の成否が決まるようなことは避けた方が良いに決まっています。そのためにも短いサイクルを繰り返すスタイルの開発プロセスの方が良いといえます。
それでは実際のプロセス構築の流れをお話ししたいと思います。
新しいプロセス構築は、現状を改善するための活動の一環ですから、基本的な進め方は、改善活動と同じです。つまりPDCAサイクルと同様のことを行うことになります。われわれの業界においてなじみ深いものとしては、SEIが定めたIDEALモデルがあります(図1)。
以降では、IDEALモデルそのものではありませんが、Borland/TeraQuest社でコンサルティングを行う場合の流れの一例をお伝えしたいと思います。
(1) リーダーチーム組成
リーダーチーム組成の具体的な活動として、
を行います。これによって、プロセス定義、プロセス改善活動が、組織として正当な認識、理解の下で行われるものであることを確認、保証することになります。
(2) ビジネスゴール設定
組織として“どうありたいか”“どうあるべきか”という視点で、ゴールを設定します。
(3) 現状分析
設定したゴールに対して、現状はどうであるかを、現場に対するヒアリング結果、過去のプロジェクトデータ(費用、工数、期間、規模などの予実など)を分析し、具体的な取り組みについて検討し、リストアップします。
(4) 優先順位設定
限られた期間内で望む結果を出すために、リストアップした取り組み案に対して優先順位を付けます。そして、今回のサイクルで取り組む活動を決めます。
(5) ゴール達成条件の設定
ここが非常に重要なのですが、取り組むべき活動に対して、その活動が目的を達成したということを判断するための基準を定義します。この判断基準、判断方法を明確にしておかなければ、「いろいろやってみたけど、望む結果は得られず、次にどのような活動をしたらよいかもよく分からない」となってしまって、結局1回だけの取り組みで終わってしまうということになります。「測定されるものは改善される」ということを忘れないようにしましょう。
(6) 実活動チーム組成
いよいよ、具体的なプロセスの定義や、定めたプロセスの実施を支援する環境の構築など、実作業を行うためのチームを組成します。
(7) 計画策定
詳細なWBSを作成し、担当者と成果物、期限を確認します。ここでは、大きく(1)エンジニアリングプロセスの定義、(2)マネージメントプロセスの定義、(3)環境・ツールの開発・整備、という分類でそれぞれのタスクの細分化を行うのがよいと考えています。実際、それぞれを検討するのに求められるスキル、知識、経験は異なります。大切なことは、お互いの尊重と協調だということを忘れないようにしましょう。
(8) パイロット実行
無事、開発プロセスとその環境ができたからといって、それをいきなり全プロジェクトへ展開する、というようなことはしませんね。実プロジェクトで使ってみることで、教育プログラムの問題、不備、環境の問題、不備、プロセスの問題、不備といったものが明らかになります。システム開発におけるテストと同様に、プロセス自体もテストが必要なのです。従って、このパイロット実行という活動自体は適宜繰り返し行われることになります。
ただし、ここでは開発プロセスと環境の不備を発見して修正することを目的とし、ビジネスゴールが達成できているか否かの評価は、この後で実施します。くれぐれも“いつまでもパイロット実行が終わらない”という状況にならないようにしましょう。
(9) 評価
パイロット実行によって、ある程度満足のいくものが得られたら、それらが具体的なゴール達成を満たすものであるか否かを、測定し、評価します。そして、次に取り組むべき活動を明確にします。
以上、非常に簡略ではありますが、標準プロセス策定からプロセス改善活動に通じる取り組みの流れを説明しました。これで、あなたの組織は期待する効果を得ることができます。と、いいたいのですが、ここでもう1つだけきちんと認識しておいてほしいことがあります。それは、現在の状態から、望むべき状態へと変化する際には、必ず一時的な生産性の“落ち込み”が生じるということです(図2)。
ここでもまた余談になりますが、この落ち込みをいかにして小さく、そして短期間で済ますか、という観点で見た場合にも、1回1回の取り組みのスコープを小さくして、短いサイクルを繰り返すスタイルの開発プロセスの方がよいといえます。
今回の連載では、考え方、心構えに重きを置いてお伝えしてきました。やり方、テクニックに関してはすでに多くの知識が皆さんの中にあるはずです。それなのに行動できない、やってみたけどうまくいかないということが多いのは、考え方、心構えによるところが大きいのです。これを機に、少しでも考え方、心構えにフォーカスした取り組みをする方が増えてほしいと切に願う次第です。
今村智(いまむらさとし)
ソフトウェア開発に関わる方々を少しでもハッピーにすべく、要求開発・管理、ソフトウェア開発プロセス構築に関する啓蒙、コンサルティングに従事。 Webサイト( http://www.human-process.com/ )からの情報発信も行っている。
Copyright © ITmedia, Inc. All Rights Reserved.