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