遊星からの抽象X――抽象的な課題との闘いおよびその技法の記録――

本稿は、テックタッチアドベントカレンダー 19 日目の記事です。担当は canalun (twitter: @i_am_canalun_) です。

……

Why don't we just... wait here for a little while... see what happens?
「もう少しここで待って、何が起きるか見てみよう」
―― MacReady, from The Thing(邦題: 遊星からの物体X)

1982年、南極大陸にて基地隊員が得体のしれない物体との死闘を展開。その正体は未だ明らかになっておらず、それ（・・）はひとまず「遊星からの物体X」という名前を与えられた。

残念ながら、南極大陸で未知の怪物と闘うようなチームにとって、これから記されることはまったく役に立たないだろう。

しかし、スタートアップの宇宙を旅する私たちのようなチームからすれば事情は違うはずだ。なにしろその宇宙には恐怖の破滅的怪物すなわち物体Xに代わって、難解な抽象的課題すなわち抽象Xが数多く潜んでいるというのだから。

本稿は、テックタッチのプロダクトチームが「開発組織の体制をどのように変えるべきか」という抽象的な課題(問い)に立ち向かった過程を記録したものである*1。ただし、ただの日記ではスタートアップ宇宙を旅する仲間の助けにはならないだろうと考え、課題解決に関する有名な書籍等*2を参考にしながら取り入れたり考えたりした課題解決の技法を併せて記した。登場するいくつかの技法――「課題が解決策の裏返しで語られていないか確認する」「経過観察を必ず行う」などなど――は組織や経営の抽象的な課題に広く適用できるポテンシャルを秘めているはずだ。

あのまま抽象Xに全滅させられることなく生還し、これを書き残せているのも勇敢な仲間たちのおかげである。同じ宇宙の仲間に届くことを願って、ここにボトルメッセージを流す。

次の楽しい予定まで時間がないのなら、興味があるセクションやまとめだけでも読んでいってほしい。もしスケジュール帳につまらない予定しかないのなら、ぜひじっくり読んでほしい――ちょっとした退屈しのぎにはなるはずだ。

day 0: プロローグ ――組織の成長痛としての抽象X――

それ（・・）がどうして私たちの前に姿を現したのか、少し昔の話から始めなければならない。

すべてのユーザーがシステムを使いこなせる世界に――このテックタッチなる宇宙船がそんな壮大な理念を掲げて旅を始めた2018年、そのプロダクトチームは自分たちが理想とする組織像とは何かを雄弁に語った。

役職や階級といった上下関係を規定する制度と決別し、組織の意思決定に関わる権限があらゆるメンバーに均等に分散されている組織。組織と個人の目指すところが寸分違わず一致しており、完全に対等なメンバーが要所要所で必要な意思決定をすることで成功をおさめる組織。

組織形態に関心のある人であればこのようなコンセプトに聞き覚えがあるだろう。これは他ならぬティール組織である。そう、テックタッチのプロダクトチームはティール組織を理念としてきた。そしてそれは4年間変わってこなかった。

さて、これは機能したのか。答えは、YESであった。これまではこれで良かった、いや、これが良かったのだ。マネージャーを置かずに誰もが同質の大きな裁量を持つことで、組織は成長してきた。

では、これは機能し続けるのか。答えは、YESだとは思えなかった。

成長する組織の宿命からは逃れられなかったのだ。成長には痛みが伴う。プロダクトが育ち、組織の規模が大きくなる中で、ティールの理念はその現実的な持続可能性を問われなければならなかった。既に開発チームのメンバーは30人ほど。これだけ多くの人間がいる中で、ティールを組織の理想として掲げ続け、取り入れ続けることが本当にやるべきことなのか。事実、組織としてティールを貫徹できているかと聞かれれば、それも既に判然としない状態だった。

組織の在り方について抱かれる疑問は、ティールかそうでないかという理念の問題の範囲にとどまらなかった。実際の現場でも様々な課題の感覚が持たれ始めていた。

「いろいろな意思決定をもっと加速させられないか」
「役割分担をもっと明確にしていった方がいいのではないか」
「個人がチームに縛られていないか。チーム間の垣根がないか」

幸いなことに、テックタッチのプロダクトチームのメンバーは思ったことをとりあえず議論してみるというやり方を好んだ。日常的に交わされる議論の甲斐あって、組織の在り方について皆がなんとなく疑問を抱いているということを、皆がなんとなく知っていた。知ることができていた。

だからこそ、いつの間にか抽象Xがいた。いや、私たちの側が呼び寄せるべくして呼び寄せたのだ。「開発組織の体制をどのように変えるべきか」。そんな抽象的な問いが生まれていた。この問いは二重の意味で抽象的だった。第一に形あるものを扱った問いではないという意味で。そして第二にその問いの背後にある課題が具体的に何であるか、すなわち何を解決しなければいけないのかがまだ明確に見通せないという意味で。その怪物は他ならぬ私たちの手によって、宇宙船に招き入れられていたのだ。

5月の暑い日にCTOからこんなSlackメッセージが投稿された。

プロダクトチームの方へ、「組織マネジメントWT」発足のご案内
プロダクトチームはティールとまではいかないまでも、マネージャー職を設置しておらず、階層のないフラットな組織運用になっておりますが、今後上場準備を進めていく中で ...略... 統制の仕組みが求められてきます。
...略...
今までは事業全振り（立ち上げ最優先）でやってきた感がありますが、より経営を安定させ、もっと大きなビジョンを持てるように、冒頭の「組織マネジメントWT」を発足し、現状の課題の整理と、次の組織設計に必要な改善案を一緒に考えてくれる方を募集します。

...略...
募集人数が少なければ、こちらからお声がけさせてもらい、大勢いた場合は、その時進め方検討させてくださいｗ
※WTに入らなくとも、一通り皆さんの意見を聞きつつ進めていく予定なのと、しっかり議論をオープンにしていきたいと思っています。
やりたいという方は、是非スレッドでコメントください！

――テックタッチCTO 日比野淳, 社内Slackの実際のメッセージより一部抜粋

ティールを掲げていたおかげかは定かではないが、皆のことを皆で議論して決めるという文化はしっかりと根付いていたようだった。驚くことに、投稿して1日が経つころには30人のチームのうち既に8人が協力したい旨を表明していた。

こうして、この抽象Xに相対するチームが結成された。このチームは週に1回会社に集まり、1ヶ月から1ヶ月半でこの闘いに蹴りを付けることを目標とした。

これは、その闘いの記録である。

day 1: 活動計画の策定 ――抽象Xに立ち向かうための作戦会議――

当たり前だが、ことはそう単純ではなかった。

私たちは、まずこの怪物にどう立ち向かうかを考えなければならなかった。この抽象的な課題の答えが必要な時期まで、残された時間はそう長くなかったからだ。1ヶ月から1ヶ月半。要するに、無駄な検討や手戻りによるロスは極小化される必要があった。

そこで、下記の流れに従おうという話になったのである。

1. 課題の特定
2. 課題の整理
3. 課題の優先順位付け
4. ソリューション仮説の作成
5. ソリューション仮説の検証・具体化

これは元マッキンゼーコンサルタントCharles ConnとRob McLeanが唱えるフローや、有名どころでは「イシューからはじめよ」で言われているようなことの変奏である。私もこの会社で働いていた経験があるが、上の流れに違和感はなかった。

1. 今本当に答えを出すべき問題＝「イシュー」を見極める

2. イシューを解けるところまで小さく砕き、それに基づいてストーリーの流れを整理する

3. ストーリーを検証するために必要なアウトプットのイメージを描き、分析を設計する

4. ストーリーの骨格を踏まえつつ、段取り良く検証する

5. 論拠と構造を磨きつつ、報告書や論文をまとめる

――安宅和人「イシューからはじめよ」P34

ところで、これら一つ一つのフェーズで言われていることは当たり前のように思えるかもしれないが、こうして明文化することでメンバー全員がフェーズをきっちりと切り分け、常に議論の目的を共有することができる。ここに大きな価値がある。

「いま何のために何を議論しているのか」はもちろん、もっと言えば「いま議論しなかったことはいつ議論されるのか」も含めて、皆が共通認識を持っていることの価値――裏を返せばそれを持っていないときの問題――は誰もが身を以て知っている。

分からなくなったら、いつだって先の流れに立ち返って「いまどのステップだったっけ？」と問い直せばよい。問題解決ステップの明文化は、ともすれば迷宮に迷い込む私たちに与えられたアリアドネの糸なのだ。

さあ準備が整ったところで、抽象Xとの闘いを進めよう。

day 2: 課題の特定 ――抽象Xよ、お前はいったい何なんだ――

まずは初めのステップ、課題の特定である。

このステップの目的を平たく言えば、自分たちの組織がどのような課題を持っているのか洗い出すことである。これはすべてのスタート地点となるため、とにかく出しきることが重要だった。ここで何か言いそびれれば、後々になってすべてがひっくり返ったり、重要なことが話せないまま進んでいるモヤモヤ感を誰かが抱いたり、といった展開が生まれてしまう。もちろん散らかったままでは対処ができないので整理はするが、それは次のステップの話なのだ。「発散と収束」なるクリシェを拝借するならば、ここではもっぱら発散に集中するべきなのだ。全集中・発散の呼吸である。

というわけで各々が課題だと思っていることをとにかくmiroに付箋で貼っていく作戦に出た。実際に出た意見をいくつか列挙してみる*3。

「物事を進めようとすると色々なグループをまたいでしまう。そして会議になると参加者が爆増して、意思決定のスピードがどんどん落ちている」
「スクラムで管理していないプロジェクトの進捗が見えづらい」
「もっと簡単にチーム移動や職務移動ができるようになってもいいと思う」

などなど。多種多様な意見が出た。

あとになって思えば、とても良い雰囲気で意見出しができていたと思う。整理はあとでするのだからこの段階ではまだ感覚に基づく話でもいいのだ――そんなふうに皆がなんとなく思っていたのかは分からないが、否定したり反論したりは誰もしなかった。

ざっくばらんでもいいから、とにかく思っていることを出せる。このような「酒場」的な雰囲気について、Wiiの企画担当であった玉樹真一郎はこう述べている。

アイデアを出し合う場所では、多かれ少なかれ人はプレッシャーを感じているものです。

そんな状態で「何でもいいから発言してください」と言われても、参加者は逆に困ってしまいます。現に、私自身が「怖い」と感じてしまっているぐらいです。...略...

冒険の酒場にふさわしい雰囲気を作るところから、始めましょう。

――玉樹真一郎「コンセプトのつくりかた　「つくる」を考える方法」P104-105

もちろんこの書籍で言われるコンセプトワークと私たちがやっていることとは少し異なるが、アイデアを出し合うという点では共通しており、やはり「酒場」的な雰囲気は大事だろう。

幸い、普段から社内やメンバーの雰囲気が明るい組織であることも相まって、その場はすぐに「冒険の酒場」へと姿を変えた。これは大きかった。

また、もしかしたらここでも、いまは何をやるフェーズであるかの共通認識を持っていることが効いていたのかもしれない。あとで収束すると分かっているからこそ安心して発散できる、そんな側面もあったのかもしれない。

day 3: 課題の整理 ――抽象Xは姿を変える？いや抽象Xの姿を変える――

嬉しい悲鳴とはまさにこのこと。貼られた付箋の枚数は40枚ほどにのぼった。

問題はどのように整理するのかであったが、私たちとしては、この後のステップで優先順位付けができる形になれば何でもよかった。そこでひとまず、この幾多の付箋を数個のグループに分け、グループごとの関係性を明らかにできればそれで十分ではないかと考えた。

結論から言うとこれはうまく機能した。具体的には、一つ一つの付箋を丁寧に深堀りしながら、①課題の分類、②課題内容の精緻化を思いつく限りやっていった結果、良い構造化ができたのだ。思いつく限りというのは要するに「いまは分類の時間だ！」などと限定することなく、「これ似ているな」と思ったらすぐに分類してしまったり、「ところでさっきの付箋で気になることがあって」と好きなタイミングで精緻化してみたり。要するに自然な流れに任せたということである。乱雑に散らばったアイデアを収束させていく作業は一定、発見的であるから、定まった手順を踏むというよりはこのようなやり方が機能しやすいのかもしれない。もちろん分類も精緻化も、やってみた結果を眺めながらもう一度考えてみるという繰り返しが何度か必要だった。

ここでは、それぞれの作業をどのように行ったかを具体的に書いてみる。

day 3-A: 課題の分類

これは似たようなものをまとめてみるということである。

まずは各付箋に書かれた事象について皆で理解する。そうすると割と似たような付箋があることに気づく。

「自分を見つめ直して成長につなげられるようなフィードバックや評価がもっとあってもいいかも」
「普段から仕事のやり方や内容にもっとアドバイスがあると嬉しい」

このような付箋同士は「成長のためのフィードバックが不足」のようなカテゴリーを作り、まとめることができる。

ただ、これをやっただけではどのカテゴリーにも入らない単体がパラパラと残ってしまう場合もあるだろう。それらをそれぞれ独立した課題として扱うのも良いが、深堀りしてみると案外つながっていることが分かるときもある。すなわち、その課題の原因(なぜ起こっているのか)や影響(何を引き起こしているのか)を議論することで共通点が浮かび上がることもあるのだ。エンジニアの開発現場に引き寄せた例で言えばこういうことである。

「PRのレビューにめちゃ時間がかかる」
↓「なんでなんだろう？？」
「そもそも時間が取りづらい気がする」
↓「なんでなんだろう？？」
「誰か一人に集中しちゃうことがある。タイミングの問題かなあ」
↓「他の人はできないのか？？」
「その部分はその人しか分からないことが多くて」

「バグ修正が思っていた予定に間に合わないことがある」
↓「なんでなんだろう？？」
「急に別のトラブルが発生して対応に追われることが多い」
↓「他の人に任せられないのか？？」
「その部分は自分しか分からないことが多くて」

現実にはもっと複雑なことも多いが、このように一見すると異なる問題が結びつくこともやはりある。「PRのレビューにめちゃ時間がかかる」という付箋と「バグ修正が思っていた予定に間に合わないことがある」という付箋を、「円滑な業務遂行に必要な知識の分散がなされていない」というカテゴリーの下に持っていけるのである。

なお、上の例のように「なんでなんだろう？」というfive whysにも通じるやり方で道を切り開けることが多いが、「結果、何が起きているんだろう？」という逆の問いかけも時には有効であろう。

day 3-B: 課題内容の精緻化

課題を分類しつつ、課題の内容への理解を深めることも非常に重要である。

特にこのタイミングで、各課題について裏付けとなるファクトがあるのかを気にしてみても良いだろう。よくよく考えるとそこに書いてあることが単なる印象論だと分かることもある。例えば「会議の人数が多すぎる」という付箋を見たら「具体的にはいつのこと？」「いつもそうなの？」という問いかけをしてみよう。既に終わった単発プロジェクトでの話だったなら、そのプロジェクトの振り返りを別途してもらうとして、ここでは課題として取り上げなくてもよいはずだ。

また、「解決策の裏返し」で語られている課題にも注意しよう。例えば先ほど出てきた「成長のためのフィードバックが不足」という課題カテゴリーは、この罠に陥っているかもしれない。このような問いかけをしてみよう。

「成長のためのフィードバックが不足している」
↓「何がまずいの？？」
「みんな仕事のやる気が出ていない」
↓「やる気が出ていない！？そんなことあるかなあ？？」
「従業員のモチベーションアンケートがそれを示している」
↓「なるほど……そのアンケート結果からフィードバック不足が原因とまで分かるの？」
「うーん、自分とあの人はそう思っていたけど実際に確かめてはいないなあ」

この会話によって下記の2点のことが明らかになった。

1. 実際に起きているのは、従業員のモチベーションの低下である
2. モチベーション低下の原因がフィードバックの不足であるかは不明

こうなると「成長のためのフィードバックが不足」という課題認識は妥当性を欠いていることになる。それは早とちりであるし、その認識のもとでは「従業員のモチベーション低下」という事象に対して、ソリューション案が「フィードバックを与える」ということだけに絞られてしまうのだ――モチベーション低下の原因がフィードバックの不足であるかは全くわからないのにもかかわらず。

要するに「XXが存在しない」とか「XXが十分ではない」といった形式で語られる課題認識は、解決したい事象に対するソリューションの幅を、決め打ちで無根拠に狭めている可能性があるのだ。もちろん、念頭に置かれているソリューションは正しいかもしれない。ただ、本当に問題となっている状況やその本当の背景を正しく認識することに注意すべきである。「XXが不足している」という解決策の裏返しとして語られる課題に対して、私たちはその更に裏返しを読む必要があるのだ。

ただ一方で、深堀りをしているうちに厳密さの囚人になってしまうことも避けたい。例えば次のようなフレーズを聞くことがある。

「それは原因であって、課題ではない」
「それは単なる状況であって、問題ではない」

至極当たり前だが、このような定義の厳密性は有用なときもあれば、全く役にたたないときも同様にあることに注意したい。

そもそも課題と原因を厳密に分けて考えるのは簡単ではない。「スクラムからはみ出しているプロジェクトが、ちゃんとマネジメントされていない」という事象は課題だろうか。それとも、これは「プロジェクトが遅延してしまう」ことの原因だろうか。もしくは本当の課題/原因は「すべてのプロジェクトをスクラムで管理していないこと」なのだろうか。もちろん課題と原因は全く異なる概念ではあるのだが、具体的な事象をどちらであるとみなすかについては微妙な判断になることが多々ある。

事象を深ぼることはとても価値のあることである。先述のように事象間のつながりを見つけられることもあれば、そもそも事象の理解をするうえで不可欠な行為である。それと同じように、何が課題で何が原因かという議論も一定の共通認識を持つうえでは必要なことだ。

しかし、私たちの課題分析が目指しているゴールはあくまでも「いま起きている悪い事象を取り除くこと」であり、物事を実際に前に進められなければ意味がないのだ。言葉を弄くり倒しても、事態が進展しないのなら無意味だ。この「課題内容の精緻化」ステップひいては多くのビジネス的な議論においては、ある程度の共通認識が揃えばそれで及第点、いや満点なのである。もちろんどこまで行ってもケースバイケースではあるが、先ほど例に挙げた問題も「スクラムからはみ出たプロジェクトが遅れがち」くらいでひとまずまとめておけばよい。このあとのステップで高い優先順位が付いたなら、そこで初めてもっと真面目に「原因」とやらの究明を始めればよいはずだ。

厳密さは大事なときもあるが、特にグループで話し合っているような場合にそれを気にして議論活動が縮小してしまうのはもったいない。

とにかく、このフェーズの目的は優先順位を付けるための整理である。適当な大きさで意味のある単位に課題をまとめることができれば、そしてその各課題の内容について共通見解を持っていれば、それで十分なはずだ。このあたりはバランス感覚が重要だと感じる。

さて、このフェーズの結果として当初「開発組織の体制をどのように変えるべきか」と語られていた抽象Xは7つほどの小課題に形を変えた。下記は実際の結果をもとにしたイメージである。

整理された課題(イメージ)

解決すべきことは言語化され、抽象Xの輪郭がくっきりとした。漠然とした抽象的課題はいまや一定の具体性を持った小課題にブレークダウンされ、それら小課題についてのしっかりとした共通認識も深堀りを通じて持つことができていた。

day 4: 課題の優先順位付け ――抽象Xを倒しきろうという無理難題――

ではさっそく解決策を議論しよう！といきたいところではあったが、ソリューションの議論にはまだ触れられない――いまだu can't touch thisである。

疲れた頭をヒップホップで癒やせば明らかだ――いまここで必要なのは優先順位である。というのも先述の通り、抽象Xは今や議論可能な7つの小課題に分裂したが、すべてのことに同時に取り組めるほどのリソースを私たちが抱えているわけではないからだ。

この段階では実直に、比較のための軸をいくつか言語化したうえで、各小課題について評価をしていった。振り返ってみてここで大事だったと感じるのは――当たり前なのだが――物事の根拠を確認しながら議論をすること(day 3-B セクションを参照)、そして軸の定義を明らかにしておくことである。特に、分かりやすい言葉で明確な議論をする(「ふわっとした言葉」を極力使わないようにする)ことは、議論に参加しているメンバー数が多いこともあって大事だった。

ところでこの優先順位付けのステップは、今回の課題解決フロー(下記)の中で明示的に意思決定をする初めてのフェーズであった。

1. 課題の特定
2. 課題の整理
3. 課題の優先順位付け
4. ソリューション仮説の作成
5. ソリューション仮説の検証・具体化

解決したい課題を選ぶことは、同時に解決しない課題を選ぶことでもある。優先順位付けは課題解決の流れを大きく規定するので、ここは特に慎重になった。また、これは組織全体を巻き込む意思決定でもあったため、他メンバーへの説明責任を果たせるようにしっかりと議論することも意識した。

結果、主に影響範囲の広さや緊急性を鑑みて、私たちは「各チーム・部門がより迅速な意思決定をできるようにするために何をすべきか」という小課題のソリューションについて考えることにしたのであった。

day 5: ソリューション仮説の作成 ――抽象Xに対する具体Y――

私たちはとうとう具体的なアイデアを考える段階にたどり着いた。

このステップではソリューションの仮説をなるべく多く持つことが目的である。検証はあくまで次のステップでの話だ。発散と収束を切り分けよう。要するにここでは「こんなアイデアもある、あんなアイデアもある」という状態になればよい。

なお、このとき私たちが検討対象としていた課題は先述の通り、「テックタッチにおいて各チーム・部門がより迅速な意思決定をできるようにするために何をすべきか」であった。些細なことではあるが、課題の書き方を「答えを出したい問い」の形に変えることで少し問題が考えやすくなっていたように思う。もともとは「各チーム・部門の意思決定が遅い」という文言で考え始めたが、「各チーム・部門がより迅速な意思決定をできるようにするために何をすべきか」という将来の目標(「各チーム・部門がより迅速な意思決定をできる」)を埋め込んだ文章にすることでイメージがしやすくなったように思う*4。

さて、このように課題の形を定めたうえでアイデアの発散に入った。付箋に思いつくソリューションを書いていく。ここまで来ると手慣れたもので、その後は課題の特定・整理と同様に、各付箋の深堀り・グルーピングという流れへと自然に移っていった。

ところで、ソリューション案を出す際は取りこぼしがないよう、色々な切り口で考えてみるとよい。例えば「各チーム・部門がより迅速な意思決定をできるようにするために何をすべきか」という今回の例について、「チーム間連携時のコミュニケーションラインの確立」という解決策があったとする。このとき、これがチーム間のいわば水平的な話であるとして、では垂直の話はありうるかと発想してみる。そこで例えば「CTOを巻き込んだ意思決定フローの明文化」のようなアイデアが出れば儲けものである。このように、いろいろな軸を以てアイデア群を眺めることで網羅的に考えることが有用である*5。

さて、このようにして実際に多くの案が出せた。そこから似たようなソリューション同士はより本質的な新しい一つに置き換えてみたり、成功する見込みがないことが既に明らかなものは消してみたりを通じて、3つのソリューション案が残った。下記に、実際の議論の記録を一部掲載する(編集済み)。ちなみに、ここではバーバラ・ミント著「考える技術・書く技術」第2章「ピラミッドの内部構造はどうなっているのか？」あたりの内容を意識したメンバーもいた。

ソリューション仮説の整理結果(イメージ)

ところで専門家の意見はこのフェーズにおいて非常に有用である。もちろん課題の特定や整理のフェーズでも話を聞けるなら聞きたいのだが、如何せんその段階ではこちら側もまだ状況を整理しきれていないことがある*6。一方で、この段階まで来るとチームの議論も地に足のついたものになっていることが多いはずで、知識が豊富な人間に適切な質問や深堀りがしやすくなっている。実際テックタッチでもこのくらいのタイミングで外部の組織コンサルティング会社に意見を伺い、素晴らしいインサイトを得られた。

さて、こうした議論の果てに私たちは下記のソリューションを検討することにした。

• 何かを決定するときに、誰とどういう流れで決定のステップを踏んでいけばよいかをルールとして定める
• 各チームが責任を負っていることを明確にして、その決定権も与える
• チームの意見を取りまとめる人・チームへの問い合わせに最初に応える人を決める、チームの権限と責任の範囲内で実行を決定する

day 6: ソリューション仮説の検証 ――さらば抽象X、後ろに戻る勇気をこめて――

ここからはソリューションの仮説を検証する。課題を解決するためのアイデアが本当に機能するかを考えてみるのだ。この段階までくると、抽象的な課題との闘いという色合いも薄れ、通常の業務でも多く行われるような具体性の高い議論になってくる。

例えば今回は「各チームが責任を負っていることを明確にして、その決定権も与える」「チームの意見を取りまとめる人・チームへの問い合わせに最初に応える人を決める、チームの権限と責任の範囲内で実行を決定する」といった仮説に対して、それらが実現されるような新しい組織設計を検討した。「チームはこう分けた方が良い」「各チームの権限はこうすると良さそう」といった議論を通じて、これらのソリューションが本当に機能するかを確かめたのだ。

ところで、このようなソリューション具体化の過程において、これで絶対にうまくいくという確信を持つことは当然不可能である。異なる文脈でなされた哲学者ジジェクの発言がここでも当てはまる――「我々は常に、確固たる知識をもたずに人生を運命づけるような事柄について決定を下さなければならないという立場に置かれる」のだ。有限の時間の中で有限の情報とともに生きる私たちは、どこかで決断して前に進む勇気を奮わなければならない。

一方で経過観察が重要な理由はここにある。組織課題に限った話ではないが、意思決定に対する振り返りは必須だ。テックタッチでも今回導入するソリューションが機能しているかの検証を、導入後6ヶ月で実施する運びになった。このように経過観察をして、もし失敗していたらやり直せばよいのだ。むしろやり直す余地が残るようなソリューション設計ができるならそうすべきである。勇気は前に進むためだけにあるのではない。勇気は後ろを振り返り、後ろに進むためにも奮われるべきだ。

afterward: エピローグ ――冒険のおわりに……いやはじまりに――

このようにして「開発組織の体制をどのように変えるべきか」という漠然とした問いを具体化し、構造化し、最終的に具体的な策に落ち着けるに至った。この流れの中で登場したレッスンを再度ここにまとめてみよう。

• day 1: 最初から最後までどう進めるかを明文化することで、メンバー全員がフェーズをきっちりと切り分けて常に議論の目的を共有することができる
• day 2: 発散のフェーズでは何も気にせず発散する。否定したり反論したりはあとにする
• day 3-A: 「なんでなんだろう？」「それで何が起きているのか？」をキーワードに課題を深ぼっていく
• day 3-B: 「解決策の裏返し」で語られている課題に注意する。一方で、言葉の定義に拘泥しない
• day 4: 解決したい課題を選ぶことは解決しない課題を選ぶことである
• day 5: いろいろな軸でアイデア群を眺め、網羅的なアイデア出しをする。遅くとも、ある程度状況が整理されてきた段階で専門家の意見を取り入れる
• day 6: ソリューション実施後、経過観察をする。やり直す余地をなるべく残しておく

課題も状況も組織によって千差万別なのだから、一般化されたレッスンは抽象的にならざるを得ない。実際、このように書いてみるとどれも当たり前のことに思えてしまう。ただそうは言っても、今回の旅を振り返ると、基本をしっかりとおさえて議論を進めたことが成功の鍵だった実感がある。

また、メンバーの当事者意識が強かったことも大きかった。どのステップのどんな話し合いのどんな些細なことであっても、皆が真剣に向き合っていた。組織全体に関わる話に多くのメンバーが関心をもって、積極的に議論する雰囲気がひとまずの怪物撃退につながったのだと思う。これは皆の、皆による、皆のためのチームなのだ。

……

さて、私たちが抽象Xと闘ったときの話はこれでおしまいだ。この記録が、今日も至るところで繰り広げられているだろう闘いのちょっとした助けになることを願う。

だいぶ長くなってしまったが、そろそろ私たちのもとにまた次の抽象Xが現れる頃だろう。スタートアップの宇宙を旅する私たちは何回でも闘わなければならない。マクレディのように「もう少しここで待って、何が起きるか見てみよう」などと悠長なことを言っている余裕は全く無いのである。

Why don't we just... wait here for a little while... see what happens?
「もう少しここで待って、何が起きるか見てみよう」
―― MacReady, from The Thing(邦題: 遊星からの物体X)

*1:本旨が伝わりやすくなるよう、実際の時系列に対して編集を加えた記録です

*2:「イシューからはじめよ」や「考える技術・書く技術」、はたまた「コンセプトのつくりかた」などなど

*3:一部改変しています

*4:加えて、末尾を「何をすべきか」とアクションを問う形に書くことも良いと言われる。理由はいくつかあるが、ここでは割愛

*5:もちろんこれはあらゆるアイデア出しに有効である

*6:それでも巻き込めるならどんどん巻き込めばよいのだが、コストや時間の関係でコネクションが限られることもやはりある