現場が業務ツールを自分で作れる組織になる。内製化の入口設計

「こういうツールがあれば楽になるのに」という声は、どの現場にもあります。

多くの組織では、その声がそのまま情シスへの依頼になり、優先順位の列に並び、数か月待つか、そのまま忘れられていきます。
依頼する側も待たされると分かっているので、次第に言わなくなり、小さな不便がそのまま放置され続けます。

今回は、現場が業務ツールを自作できるようになるまでの入口の設計を書いていきます。
内製化そのものの全体像は社内AIツールの内製化。現場が自分で作れる組織にするまでにまとめてあります。

情シスに頼まないと、要望そのものが出てこなくなる

情シスに頼るしかない状態は、何を止めているでしょうか？
問題は4つに整理できます。
まず待ち時間の長さで、依頼から着手までに数週間から数か月かかります。

次に要望そのものが出てこなくなることで、「これは依頼するほどのことじゃない」と現場のほうで諦められていきます。
もうひとつが情シスの負荷で、依頼が溜まって本来やるべき業務が圧迫されます。
最後が要件の曖昧さで、作ったことがない人が要件を書くぶん、実際に欲しいものとずれます。

いちばん損失が大きいのは、要望が出てこなくなることです。
改善の余地があるのに、誰も声を上げない状態になるからです。

現場が作れるようになると、待ち時間がゼロになる

現場が作る側に回ると、何が変わるでしょうか？
変化は3つあります。
いちばん大きいのが、待ち時間がゼロになることです。
思いついたその日に形になり、使ってみて違えばその場で直せるので、現場の発想そのものが変わってきます。

もうひとつが、要件を書けるようになることです。
自分で作ってみた人は、外部に発注するときの要件も具体的に書けるようになります。
内製化の副産物として、発注の質のほうが上がります。

3つ目が、情シスの負荷が下がることです。
「作ってほしい」という依頼が「見てほしい」という相談に変わるので、受ける総量そのものが減ります。
この負荷の低下が、情シスとの合意の材料になります。
内製化を進めるときに情シスが持つ懸念は正当なので、この構図を先に共有しておきます。

フェーズ1と2は、作れる人を数人つくり、部門に作り手を置く

導入は段階を踏みます。
最初の2つのフェーズを見ていきます。
最初は3〜5人に、実際に1つ作ってもらうところから始めます。
選ぶ基準は面白がって触るかどうかで、指示されて学ぶ人より勝手に試している人のほうが伸びます。

「作るものは指定しません」。
自分の業務で困っていることを1つ選んでもらいます。
自分が使うものを作ると、そのまま続きます。

作るものの条件は1つだけで、手元のデータだけを処理するものにします。
テキストの整形、表記の統一、形式の変換といったあたりで、データが外に出ないぶん失敗しても影響がありません。
期間の目安は2〜4週間で、1人が1つ作れれば十分です。

「動いたものを、共有の場で見せる」ところまでが、次のフェーズの材料になります。
数人が作れるようになったら、部門に広げます。
目指すのは部門に1人作れる人がいる状態で、全社員が作れるようになる必要はありません。

理由は2つあります。
100人に薄く教えるより10人に厚く伝えたほうが速く、部門の作り手が周りの要望を聞いて作る形になるからです。
もうひとつは、要望を出せる人と作れる人がそろえば、それで業務は回るからです。

やることは3つあります。
まず作り手を明示的に任命し、上司にも伝えます。
「業務時間の一部をこれに使ってよい」と上司が知っている状態にしておきます。

次に支援を用意します。
手順書、練習用の環境、相談の窓口です。
もうひとつが、作ったものを共有の場で見せる場づくりで、月1回・10分の場を設けます。

「それ欲しい」という声が出ると、次を作る動機になります。
いちばん重要なのは、時間を確保することです。

時間が確保されていないと本人の善意の持ち出しになり、まず続きません。

現場発ツールの作り方そのものは「あったら便利」を1日で形にする。現場発ツールの作り方と社内配布にまとめてあります。

フェーズ3は、全社で共有し、扱う情報で作らせる範囲を分ける

数が増えてきたら、共有の設計に入ります。
ここで決めるのは2つです。

まず、作られたものをカタログにして、全社から探せる状態にします。
カタログに載せる項目は5つで、名前・何ができるか・想定する職種・作成者・最終更新日です。

「職種でたどれる形にすること」も効きます。
自分と同じ職種の人が何を使っているかは、そのまま自分への提案になるからです。
「利用回数を、作り手に見せること」も欠かせません。
「30人が使っている」と分かれば、その人は次を作ります。

四半期に一度、棚卸しをして、3か月使われていないものは外し、カタログの密度を保ちます。

カタログ化そのものは共有したのに使われない。社内AI資産をカタログ化するで扱っています。

自由に作らせると事故が起きるので、線も引いておきます。
「何を作ってよいか」ではなく、扱う情報のほうで分けるのがコツです。

第1階層は自分の手元のデータだけを扱うもので、テキストの整形、形式の変換、差分の比較です。
ここは自由に作って構いません。

第2階層は社内データを読むもので、共有シートを集計する、社内文書を参照するといった用途です。
作る前に、一声かけてもらいます。

第3階層は社内データを書き換える、外部と連携する、他部署に配るものです。
ここは推進チームか情シスのレビューを通します。
この3分類を1枚にして配ると、現場は自分がいまどこにいるかが分かり、萎縮せずに動けます。

「第1階層を先に『自由』と言うこと」も大事です。
制約の話から入ると、全部が制約に見えてしまうからです。

扱う情報の階層そのものは現場が作ったツールが業務データに触り始めたら。個人利用と法人利用の境界、配布と権限の設計は現場が作ったAIツールを埋もれさせない。社内配布と権限の設計にまとめてあります。

続かない原因は、使われているかが見えないことと、作りすぎ

内製化はなぜ止まるのでしょうか？
最大の原因は、作ったものが使われているかどうか分からないことです。
自分が3時間かけて作ったツールが誰にどれだけ使われているか分からず、褒められもしないと、次を作る動機が湧きません。

必要なのは、利用回数と利用者が作り手に見えている状態です。
「30人が使っている」と分かれば次を作りますし、周りから「あれ便利ですね」と言われれば、称賛の循環が内製化を回す燃料になります。

逆に、使われていないと分かるのも重要です。
廃止の判断ができるようになり、「作ったものを捨てられる」状態は、内製化が健全に回っているサインです。

もう1つの失敗パターンは、作りすぎることです。
まず機能を詰め込みすぎるやり方で、「せっかく作るなら」と機能を足していくと、完成が遠のいて操作も複雑になり、結局使われません。
もうひとつは汎用化しようとするやり方です。
「他の部署でも使えるように」と抽象化すると、誰にとっても中途半端になります。

まずは、1人のために作ります。
対策は、1つの用途だけの超最小単位で作ることです。

作るのに半日、使ってみて2週間、使われたら広げ、使われなければ捨てます。
最初から小さく作っておくと、捨てる判断のほうが軽くなります。
超最小単位での開発は内製開発は超最小単位で回す。作りすぎて失敗しないためににまとめてあります。

作ったものが共有され使われる場がないと、内製化は続かない

内製化を回す鍵は、作り手が報われる経路にあります。
手順や環境のほうは整えれば済みますが、ここは仕組みがないと成立しません。
必要な情報は明確で、誰にどれだけ使われたかです。
これが作り手に見えていれば次を作りますし、見えていなければ1つ作って終わります。

「職種でたどれる一覧」も必要です。
ここがないと部門を越えた利用が起きず、使われないものは実績も出ません。
ただ、これを手作業で維持するのは重く、利用回数を集める作業が続かなければ、カタログの価値も半分になってしまいます。

私たちが提供している組織のAIポータル「AI Portalize」では、社内で作ったAIツールを登録すると全社に公開され、「いいね」の数・使われた回数・使った人数が作った人に返ってきます。
作られてはいるが続かない、という状態で止まっている場合は、考え方の参考になると思います。

内製化は、次の作り手が動く仕組みまで含めて完成する

情シスに頼まないと作れない状態の最大の損失は、要望そのものが出てこなくなることです。
改善の余地があるのに、誰も声を上げなくなります。
現場が作れるようになると、待ち時間がゼロになり、要件を書けるようになり、情シスの負荷が下がります。
もちろん、この負荷の低下こそが情シスとの合意の材料になります。

進め方は3フェーズです。
3〜5人に自分の業務のものを1つ作ってもらい、部門に1人作り手を置き、カタログにして全社から探せる状態にします。

作らせる範囲は扱う情報で3階層に分け、第1階層を先に「自由」と言います。
続かない最大の原因は、作ったものが使われているか分からないことです。
利用回数が作り手に見える状態こそが、内製化を回す燃料になります。
作りすぎを防ぐには、1つの用途だけの超最小単位で作り、使われたら広げ、使われなければ捨てます。

まずは自部門で面白がって触っている人を1人見つけて、その人が業務でつまずいている点を1つ、一緒に形にしてみましょう。