技術的負債に立ち向かう、 ひとりから始めるチームづくり / From One to Team: Building Momentum Against Technical Debt

現場から始める──変化・負債・拡大に向き合うチームの実践知
https://devkan.connpass.com/event/364829/

Transcript

1. 技術的負債に立ち向かう、
 ひとりから始めるチームづくり
 FUJII Yoshitaka (@yoshiyoshifujii) 
 2025-08-08
 現場から始める──変化・負債・拡大に向き合うチームの実践知 DevLOVE関西 

2. 前提
 • 10年以上運用されているプロダクトの現場
 ◦ 大規模でミリオン以上のユーザー数 
 • 技術的負債が多様でどこから手をつけていいのか分からない
 ◦ EOL祭、仕様不明、初期メンバー不在、コードのノリが複数混在、とにかく1ファイルが長い 
 • 現場に任せて何とかなるならもうなっている
 ◦ もちろん現場だけでなくマネジメントにも問題がある 
 • 新規開発を止めることはできない
 ◦ ほんとうにそうなのだろうか。だがそうしておきましょう 
 • 戦略的に取り組まないとどうしようもないんじゃないかと素直に思う
 ◦ ということで何度かトライしたが失敗した経験を持っている 

3. ある日
 • マ「技術的負債をなんとかしてほしい」
 • ふ「わかりました。いまってどうなってるんですかー」
 • マ「こんなシステム構成図でー、EOLが過ぎててー、オンプレとAWSとk8sがあっ てー、新機能を開発すると時間がかかってー、障害も多くてー、不整合をよく起こし ててー、問い合わせ対応も多くてー…」
 • ふ「わかりました。じゃあちょっと観察してみますねー」

4. ミッション
 技術的負債があるので何とかしてほしい。
 だが、何をしたらいいのかは、正直、分からん。
 とにかく何とかしてほしい。

5. 観察からはじめよう
 • くもりなき眼で観察をはじめた
 • あらゆるミーティングに参加した
 • だれがよく発言しているのか
 • だれに質問が集中しているのか
 • だれが意志決定しているのか
 • コミュニケーションに着目する

6. コミュニケーションから見えてくる構造
 • なぜ、その人の発言が多いのだろう
 • なぜ、その人に質問が集中するのだろう
 • なぜ、その人が意志決定をしているのだろう
 • その人だからなのか、役割なのか、役職なのか、性分なのか
 • 社歴？経験？声が大きい？所属しているチームの責務？

7. 人の先にあるシステムの構造
 • 役割、役職、チームを特定する
 • ステークホルダー と ドメイン が見えてくる
 • アクターと箱を書いて、つながりを線で結び、モデリング
 • コンテキストマップ を用いて、コミュニケーションの旅にでる

8. コミュニケーションの旅
 • そもそも誰と話したらいいのか分からない
 • コンテキストマップを持って、マネージャーに相談
 • 人と人を繋ぐことに、マネージャーはコミットする
 • 仲間になってくれそうな人を探す
 • 壁打ち相手はいないだろうか

9. 壁打ち相手
 • ひとりで考えると主観しか得られない
 • 客観性は、他人から得る
 • 現場に理想がある場合とない場合がある
 • 理想がある
 ◦ 積極的に相談しましょう 
 ◦ 視座は同じ
 ◦ 理想を擦り合わせて、課題を浮き彫りにし、共に立ち向かいましょう 
 • 理想がない
 ◦ 課題を知覚できない 
 ◦ なるほど、おっしゃる通りですね 
 ◦ 同じ視座で話せないなぁ 

10. 課題の知覚
 • 課題は、現状と理想のギャップ
 • 理想がないと、現状に課題を感じない
 • 現場に課題がないのは、理想がないから
 • 理想を持つにはどうするといいのか

11. なぜ理想を持てないのか
 • 昔はあったはず
 • 日々の業務に追われている
 • 問い合わせ爆発、障害対応爆発、整合性復旧爆発
 • なぜそうなっているのか経緯が分からず理解し難く混沌
 • そして思考停止…

12. 「無知の知」 - ソクラテス
 • 「不知の自覚」と訳すべき論があるらしい
 • 知らないという状態であることを自覚する必要があるよね
 • 理想が我々には無いんだということを自覚する
 • そのうえで、なぜそうなっているのかを問う
 ◦ なぜ、問い合わせが多いのか 
 ◦ なぜ、障害は繰り返すのか 
 ◦ なぜ、仕様は混沌としているのか 
 • 「知らない」を認める勇気も必要
 ◦ 外部に知見を求めてみてはどうか 
 ◦ 学ぶ時間を持つために何ができるか 

13. 理想を言語化
 • 現状を把握したうえで、理想を話し合う
 • 課題の話は、それからだ
 • 我々は、どうしたいんだ、どうなりたいんだ、どうなってたら楽しいんだ
 • ステークホルダーを巻き込み言語化に取り組む
 • 常に現状の認識が合っていることを確認してから理想を話す

14. 課題について話し合おう
 • ふりかえってみると、最初の マ のお話は課題じゃないんですよね
 • 現状と理想を明確にせずして話していることは、課題の話じゃない
 • なので、課題について話したいというときは、理想を問うといいですよね
 • 「あなたの理想をまず教えてください。話はそれからだ。」

15. 課題と打ち手はセットで話す
 • 課題 (Why) と 打ち手 (How) って、そんなキレイに分けて話せない
 • 発散しているときは特にそう
 • 「Howの話をしていますよね。目的と手段が入れ替わっていますね。」
 • という類の発言は、この時点でしないようにしましょう
 • 言説が時と場合によって是非を問うと、非になることもある
 • 世の中そんな単純じゃない
 • この段階では、気にせず混ぜて話し合おう

16. [脱線] 主義と主張について考える
 • 主義
 ◦ 人が持つ根本的な考え方や信念の体系 
 ◦ 「功利主義」「自由主義」「直観主義」 
 ◦ ある一貫した価値観や原理に基づいた思想的立場を指す 
 • 主張
 ◦ 特定の事柄について述べる意見や見解 
 ◦ 「この政策を実施すべき」「この方法が最善だ」 
 ◦ 主張は状況に応じて変わることもあり体系的である必要もない 
 • 主張だけを取り上げて議論しても仕方がない
 • 主義を理解し合ったうえで主張を傾聴し議論しよう
 • 人はそんなに単純じゃない。主義も複数あるよね。

17. 大体の方向性を示す
 • 打ち手の中から何に取り組むか意志決定する
 • ホップ・ステップ・ジャンプ でいい
 • ここまで、まだ、ひとり
 • チームも無いのに、具体的な線を引けるわけがない
 • どんな能力で、どんな速度で、どんな品質を、アウトプットできるのか
 • 分からないうちからスケジュールは引けない

18. 人を集める
 • 自分ひとりで出来ることに限界を感じる
 • ここからはチームの仕事だ
 • 社員、業務委託、派遣、副業、AI
 • どういったチームが課題に向き合えるのか
 • デコとボコが噛み合うチームをデザインする

19. とはいえAIがある
 • 生成AIの台頭
 • AI Agentの台頭
 • 日毎にアップデートされる現代におけるチームのあり方について
 • ここと向き合い常に考え小さく検証していくことが問われる

20. 仮説その1
 • AI Agentを開発者のバディとする
 • 今まで不得意としていた領域もカバーできるようになる
 • デコとボコを噛み合わせて補い合っていたチーム
 • デコが自分でボコが他人から、デコが自分でボコがAIになる
 • ほとんどのことが、ひとりで完結する世界線
 • 従来通りのチーム開発は不要
 • 何を合意形成するべきか

21. 仮説その2
 • AI Agentを開発者の一員とする
 • モブプログラミングのドライバー
 • ナビはプロンプトを議論する
 • プロンプトについて話し合い、ドライバーがアウトプットするコードを確認
 • 自然言語力が問われ、コードの読解力が問われる
 • 従来通りの合意形成でよさそう

22. 仮説その3
 • AI Agentに丸投げ
 • プロンプトをメンテする
 • 自然言語が問われる
 • 人に理解してもらう必要ってあるんだっけ
 • 自分でやったほうが早くね

23. とはいえ運用は続くよ
 • 新しく価値を生み出す世界線においてはAI Agentの活躍余地はありつつも
 • われわれの現場において全てに適用できないよね
 • デファクトとなるコードを生み出すのは人間
 • それをAIに教える
 • 教えたAIを使えるような開発者を育てる
 • そのとき必要になる前提となる知識は何か

24. スキルマップ
 • 理想に必要なスキルマップを洗い出す
 • 自己評価で採点
 • 現状と理想のギャップを得る
 • どう学びを構築していくか
 • 何から学ぶといいのか
 • 人の成長がチームの成長となりこれからを担っていく

25. まとめ
 • 観察とコミュニケーションからの構造把握
 • 理想の言語化と課題設定
 • チームの形成とAIの活用
 • 人の成長とチームの成長