プロセスとは何か？ ～ 開発プロセスについて考えてみよう
この記事を見てくださっている方は、製品の開発プロセス作成に何らかの形で携わっている方だと思います。今回は、「プロセス」という言葉との向き合い方について、そのヒントをお伝えします。
Process という言葉の解釈
皆さんは、「プロセス」という言葉の意味を、うまく説明できますか？ 筆者は、当初なかなかうまく説明できませんでした。プロセスという単語は、そもそもカタカナで記載される単語であり、日本語の解釈が数多くある言葉だと思います。従って開発プロセスとして使う場合は、プロセスという言葉の使用環境を理解して、その解釈の適合性を整理しておくことが、スタートラインだと考えています。
まず、Google 先生に「プロセス」「広辞苑」と入力して聞いてみたところ、下記の回答が返ってきました：
- 広辞苑における「プロセス」の意味は、「過程」や「工程」と同義で、物事が結果に達するまでの道筋や手順、方法を指します。ビジネスシーンにおいては、業務の進め方や手順、または一連の出来事を指すことが多いです。
- 広辞苑には「プロセス」という単語そのものの定義は直接記載されていませんが、類語として「過程」、「工程」、「手順」などが挙げられています。これらの言葉は、広辞苑で「プロセス」の概念を理解する上で参考になります。
- AIによる概要として、英語の「process」が語源であり、現代では物事の達成までの工程や過程、あるいはその進め方を指す言葉として一般的に使用されています。 という説明も出力されました。
次に日本語辞書から検索してみると（デジタル大辞泉で検索）：
- 仕事を進める方法、手順。「作業のプロセス」
- 過程、経過
- コンピューターでプログラムなどを動作させる際、CPUが実行するひとまとまりの処理の単位
他の検索ツールにおいても、おおむね同様の説明が得られるようです。結論からすると、外来語である「プロセス」を直接当てはめる日本語はなく、使用用途に応じて適切な解釈をすることの重要性が再認識されます。
では、「開発プロセス」として見た場合、どのように解釈するのが良いでしょうか？ ここでは、欧米が発信する世界標準や文献から、Process の一般的な定義を調査してみます。
IEEE Standard Glossary of Software Engineering Terminology：
ある目的のために実行される一連のステップ
CMMI 用語集：
互いに関連を持った活動の集合であり、所与の目的を達成するために、入力を出力に変換するもの
Quality Process Management by Pall, Gabriel：
指定された最終結果を生み出すように設計された作業活動に関わる「人、材料、エネルギー、機器および手順」の論理的編成
つまり、開発プロセスとは、「アウトプットを出すために実施している作業ステップ」と考えられます。
プロセスアセスメントのインタビューで、プロセスという言葉を使って会話すると、「残念ながら、私たちにはプロセスはないんですよ」というやり取りになることがあります。プロセスの意味を正しく理解していれば、少しおかしな発言だと思いませんか？
言葉の解釈が正しくできていれば、「私たちの作業プロセスは文書化されていません」という回答となるはずです。何らかの作業をしてアウトプットが生成されていれば、そこに「プロセス」は存在するからです。
開発プロセスを文書化する際のヒントと注意点
それでは、開発プロセスを文書化する上で重要な点について考察してみます。
- 現状の作業方法を正しく理解すること
- これには、「誰が」、「何を入力として」、「どのような方法で」、「何を作成しているか」を含みます
- そして明確になったことを文書化すること
これを第一ステップとして、開発メンバー全員で共有することが重要です。もし、個々人で作業内容が異なる場合は、調整しながら納得のいく手順に修正する必要があります。このステップなくして、プロセス改善 = 「品質や生産性の向上」にはつながりません。
特に、プロセスアセスメントモデルを活用しているケースでは、次のようなことが起こりがちですので注意が必要です：
- 従来の作業方法を考えずに、モデルをそのままコピーしてプロセスを作成してしまう
- アセスメントで「○○文書がない」と指摘されたため、モデルに定義されている成果物をそのまま新たに導入してしまう
製品開発ができている限り、アセスメントモデルが言及していることと同様の作業や成果物が必ずあるはずです。言葉遣いの相違、成果物の過不足あるいは作業順の違いなどはあって当たり前です。アセスメントモデルは、世の中のベストプラクティスをモデル化しただけですので、順番や言葉遣いは標準化されているからです。
ここで重要なことは：
- モデルの意図を理解すること
- 自分たちが従来実施している作業手順を尊重すること
- もしモデルが言及していることと現作業手順にギャップがある場合、それを変更・追加した際の価値と効果を評価すること
アセスメントモデルがプロセス能力レベルを定義していることから、ゴールを急ぐことが目的になり、ついつい本質を見失う活動になりがちです。ばくだいな工数をかけてプロセスを変更したにもかかわらず、工数ばかりが増加して誰からも歓迎されない手順になってしまったり、アセスメントの説明以外では誰も使っていない成果物ができてしまうということが実際に起こっています。まずは、自分たちの作業を尊重して作業を進めることを第一ステップとしてください。
プロセスは、段階的に改善していく
「現状手順をベースに作業すると、すぐに能力ベルが上がらないじゃないか！」、「上司からは、顧客要求だから１年後に能力レベル３が必達だ！と言われている」という声が聞こえてきそうです。それは、確かにリアルワールドで起こっていることだと認識しています。目標到達までの時間は、現状いる位置により異なりますよね。従って、まずは自分のいる位置をきちんと把握した上で、議論することが必要です。
Automotive SPICEを要求してくる欧州自動車メーカーも、プロセスに関するプロフェッショナルです。発注前のアセスメント結果（サプライヤーの現状の立ち位置）があまりにも低い場合は、無理な要求はしないはずです。それは能力レベルを１段階向上させるために要する時間を経験上知っているからです。言葉を変えると、そのような評価になったサプライヤーには発注しないはずです。ノミネーションに残ったということは、それなりの期間で能力レベルの向上が可能だと判断したということなのです。
現状の立ち位置から目標到達までの改善計画を立案し、自動車メーカー（あるいは会社の上司）と合意しながら進めていくことが最短の道のりとなるはずです。ぜひ、従来の作業方法に自信を持って、アセスメントモデルに翻弄されない活動をしていただけるよう切に願います。
プロセスの可視化のステップのわかりやすい事例が、CMMI関連の技術文書に書かれているので、プロセス能力の向上という観点からプロセスの可視化のイメージをつかんでください。
能力レベルとは、作業（プロセス）の定着度合いを示す指標だと考えてみてください。プロジェクトの経験から得た学びを、継続的に改善を繰り返すことで段階的にプロセス能力の向上が可能となります。この過程では、「プロセスが適切な粒度で可視化」されるようになることで、その粒度でプロセス実績が計測可能となり、結果としてプロセス実績のばらつきが少なくなっていくことになります。
「文書化されたプロセスが使われない」 もう１つの要因
作成者が苦労して作成したプロセスも、開発メンバーに使ってもらえなければ、まったく意味がありません。残念ながら、数多くの組織やプロジェクトで、このような状況が起きています。
もう一度「プロセスの可視性」と「予測される実績」の図を見てください。プロセスが可視化されていても、開発メンバーに浸透していなければ「能力レベル１」の状態と変わりません。たとえプロセスが文書化されていても、そのプロセスを意識せずに各メンバーが思い思いの方法で作業しているのであれば、プロセスは雲の中にある状態と変わらず、実績もついてこないことは容易に想像できると思います。
なぜこんなことが起こってしまうのでしょうか？ 誰が考えても、この無駄な状況を理解できると思います。
ズバリ！日本の文化では、「Process」の必要性を多くの人が感じていないのだと思います。特に、人と人との擦り合わせの中で業務をしていく習慣が強い日本では、その場その場で臨機応変な対応を迫られます。ここが、外来語である「プロセス」の難しいところだと思っています。たとえプロセスを文書化しても、プロセス通りには作業できないことが日常で多く起こってしまうのかもしれません。あるいは作業計画を作成したが、要件変更が日常的に発生し、計画しても意味がないということが日本では多いようです。
一方、日本でも擦り合わせだけではうまくプロジェクトを回せない状況になりつつあります。例えば、Z世代のような若い人たちの考え方の変化、海外を含めた多拠点開発や分業制の必要性など、開発プロジェクトの環境は欧米に近づいてきています。従って、このままの状況を放置していくことは良いことではありません。
では、「プロセス」にはどのように向き合っていけばよいのでしょうか？
第一に、プロセスを確立することの目的を明確にし、その価値を共有することです。
- プロセス管理の前提は、製品品質や生産性の向上が直接的な焦点ですが、最終ゴールは事業への貢献にあります
- 従って、プロセスは経営者や上級管理者の事業への思いを実現する手段でなければなりません
- 欧州自動車メーカーは、Automotive SPICEをプロジェクト要求としてインプットしてきますが、彼らがアセスメントモデルを活用する背景には、プロセス管理の前提を理解した経営層が組織運営しているサプライヤーと幅広く長期間の取引をしたいという目的もあるのです
次に、目的を達成するためのアプローチを経営側面で決定し、段階的に進めながら最終ゴールを目指すことです。
- 初めから高望みははしない
- アセスメントモデルで使用される各能力レベルへの到達指標は、その評点に大きな幅（50点から85点）があることを認識してください
- 最初の目標は50点で良しとし、次の段階で85点以上を目指すようなアプローチが可能になっています
- はじめから重厚長大なプロセスを作っても、使われなくなるという副作用が増すだけです
- 能力レベルの評点に大きな幅を持たせているのは、プロセス改善で起こりうる状況を考慮した上で、段階的なアプローチを可能にするためなのです
- プロジェクト個別に進めるのか、最初から組織標準を導入するのか？
- Automotive SPICEのようなプロセスモデルの本質を理解して、アプローチを決定することが良いでしょう
- アセスメントモデルでは、組織標準の適用段階は能力レベル３であるということを理解しておくことも重要です
- 経験則的に、プロジェクト内の決め事が徹底できない状況のプロジェクトに、組織標準を適用し浸透させることは至難の業です
- プロセスの作成に専任リソースを準備するのか、プロジェクトメンバー全員が参加する方法（プロジェクト業務との兼務）で実施するのか？
- ここには正解はなく、経営者や管理者の思いで体制を構築することが最善策となるでしょう
- たとえば下記の２つの考え方は、人によって異なるはずです：
- 兼務の場合、プロジェクト業務がひっ迫するとプロセス改善活動がおろそかになるため、専任リソースによる活動が望ましい
- 専任リソースがプロセスを定義すると、プロジェクトの思いとは異なるプロセスができやすく、浸透しにくいため、全員参加が望ましい
- ここで重要なのは体制ではなく、経営者・管理者が自分の思いで活動を主導することであり、これができる組織は必ず成功しています
最終的なゴールを最初からある程度想定しながら、段階的にゴールを変更していくことも重要かもしれません。
筆者は、これまでの経験（自社や他社の取り組み）から、最終ゴールは、「ツール上で日々の仕事ができるようになれば、担当者はプロセス文書を見なくても仕事ができる状態にすること」だと考えています
プロジェクト計画書の作成を例に挙げると：
- 日本では、計画書のテンプレートを準備して、人手により時間をかけて書いていることが大半です
- 欧米では、日々の作業に必要なWBSタスクや役割分担などをツール上で管理者が定義し、担当者はWBSに従って作業し、実績を入力する方法が一般的です
- これは、ツール上にある各タスクが日々の作業計画であり、作業記録が進捗状態だという合理的な考え方です
- プロジェクト計画書を他者に見せる必要がある場合は、「計画書作成ボタン」を押すと、ツール上に組み込まれたテンプレートに必要なデータ要素が組み込まれ、自動で印刷されるような仕組みが導入されています
欧米のケースでも、プロセス文書は存在しており、それはツールの設計図という位置づけに加えて、各ツールの機能画面から必要に応じて簡単に参照できるようになっています
さいごに
筆者は、全社にCMMIに準拠した標準プロセスを導入するように命じられた時、欧米人を１名プロジェクトに加えてくれとお願いしました。なぜならば、カタカナで分かりにくい内容のものを導入するなら、文化的に「Process」という扱いに慣れた人材の投入が最短だと思ったからです。残念ながら願いは叶わず、プロセス能力が上がるまでに長い時間がかかってしまいました。しかしながら、長い年月をかけて数多くの挫折を経験できたことで、開発現場におけるプロセスとの向き合い方に関するノウハウを得られたことは貴重な体験でした。今回のコラムが、同様の悩みを持たれている方々への一助になれば幸いです。
弊社では、プロセスアセスメントモデルを扱う際に発生する課題や教訓を記載したコラム（Automotive SPICE（アセスメントモデル）の功罪）も発行しておりますので、こちらもご参照ください。
次回は、プロセスを文書化していく際に有効な「プロセスモデリングの原則」を取り入れたプロセスアーキテクチャに関するコラムをお届けする予定です。
（日吉昭彦）