決めた通りに完成しそのあとも良くなり続ける
決めた品質とコストと期間でプロダクトが完成する。作りながら、出してから分かったことが何度でも形になる。企業のステージに合ったプロダクトと開発プロセスを実現します。
こんな方へ
決めた品質とコストと期間でプロダクトを完成させること。完成したものがユーザーに使われ続けること。どちらも難しく、それぞれ別のプラクティスが必要です。
見積もり通りに開発され、品質が落ちず、納期に間に合う。この状態は要件を正しく把握管理する力、変更への対応能力、決まったものを高速かつ高品質に作る開発力が揃って初めて実現されます。
完成したあとユーザーがプロダクトを使い続け、実際に価値を生むかは要件に現れないような細かな改善の積み重ねによって決まります。たとえば画面の反応速度、入力ステップ数、エラーへのアクショナブルなガイダンス。
これらも本来なら要件に入れておきたいものですが、事前に書き出すことはできません。実物が動き始めて初めて見えてきます。
プロダクトの理想像を事前に書き出せない以上、課題が判明してから改善するサイクルの速度が最も重要です。作り始めてから、リリースしてから分かったことを何回プロダクトにフィードバックできたか。実際に使用されるかどうかはその回数で決まります。
回数を決めるのは変更にかかるコストと時間、そして変えても壊れないことです。一度の変更に数週間かかり、変えるたびに別の場所が壊れるならフィードバック自体が不可能になります。変えやすさと壊れにくさはそれ自体が目的ではなく、改善を何回重ねられるかを決める条件です。
要件の把握が浅いまま着手し、途中で作業量が膨らむ
変更が起きるたびに追加見積もりと納期延長が積み上がる
納期に間に合わせるために品質が削られ、後の改修費用として跳ね返る
要件書の機能は揃っているが、ユーザーが自分から使いに来ない
ユーザーに価値が生まれたかどうかは納品時に確認されず、誰も見ていない
現場が Excel などの別ツールを使い続け、プロダクトが飾りになる
実装中に気づいた改善が仕様にないという理由で見送られる
改善するたびに追加費用と納期の交渉が必要になる
リリース後に見えた課題が次の開発案件まで手つかずで残る
小さな修正でも数週間かかり、思いついた改善が実行されない
新機能追加のたびにベンダーから全面刷新の見積もりが返ってくる
改修コストが上がり続け、事業の変化に追いつけなくなる
変更のたびに別の場所で不具合が生まれ、修正が修正を呼ぶ
本番の障害対応に人手を取られ、改善に手が回らない
壊れることを恐れて変更を避けるようになり、プロダクトが固まる
同じものを作るとしても、どの技術で、どのプロセスで作るかで結果は変わります。
作るものが同じでも、選ぶ技術によって費用も成果も変わります。そして最適な選択肢を実際に選べるかどうかは、手札をどれだけ持っているかで決まります。枯れた技術しか扱えなければ最近の課題解決に追従できず、新しいものだけを使うと過剰で不安定な構成になります。
技術力とはコストリターンを最大化する能力そのものです。
技術選択ができても開発プロセスが貧弱では改善実現はできません。フィードバックの反映回数は日々の開発プロセスがクリティカルに効いてきます。
速度を決めるのは二つで、改善を決めてから着手するまでと、着手してから本番に出るまでです。前者は計画と意思決定の組み方が、後者は継続的なデリバリの仕組みが決めます。両方が整った状態は日や週単位など任意のタイミングでの改善を可能にします。
人的努力で品質を担保する運用とは仕組みとして別のものです。
技術が事業とフィットするかどうかは業界の制約と企業のステージによって変わります。金融で求められるセキュリティ要件、不動産や建築の業務プロセス、広告で扱うデータ量。スタートアップに必要な立ち上げ速度と、大企業に求められる統制。
不動産、建築、広告、金融・証券、システム開発、EC、AI・機械学習といった業界で、企画・戦略の立案から設計、開発、運用構築まで手がけてきました。外部 CTO や技術顧問として技術投資の判断そのものを担う立場でも参画経験があり、立ち上げ期のスタートアップから大企業の子会社まで規模とステージを問いません。技術面だけでなくビジネス適用の側面でも実践知を有します。
プロダクトやプロジェクトで実際に使っている主要な技術です。安く、速く、安全に、将来にわたって性能と安定性を保てるかどうかで選びます。流行しているかどうかは判断基準にしません。
お客様の確認は判断が要るところだけに絞ります。材料は文章ではなく、図と画面イメージと動く実物で用意します。仕様書を読み込んで齟齬を探す作業は発生しません。
実装以前に定義可能かつそうすべきものは全て定義します。曖昧なまま進めると途中で作業量が膨らみ、着手から動くものが出るまでのリードタイムが伸びます。ただし定義すべきものとそうではないものには基準があります。
分ける基準はデリバリーのリードタイムです。データモデルを曖昧に残したまま進めると、画面の都合が出るたびに広範囲の改修が必要になります。反対に細かな文言まで固定すると、実物を触って分かったことを反映できなくなります。
お客様にお願いするのは業務の実態と事業の意図の共有、そして機能の優先順位の合意です。設計の内容は文字と共に図表やモック画面などを補い、なるべく理解と判断のコストを下げることを目指します。
機能を実装する前に、最小構成のコードが検証環境まで自動でデプロイされる状態を作ります。デプロイ経路を一番最初に確保し、フィードバックサイクルの高速化を実現します。
お客様にお願いすることはありません。
着手の順番は事業への影響が大きいもの、実物を見ないと判断できないもの、技術的な不確実性が高いものからです。早く形になるほどフィードバックを戻せる回数が増え、問題を早期に見つけることができます。
変更を前提に決めておいた画面のレイアウトや操作の順番は実物を触ってから確定させます。実物を触って出る指摘は設計のやり直しではなく、想定した手順の一部です。
お客様にお願いするのは検証環境を触っての指摘です。実際に画面を触ることで本番レベルの指摘を可能にします。
検証環境まで通しておいたデプロイ経路を、本番まで延ばします。一度きりの本番投入ではなく、繰り返し出すための経路を仕上げる段階です。
お客様にお願いするのは受け入れテストです。受け入れシナリオは共同で作成するため、何を確認すればよいかが最初から明らかな状態で始まります。
利用状況から出た改善候補が次の継続的なリリース反復に含められます。実装からリリースまではすでに整備されている基盤を再利用し高速にリリースを回します。アーキテクチャと非機能の水準を保ったまま、優先度の高い機能から随時リリースします。
お客様にお願いするのは改善候補の共同策定です。候補は利用データと一緒に提示するため、勘ではなく根拠を持ってネクストアクションを策定します。
このサービスで取り組んだ事例です。
AIを主力とする開発会社との取り組みです。同社にはプロダクト開発の引き合いがありましたが、大規模な開発の経験も、中核の技術を担える人もいませんでした。KDOTは技術顧問として、アプリケーション基盤と中核の技術を用意し、エンドクライアントとのプロジェクトの進め方も並走しながら伝えました。同社は海外市場向けの単発ワークのマッチングサービスを受託し、数億円規模の開発を公開まで完走しました。これで同社が受託できる範囲は、AIからプロダクト開発まで広がりました。
製造業向けにソフトウェア製品を提供する企業との取り組みです。同社は工場の電力を見える化する機能を製品に加えたいと考えていましたが、社内の開発者だけでは手も知見も足りませんでした。電力計の接続から、データを工場の判断に使える形にするところまでを開発支援会社のKDOTにまとめて任せ、同社は着手から約4か月でこの機能を製品に加えて工場へ販売できるようになりました。納品後の約9か月はKDOTが運用を担い、支援が終わった今は同社が自ら運用を続けています。
広告枠の価格設定モデルを開発する分析会社との取り組みです。分析会社はこのモデルを、アドネットワークを運営する配信事業者に提供しています。配信事業者は、自社の環境で自社のデータと統合して分析を実行し、新しいモデルを自ら検証できるようにしたいと考えていました。それにはモデルを配信事業者のシステム上で稼働させる基盤が必要でしたが、分析会社はそれを社内で開発できませんでした。KDOTは分析会社側のチームに参画し、この基盤をチームで設計・構築しました。分析会社はモデルを分析結果として納品するだけでなく、稼働させる基盤まで含めて納品できました。あわせて、社外からの要望に応じてモデルを相手の環境へデプロイできる基盤を自社の資産にできました。分析会社はこの基盤を継続的に提供するサービスも配信事業者に提案しています。
業務向けソフトウェアを提供する企業との取り組みです。同社は、プロダクト共通の認証基盤の内製を始めましたが、技術的な難しさから着手直後に断念しました。開発支援会社のKDOTはその開発を引き取り、Amazon Cognitoによる認証とトークン発行に、Goで実装した独自の認可サービスを組み合わせた共通基盤を設計しました。現在は同社の10近いプロダクトがこの基盤を共通で使い、新しいプロダクトを追加するたびに認証を作り直す必要がなくなりました。KDOTは統括するチームでこの複雑な基盤を開発し、その上で機能追加と運用保守を数年にわたって続けています。
金融機関向け資産運用システムを開発する企業との取り組みです。同社は、性能とセキュリティに高い要件を持つシステムを、複数のエンジニアで開発していました。開発支援会社のKDOTが担ったのは、アプリケーションの実行を支える機能と、複数の機能で利用する中核処理です。技術的な難所は、調査から解決まで担当し、意思決定履歴として社内に残しました。またクライアント企業の力を底上げするため、我々の問題解決が会社内で再現可能になるように勉強会も実施しました。これにより、担当者を増やしても全体の整合性を保ち、エンジニアのインプットが線形にスケールする状態を実現しました。
事業の課題や技術的な悩みなど、どんなことでもお聞かせください
