僕は「エンジニアリングマネージャー」というものをやってます。

開発職は専門的な部分も多く、考え方や美徳とされること、仕事の進め方も独特なため、なかなか一般職の人がエンジニアをマネジメントすることは難しく、エンジニア出身者がその役割を務めるケースが多いです。

事業の状況変化に合わせたエンジニア組織体制や開発フローを考えるのですが、改めて「Spotify Model」と、中の人の「問題もいっぱいあったよ」という失敗談を読みました。

Spotify’s Failed #SquadGoals

https://www.jeremiahlee.com/posts/failed-squad-goals/

Spotifyの内状はさておき、これを読んで改めて「試してみたけど盛大に失敗したよ！」っていう情報のたいせつさについて考えました。

いわゆる一般情報や基礎知識、要約はChatGPTが誰よりも分かりやすく教えてくれるので、すでに「まとめ記事」は価値を失っていて、むしろ「やってみた」、いや「やってみたけど失敗した(照)」という情報のほうが、応用的に自分の状況に当てはめて考えらるので面白い。

外資系のIT企業に勤めたことがないので本当のところは分からないけど、彼らは「失敗から学ぶ文化」が確立していると聞きます。

誰が責任とるんだ、失敗は能力の欠如だというのはなくて、失敗は挑戦の証だよね、失敗談をフィードバックしてくれてありがとう！という文化。

これは本当にその通りで、僕のチームでもなにかシステム障害が起こった際は責任追及は行わず「次にもっと上手くやるためにはどうしたらいい?」っていうポストモーテムというイベントを開いたりしています。

そういうところから、開発者が「どんどん失敗してもいいんだ」と思える心理的にも安全な環境を作っていきたいなという考えです。今のところはこれでチームのパフォーマンスが落ちたすることもなく、根本解決を話し合えるチームが育ってきたなという感じです。

ところで、「深夜特急」というユーラシア大陸横断の旅を書いた沢木耕太郎さんが「旅をする力」という後日談の本を出されているんですが、その中で「巻き起こる風」のたいせつさに触れていました。

旅を描く紀行文に「移動」は必須の条件であるだろう。しかし、「移動」をのものが価値を持つ旅はさほど多くない。大事なのは「移動」によって巻き起こる「風」なのだ。いや、もっと正確に言えば、その「風」を受けて、自分の頬が感じる冷たさや暖かさを描くことなのだ。「移動」というアクションによって切り開かれた風景、あるいは状況に、旅人がどうリアクションするか。それが紀行文の質を決定するのではないか。 - 「旅をする力 第四章」

これを見て、失敗談、つまり実際にやってみて自分やメンバーがどう感じたか、組織がどう変化したかという話こそ価値があるんだ、というふうになんとなく繋がった感じがしました。