#199 受託開発からプロダクト開発への移行 ～技術的負債との向き合い方～
こんにちは。ITベンチャーエンジニアのこへいです。
「負債」と聞いた何を思い浮かべるでしょうか。
借金によって生まれる負債。最近では睡眠不足が重なることによる認知機能などの低下は一度休日にたっぷりと睡眠をとるだけでは改善しないことを睡眠負債と呼ぶのも一般的になってきましたね。
エンジニアが負債と聞くと「技術的負債」を思い浮かべます。
今日は技術的負債とは何か、受託開発とプロダクト開発ではたとえ同じように顧客に価値を提供しようとしても技術的負債の貯まり方には大きな違いがあること、そしてその違いを認識しておかないと予期せずビジネスの停滞を引き起こすことになるということについて考えます。
◯技術的負債とは
技術的負債は経営上の扱いが難しい
技術的負債は一般には、「早さ」を求めて構築されたシステムの構造的な課題が徐々に蓄積し、債務であるように徐々に開発速度そのものを遅くしていくという現象のことを意味しているように捉えられます。
また、エンジニアは古くなってしまったコードやわかりにくいコード全般を技術的負債と呼びます。
「技術的負債」という言葉は、ソフトウェア開発が段階を経るに連れて、それまでの構造によって機能追加が徐々に困難になっていく様子を見事に言い表しています。
技術的負債がやっかいなのは、非エンジニアにとっては負債が見えず、技術的負債という言葉は、会計上も経営指標においても計上されるわけではない空想上の概念にすぎないからです。
エンジニアが「バグの原因は技術的負債のために防ぐことが難しかった」「技術的負債のため当初の想定スケジュールに間に合わない」「技術的負債の返済をしなくてはこれ以上機能を追加が出来ない」などと説明しても、経営陣には技術的負債が見えないために返済に関する議論が出来ず、エンジニアの能力不足を疑ったり、技術的負債という課題そのものを棚上げしてしまいがちです。
するとある日突然、大量のバグが発生したり、予定したスケジュールに間に合わないプロジェクトが発生したりと、ビジネスの停滞を招く事件に発展します。
ジェンガと似ている技術的負債
技術的負債を説明する際にはパーティーゲームの「ジェンガ」に例えるとわかりやすいです。
システム開発が徐々に困難になるのは、ジェンガのようなものだからです。
ゲーム初期段階でのジェンガは、簡単にブロックを抜き出したり、積み上げることができます。このとき、ゲームはスピーディに進んでいきます。ところが、ゲームをしばらく続けると、バランスを取るのが急激に難しくなっていき、テンポがゆっくりとなっていきます。慎重に抜き差しをしないと崩れてしまうためです。 様々な要件の変化によって形作られたジェンガは、徐々に不安定に、積み上げるのが難しく時間がかかるようになります。これが開発が遅くなる現象とよく似ています。
不安定になったジェンガにさらにブロック（機能）を積み上げるには土台（システム）を綺麗に整える必要があります。
技術的負債との向き合い方
マネジメントの観点では、「技術的負債何か」という議論にあまり意味はありません。技術的負債がどのように生み出されるかについて考えるべきです。
高明なソフトウェアエンジニアのマーティン・ファウラーは、このような観点から「無鉄砲な／慎重な」「意図的な／無意識の」という2つの軸を掛け合わせて、技術的負債の4象限を定義しました。 重要なのは、慎重かつ意図的に作られた負債であれば、問題なく返済することができるだろうと考えた点です。一方、無知や無鉄砲さから生まれた技術的負債は、予想しない利息を支払うこととなり、問題が大きくなってしまうため、避けるべきであるとしています。
1つひとつの問題がなぜ生まれたのかを検討することで、避けられるべき問題を避け、解消すべき問題をあぶり出すことが出来るということです。
◯プロダクト開発を受託のノリで行うと技術的負債は増加する
受託開発とプロダクト開発では、機能を作ることで価値を提供するか機能を使って価値を提供するかの違いがあるということを、こちらの記事で述べました。
プロダクト開発は一つのシステムを複数の顧客に提供して価値を提供します。顧客A向けの機能、顧客B向けの機能というように個社ごとに機能を追加していくと、顧客ごとに機能の出しわけをする必要が出てきます。
顧客ごとの出しわけが増える程、顧客A用の機能が顧客Bに表示されるというバグの可能性が高くなります。
プロダクトに対して受託開発のように特定の顧客向けの機能を追加することは、意図的に慎重に技術的負債を取り込むことを意味します。
この意思決定は非エンジニアが想像するよりも遥かに大きな負債を抱えることになるということを理解しておかないと後になって痛い目にあいます。
そのため、プロダクト開発では受託開発の時とは異なり、顧客の課題を機能提供で解決するのではなく、既存の機能を使って解決することや多くの顧客の共通の課題を解決できる汎用的な共通機能として提供することが求められます。
技術的負債を意図的に増やさないために、受託のノリで価値提供することからの脱却が必要です。
◯顧客の要望を断れと言うのですか？
プロダクト開発では、顧客の要望を「出来ません」と断ることも必要です。
意図的に技術的負債を取り込まないことで、プロダクトの安定稼働を担保し、より多くの顧客に継続的に価値を提供することを優先することが出来るからです。
このような説明に対して、「顧客の要望を断れということですか？」と突っかかる人が出てきます。
しかし、そうではありません。
顧客の要望する機能の開発を断る一方で、顧客の要望・課題解決には真摯に向き合いましょうという話です。既存機能や追加する汎用的な機能を使って顧客の課題を解決する方法を探るアプローチは、顧客の要望を断ることとは意味が違います。
受託開発とプロダクト開発では求められるアクションや優先されることが異なる、今までのやり方との違いに戸惑いを感じ、ハレーションが起きるのは仕方がありません。
しかし、ビジネスモデルの変化に合わせて、マインドセットやアクションを変えていかなければ、ビジネスの成長は実現できません。
最近、今までのやり方を作業的にこなすことが顧客からのクレームに繋がってしまったケースがありました。
状況の変化に合わせて目的から逆算して自らの仕事を作り出すことが出来ればこのような顧客のクレームを防ぐことが出来るはずです。
受託開発からプロダクト開発への移行はまだまだ色々な困難があるかと思いますが、プロダクトマネージャーとしてチームメンバーと協力して実現していきます。
ということで、受託開発からプロダクト開発へ移行する際の技術的負債との向き合い方について考えました。
技術的負債に関しては、エンジニアリング組織論への招待での解説を参考にさせていただいています。
ぜひ、こちらもお読みください。
最後までお読みいただきありがとうございました。
この記事が気に入ったらサポートをしてみませんか？