トップ > イベント・カンファレンス > 失敗とは、見積もりの失敗である。～新入社員のデブサミ見聞録～

失敗とは、見積もりの失敗である。～新入社員のデブサミ見聞録～

イベント・カンファレンス 新卒 技術的負債 リファクタリング

プロジェクトが失敗したのは、納期が遅れたり、予算を超えたりしたからだというよりも、むしろ見積もりが失敗したからだと言いたい。1 - Martin Fowler

はじめまして、価格.com開発本部のしがない新卒エンジニアです。春の研修を終え、価格.com延長保証などのサービスを担当するチームに配属されました。

この度、ソフトウェア開発の知識獲得を目的として、技術カンファレンスであるDeveloper Summit 2024 Summer（通称:デブサミ）に参加しました。 本記事では、弊社でも頻繁に話題に上がる技術的負債とリファクタリングというテーマに絞って、2人のスピーカーの発表内容をご紹介します。 ソフトウェア開発については右も左も分からない青二才ではございますが、新卒エンジニアなりの視点で共有させていただきます。

なお、価格.comのQAエンジニア 伊藤さんが登壇した昨年のデブサミはこちらの記事で紹介されておりますので、あわせてご覧ください！

さて、耳の痛くなる冒頭の格言は、次にご紹介するセッションで引用されたものです。

『技術負債による事業の失敗はなぜ起こるのか』

DMM.comプラットフォーム開発本部部長の石垣雅人氏による発表2です。

ソフトウェア事業失敗の原因

事業予算における失敗の背景はほとんど「作ることが間に合わなかった」という一点に帰着されるようです。 なぜならば、開発期間が延びたことによる追加予算の分だけ、新たな売り上げが必要となるから。 ソフトウェア技術者Martin Fowlerの言葉を借りれば、 プロジェクトの失敗は開発の失敗ではなく、見積もりの失敗に起因するとのことです（タイトル回収）。

それなら見積もりを正確にやれば解決！と言いたいところですが、そんな簡単な話ではないようです。 この手の話題では必ず出てくる不確実性コーンを見れば一目瞭然、工数というものは開発工程の中で徐々に固まっていくもの。 プロジェクトの初期段階で細かいことまで決定するのは不可能とのお話でした。

※「ソフトウェア見積り」（スティーブ・マコネル／日経BPソフトプレス）3を基に作成

つぶやき

不確実性コーンは、弊チームで実施したアジャイル開発に関する書籍4 の輪読会で既習だったため「進研ゼミで出てきたやつだ！」状態になり大興奮でした。

技術的負債が引き起こす影響

ただでさえ難しいとされる見積もりですが、蓄積された技術的負債の存在によってさらに予測困難なものとなるようです。 結果として、エンジニアは無意識に失敗を隠すようになってしまうんだとか。 具体例として、以下のような現象が挙げられました。

 * リカバリーできるという自信から、課題をすぐに報告しない（その結果、「間に合いません」が直前になって出てくる）
 * 不安だから、無意識に無意味なバッファを作る

スケジュールに余裕があるうちに課題がすぐに報告されれば、リカバリープランとしてあらゆる選択肢を準備できるでしょう。 しかし、失敗が隠されることによって課題が埋もれてしまい、 気付いたときにはリカバリープラン無し...という恐ろしい事態が待っているとのことです。

つぶやき

学生時代の自分も卒業研究で似たような状況に陥っていたなぁと冷や汗をかいてしまいました。

このような問題に対してどのような取り組みを行うべきなのでしょうか？

技術的負債の解消に向けた取り組み

石垣氏からは以下の解決策が提案されました。

エンジニアは保守業務の開発優先度をブラックボックスにせず伝えるべし

エンジニアは、事業責任者に言われるがまま新規開発や改修作業を増やすのではなく、

などの抜本的な保守業務の重要性を説く必要があるとのことです。 そうでなければ、プロジェクト失敗の要因である技術的負債が解消できないため、 ユーザに直接的に価値を届ける業務が達成できなくなってしまうのですね。

リファクタリングという言葉を濫用するべからず

確かに、技術的負債を解消するためにリファクタリングは必要と言われています。しかし、その言葉だけを独り歩きさせて説明を怠ってしまうと、 「とりあえずリファクタリングしてますって言えば良いか！」状態になってしまうので、 他者にとっては何をしているのかがイマイチ伝わらないというお話でした。 なおかつ、リファクタリングには終わりがないため、着地点を決定しなければ漠然と工数だけを消費するのみということです。

つぶやき

逆説的ですが大事な視点だと感じました。何をどのように、何のためにリファクタリングするのかを明確にする必要があるということですね。 私自身も、単語の威力に頼って曖昧な作業報告をすることがたまにあるので十分に注意しようと思いました。 エンジニアと事業責任者がタッグを組んで、これらの観点を大事にしていきましょう！

『組織で技術的負債を解消する場合のボトルネックと解決の切り口』

続いては、一本目の石垣氏と同じくDMM.comからミノ駆動氏のご登壇です。

（「ミノ」って何...？）

リファクタリングに付きまとう困難

最初に、エンジニア組織でリファクタリングを行っていく際に起こりがちな課題が列挙されました。

チーム別々で取り組む上での弊害

チームごとにメンバーの設計スキルにバラつきが存在することに加えて、 リファクタリングは機能開発に比べて後手に回りがちなので、積極的に取り組むチームとそうでないチームとの乖離が大きくなりやすいそうです。

リファクタリング対象の選定

技術的負債は変更コストが高いコードであるため、将来頻繁に変更されそうな箇所に絞ってリファクタリングを行う必要があるようです。 しかし、そのリファクタリング対象を見極めるための分析が困難というお話でした。

これまでのリファクタリング

過去のDMM.comでは静的解析ツールを導入したり、 リファクタリングの専門チームがPullRequestレビューの内容をレビューしたりすることによって、コードの良し悪しに関する認識合わせを試みたそうです。 結果として一定の成果は得られたものの、 レビューのレビューはその場だけの対応に陥りがちで、設計スキルとして定着したかどうかには疑問符が付くようでした。

新たなリファクタリング指針

ミノ駆動氏のリファクタリングチーム参画以降は、次のような取り組みが実施されました。

設計リテラシー教育

リファクタリング以前の問題として、技術的負債がもたらす弊害があまり認知されておらず、 組織の間で負債が脅威として捉えられていないケースが考えられるとのことです。 チームごとの意識乖離を解消するため、体系的なリテラシー教育を実施するというのが1つ目の指針でした。

書籍を設計ガイドラインに

コードの良し悪しに関する認識合わせを行う手段として、レビュー内容のレビューを人力で行うのではなく、 設計ガイドラインを導入してしまおうというのが2つ目の指針でした。例として、以下のようなレビューが提示されました。

 「このコードは設計ガイドラインのx.x章の問題コードと同じ問題を抱えています。x.x章を理解し設計改善を行ってください」

ガイドラインを設けることによって、レビューコメントのコストが軽減されるだけではなく、 理論を理解しながらのアウトプットを通じて、再現性のあるスキルが定着しやすいとのこと。DMM.comではミノ駆動氏の著書5 が実際に設計ガイドラインとして使用されているようです。 引用：良いコード／悪いコードで学ぶ設計入門 ―保守しやすい 成長し続けるコードの書き方：書籍案内｜技術評論社

つぶやき

ここだけの話、私自身もレビューコメントの指摘内容を正確に理解できず、 その場しのぎでコードを修正してしまったことがあります。 確かに、全員の共通言語としての設計ガイドラインがあれば、 自分のような新人エンジニアでもレビューの理屈が理解しやすそうだなという期待感が持てました。 なお、「ITエンジニア本大賞2023」技術書部門で大賞を受賞した実用書として知られているため、弊チームでもガイドラインにしていくことを現在検討中です！

おわりに

初めての技術カンファレンスに参加したことによって多くの学びがありました。 私はまだ入社してから数か月しか経過していないですが、チーム内勉強会や普段の業務で取り沙汰される課題などが、 他の企業でも同様に問題視されていることを認識できたため点と点が繋がったような実感がありました。

また、今回は尺の都合上ご紹介に至りませんでしたが、百年間のウォーターフォール開発を脱却してアジャイル開発に舵を切った、 シチズン時計の発表も大変興味深かったです！

今回の経験をただの1回きりのイベント参加として終わらせるのではなく、自分なりに落とし込んで普段のアウトプットに活かしていこうと考えています。

カカクコムでは、ともにサービスをつくる仲間を募集しています！

カカクコムのエンジニアリングにご興味のある方は、ぜひこちらをご覧ください！

カカクコム採用サイト

  1. What Is Failure↩
  2. 技術負債による事業の失敗はなぜ起こるのか / Why do business failures due to technical debt occur? - Speaker Deck↩
  3. ソフトウェア見積り _ スティーブ マコネル, 憲之, 久手堅, McConnell,Steve, 恵, 田沢, 真理子, 溝口 _本 _ 通販 _ Amazon↩
  4. アジャイルサムライ−達人開発者への道− _ Jonathan Rasmusson, 西村 直人, 角谷 信太郎, 近藤 修平, 角掛 拓未 _本 _ 通販 _ Amazon↩
  5. 良いコード悪いコードで学ぶ設計入門 ―保守しやすい 成長し続けるコードの書き方 _ 仙塲 大也 本 _ 通販 _ Amazon↩