技術的負債返しますか？それとも開発辞めますか

〜 DevLove 広島 〜「 DevLove 甲子園勝手にプレイバック Ver. 西 + α 」

BMC 西　秀和

自己紹介

• 西　秀和（３３歳）

• 経営管理センター所属　主任

• 仕事先： BIGLOBE

( 月曜〜金曜は東京にいます )

• 業務システム設計・開発

DevLove 甲子園お邪魔してきました

DevLove 甲子園発表内容

（ダイジェスト）

中間管理職がいなくなったらプロジェクトが

うまく進みだしたよ♪

経営管理センター (BMC) 　西　秀和

隊トラック

みなさん！！管理されてますかー？

お客様

１次

２次

常駐

常駐

僕

担当

主任

主任

M

お客

発注

API設計部門

API製造部門

担当 画面部門

担当M

発注

東京

広島 広島愛媛

S-in 日までに完成した画面

１０７画面中

７画面

お客様

１次

２次

担当

主任

主任

M

お客

API設計部門

API製造部門

担当 画面製造部門

担当MGM

僕

S-in するまで、　　　帰ってくるな！！

■ 命令

無事に S-in できた

全員でゴールを共有

WHY?

WHAT?

HOW?

現場では逆走不可

← ココを与える

現場を変える可能性を

一番持っているのは、現場のエンジニア

発表内容ここまで。

中間管理職いたらダメなのか？

数値化して管理

数値化が難しいことに弱い

現場の全てを把握できない

数値化が難しいこと

現場のエンジニアが解決するしかない！

技術的負債

ウォード・カニンガム最初のコードを出荷することは、借金をしに行くことと同じである。小さな負債は、代価を得て即座に書き直す機会を得るまでの開発を加速する。危険なのは、借金が返済されなかった場合である。品質の良くないコードを使い続けることは借金の利息としてとらえることができる。技術部門は欠陥のある実装や、不完全なオブジェクト指向などによる借金を目の前にして、立ち尽くす羽目になる

技術的負債とは？

今後の開発・運用に悪影響のあるコード

Reckless( 無鉄砲 )

Prudent( 計画的 )

Deliberate( 意図的 )

設計する時間がない品質を犠牲にして作れ！！

問題は認識しているが、リスクは承知の上でリリース

Inadvertent( 無意識 )

負債が溜まっていく事に気づいてない

最善を尽くしたが、のちに最善の方法が分かる

技術的負債 (四象限 )

保留！！

技術的負債とはどのレベルの問題を言っているのか？

• 処理の共通化（共通化）

• 単体テストが可能（テストの容易性）

メソッド抽出<- 生産性の UP

<- 品質の向上

実例

Reckless( 無鉄砲 )

Prudent( 計画的 )

Deliberate( 意図的 )

設計する時間がない品質を犠牲にして作れ！！

問題は認識しているが、リスクは承知の上でリリース

Inadvertent( 無意識 )

負債が溜まっていく事に気づいてない

最善を尽くしたが、のちに最善の方法が分かる

技術的負債 (四象限 )

技術的負債が発生する原因

技術的負債の分類

技術的負債 (四象限 )

1.短納期2.未熟なチーム3. 業務知識不足

原因の発生元は？

1.短納期

Reckless( 無鉄砲 )

Prudent( 計画的 )

Deliberate( 意図的 )

設計する時間がない品質を犠牲にして作れ！！

問題は認識しているが、リスクは承知の上でリリース

Inadvertent( 無意識 )

負債が溜まっていく事に気づいてない

最善を尽くしたが、のちに最善の方法が分かる

技術的負債 (四象限 )

「短納期」弊害

• 設計・レビューの時間が十分に取れない

• 最善の手法では間に合わない

• 似た処理をコピー &ペースト

• 仕様変更に柔軟に対応できない

2.未成熟なチーム

Reckless( 無鉄砲 )

Prudent( 計画的 )

Deliberate( 意図的 )

設計する時間がない品質を犠牲にして作れ！！

問題は認識しているが、リスクは承知の上でリリース

Inadvertent( 無意識 )

負債が溜まっていく事に気づいてない

最善を尽くしたが、のちに最善の方法が分かる

技術的負債 (四象限 )

「未成熟なチーム」の弊害

• チームの設計方針が安定しない

• 実装方法に統一性がない

• 後戻りが多い

• 打ち合わせ・議論が長い

3. 業務知識不足

Reckless( 無鉄砲 )

Prudent( 計画的 )

Deliberate( 意図的 )

設計する時間がない品質を犠牲にして作れ！！

問題は認識しているが、リスクは承知の上でリリース

Inadvertent( 無意識 )

負債が溜まっていく事に気づいてない

最善を尽くしたが、のちに最善の方法が分かる

技術的負債 (四象限 )

「業務知識不足」の弊害

• データの変換している処理が多い

• データ構造が業務に合っていない

• ST などプロジェクト後半で問題が多い

最近、関わっている

プロジェクトの話

プロジェクト状況

• ７人チーム( バラバラのチームからかき集めた )

• １０月に結成して２月リリース

• 初めてのビジネスモデル

直ぐに問題が発生

チームの中心になる共通認識がない

技術的負債が増えている事は

エンジニアが一番理解している

レビューで設計方針の討論が起きる

コレは良いこと( 時間があれば）

議論が発散

レビュー時間が長時間化

技術的負債を生む原因

作業時間を圧迫

一旦、議論禁止

代わりにやった事

共通認識を作る

ドメインモデル

１４００クラス１００テーブル

技術的負債を共有する

←議論したい事

←議論はして取組でいる事

チームの方針

• 毎日、１６：００から１時間だけ開催

• 1回で１議題

• ファシリテーターは持ち回り

• 朝会で今日の議題を発表

• ファシリテータが初めに問題提起と改善案を提示

議論中…

議論する時間を設ける利点

• １つの議題に集中して討論できる

• もめた時の受け皿になる

• みんなで決めたという納得感

• やりたい事を提案する準備の期間がある

技術的負債を見逃さない

KPT では残った Problem を捨てたらダメ

まとめ

技術的負債の返済はチームで挑め！！

なぜか？

技術的負債の発生はエンジニアの

スキルではなく状況に左右されやすい

誰か一人でリファクタを実施

未熟なチーム業務知識が乏しいメンバは新たな技術的負債を生む

技術的負債の返済が終わらない…

技術的負債の返済と共にチームが

成長すること

大切な事

技術的負債の返済はチームで挑め！！

ご静聴ありがとうございました。