読書メモ。2025年36冊目。
『成功する開発チームの作りかた 対話と信頼の好循環』を読んでの感想となります。(2025/6/10記載)
本の概要
本書は、チーム開発における以下の各フェーズ、各イベントごとにメンバー同士がしっかり対話をすることで関係性を構築し、心理的安全性のあるチームを作っていこうという内容です。
・結成: チームビルディング
・運営: デイリー、振り返り、レビュー会、リリース、新メンバーのオンボーディング
・解散: 総括タイトルにも入っている「好循環」というワードは、チーム内での対話を基礎にして信頼関係を作り上げ、その信頼関係の上で改善やチャレンジをすることでさらに信頼関係が強固になるというサイクルです。このサイクルをたくさん作り出すことができれば逆境にも耐えられる強くてしなやかなチーム、つまり成功する開発チームを作り上げることができます。
ソフトウェア開発において、「技術力」だけではチームは前に進みません。自分と相手とチームというものの理解から始め、対話と信頼によって好循環を育み、成功する開発チームをつくる一歩を踏み出しましょう。
引用:
動機
-
著者のプログラミングをするパンダさんの登壇資料をチームで参考にさせて頂いている。
-
先日のTSKaigiでのご登壇も翌日チームメンバーと感想を話し合い学ばせて頂きました。
-
チームについてどんな本なんだろうと気になっていたら、技術書典のブースがご近所であることを知りご挨拶と共にご本を交換させて頂きました…!
感想
自分と同じはじめて書いた本のはずなのに、完成度の高い一冊で驚きました。
さらに、冒頭の本文に生成AIを利用していないという注釈に、プログラミングをするパンダさんの誠実さを感じました。
各章で整理された知識と経験を、私自身の経験や考えと照らし合わせることで、多くの気付きと学びを得ることができました。
技術書典では近いジャンルのサークルが同じブロックに集まるようにしているという話がありますが、自分の本で書きたかったことと重なる部分も多く、親近感を覚えました。
そのうえで、私の本があくまで私的な反芻であるのに対して、プログラミングをするパンダさんの書籍はチームに対する施策と向き合っており、等身大で学ぶ部分が多くありました。
一番根幹の部分で参考にしたいと思ったのは、本書に記載の哲学対話でした。
私はコミュニケーションに苦手意識があり、どうしても一方通行になってしまったり、結論を急ぎたがるところがあります。
その結果、真因にたどり着けず、もう一歩のところで議論が終着してしまうことがあります。
プログラミングをするパンダさんの文章からは、そうした「考え抜くこと」への誠実な姿勢を感じ、大きな刺激を受けました。
忘れたくないメモ
■状況リソースと経験リソース
エンジニアがクリーンなコードを書く意義はここにあります。例えば、レガシーコードに対して改修を加えようとしたときに、変数名がおかしくてどんな値が入っているかわからないとか、処理が200行も300行も長くなっていて、何をしているのかよくわからないというケースがあります。これはコードという状況リソースが複雑であるため、自分の経験リソースに照らしてもここを書き換えたらこう動くという結果が見えづらいのです。つまり、環境に対するシミュレーションがしづらいのです。
学習コストとして大雑把に捉えていたものが、状況リソースと経験リソースという2つの軸で細分化した捉え方ができるようになる気がしました。
■クリーンなチーム
クリーンなチームであること、つまり状況リソースが適切に整えられていることで、自分の経験リソースもフル活用できます。すると、そのクリーンなチームでは、 それぞれの人が自分のスキルをフルに発揮できるチームだと言えるでしょう。
新しいメンバーのオンボーディングを考えるとき、対応するシステムや開発プロセスを明瞭化した資料を揃えることに意識が向かっていましたが、チームの状況を整えることも同じように意識すべきと気付きました。
■他の人の経験をチーム全体の経験に
新しいトライやチャレンジを歓迎し、他の人の経験をチーム全体の経験として捉え、メンバー同士協力しあって次回は良い結果にまで導けるようにするのが真のチームだからです。
自分の経験をチームの経験に近づける視点は持てていたものの、他の人の経験をチームの経験に近づけることに、主体性を持って意識できていませんでした。改めて、チームに視点を持つ重要性に気付きます。
■チームにとっての好循環
本書でこだわっている好循環とは、チームメンバーが対話をして相互理解を深めた上で、チーム目標のスムーズな達成を阻害する課題の発見と解決を通して、チームに信頼関係、協力関係を構築し発展させることなのです。
チームが主語であり、フィードバックを受けて次を目指すのもチームである。
そうすることで、チームが活性化するフィードバックサイクルを作り出すことができると理解しました。
■振り返りにはKPTを使わない方がいい
KeepやProblemというラベリングを与えられているため、思考の枠が制限されるということです
意識せずKPTを扱ってしまっていたことに気付きました。
KPTでふりかえれば、KPTの観点ではふりかえれるけど、それ以外の観点は埋もれてしまう。
チームで目指したい目的にあった手段を選ぶべきだと理解しました。
■オンボーディング期間は非日常
オンボーディング期間はある種の非日常です。非日常だからこそ、仕事ではなく相手に向き合える時間を作れるのです。このタイミングを逃して日常に戻ってしまうと、なかなかその人の持つ価値観や背景について話すタイミングはありません。
日々の仕事が始まってしまうと日々の仕事が関心事の中心になってしまう。
そうすると、日々の仕事から外れた大切なことに接しづらくなります。
新しいメンバーがチームに馴染むためには、仕事以外の重要なことを扱える時間を大切にすべきと理解しました。
■未来の情報を手にして過去の問題を解く
未来の情報を持ちながら、自分たちが直面した過去の課題を改めて確かめてみるのです。それを今の自分たちならどう解き直すかと考えたり、今から考えると別解があるのではないかとあれこれ議論しましょう。
ひとつの大きな出来事に対して、個人でのふりかえりや学びはできていたつもりでしたが、個人の解釈をチームの解釈に、個人の学びをチームの学びに昇華するという意識が薄かったことに気付きました。
追いたい参考文献
・参考文献
本書の参考文献(一部)です!
— 技術書典さ03 プログラミングをするパンダ (@Panda_Program) 2025年5月31日
うまくデザインできてニッコリ(ありがとう「ノンデザイナーズ・デザインブック」) https://t.co/rmqZKeC3Wi pic.twitter.com/v82U22dwOx
『Team Geak』、先日のSHIFT Agile FESでクリエーションライン安田さんもご紹介されていました。
積んで久しい1冊のため、そろそろちゃんと読みたい。
・映画「スティーブ・ジョブズ 1995~失われたインタビュー~ 」特別映像
今から30年前のインタビューとは思えない普遍性。
コンピューターは手段でしかないと30年も前に言っていたことに唸りました。