次世代プロジェクトリーダーのための すりあわせの技術

新規事業系サービス開発における提供価値を最大化するための「すりあわせの技術」を紹介した実用書。近未来に新たな教育サービスを開発するストーリーに前半部分の多くのページが割かれているが、前半のストーリーに散りばめられた「すりあわせ」の実践技術について後半部分で体系的に解説する構成となっている。読書メモ②。

第2部　プロジェクトを成功に導く「すりあわせ」の技術

例えば分野横断型の大規模なプロジェクトであれば、それぞれの分野の専門家を含めたチーム編成が必須となる。一方で、各分野それぞれにビジネスやシステムの作法や考え方、共通言語が異なるのでこれらのギャップを埋めるためのすりあわせ技術が非常に重要となる。ギャップを埋めるには、各分野の興味やカバー範囲をオーバーラップ（重ねる）ことが有効なので、出来るだけ分野ごとの専門家同士の興味が重なるようにガイドできると良い。

・オープンイノベーション：企業や組織が外部との協力や情報共有を通じて新しいアイデアや技術を取り入れて技術革新や事業革新を促進する手法

プロジェクトマネジメントを行う上で、組織内・企業内だけでなく外部を巻き込む力が必要。

・EU（European Union）：欧州連合。ヨーロッパにおける経済的・政治的な一体化を促進する組織・地域連合体

この必要条件があるから、ヨーロッパの公的研究や標準化はグローバル指向が強くなる。一方で日本ではこのような必要条件が無いから、グローバルに通用する公的研究や標準化が推進されにくいかもしれない。

・自然科学：物理学、化学、生物学などを含む自然界の法則や現象を対象とする科学の分野
・社会科学：人間の社会やその構造、行動、文化などを研究する科学の分野

自然科学はテクノロジー、社会科学はビジネスとの結合度が高い。テクノロジーとビジネスは表裏一体であることから見ても自然科学と社会科学の関連度は高いはずだが、これらの知の統合が未だ困難なのは何故なのか。
人間は言語や文化や宗教などにおいて異なるものと境界を作る性質があるが、自然科学と社会科学の間にも同様の境界が存在しているのかもしれない。一方で、これらの知の統合が生まれたときには大きなイノベーション（革新）が起こるという期待感もある。

「顧客要求の明確化」は「利用者の価値の明確化」と捉えることが重要。顧客自身が「顧客要求の明確化」ができていない場合には、顧客以外の第三者が「利用者の価値の明確化」をする必要がある。いずれにせよ、「利用者の価値」を向上させることができるサービスやシステムであれば、大抵は良いものができる。
また、「利用者の価値」は必ずしも現在のニーズから抽出できるとは限らない。未来に起こるであろうニーズを予測することも「利用者の価値」の向上に繋がる。

コストカットは価値の一部でしかない。自動化や効率化でコストやリソースが削減できることは価値のひとつだが、社会や個人にとって便利であったり新たな楽しみを提供することも重要な価値。
一般企業の評価指標も、ビジネス的な価値提供だけではなく社会的な価値提供がどれだけ出せるかが重視されつつある。

「利用者の価値」の積み重ねによって個人や社会の価値に広がっていき、巡り巡ってサービス提供者の価値となる。「To Be」は個人や社会にとっての「あるべき姿」のこと。

まずは生み出す価値を先に定義して、価値を提供するサービス・システムを作り運用するコストと見合うかどうかを比較することが重要。

ここで注意すべきなのは「本当の価値が何であるか」が、明確になるまでプロダクトを生み出さないという行為が一番危険であるということ。プロダクトを生み出して改善していく過程で、マーケットからのフィードバックをもらって改善するというサイクルが重要。
AppleのiPodは恐らくこのようにプロダクトを生み出し、それを改善し続けることによって洗練された音楽プレーヤーでユーザに価値を提供し続けることができた。

「顧客視点」とは「利用者の価値」を最重要とする考え方。「利用者の価値」のためのシステム設計・システム開発を行ってしまうと、結局は利用されないシステムが出来上がってしまう。

「活用指向」とは、利用者が「価値」を感じて「活用」することを目指すアプローチ。

ここでいう「先の要件」とは、未来指向の要求定義・要件定義のこと。「先の要件を定義するには、潜在的なニーズの探索がひとつの方法。また、未来指向の要求定義を継続し柔軟にシステムを拡張するためには、ビジネスやシステムのアーキテクチャ（設計思想）が柔軟で、拡張性を持っている必要がある。ある時点での要求定義だけを満たすシステムにしてしまうと、未来の要求定義を実現する際に、最悪の場合すべて作り直すことになってしまう。

・マイクロサービス・アーキテクチャ：大規模なソフトウェアシステムを複数の小さな独立したサービスに分割し、それらを連携させて構築するアーキテクチャ手法

マイクロサービス・アーキテクチャそのもの。マイクロサービス化は、システムだけでなくビジネス的なアプローチでも有効に働く。分解されたサービスコンポーネント（サービスの部品）を結合することで、新しい価値を生み出すサービスが実現することもある。

・構造化：要素や情報を規則的で整然とした形に配置し、組織づけるプロセスや手法
・相対化：対象や情報を他の要素との関係や比較に基づいて理解・評価すること
・統合化：異なる要素や部分を一体化し、協調させて統一された全体を形成するプロセスや手法

要素分解と結合の具体的な方法。客観的な構造化によって要素を分解し、分解した要素を比較して分類したり類似性を検証する。その後、結合・統合のタイミングで分解した要素を一体的に動くように再結合する。

スキマはプロジェクトにかかわる組織やヒトの間で発生し、システム間の接続でも発生する。組織やヒトのスキマは、縦割り組織で自分の役割以上のことをしないマインドや風土のもとで発生しやすい。システム間のスキマは、サービス設計時の考慮不足や運用設計の検証不足によって発見が遅れやすくなる。

異なる分野、異なる会社、異なる人によって理解できる言語が違う。そのことを理解している「すりあわせ家」が、両方の立場で理解できる共通言語を準備して通訳する必要がある。
一方で、共通の価値（なぜそれを提供するのか）が明確になっていると、共通のゴールに向かって相互理解が進むことも多い。共通のゴールに向かって一枚岩になっているプロジェクトは、スキマが発生しにくい。

プロダクト（製品）は進化することで、継続的な価値を提供することができる。プロジェクトは期間でゴールを設定し期間内に完了することが重要となるが、プロダクトは継続的に価値を提供し続けることが重要となる。プロジェクトに関わる全員が、プロジェクト完了後も価値を提供し続けることにコミットできる（積極的に関わり続ける）と良いサービスができる。

プロジェクトの成功・失敗体験はあまりノウハウが蓄積されていないことが多い。優秀なプロジェクトリーダーは、プロジェクトを掛け持ちしていたり、プロジェクト終了後にすぐに新たなプロジェクトにアサイン（任命）されることが多く、経験が共有される機会が少ない。
優秀なプロジェクトリーダーの経験を複数人に共有する方が、社会や会社全体から見た場合には結果的に効率が良くなるはず。

あとがき

水道、電気、ガス、交通などの社会インフラがそうであったように、次世代ITインフラが完全な社会インフラとなったときには、人々の生活や経済活動に自然に溶け込んでいる（意識せずに使われている）はず。

「情熱」と「謙虚」さは本当に重要。物事を前に進めるには「情熱」が必要で、物事を実現するには「謙虚」さをベースに「学習」「理解」しなければならない。どちらが欠けても良いサービス・事業は出来ないし、それを実現するための「すりあわせ」も出来ない。