無秩序からの脱却 / Emergence from chaos

アーキテクチャカンファレンス2025 の講演資料です。
過去、アーキテクチャをもたらすために行った変革を題材に、どのような学びを得られるかをお話しています。

# URL
YouTube: https://www.youtube.com/c/narusemi
HomePage: https://nrslib.com
Twitter: https://twitter.com/nrslib
Instagram: https://www.instagram.com/nrslib/

Transcript

1. 無秩序からの脱却 nrs
2. 2 アーキテクチャに関する素養やノウハウのないチームで、どのように設計思想を導入し、組織全体に 浸透させるか。本セッションでは、過去の実践記録を共有します。 トランザクションスクリプトで書かれた無秩序なコード、設計に関する知見の欠如、そんな状況下で 新規プロジェクトが立ち上がりました。 このプロジェクトを契機に、アーキテクチャを策定し、段階的にチームに浸透させていった過程、そ して予想外にもチームの垣根を超えて組織全体に広がっていった経緯をお話しします。 技術導入における意思決定のポイント、抵抗と受容のプロセス、小さな成功を大きな変革につなげる 方法論を実体験を基にお伝えします。 プロポーザル
3. 3 アーキテクチャに関する素養やノウハウのないチームで、どのように設計思想を導入し、組織全体に 浸透させるか。本セッションでは、過去の実践記録を共有します。 トランザクションスクリプトで書かれた無秩序なコード、設計に関する知見の欠如、そんな状況下で 新規プロジェクトが立ち上がりました。 このプロジェクトを契機に、アーキテクチャを策定し、段階的にチームに浸透させていった過程、そ して予想外にもチームの垣根を超えて組織全体に広がっていった経緯をお話しします。 技術導入における意思決定のポイント、抵抗と受容のプロセス、小さな成功を大きな変革につなげる 方法論を実体験を基にお伝えします。 プロポーザル
4. 4 アーキテクチャに関する素養やノウハウのないチームで、どのように設計思想を導入し、組織全体に 浸透させるか。本セッションでは、過去の実践記録を共有します。 トランザクションスクリプトで書かれた無秩序なコード、設計に関する知見の欠如、そんな状況下で 新規プロジェクトが立ち上がりました。 このプロジェクトを契機に、アーキテクチャを策定し、段階的にチームに浸透させていった過程、そ して予想外にもチームの垣根を超えて組織全体に広がっていった経緯をお話しします。 技術導入における意思決定のポイント、抵抗と受容のプロセス、小さな成功を大きな変革につなげる 方法論を実体験を基にお伝えします。 プロポーザル
5. 5 アーキテクチャに関する素養やノウハウのないチームで、どのように設計思想を導入し、組織全体に 浸透させるか。本セッションでは、過去の実践記録を共有します。 トランザクションスクリプトで書かれた無秩序なコード、設計に関する知見の欠如、そんな状況下で 新規プロジェクトが立ち上がりました。 このプロジェクトを契機に、アーキテクチャを策定し、段階的にチームに浸透させていった過程、そ して予想外にもチームの垣根を超えて組織全体に広がっていった経緯をお話しします。 技術導入における意思決定のポイント、抵抗と受容のプロセス、小さな成功を大きな変革につなげる 方法論を実体験を基にお伝えします。 プロポーザル
6. 6 アーキテクチャに関する素養やノウハウのないチームで、どのように設計思想を導入し、組織全体に 浸透させるか。本セッションでは、過去の実践記録を共有します。 トランザクションスクリプトで書かれた無秩序なコード、設計に関する知見の欠如、そんな状況下で 新規プロジェクトが立ち上がりました。 このプロジェクトを契機に、アーキテクチャを策定し、段階的にチームに浸透させていった過程、そ して予想外にもチームの垣根を超えて組織全体に広がっていった経緯をお話しします。 技術導入における意思決定のポイント、抵抗と受容のプロセス、小さな成功を大きな変革につなげる 方法論を実体験を基にお伝えします。 プロポーザル
7. 7 アーキテクチャに関する素養やノウハウのないチームで、どのように設計思想を導入し、組織全体に 浸透させるか。本セッションでは、過去の実践記録を共有します。 トランザクションスクリプトで書かれた無秩序なコード、設計に関する知見の欠如、そんな状況下で 新規プロジェクトが立ち上がりました。 このプロジェクトを契機に、アーキテクチャを策定し、段階的にチームに浸透させていった過程、そ して予想外にもチームの垣根を超えて組織全体に広がっていった経緯をお話しします。 技術導入における意思決定のポイント、抵抗と受容のプロセス、小さな成功を大きな変革につなげる 方法論を実体験を基にお伝えします。 プロポーザル
8. 8 アーキテクチャに関する素養やノウハウのないチームで、どのように設計思想を導入し、組織全体に 浸透させるか。本セッションでは、過去の実践記録を共有します。 トランザクションスクリプトで書かれた無秩序なコード、設計に関する知見の欠如、そんな状況下で 新規プロジェクトが立ち上がりました。 このプロジェクトを契機に、アーキテクチャを策定し、段階的にチームに浸透させていった過程、そ して予想外にもチームの垣根を超えて組織全体に広がっていった経緯をお話しします。 技術導入における意思決定のポイント、抵抗と受容のプロセス、小さな成功を大きな変革につなげる 方法論を実体験を基にお伝えします。 プロポーザル
9. 9 アーキテクチャに関する素養やノウハウのないチームで、どのように設計思想を導入し、組織全体に 浸透させるか。本セッションでは、過去の実践記録を共有します。 トランザクションスクリプトで書かれた無秩序なコード、設計に関する知見の欠如、そんな状況下で 新規プロジェクトが立ち上がりました。 このプロジェクトを契機に、アーキテクチャを策定し、段階的にチームに浸透させていった過程、そ して予想外にもチームの垣根を超えて組織全体に広がっていった経緯をお話しします。 技術導入における意思決定のポイント、抵抗と受容のプロセス、小さな成功を大きな変革につなげる 方法論を実体験を基にお伝えします。 プロポーザル
10. 10 新規プロジェクト 垣根を超えて 方法論との答え合わせ 無秩序からの脱却
11. 11 新規プロジェクト 垣根を超えて 方法論との答え合わせ 無秩序からの脱却
12. 12 • コドモンの話じゃないです ◦ 過去のプロジェクトの話です ◦ ただよくある話でもあります 前提
13. 13 • チームは苦しんでいた ◦ １ファイルが長大なコード ◦ 複雑に依存しあうオブジェクト ◦ 過渡期特有の「動いている」コード 新規プロジェクト以前
14. 14 • 自分の立ち位置 ◦ チームには所属するも他メンバーとは別プロジェクトで動いていた ◦ 別プロジェクトのビッグバンリライトを成功へ ◦ 新規プロジェクトのアーキテクチャあたりを任されることに 新規プロジェクト以前
15. 15 • プロジェクト ◦ １０名程度が関わるプロダクト ▪ 開発者は６〜８名程度 ◦ 工数 ▪ 見立ては上記メンバー数で１０ヶ月程度のボリューム • （工期が１０ヶ月あるとは言っていない） ▪ プレスリリース等の関係で締め切りは厳守 ◦ 運用 ▪ 長く運用保守をしていく想定（１０年↑） 新規プロジェクト
16. 16 • どうしたらいいんだろうの「かお」 ◦ アーキテクチャに関して勉強しているメンバーは１名 ◦ なにがよくてなにがわるいかの言語化ができていない状態 みんなのかお
17. 17 • さて、みなさんならまず何から始めるだろうか？ その理由は？ ◦ １．実証実験から始める ◦ ２．先行して形を作る ◦ ３．話し合う ◦ ４．外部の知見を入れる ◦ ５．なにもしない ケーススタディ
18. 18 • ここから始めた ◦ １．実証実験から始める ◦ ２．先行して形を作る ◦ ３．話し合う ◦ ４．外部の知見を入れる ◦ ５．なにもしない ケーススタディ
19. 19 • やらなくてはいけなかったこと ◦ アーキテクチャに沿う動機づけ ▪ 今抱えているものを解決する手段があることへの理解醸成 ◦ 変化への受け入れ度合いの確認 ▪ 変化することを前向き／後ろ向きどちらに捉えているか ◦ 視座の変更 ▪ 今だけではなく未来を見る意識（持続可能性） なぜ話し合ったのか
20. 20 • ３から始めただけで、１〜３はすべてやった ◦ １．実証実験から始める ◦ ２．先行して形を作る ◦ ３．話し合う ◦ ４．外部の知見を入れる ◦ ５．なにもしない 結局のところ
21. 21 • 現在課題のあるプロダクトでリファクタリング ◦ 実装をベースに以下を説明 ▪ 実装イメージ ▪ どうして課題が解決されるのか ▪ 代償となるものはなにか • その解決策はあるか ◦ 新規プロダクトへの準備 ▪ 「こうすればよかったのか」を現在取組むもので意識できる ▪ 知識と技術の違い • 聞かれたら答えられる＝知識 • やってできること＝技術 実証実験
22. 22 • 手本を作る ◦ 可能な限りパターンを網羅するように ▪ 簡単なパターン ▪ 中難易度パターン ▪ 高難易度パターン • 水の低きに就くが如し ◦ めんどうなことを解決するツール実装 ▪ ここらへんは YouTube でよく話してたので→ 先行実装
23. 道中は成功譚で面白くないので割愛
24. 24 • 残業なし ◦ どんどんやることなくなっていった尻すぼみ型プロジェクト • 夏休みは返上した ◦ コード書くのは楽しいから休みみたいなもんだよ • １〜２年後の改修は意図通りだった ◦ 勘所は押さえられたコード ◦ 「改修が楽です」←嬉しい 結果
25. 25 新規プロジェクト 垣根を超えて 方法論との答え合わせ 無秩序からの脱却
26. 26 • 新しいシステムは過去のシステムを参考に作られる ◦ 「あれを参考にして作ってよ」 ▪ 常に参考になるわけではないが…… ◦ 「あのプロジェクトよかったらしいよ」 ▪ その良さが新しいプロジェクトに適しているかは別だが…… 他プロジェクトに伝播する
27. 27 • 「コード見てほしいんですけど」 ◦ 「お、いいよー。……ん？ なんか見たことあるなこれ」 ◦ 「参考にしてました！」 参考にされる
28. 28 • システムのリファクタ相談 ◦ 「こんなふうにやってるよー」 ◦ 「このアーキテクチャと、このツールいいですね。ほしいなー」 ◦ 「じゃあ使えるようにツール改修するよ」 ツールが輸出される
29. 29 • アーキテクトの意思とは関係なく輸出入される ◦ 成功は伝播するし失敗も伝播する ▪ 輸入する側は可能な限りヒアリングするとよい ▪ 輸出する側は全体最適化の観点で喜ぶと良い ◦ 良し悪しの判断がされないこともある ▪ 要件と合っているか ▪ 似ていても異なるプロジェクトは数多ある アーキテクチャは伝播する
30. 30 新規プロジェクト 垣根を超えて 方法論との答え合わせ 無秩序からの脱却
31. 31 • はたして今日の話は明日から使える知識なのか？ ◦ このプロジェクト固有の事情によるものか？ ◦ 再現性はあるのか？ ◦ 似ていても異なるプロジェクトの話なのか？ 何を参考にすべきか
32. 32 • MBAプログラムでやること ◦ ビジネスの問題を解決するための「考え方の型」を学ぶ ▪ ＝考え方のフレームワーク ところで最近MBAプログラムに通ってまして
33. 33 • 求められるは「変化に対処する」こと ◦ 対応する科目はリーダーシップ ◦ その中で学ぶ「考え方の型」 ▪ コッターの「変革の８つのステップ」 今回のケースに当てはめるなら
34. 34 • 危機意識を高める • 変革推進チームをつくる • 適切なビジョンをつくる • 変革のビジョンを周知徹底する • 従業員の自発的な行動を促す • 短期的な成果を生む • さらに変革を進める • 変革を根付かせる 変革の８つのステップ
35. 35 • 危機意識を高める ：話し合う • 変革推進チームをつくる ：自分とマネジャー・サブマネジャー • 適切なビジョンをつくる ：直前の成功をベースに策定 • 変革のビジョンを周知徹底する：全員での会話 • 従業員の自発的な行動を促す ：開発のレールを準備し走ってもらう • 短期的な成果を生む ：プロジェクトでメンバーが成功体験 • さらに変革を進める ：その後のプロジェクトでも当たり前に • 変革を根付かせる ：コードを越えて伝播していった 変革の８つのステップ
36. 36 Profile nrs（成瀬 允宣） @nrslib プログラマ 趣味：カンファレンス講演 学生支援 小学校支援 写真