この手順だけは実データが揃っている
この図書館で唯一、進め方・ガバナンス・数字・失敗まで公開されている領域です。 他の職種では「こうするとよい」としか書けないところを、ここは実際にやった会社の記録で書けます。
そのぶん、楽な部分だけ真似される傾向があります。「現場が自分でアプリを作れる」は真似されますが、その後ろにある 3 つの仕掛け——機能制限・申請制・棚卸し——が抜けます。抜けた状態がいわゆる野良ツールです。
広げる順序
LIXIL の記録を段として並べるとこうなります。
| 時期 | やったこと |
|---|---|
| 2021年春 | Digital 部門内の事務スタッフで試験運用 |
| 2021年6月 | ワクチン職域接種の予約アプリを作って実績にした |
| その後 | 社内有志**約250名を「チャンピオン」**として開発・テスト・普及を担当させた |
| 同時期 | 役員全員に「夏休みの宿題」として自分でアプリを作らせた |
いきなり全社に配っていません。 事務スタッフ → 実績になるアプリ 1 本 → 有志 250 名 → 全社、と段を踏んでいます。
「役員に宿題」はそのまま真似できます。 経営層の理解を得る方法として、説明会よりはるかに確実です。自分で作れば、何ができて何ができないかが分かります。
数字が示していること
| チャンピオン 250 名の時点 | アプリ 500点以上 |
| 全社展開後 わずか3か月 | 10,000点超 |
| うちオフィシャルアプリ | 3,000点超 |
10,000 点のうち本番は 3,000 点。 7 割は作られたが本番に上がっていません。
これは失敗ではありません。 工程 4 の申請制が効いている状態です。作るのは自由、使うのは審査、という設計だからこの比率になります。申請制が無ければ 10,000 点すべてが業務に紛れ込みます。
3 つの仕掛け
1. 機能制限 — 触れなくしておく
複雑な機能についてはあらかじめ使えないようにしました
教育ではなく設定で防いでいます。 「気をつけてください」ではなく、危ない機能をメニューから消す。
AI にコードを書かせる側でも同じ考え方が使えます。Claude Code の permission mode は確認の頻度を段階で切り替えられ、モードを緩めても deny ルールと明示的な ask ルールはすべてのモードで適用されます（facts/claude-code/permission-modes.md）。sandboxing は OS レベルでファイルシステムとネットワークの境界を強制します（facts/claude-code/sandboxing.md）。
「あらかじめ使えないようにする」をコード側でやるなら、この 2 つがそれに当たります。
2. 開発は自由、本番は申請制
これがこの手順の中心です。
- 誰でも作ってよい
- 業務で使うには Digital 部門への申請と審査が要る
- 通ったものだけが「オフィシャルアプリ」として本番環境に入る
「自由」と「審査」を対立させていないところが要点です。作ることを止めると誰も作らなくなり、審査を止めると何が動いているか分からなくなります。
Power Automate も同じ構造を製品側で持っています。
組織の多くでは環境を使用することで、まだ開発中のフローと、幅広く使用する準備が整っているフローとを分けています
ただし注意が要ります。
組織内のすべてのメンバーが、既定の環境にアクセスできます
既定の環境をそのまま本番にすると、この分離が成立しません。 環境を分けるところから始めてください。
3. 年 1 回の棚卸し
2024 年は約 10% を削除しています。利用実績のないアプリを消す作業を、運用に組み込んでいます。
作りっぱなしは避けられないという前提に立っているのがよいところです。「使わなくなったら消してください」という運用は必ず破綻するので、時期を決めて機械的に消します。
現場の抵抗をどう扱うか
船井総研グループの記録に、顧客先で実際に出た声が残っています。
「タブレット入力が二度手間になる」「管理されるようで嫌だ」
対応は 2 つ挙げられています。
- リアルタイムで修正を出し続ける — 工場に朝から晩まで張り付き、見つけた要望をその場で Gemini に伝え、生成されたコードを即座にアプリへ反映した。「従来なら数か月かかるような開発がその場で実現」
- 作業員一人ひとりにヒアリングを重ねて「不安や懸念に隠れている要望」を見つけ出す
2 番目が本質です。 「管理されるようで嫌だ」は反対意見ではなく、要件が形を変えて出てきたものとして扱われています。誰がその画面を見るのか、何に使われるのかが不明なことへの反応です。
結果として顧客の 8 割がアプリを活用しています。
要望を拾う工程を飛ばさない
この職種で最も飛ばされやすいのが工程 1 です。 作るのが速くなったぶん、聞かずに作れてしまいます。
船井総研の型は「聞く」ではなく**「見る」**です。工場に張り付いて作業を観察し、そこで見つけた要望をその場で反映する。現場は自分が何に困っているかを言語化できないことが多いので、聞くだけでは出てきません。
これは 業務要件定義の工程そのものです。この職種は工程が分業されていないので、要件定義と受入れを飛ばして「作る」だけに集中しやすい構造になっています。LIXIL の申請制も船井総研のヒアリングも、飛ばしがちな前後の工程に手を入れています。
始めるときの順序
- 環境を分ける（工程 2）。ここを最初にやらないと後から直せない
- 実績になるアプリを 1 本作る。 全社に説明する前に、動くものを 1 つ
- 申請の窓口と審査基準を決める。 誰が何を見て通すか
- 棚卸しの時期を決める。 始める前に決める。始めた後では決まらない
- そこまで決めてから広げる
この分野で分かっていないこと
- ブラックボックス化への解答が無い。 LIXIL は「開発者の異動・退職によるブラックボックス化」を課題として挙げているが、どう解決したかは公開されていない
- 本番に上がらなかった 7,000 点が何だったのかの分析が無い。 練習なのか、審査に落ちたのか、申請すらしなかったのかが分からない
- 審査基準が公開されていない。 申請制があることは分かるが、何を見て通しているかは書かれていない
- 吉本興業/FANY の「野良GAS の解消」が未調査。 LIXIL のつまずきの続きに当たるはずで、この手順で最も埋めたい穴