内製開発は超最小単位で回す。作りすぎて失敗しないために

「せっかく作るなら、あれもできるようにしよう」と機能を足していくと、完成までに1か月かかります。
そのあいだに操作のほうも複雑になっていき、配ったときには作った本人にしか使い方が分からなくなっています。
一度この経験をすると、次を作らなくなります。

内製で作ったものが結局は使われない原因の大半は、そもそも大きく作りすぎたところにあります。
今回は、業務改善を小さく始めて、この失敗を避ける進め方を書いていきます。
内製化の全体像は社内AIツールの内製化。現場が自分で作れる組織にするまでにまとめてあります。

大きく作るほど、完成は遠のいて使われなくなる

なぜ大きく作ると失敗するのでしょうか？
構造としては3つあります。

機能が増えるほど完成までの時間が延びて、途中で優先順位が下がり、未完成のまま止まります。
入力する項目や選択肢が増えるほど、使う側からすると単純に重くなります。
いちばん損失が大きいのは、使ってみないと本当に必要な機能が分からないのに、作り込んでから「これは要らなかった」と気づくパターンで、使わない機能に費やした時間が無駄になるうえ操作まで複雑になります。

だからこそ「小さく作って、使ってから足す」。
これが、この記事で書く対処の方向です。

作りすぎの失敗は、汎用化しようとするところがいちばん多い

具体的な失敗の型は、3つに分かれます。
まず、「せっかく作るなら、あれもできるようにしよう」と機能を詰め込む型で、操作が複雑になって使われなくなります。

次に、「他の部署でも使えるように」と汎用化しようとする型で、誰にとっても中途半端なものになります。
もうひとつが、「こういう場合はどうするか」を全部考えて例外に対応しようとする型で、そのぶん完成が遠のいていきます。
このなかでいちばん多いのは汎用化しようとする型で、良いことをしているつもりで、実際には価値のほうを下げています。

だからこそ「まずは1人のために作ります」。
自分自身か、目の前にいる1人のために作るためです。

そこで実際に使われたら、そのとき初めて他の人にも合うかを考えます。
現場発のツールの作り方は「あったら便利」を1日で形にする。現場発ツールの作り方と社内配布にまとめてあります。

超最小単位は、入力項目3つ以内で決まる

超最小単位は、どこまで削ればよいのでしょうか？
基準は3つあります。
まず、用途は1つだけに絞ります。
例えば「動画を分割する」だけにして、サイズの変換や形式の変換は足しません。

次に、作るのに半日以内で済むかどうかです。
これを超えるようなら、範囲のほうが広すぎます。
最後は、入力する項目を3つ以内に絞ることで、4つ以上必要になるなら用途が複数含まれています。
このなかでいちばん判断に使いやすいのは入力項目の数で、数えるだけで範囲が広すぎるかどうかが分かります。

もちろん、例外のほうには対応しません。
8割のケースで動けば十分で、残りの2割は手作業で回します。

とはいえ、エラーの処理まで作り込む必要はなく、想定外の入力が来たらそこで止まる状態で構いません。
少なくとも、最初に配る版においてはそうです。
完璧な仕様を待たない考え方は完璧な仕様を待たない。「作って動かす」を組織の作法にするにまとめてあります。

2週間使ってから、続ける・直す・捨てるを決める

作ったあとは、どう運用すればよいのでしょうか？
作ったら2週間使ってみて、そこで判断します。

判断は3つで、続ける場合は使われているので出ている要望の機能を足していきます。
直す場合は、使われてはいるが使いにくい点があるので、そこだけを直します。
捨てる場合は使われていないので、その理由を1行だけ残して捨てます。
要点は、この「2週間」という期限を決めておく点で、期限を切らないと使われていないものがそのまま放置されます。

「捨てた記録のほうも、残しておきます」。
何を作ってなぜ使われなかったのかが残れば、同じ無駄を別の人が繰り返さずに済みます。

「捨てるのは、失敗ではありません」。
2週間で判断できたこと自体が成果で、1か月かけて作り込んでから捨てるより、はるかに良いはずです。

足す機能の判断基準は1つだけで、複数の人から要望が出ているかどうかです。
1人からの要望だけでは足しません。
その人に固有の事情である可能性があるからです。

「要望が出ていない機能は、足しません」。
「あったほうがいいだろう」という予測で足すと、使われない機能が増えるだけだからです。

また、機能を足すときには必ず1つ外し、使われていない機能を外してから新しい機能を足していきます。
そうしないと、操作が複雑になり続けます。

外す判断のためには、機能ごとの利用状況を見ておきます。
どの機能が実際に使われているのかが分からないと、そもそも外せません。
この設計にしておけば、ツールは重くならず、そのまま使われ続けます。

捨てる判断を軽くする文化こそ、いちばん効く

組織の設計は、なぜここまで重要なのでしょうか？
捨てる判断が重いと、そこから作りすぎが起きます。
「捨てるのが惜しいから、完成度を上げてから配ろう」という判断になってしまいます。
だからこそ「捨てること自体を、減点にはしません」。

やることは3つあります。
まず「試した数」を評価の対象にすると宣言しておき、成功した数ではなく試した数のほうを見ます。

次に、捨てた事例を共有の場に載せます。
月1回の共有会で、成功例2件と捨てた例1件を出します。
捨てた例のほうが、学びが多いからです。

最後に、推進担当が自分の捨てた事例を最初に話します。
「これを作ったけど、使われませんでした」。
それだけで、場の空気が変わります。

また、部門長のほうにも事前に伝えておきます。
部下が試して捨てたことを減点しないよう共有しておかないと、現場は上司の評価を気にして動かなくなります。

小さく作るのは、実は難しい判断です。
理由は3つあります。
まず、作っている途中で「これもできる」と気づいて足したくなります。

次に、「これで配っていいのか」と不完全なものを配るのが気が引けます。
最後に、「こういう場合はどうするんですか」と聞かれるのが怖くて、例外を無視するのが不安になります。
このなかでいちばん大きいのは不完全なものを配るのが気が引けるという理由で、作り手は自分のものが荒いことを自覚しているので簡単には配れません。

対処としては、「試作」という区分を作っておきます。
試作として配れるのであれば、完成度の議論をしないままそこへ置けます。

「推進担当が、自分の荒いもののほうを最初に配ります」。
「これくらいの完成度でいいんだ」と分かった途端に、配りやすくなります。
内製化の入口そのものは現場が業務ツールを自分で作れる組織になる。内製化の入口設計、内製と購買の判断は業務システムを内製するか買うか。判断基準を組織のフレームにするにまとめてあります。

つまずきやすい失敗は8つあって、機能を詰め込む、汎用化しようとする、例外に全部対応する、2週間の判断の期限を決めない、要望が出ていない機能を足す、足すときに外さない、捨てることを減点にする、小さく作ったものを拡張して外に出す、というものです。
どれも、1つの用途に絞り、まず1人のために作り、8割で動けばよしとし、期限を決め、複数から要望が出たものだけを足し、足すときに1つ外し、試した数を評価し、外に出すときは作り直せば避けられます。

事業化を狙うなら、社内ツールの前提ごと作り直す

小さく作ったものは、事業になるのでしょうか？
社内向けに作ったものが、外に出せる価値を持っている場合があります。
そのとき、「小さく作る」という原則のほうが変わります。
社内ツールは使い方を知っている人が使う前提で成り立っていて、例外に対応していなくても手作業で回せますし、エラーで止まっても作った本人が直せます。

ところが外に出すとなると、その前提が丸ごと変わります。
使い方を知らない人が使い、例外が必ず発生し、エラーで止まると相手の業務のほうが止まります。
つまり、小さく作ったものをそのまま拡張するのではなく、設計そのものを一度作り直すという判断になります。

その手前には、「事業として成立するのか」の見極めが来ます。
同じ課題を持つ会社が他にもあるのか、提供を続けられるのか、責任を負えるのか、というところです。

この判断を軽く見て進めると、本業の業務まで巻き込んで止まります。
社外に公開する場合の審査は社内AIツールを社外に公開する時の審査フローとチェックポイントにまとめてあります。

私たちが提供しているAI開発支援では、事業として成立するかの見極めから、PoCやMVPとしての作り直しまでを一緒に進めています。
内製したものに手応えがある場合は、考え方の参考になるかもしれません。

小さく作って、使われたら足す。それだけで作りすぎは防げる

内製で失敗する原因は、大きく作りすぎた点にあります。
完成が遠のき、操作が複雑になり、要件が固まる前に作り込んでしまいます。

失敗の型は3つで、いちばん多いのは汎用化しようとする型です。
良いことをしているつもりで、価値のほうを下げています。
超最小単位の基準も3つで、用途は1つだけ、作るのに半日以内、入力する項目は3つ以内です。

このなかでいちばん判断に使いやすいのは入力項目の数で、例外には対応せず8割で動けば十分です。
運用は、2週間使ってから続ける・直す・捨てるを判断します。
この期限を決めておくことが要点で、捨てた記録のほうも残しておきます。

足す機能は、複数の人から要望が出ているものだけに限ります。
足すときには必ず1つ外し、外す判断のために利用状況を見ておきます。

そして、捨てる判断を軽くする文化がいちばん重要です。
「試した数」を評価の対象にし、捨てた事例を共有の場に載せ、推進担当が自分の捨てた事例を最初に話します。

また、部門長にも事前に共有しておきます。
小さく作るのが難しいのは、不完全なものを配るのが気が引けるからです。

「試作」という区分を作っておくと、配りやすくなります。
外に出す規模になったら、設計を一度作り直します。

一言でいうと、小さく作って使われたら足す、それだけで作りすぎの多くは防げます。
まずは自分の業務の困りごとを1つ選んで、入力する項目3つ以内で作ってみましょう。