01
画面を見て初めて、思っていたものと違うと気づく
企画の段階では、言葉で合意できます。ところが実際の画面が出てくると、想定していなかった使われ方や例外が見つかります。ここから作り直すと、決めた予算と期間には収まらなくなります。
ECNは、先に決めるべきことと、動くものを見てから決めることを分けます。文字だけの仕様で合意する範囲を、できるだけ小さくするためです。
Why Now
見積りを取ったところで、話が止まっていませんか
作りたいものは決まっている。
ただ、金額と期間が出てきた時点で、企画のほうが止まります。
全部を作る前提で見積もれば、金額は大きくなります。大きな金額には稟議が要り、稟議には根拠が要ります。ところが根拠になる数字は、作って使ってみないと出てこないことが多い。ここで止まったまま動かなくなる企画を、よく見ます。
つくる速さが変わったいまは、順番を入れ替えられます。使われるかどうか分からない機能まで先に見積もらず、確かめたい部分だけを先に動く形にする。全体をいくらで作るかは、その結果を見てから決められます。
まず小さく動かして、続けるかどうかを決める。
その順番でやれるようにするのが、ECNの役目です。
Issues
一度つくったことがある方から、よくうかがう話
02
納品されたが、中身が分かるのは作った会社だけ
動いてはいる。ただ、直したいときにどこを触ればいいのか、社内に分かる人がいない。聞けば見積りになる。担当者が替われば説明からやり直しになります。
ECNは、引き渡すものを始める前に決めます。動くものだけでなく、次に触る人が読む資料と運用の手順まで、契約の範囲に入れておきます。
03
要望を全部入れたら、使われない機能の保守費が残った
出てきた要望を漏らさず入れることが、丁寧な仕事だと思われがちです。ところが公開してみると、使われているのは一部だけということがあります。残りの機能にも、保守の手間と費用はかかり続けます。
ECNは、作らない機能を先に決めることをご提案します。使われるかどうか分からないものを、先に保守の対象にしないためです。
04
公開したあと、使われているかどうかを誰も見ていない
公開までは頻繁に連絡があった。公開したら、次に連絡が来るのは契約更新のときだけ。数字を見る人がいないまま、月々の費用だけが続きます。
ECNは、公開したあとに何の数字を見るかを、公開する前に決めておきます。見る人がいないまま費用だけが続く状態にしないためです。
05
AIを使ったサービスを出したいが、社内に作れる人がいない
構想はある。ただ社内に作れる人がいない。外に頼むにも、何を頼めばいいのかを決められる人がいない。AIを使った部分は作って終わりではなく、出てくる答えを見て直し続ける運用が要ります。
ECNは自社でAIプロダクトを運用しています。作ることと、動かし続けることを、分けずに引き受けます。
Methodology
ECNの進め方
仕様書で決めきる前に、動くものを出します。
01
確かめたい部分だけを、先に動く形にする
最初に作るのは、全体ではありません。この企画で一番あやしいところ、外れたら計画ごと変わるところを選んで、そこだけを動く形にします。
触ってもらえば、言葉では出てこなかった条件が出ます。直すのは、まだ小さいうちのほうが安く済みます。
02
作る前に、使う人に会う
その画面を毎日開くことになる人に、作る前に話を聞きます。事業の狙いを立てた人と、実際に手を動かす人は、たいてい別だからです。
聞かずに作ったものは、正しく作られていても使われないことがあります。
03
止まってはいけないものの基準を、小さいうちから当てる
障害が起きたときの戻し方、データの持ち方、ある変更が他のどこに及ぶか。大規模なシステムで使ってきた見方を、最初の版から当てます。
利用が増えてから作り直しになる設計を、最初に選ばないためです。
04
公開の日を、運用の開始日として設計する
利用が集中する時間帯。想定していなかった使われ方。増えていく利用料。これらは自社のプロダクトで、実際に費用として払ってきたものです。
公開後に必要になるものを、公開前の設計に入れておきます。
05
削る提案を、こちらから出す
使われていない機能は、残しておくだけで保守の対象になります。数字を見て、外す候補をこちらから出します。
機能が少ないほど、直すのも足すのも速くなります。
Features
ECNに頼むと何が違うか
01
自分たちもプロダクトを動かしている
つむぎさん、Chatrus、AIコンシェルジュ、Sentina、Doga-Run。ECNは自社のAIプロダクトを、企画から開発、運用まで自分たちでやっています。
運用にいくらかかるか、使われない機能がどれだけ重いか。自社の費用として払っているので、提案の根拠もそこにあります。
02
止まってはいけないシステムを、長く動かしてきた
大手企業や官公庁の大規模なシステムを、作るところから動かし続けるところまで請け負ってきました。守秘の都合で社名は出せませんが、そこで使ってきた基準は変わりません。
小さく始めるプロダクトにも、同じ基準を当てます。
03
小さく始めて、育てるところまで受ける
最初の版を渡したあと、使われ方を見て次に何を作るかを決め直すところまで、同じ契約の中でお受けできます。
規模が大きくなってから作り直しになる設計を、最初に選ばずに済みます。
FAQ
よくあるご質問
構想が固まっていない段階でも相談できますか。
できます。何を作るかが決まっていない段階からで構いません。作るかどうかを決めるための材料づくりからお受けします。
途中まで作ったものを、引き継いでもらえますか。
できます。まずコードと設計資料、運用の記録を読んで、いまどうなっているかを整理するところから始めます。読んだうえで見つかった問題も、そのままお伝えします。引き継がないほうがよいと判断した場合も、その理由をお伝えします。
開発の途中で仕様を変えられますか。
変えられます。動くものを見てから決める進め方なので、途中で変わることを前提にしています。ただし変更のたびに、影響する範囲と費用をお出ししてから判断していただきます。
社内のエンジニアと一緒に進められますか。
できます。同じ環境で作業しながら、設計の考え方やレビューのしかたを共有します。いずれ自社で回したい場合は、この形をおすすめしています。
実装にAIを使うと聞きました。品質はどうなりますか。
AIが書いた部分も、設計の判断と最終確認は人がやります。何をどう確かめているかは、AI駆動開発のページに書いています。
作ったものの権利は、どちらに残りますか。
権利の帰属と、引き渡すものの中身は、契約で定めます。使っている外部サービスや部品の扱いも含めて、始める前に確認します。権利だけがあって中身が分からない状態にならないようにするためです。
運用や保守だけを頼むことはできますか。
できます。決められた点検だけでなく、動かしているなかで見つけた改善も、こちらから提案する形にしています。
まずは相談だけでも可能ですか。
可能です。作るかどうかを決める前の段階でも構いません。まず現状をうかがったうえで、進め方をご提案します。