【完全ガイド】プロダクト開発の最適化を考えるべき時期と期待される成果
開発最適化とは、プロダクト開発の効率と品質を向上させるのに有効な取り組みです。もちろん組織や企業によってゴールは異なりますが、本来はチェックや改善を続けるべきものだと考えられています。ただし一言で「開発最適化」といっても、その中身は大きく2つに大別できます。
1：開発チームの最適化
2：プロダクト開発の最適化
当然どちらもビジネスチームや経営にも影響を及ぼす重要な課題です。そこで本記事では、ProfitMakersの副社長であり、数々の新規事業や開発部門を立ち上げてきた実績のある伊東の実体験を交えながら、プロダクト開発の最適化に焦点を当てて解説します。
伊東プロフィール
開発最適化で重要な3つの柱
まずはプロダクト開発の最適化で主要な改善項目について整理しましょう。
私が考える観点は3つです。
1. 開発効率の向上
一定量の作業を完了させる際の短く区切られた期間ごとに、作業が進む速度もしくは作業量を計測し、直近の状況が過去と比べてどのような状況であるかを確認します。問題があれば原因を突き止め、対応していく作業です。
2. プロダクト開発フロー
ビジネス側と開発側で円滑に運用されるよう、ルールやフローの改善も重要です。イメージしやすいように、改善方法の具体例を5つ示していきます。
1. 現状分析
- プロセスマッピング：現在の開発フローを視覚化し、各ステップを明確にします。フローチャートやカンバンボードを使用します。
- データ収集：各ステップの所要時間、リソースの利用状況、発生する問題点などのデータを収集します。
2. 問題点の特定
- ボトルネックの特定：どのステップで作業が滞っているかを見つけます。例えば、コードレビューの遅れやテストの長期化などです。
- フィードバック収集：チームメンバーからのフィードバックを集め、現場で感じている問題点を明らかにします。
3. 改善策の策定
- ベストプラクティスの導入：アジャイルやリーン開発の手法を取り入れます。例えば、スプリントの短縮、デイリースクラムの導入、WIP制限などです。
- 自動化の推進：テストやデプロイなど、繰り返し行う作業を自動化します。CI/CDパイプラインを構築し、エラーの減少と迅速なデプロイを実現します。
4. 改善策の実行
- 試験的なプロジェクトの実施：全体に適用する前に、部分的に改善策を試し、効果を測定します。
- トレーニングと教育：チーム全体に新しいプロセスやツールの使い方を教育し、スムーズな移行をサポートします。
5. 評価とフィードバック
- 定量的評価：改善策の導入後、収集したデータをもとに効果を測定します。また、作業量（＝ベロシティー）の向上、バグの減少、リリースサイクルの短縮などを評価します。
- 継続的な振り返り：定期的にレビューを行い、さらに改善の余地があるかを検討します。
3. 技術的負債の解決
技術的負債（Technical Debt）とは、短期的な利益を得るために品質を犠牲にした設計や実装上の決定、または古い技術を使用し続けることで置き換えられない状況を指します。これらは将来的なコストやリスクを増大させるため、開発効率やセキュリティの観点でも解決していくことが必要です。プロジェクトの成功と長期的な健全性に貢献する不可欠な取り組みだといえるでしょう。
そこで、この観点での改善例を4つご紹介します。
1. 技術的負債の可視化
綺麗で理解しやすいコードを維持することで、バグの修正や新機能の追加が容易になり、保守性が大幅に向上します。
- ソースコードのレビューとリファクタリング（＝内部構造の整理）：定期的にコードレビューを行い、リファクタリングを推奨します。
- 技術的負債のリスト作成：負債となっている箇所をリストアップし、優先順位をつけて対処します。
2. リファクタリングの計画と実施
技術的負債が少ない状態であれば開発がスムーズに進むので、納期を守る/遅れない体制が実現になります。
- 作業期間（＝スプリント）にリファクタリングを組み込む：各スプリントに一定時間をリファクタリング作業に割り当てます。
- 自動化されたテスト：リファクタリング後の動作確認を自動化し、作業効率を高めます。
3. コード品質の継続的な監視
最新のセキュリティガイドラインに沿ったコードを書くことで、法的要件や業界標準を満たすことが可能になり、コンプライアンスの確保にもつながります。
- 静的解析ツールの導入：SonarQubeやESLintなどのツールを使用して、コード品質を継続的に監視します。
- CI/CDパイプライン（＝ビルド～テスト～デプロイまでのステップの自動化）の強化：コードの変更が自動的にテストおよびデプロイされるようにします。
4. 技術的負債の予防
古いライブラリ（機能や処理のプログラムをまとめたもの）や、不適切なコードはセキュリティリスクを増大させる要因となりますが、これらを解決することで脆弱性を大幅に減少させることができます。
- ベストプラクティスの導入：コーディング標準、設計パターン、レビューガイドラインを策定し、チーム全体で徹底します。
- 教育とトレーニング：開発者に対して、最新の技術やツール、ベストプラクティスについてのトレーニングを行います。
ただし、ビジネスや経営サイドから見た場合、将来のコスト削減のために現時点でコストを支払うことになるため、現時点の売上を優先せざるを得ないことも多いです。一方で、そもそもプロダクトが成長しなければ、どんなに綺麗なコードと最高な仕組みが整っていてもいずれは解散しなくてはならなくなります。そのため、プロジェクトの持続可能性と収益性の向上それぞれを、どのように整理できるかが肝になります。
開発最適化を考えるタイミング
では、開発最適化について考えるベストなタイミングはいつ頃でしょうか？理想でいえば常に考えるべきですが、実際にはこれからお伝えする8つのタイミングのいずれかが考えられます。
1.開発人数が増えてきた場合
理由：チームが大きくなると、コミュニケーションや協力の複雑さが増し、プロセスの効率が低下することがあります。
対策：プロジェクト管理ツールの導入、アジャイル手法の適用、役割と責任の明確化、定期的なミーティングの実施などを行います。
2.技術負債リストが増えてきた場合
理由：技術負債が蓄積すると、開発効率が低下し、バグやセキュリティリスクが増大します。
対策：リファクタリング計画の策定、技術負債の優先順位付け、定期的なコードレビュー、リファクタリングをスプリントに組み込むなどを行います。
3.インフラ費用や開発効率が落ち始めてきた場合
理由：インフラの非効率や開発プロセスの問題がコスト増加や作業の遅延を引き起こします。
対策：インフラの見直し、クラウドサービスの最適化、CI/CDの導入、自動化ツールの活用、技術スタックの更新などを行います。
インフラのツール、設計手法などを10-5年前のものから最新のものに変えると、最大1/5減になることもあります。
4.プロダクトが成長し余裕が生まれてきた場合
理由：プロダクトの成長に伴い、品質向上や新機能追加のためのリソースが確保できるようになります。
対策：プロセスの改善、リファクタリング、テストの強化、技術的負債の解消、ドキュメントの整備などを行います。
5.資金調達などを行い、資金に余裕が生まれた場合
理由：新たな資金を得ることで、技術的負債の解消やインフラの改善に投資する機会が生まれます。
対策：インフラの拡張と最適化、開発ツールのアップグレード、トレーニングと教育の充実、外部コンサルタントの導入などを行います。
6.プロジェクトの節目やリリース後
理由：プロジェクトのマイルストーンや大きなリリースの後は、プロセスを見直し、次のフェーズに向けた改善を行う良いタイミングです。
対策：レトロスペクティブミーティングの実施、フィードバックの収集と分析、次期スプリントやリリース計画の改善などを行います。
7.パフォーマンス問題が発生した場合
理由：システムのパフォーマンスが低下したり、ユーザーからのフィードバックで問題が指摘された場合、最適化が必要です。
対策：パフォーマンスモニタリング、ボトルネックの特定と解消、アーキテクチャの見直し、コードの最適化などを行います。
8.市場や技術の変化に対応するため
理由：市場のニーズや技術トレンドが変化すると、それに対応するために開発プロセスを見直す必要があります。
対策：新しい技術やツールの導入、マーケットリサーチの結果を反映した開発計画の調整、チームのスキルアップなどを行います。
実例に学ぶ開発最適化
実のところ、私はプロジェクトの初期段階から参画するよりも、ある程度進行して問題が顕在化した後にアサインされることが多かったです。そのため、主にリプレースやリファクタリングのフェーズから対応することが求められました。このような最適化はビジネス側や経営側にも大きな影響を与えるため、実施のタイミングやプロダクトの成長段階、実装すべき機能の範囲などについて、事前に十分な話し合いを行う必要があります。
せっかくですから、読者の皆様にも理解していただきやすいよう、私が対応した過去の事例をご紹介します。この事例の場合、当該プロダクトの完成度が30〜40点程度と低い状態になることが見込まれていました。その理由は、他部署の古いサービスを参考に設計されたためで、最新の設計やサービスが組み込まれておらず、当然プロダクト開発としては良い状態ではありませんでした。
そのため、もちろん開発サイドとしては即座に作り直したい気持ちがありましたが、開発リソースを全て投入してしまうと、ビジネス側と経営側に多大な迷惑をかけることになります。そこで、現状を説明した上で、顧客とビジネス側の業務に支障が出ない「60点」の状態まで早期に改善し、そこから本格的な対応を始めるという合意を取り付けました。
「60点」の定義については、プロダクトバックログを作成し、数百項目に及ぶ改善点を洗い出して、明確な目標を設定しました。古いVer1を捨てて再設計したVer2に着手するまでに1年6ヶ月程度かかり、その後Ver2をリリースするまでにさらに1年ほど（同等の機能を実現）を要しました。
このように、話し合いの中でどのように折り合いをつけるかは非常に重要なポイントになります。
開発最適化を進める第一歩に
開発最適化の第一歩として重要なのは、チーム全体が現状の課題と改善の方向性を共有することです。そのためにはまず、振り返りをこまめに行いながら、過去と現状と最新の設計（＝アーキテクチャー）とを俯瞰して見る環境を整えることが前進に繋がります。
開発最適化は、エンジニアチームだけでなく、ビジネス側や経営陣も巻き込んで取り組むべき重要な課題です。だからこそ適切なタイミングで最適化を行えば、プロダクトの競争力を維持しながらも、長期的な成功を実現できるはずですので、ぜひこの記事を参考にしていただけたら嬉しいです。
CTO経験者への壁打ち相談会実施中！
エンジニアリング、プロダクト、マーケティング、経営など、事業にまつわるお悩みをお持ちの方がいれば、ProfitMakersの坂口や伊東が壁打ちさせていただきます！気軽にお問い合わせください！
この記事が気に入ったらサポートをしてみませんか？