企画骨子｜16年の開発経験で到達した思考

人の思考プロセスを、本質的な「思考回路」として視覚的に構造化する。
Systems Visualismでは、個人の内省を助け、他者との対話・共有・創造を促進するための図解を体系化しています。
本棚のように、多様な図を揃え、あなたの考える力を広げるツールを紹介します。

[1] PROLOGUE｜導入

テーマ概要

仕事の中では、新しいことを始めるために、プロジェクトを提案しなければならない場面がある。私自身もエンジニア人生の中で何度も企画を提案し、リーダーとして研究開発プロジェクトを推進してきた。

社会人として若いころは、企画を通すこと自体が一苦労だった。
何を目的とし、何を目標とするのか。

多くのプロセス指南書では、背景、目的、目標、課題、達成方法を説明するように定義されている。しかし、それらをどのように紡ぎだし、どう論理構成すればよいのかまで明確に語られることは少ない。

当然ながら、プロジェクトごとに中身は千差万別である。それでも、場当たり的な企画と、考え抜かれた企画とでは、結果に雲泥の差が生まれる。

今回は、私自身の経験を振り返りながら、企画の骨子とは何かを整理し、定義していく。

参考資料

今回は特定の参考書籍は用いない。
筆者がエンジニアとして積み重ねてきた過去の経験に基づいてまとめる。

[2] CORE｜本編

思考回路 - 図解ツール

こちらが図解ツール全体像です。
情報量が多いため、次章の解説を参考にしながら、じっくりと読み進めていただくことをおすすめします。

図の解説 - 紙芝居形式

図解ツールをパーツごとに分解し、詳しく解釈しながら説明していきます。
テーマ説明：全7枚

会社組織が持つ背景とは何か。
社会的責任や成し遂げたいMission
目指しているVision
大事にしている価値観。
そして、会社組織の内部の実情や、社会や競合の現状はどうか。
そうした要素から、自分たちは背景のどこに着目したのかを整理する。

では、その背景を踏まえて、チームはどんな夢を成し遂げたいのか。
リーダーとして、チームとして実現したいプロジェクトのビジョン。
それは背景から紡ぎだされる目的であり、チームの夢である。

その夢のために、チームはどんな価値を実現するのか。
その価値を、どこまで高めるのか。
価値は、それを享受する側の目線で表現する。
誰が、何が、できている状態なのか。どうなっている状態なのか。
それは、成し遂げたいVisionと現状とのギャップから見えてくる問題を捉え、そこから課題を分析し、本質的な問題を仮説として立てることで見えてくる。

その仮説の先にあるものが、目指す価値である。
目指す価値こそが、達成指標であり、チームの目標となる。

「どんなことができているか」は、客観的な観測によって確認されなければならない。

その価値が達成されていることを、どうやって観測するのか。
それが、プロジェクトを完了したと判断するための、絶対的な指標となる。

本質的な問題が見えていれば、真の課題を定義できる。

自分たちは何を乗り越えるのか。
何が難しいのか。

それを曖昧にせず、明確に言語化する。

そして、発想を転換し、課題を解くための達成方法を見つけ出す。
その達成方法を実現するために、具体的なタスクが定義されていく。

このように、企画は短絡的に中身が決まるものではない。
目的、目標、達成指標、課題、タスクという階層は、いくらでも中身がずれ得る。

だからこそ、それらを何度も階層間で行き来させながら、最も納得感のある階層分けを必死に探索していく。それが、企画骨子をつくるということだ。

ここまでお読みいただきありがとうございました。

図解ツールを手元に置いて解釈を深めたり、
「企画提案」について周りの仲間と議論する際の、「論点の地図」として活用してください。

[3] INSIGHT｜考察

ダメな企画に共通する「目標の形」

企画書を読んでいて、違和感を覚える瞬間がある。
それは「目標」に書かれている文章が、実質的にタスクの説明になっているときだ。

たとえば、
「＊＊を構築する」
「＊＊を決定する」
といった表現が、目標として掲げられているケースである。

第三者から見ると、それは目標には見えない。
なぜなら、そこに書かれているのは作業内容であって、「その結果、世界がどう変わるのか」が一切語られていないからだ。

おそらく書いた本人にとっては、「これをやれば前に進む」という実感があるのだろう。しかし主語は常に「自分（たち）」のままで、自分自身でさえ、その目標を客観視できていないことが多い。

私自身、あるプロジェクトに途中参加した際、目標がまさにこの形式で定義されていた経験がある。

その瞬間に感じたのは、
「このプロジェクトには、動ける余白がない」という感覚だった。
やるべきことはがちがちに決まっている。
しかし、そのタスク自体が理想的かというと、そうでもない。

なぜなら、その目標は
観測すべき状態を定義できていない、視野の狭い構造から紡ぎ出されたものだからだ。

人はなぜ、階層立てをさぼるのか

こうした問題は、能力不足や怠慢の話ではない。
もっと単純で、人間的な弱さに起因している。

人は、階層立てて考えることを、驚くほど簡単に諦める。
楽なほうへ流されるのが、人というものだ。

背景をなんとなく具体化し、目的を定義するところまでは頑張れる。
しかしその後の「目標―課題」の深掘りや、階層をずらして考える作業に入った途端、思考は急に止まる。

するとどうなるか。
現状から見える問題に固着し、
その問題を解決するための表面的な課題に固執する。
その表面的課題を解くことが、
そのまま達成指標や達成方法に直結してしまう。

そして最終的に、
課題やタスクを完遂することを、そのまま目標に格上げしてしまう。
「これをやれば目標達成だろう」という、思考のショートカットが起きる。

この“階層をさぼる現象”は、あらゆる場所で見られる。
わかりやすい例が、会社の情報フォルダだ。

何もルールがないと、
上位階層に置くべきでないフォルダが、すぐに現れる。
あるとき、複数チームが共同で使うサーバーの最上位階層に、
突然「会議」というフォルダが作られているのを見て、正直驚いた。

作った人にとっては、
「(自分の仕事の)会議資料をまとめた」という感覚なのだろう。
しかしその仕事に関わらない人からすると、
「いや、それ俺関係ないし」となる。

階層というのは、整理の問題であると同時に、関係者の問題でもある。
どの階層に置くかとは、「誰までを関係者として想定しているか」という意思表示なのだ。

企画における目標や課題の混乱も、
まったく同じ構造をしている。

良い企画にある「余白」と、チームの自発性

コミュニティ論でも、余白の重要性はよく語られる。

これはプロジェクトチームのマネジメントでも同じだ。
良い企画には、
完成度の高い部分と、
あえて未完成な余白が共存している。

その余白に、メンバーは引き付けられる。
自分の知識や経験、情熱を差し込む余地があるからだ。
その結果、リーダー一人では思い描けなかった方向へ、
チームが自発的に動き出す。

今回の文脈で言えば、
目的や目標は完成度を高くしなければならない。
それはチームが目指す北極星であり、簡単に曲げられるものではない。
一方で、
達成手法やタスクをどうこなすかについては、
リーダーが最初から完成させる必要はない。
そこにこそ、メンバーの知恵が働く余地がある。

自分の思い出 ― 技術研究テーマの企画

社会人10年目くらいの頃だった。
私は技術研究テーマを、リーダーとして推進することになった。
正直に言って、企画段階はかなり苦しかった。

目標を「＊＊の精度を＊＊％向上させる」と定義できれば楽だ。
過去の文脈があれば、そこから引用すればいい。
しかし、そのテーマは新しい観点だった。

我々はユーザーに最終的に提供するものを作っている。
だから出発点は常にユーザーでなければならない。

ユーザーがどうなることを目指すのか。
どこまで喜んでもらうのか。
その価値のレベルはどこにあるのか。
その価値に到達するために、
どの技術が必要で、どこまで高める必要があるのか。
そして、技術課題は何なのか。

そこまで紡ぎ出さなければ、企画にならなかった。
企画会では一度、目標として語った「何が、どうなっている状態なのか」という内容が技術部長の納得を得られず、「もう少し考えてくれ」と保留を受けた。

その後、公式な二次企画会の前に、
私は何度も技術部長の席に行き、口頭で相談した。
朝や夜、空いていそうなタイミングを見計らって、
「ちょっとお時間いいですか」と声をかけた。
大変だったが、
そこで徹底的に何度もイメージを合わせたからこそ、
企画が通ってからの開発は、メンバーが自発的に動いてくれた。
何を目指しているのかが、明確だったからだ。

あのときの技術部長が、あの人でよかった。
目標が曖昧でも受け流す人もいる。
しかし彼は、自分が納得するまで付き合ってくれた。
企画の段階で散々議論したから、
承認はすんなり進み、
完了報告でも、成し遂げた技術とその価値を明確に伝えることができた。

もちろん、すべての企画が理想や構造だけで通るわけではない。
予算やコストを厳密に審議される場では、見積もりに対して、その企画がもたらす価値や効果が見合っていることを説明する必要がある。
ただしそれは、価値の定義や目標のすり合わせができていてこそ成立する議論だ。
価値が曖昧なままでは、コストの妥当性もまた語れない。

最後に

10年目のあの経験がなければ、
今回の整理も、この図解も生まれていない。

あのテーマ完了直後、自分のためだけに描いておいた、つたないドラフト図がある。

それをいま改めて「図解の本棚」のフォーマットに載せ、自分が納得できる構造として、6年越しに完成させた。

個人的な備忘だった図を、より多くの人が使える図解ツールへと昇華させたい。
それが、この図解を公開する理由である。

[4] NAVIGATION｜関連情報

過去の図解