Rethinkingシリーズを書きながら考えていたこと - 違和感を追いかけて見えてきたこと

①違和感との出会い

正直に言うと、
私は最初から「設計」の話を書こうと思っていたわけではありません。

最初にあったのは、ずっと感じていた違和感です。

なぜ、管理しているのに進まないのだろう。
なぜ、決めたはずなのに戻るのだろう。
なぜ、説明したはずなのに伝わらないのだろう。

プロジェクトに関わるたびに、似たような光景を見ていました。

• 大規模なシステム開発

• 業務改革

• DX

• 新規事業

扱うものは違います。
業界も違います。
規模も違います。

それなのに、どこか同じ問題が繰り返されているように見えました。

会議では合意していたはずなのに、数週間後には別の話になっている。
確認したはずなのに、また同じ確認をしている。
順調だと言われていたのに、気づくと炎上している。

誰かが怠けているわけではありません。
能力が足りないわけでもありません。
むしろ、みんな真面目にやっていました。

会議もしている。
報告もしている。
資料も作っている。
レビューもしている。

だからこそ、私には不思議でした。
これだけやっているのに、なぜ思うように進まないのだろう。

問題が起きることよりも、真面目に取り組んでいる人たちが、同じところで何度も立ち止まってしまうことの方が、ずっと気になっていました。

最初は、個別の問題だと思っていました。

このプロジェクトの進め方が悪いのかもしれない。
この組織のコミュニケーションが悪いのかもしれない。
このチームの経験が足りないのかもしれない。

でも、いろいろな現場を見るうちに、少し考えが変わりました。

もし同じようなことが、場所を変えても、人を変えても、
何度も現れるのだとしたら。

それは、偶然ではないのかもしれない。

そう思った瞬間から、私の興味は「どう解決するか」ではなく、
「何が起きているのか」へ変わっていきました。

振り返ると、Rethinking Projectは、その違和感から始まっています。

何が悪いのかを知りたかったわけではありません。
誰の責任なのかを知りたかったわけでもありません。

ただ、何が起きているのかを知りたかったのです。

目の前で起きている問題ではなく、その奥で、繰り返し起きていることを。
一つのプロジェクトではなく、さまざまな現場に共通する何かを。

その問いを追いかけていくうちに、
「管理」「一貫性」「設計」という言葉に出会うことになります。

②管理について、考えていたはずだった

最初に追いかけ始めたのは、管理でした。
当時の私には、管理こそが答えに見えていました。

• 進捗が見えていない

• 課題が管理されていない

• リスクが共有されていない。

だから問題が起きる。

とても自然な考え方です。
実際、多くの現場でそう言われています。

• もっと管理しよう

• もっと見える化しよう

• もっと報告しよう

私自身も、そう考えていました。

でも、現場を見続けるうちに、
少しずつ違和感が大きくなっていきました。

管理されているプロジェクトも崩れる。

• 会議は行われている

• 進捗も報告されている

• 課題も整理されている

それでも、思うようには進まない。

• 順調です

• 問題ありません

• 予定通りです

そう報告されていたものが、
ある日突然、大きな問題として現れる。

もちろん、本当に突然起きたわけではありません。

後から振り返ると、兆候はありました。
違和感もありました。
小さなズレもありました。

でも、それは管理の対象にはなっていなかった。

ここで、私の中の問いが少し変わりました。

「なぜ失敗するのか」ではない。
「なぜ問題が起きるのか」でもない。

私たちは、何を見て管理しているのだろう。
そして、本当に見るべきものは何なのだろう。

そこで見えてきたのは、私たちが管理していたのは、
未来ではなく結果だったということです。

• 遅延を見ている

• 課題を見ている

• 障害を見ている

でも、それらはすべて、何かが起きた後に現れるものです。

管理しているつもりで、私たちは結果を追いかけていた。
では、本当に見るべきものは何なのか。

それは、結果を生み出す構造でした。

• どのように判断が行われるのか

• どこで情報が失われるのか

• どこでズレが生まれるのか。

• どこで問題が発生し得るのか

結果ではなく、結果を生み出す仕組みそのものです。
その瞬間、管理という言葉の意味が、少し変わりました。

管理とは、
進捗を確認することではない。
課題を監視することでもない。

管理とは、構造設計である

この一文を書いたとき、自分でも少し驚きました。
最初に抱いていた管理のイメージとは、
まったく違う場所へ辿り着いていたからです。

私たちが本当に管理すべきなのは、
結果ではなく、結果を生み出す構造だった。

これが、Rethinking Managementを書いて辿り着いた答えでした。

ただ、その答えに辿り着いたとき、説明できないことが残っていました。

• 管理の方法を変えても、認識のズレはなくならない

• 決めたはずなのに、また同じ議論になる

• 説明したはずなのに、人によって理解が変わる。

なぜなのだろう。

この問いが、Rethinking Consistencyを書くきっかけになりました。

③管理では、説明できなかったこと

その問いを追いかけながら、
私はもう一度、プロジェクトを見直してみることにしました。

最初は、認識を揃える方法を考えていました。

• 説明を丁寧にすればいい

• 確認を増やせばいい

• 認識を合わせればいい

そうすれば、この問題は解決すると思っていました。

でも、書き進めるうちに、
その前提そのものが少しずつ崩れていきます。

• 人が違う

• 役割が違う

• 工程が違う

• 時間も違う

プロジェクトは、最初から分断されたまま進んでいました。

そう考えると、認識が揃わないことも、
少しずつ解釈が変わることも、むしろ自然なことでした。

そこで見えてきたのは、「認識を揃える方法」ではありませんでした。

プロジェクトは、最初から分断されたまま進んでいたのです。

正直に言うと、最初はその考えを受け入れることができませんでした。
認識は、一度揃えれば、そのまま保てるものだと思っていたからです。
でも、現実は違いました。

• 同じではない

• 保てない

• 変わり続ける

それは、改善すれば解決する問題ではありませんでした。
プロジェクトそのものが、そういう性質を持っていたのです。

そして、ここで一つの疑問が残りました。
それなのに、プロジェクトは進んでいる。

• 問題は起きる

• 手戻りも起きる

• 認識ズレも起きる

それでも、プロジェクトは止まりません。

私たちは、同じだから進めているのではない。
変化の中でも、何かをつなぎ続けている。

この頃から、私はこの問題を、
「一貫性」という言葉で考えるようになりました。

一貫性とは、同じ状態を保つことではない
変化の中で、守るべきものをつなぎ続けること

そして、それは自然には生まれません。

だから、一貫性は設計されなければならない

この一文を書いたとき、
ようやく長く感じていた違和感に、言葉を与えられた気がしました。

これが、Rethinking Consistencyを書いて辿り着いた答えでした。

ただ、その答えに辿り着くと、今度は別の問いが浮かびました。

もし一貫性が設計されるものなら、私たちは何を設計しているのだろう。

④設計という言葉が変わった

最初は、設計という言葉そのものを、
もう一度考え直そうと思っていました。

それまでの私にとって、設計とは、
システム開発の中にあるものというイメージが強かったからです。

そこで、二つの設計を書きました。

一つは、プロジェクトを前に進めるための設計。
もう一つは、プロダクトやサービスを設計することです。

扱っている対象は、まったく違います。
だから私は、最初は別々のものだと思っていました。

共通点を探そうと思っていたわけではありません。
むしろ、違いを書き分けるつもりでした。

でも、書き進めるうちに、少し不思議なことに気づきます。
設計者が悩んでいることは、驚くほど似ていました。

• どこから始めるのか

• 何を優先するのか

• 何を守るのか

• 何を成立させるのか

状況が変わったとき、何を基準に判断するのか。

見ている対象は違います。
それなのに、考えていることは、よく似ていました。

そこで初めて、設計という言葉の見え方が変わりました。

設計とは、対象を決めることでも、
手段を決めることでもありません。

一つの方向へ進むために、
何を成立させなければならないのかを考えることでした。

最初は、こちらを選べば正しい。
こちらを選べば間違っている。

設計とは、その答えを探すことなのだと思っていました。
でも、書き進めるうちに、少し見え方が変わっていきます。

設計者は、正解を探しているのではありませんでした。

• 品質も守りたい

• コストも守りたい

• 使いやすさも守りたい

どれか一つを選ぶのではなく、
それぞれが成り立つ、そのバランスを探していたのです。

この考えに辿り着いたとき、
プロジェクト設計と、プロダクトやサービスの設計は、
一つの原理でつながりました。

そして、成立条件が複数ある以上、
状況が変わるたびに、新しい判断が必要になります。

だからこそ、設計者に必要だったのは、答えではありません。

• 何を優先したいのか

• 何を守りたいのか

• 何を成立させたいのか

その判断の軸でした。

変化は、これからも起こり続けます。
状況も変わります。
人も変わります。
新しい判断も生まれます。

それでも、進むべき方向は変わりません。

設計とは、変化の中で、未来への航路を描くこと

この言葉を書いたとき、ようやく「設計」という言葉が、自分の中で一本につながった気がしました。

これが、Rethinking Designを書いて辿り着いた答えでした。

⑤振り返ると、ずっと同じ問いだった

ここまで書いてきて思うのは、私は、
管理について書いていたつもりでした。
一貫性について書いていたつもりでした。
設計について書いていたつもりでした。

でも、振り返ると、
最初から同じ問いを追いかけていたように思います。

Rethinking Managementでは、
管理とは構造設計である
という考えに辿り着きました。

私たちが本当に管理すべきなのは、
結果ではなく、結果を生み出す構造でした。

Rethinking Consistencyでは、
一貫性は設計されなければならない
という考えに辿り着きました。

同じ状態を保つことはできない。

だからこそ、
変化の中でも、守るべきものをつなぎ続ける設計が必要でした。

Rethinking Designでは、
設計とは、変化の中で、未来への航路を描くことである
という考えに辿り着きました。

Managementを書いているときは、
Managementの話を書いているつもりでした。
 
Consistencyを書いているときは、
Consistencyというテーマに向き合っているつもりでした。
 
Designを書いているときも、
新しいテーマを書き始めた感覚でした。

でも、全部書き終えて振り返ると、一本の線でつながっていました。
 
それは、最初から意図していたことではありません。
書き終えて初めて、自分でも気づきました。
 
ずっと同じ問いを、少しずつ違う角度から見ていただけだったのです。

変化する世界の中で、何を見ればいいのか。
何をつなぎ続けるのか。
そして、何を成立させたいのか。

私は、ずっとその問いを書いていました。

だから、
Rethinking Projectは、
管理の話でもありません。
一貫性の話でもありません。
設計の話でもありません。

変化する世界を、どう理解するのか。
そして、その中で、何を信じて前へ進むのか。

その問いを追いかけ続けるプロジェクトなのだと思っています。

⑥そして、また次の問いへ

ここまで振り返ってきましたが、
正直に言うと、まだ答えは分かっていません。

もちろん、管理については、自分なりの答えを書きました。
一貫性についても、設計についても、今の答えを書いたつもりです。

でも、その答えを書き終えるたびに、また別の問いが見えてきます。

管理を書いていたら、一貫性という問いに出会いました。
一貫性を書いていたら、設計という問いに出会いました。

そして、設計を書いていた今、また新しい問いが見え始めています。

面白い問いは、
答えに辿り着いた瞬間ではなく、別の問いが見えた瞬間に現れる。

ここまでシリーズを書いてきて、
一番印象に残っているのは、そのことかもしれません。

振り返ると、Rethinking Projectは、
答えを探すためのプロジェクトではありませんでした。

問いを更新し続けるためのプロジェクトでした。

• 一つの違和感から始まる

• 考え続ける

• 一つの答えに辿り着く

• その答えが、次の問いを連れてくる

私は、その繰り返しを楽しんでいるのだと思います。

だから、この文章も、一つの結論ではありません。

今の私が、ここまで考えた記録です。
でも、それでいいのだと思っています。

考え続ける限り、問いは変わります。
問いが変われば、見える世界も変わります。

もし、この文章を読んでくださった方が、
どこか一つでも、同じ違和感を感じてもらえたなら。
あるいは、自分なりの問いを持ち帰ってもらえたなら。

このシリーズを書いた意味は、きっとそこにあります。

これから、どんな問いに出会うのか。
それは、まだ私にも分かりません。

でも、だからこそ、また書いてみようと思います。
 
Rethinking Projectは、まだ終わりません。
私自身も、まだその途中にいます。