【目指すべき開発体制 連載目次】
- 目指すべき開発体制とは（その1）擦り合わせ型と組み合わせ型
- 目指すべき開発体制とは（その2）日本企業文化を引きずっている「擦り合わせ型」
- 目指すべき開発体制とは（その3）組み合わせ型に擦り合わせ型組織文化を適用する工夫
- 擦り合わせ型開発 基本の仕組み (その1)「調整」の仕組み
- 擦り合わせ型開発 基本の仕組み (その2)「気づき」の仕組み
「擦り合わせ型開発と組み合わせ型開発、目指すべきはどっち？」では、「擦り合わせ型開発」と「組み合わせ型開発」の特徴を説明した後、日本の多くの開発現場で、「組み合わせ型」アーキテクチャの製品を「擦り合わせ型」の仕組み（組織能力や環境）で開発するという「ねじれ」の問題を抱えていることを指摘しました。
このような問題提起をした時には解決のために現状を否定しがちなので、どうやったら「ねじれ」解消ができるのかという思考になりやすいものです。しかし、コンサルタントとして開発現場を見てきた経験から、擦り合わせ能力は日本の技術者が本来持っている能力であり、擦り合わせ能力を活かすことこそが、製品開発における他国に対する競争優位性を高める手段だと信じています。
ただ、擦り合わせ型開発は、文字通り様々な擦り合わせが発生するため非効率な開発になりがちです。したがって、組み合わせ型開発においても、擦り合わせ能力を活かした高次元の製品開発を実現するためには、擦り合わせの非効率性を解消する仕組みが必要になります。
ということで、今回は、擦り合わせ能力を活かしつつ、組み合わせ型開発においても効率的な開発を実現するための仕組みについて考えたいと思います。
1. 擦り合わせ型開発の２つの前提条件
まず最初に、擦り合わせ型開発についてもう一度復習しておきましょう。
擦り合わせ型開発の特徴は、開発現場の一人ひとりが主導権を持ち、各人が自らの状況判断で問題を見つけて対応策を考え実行することです。 開発にかかわっている誰もが、自立的に、必要に応じて必要な人と相談しながら問題を解決するわけですね。そして、この自立的なやりとり（擦り合わせ）が開発チーム全体に連鎖して、最終的に全体最適となる製品を作り出します。
ただし、この開発スタイルを成り立たせるには2つの重要な前提条件があります。ひとつは、個別の擦り合わせ作業の連鎖が、最終的に製品開発全体のゴールを達成することを保証する仕組み。この仕組みがなければ、擦り合わせの行く先はそのときになってみないとわからないということになります。これを「調整」の仕組みとよびましょう。
そしてもう一つは、技術者が高い自立性を有していること。技術者自らが現場で起きている問題を把握し、その重要性を判断し解決に向けて行動を起こすことが、様々な「擦り合わせ」という行動になります。この自立性を「気づき」とよびましょう。 技術者が高い「気づき」能力を持っていないといくつかの問題は解決されないままになり、開発の最後の段階で顕在化することになります。
今回のテーマである擦り合わせ型能力を活かした開発の仕組みとは、この２つの前提条件「調整」と「気づき」を満足できる仕組みのことです。では、この２つをどのようにして実現するのかについて考えたいと思います。
2. 調整の仕組み
それでは、まず「調整」の仕組みについて考えたいと思います。
「調整」の仕組みがなければ、行き当たりばったりで製品開発のゴールにたどり着けないという説明をしましたが、そんなことは稀だと思うかもしれません。しかし、実際には程度はあるものの決して少なくはないのです。このような開発を、私は「できた成り開発」とよんでいます。
「できた成り開発」とは、決まっている製品開発期限までにでできているところが最終製品となるような開発のことです。製品開発の終わりはその時点でできたものということですから、もともと計画していたゴールにはたどり着いていないわけです。できたところまでだから「できた成り」開発です。期限まで精一杯がんばってその結果がゴールになるので「ベストエフォート型開発」といってもいいでしょう。この方が少し聞こえが良くなりますね。でも、計画で考えていた動作とは違っていたり、予定していなかった制限がついたり、機能そのものが変わったりすることには変わりありません。
できた成り開発でも、技術者一人ひとりは精一杯がんばっています。ただ、一人ひとりのベクトルの和が、開発全体が向かうべきベクトルとは違う方向を向いてしまっているのです。擦り合わせ型開発の場合、技術者の一人ひとりの判断の下で開発が進むわけですから、一人ひとりのベクトルの和が全体のベクトルと一致していなくてはいけません。しかしながら、技術者個人が考える最適解が全体の最適とは限らない、つまり、局所最適解が全体最適解とは一致しないという、よくある問題に陥る可能性が高いということです。
製品開発を始めるときは、製品開発（設計）の目標設定を行います。開発がはじまった直後からその時々で様々な擦り合わせ作業が発生しますが、開発初期は想定していた問題がほとんどということもあり、開発全体でも当初設定した目標に向かって進んでいきます。しかし、開発の進捗とともに想定していなかった様々な課題が発生し、個々の課題解決はそれを担当している技術者周辺で自主的に行われるために局所最適な行為になってしまい、開発全体でのベクトルの総和は必ずしも当初の目標には向かっていないことになります。そして、最後には当初の目標とは全く違うところに着いてしまうことになります。
技術者は個々の問題解決に全力を注いでいるにもかかわらず、全体で見るとゴールとは違う地点を目指しているのですから、技術者にとってはがんばりが報われないことになりがちです。プロジェクトマネジャーやリーダーも同じです。あちこちで行われている擦り合わせ作業を把握することが困難なため、最終目標とどの程度乖離しているのかを把握できるのは統合評価などの開発の最終段階になってしまい、何とか軌道修正を試みるもののあえなく時間切れとなり、徒労感でいっぱいになるということになりがちです。
このような状況に陥ることを避けるには、技術者のベクトル和が全体のベクトルと一致しているかどうかを常に確認できる仕組みが必要です。「調整」の仕組みとは、常に個別活動とその総和となる全体の開発活動が把握でき、最終目標との乖離を軌道修正できる仕組みです。
ところで、擦り合わせ型開発というとトヨタ生産方式がモデルとなっているわけですが、トヨタ生産方式における「ジャストインタイム」の仕組みは「調整」の仕組みと考えることができます。ジャストインタイムとは、部品もしくはモジュールが、必要なときに必要なだけ供給される仕組みですが、その本質は、在庫がたまったり供給が切れたりすることが、工場のどこであっても、誰の目にもわかるようになっているということです。そして、工場全体を見渡せば常に全体の状況を把握することができるようにもなっています。このように、個別と全体の「見える化」によってジャストインタイムは成り立っていると考えられます。
ジャストインタイムは生産における仕組みですが、開発（設計）においても同じような仕組みを構築することが「調整」の仕組みを作ることになります。しかし、開発（設計）は、工場での生産の各工程や仕掛品含めた生産物のようには目で見える状態にすることが難しい面があり、より複雑な仕組みが必要になります。
3. 基本メトリクスセットとスケーラブルな可視化
開発（設計）を工場と同じように「見える化」し、最終目標との調整作業を可能にするためには、開発（設計）作業を把握するための指標（メトリクス）を明らかにすること、そして、それが、全体でも個別でも最終目標との乖離を同じ方法で分析できることが必要になります。前者を「基本メトリクスセット」、後者を「スケーラブルな可視化」とよびたいと思います。
開発（設計）はプロジェクトとして実施されることがほとんどです。「基本メトリクスセット」とは、製品開発を行うプロジェクトを可視化するための必要...
最小限の指標（メトリクス）のことです。製品開発は、企画、基本設計、詳細設計、試作、評価などの様々な工程に分けて行われ、その工程の構成や工程の中身は開発する製品によって変わりますが、どのような製品開発であっても、これだけを計測していれば開発状況を把握することができるというのが「基本メトリクスセット」です。
製品開発を行っているプロジェクトは、開発工数、タスク（作業要素）、作業成果物、不具合・課題の４つを計測すればその状態（進捗）を把握できます。このうち、開発工数はプロジェクトに対するインプットで、その他３つはアウトプットです。このインプットとアウトプットを見ていれば、プロジェクトそのものの動きを知ることができるわけです。
さらに、プロジェクト全体でも、プロジェクトの中のグループでも、そして、プロジェクトメンバーでも、どのような単位であっても同じメトリクスで同じように状況を把握することができること、それが「スケーラブルな可視化」です。組織全体、その中の任意のプロジェクト、プロジェクトの中の任意のグループ、そして、その中の任意の技術者という、どのような階層であっても同じメトリクスで進捗を確認できることを示しています。
どのような製品開発であっても、基本メトリクスセットの４つの指標（メトリクス）を使って、常に、プロジェクト全体や技術者個人、そして、その中間のサブグループの任意の単位の進捗を把握できる仕組みで、技術者による擦り合わせと開発全体の「調整」が可能になるということです。それぞれ詳しい説明は別の機会にしたいと思います。
次回は、「気づき」の仕組みから解説を続けます。