そもそも自分たちで作るべきか

生成AIに頼めば、社内で使う仕組みを自分たちで作れる範囲は大きく広がりました。AIと対話しながら、コードの中身を細かく見ずにプログラムを作るやり方は、バイブコーディングという俗称で呼ばれています。勤怠管理のような社内の仕組みを、経営者が自分で作った例も出てきました。けれど、「簡単に作れる」と「動かし続けられる」は別の問いです。作れるようになったから作るのではありません。既にあるものでは足りない理由があり、自分たちで持つ意味があり、作った後の責任まで引き受けられるときに作ります。

この記事は、実務編の最初の問いを扱います。作る前に考える4つの問いの、一つ目です。対象は社員だけが使う社内システムで、前提は冒頭ページにまとめました。作らずに済む道を先に探し、それでも作る業務が、自社の人が自分たちで作り、直していく「内製」に向くかを6つの基準で見て、責任者と最初の一つの業務を決めるところまで進みます。

「簡単に作れる」と「動かし続ける」の間に何があるか

「作る」は、AIに頼んで、動くものが出てくるまでのことです。小さな仕組みなら、半日から数日で形になることも珍しくありません。一方「動かし続ける」は、その仕組みを業務に組み込んだあと、業務が続く限り面倒を見続けることです。業務が変われば直す。土台にしているサービスの仕様が変われば追随する。壊れたら戻す。出てくる結果が正しいかを、確かめ続ける。

「AIが書いたコードをどう動かすか」で、コードは書いただけでは動かず、動かす場所に置いて初めて動く、と扱いました。社内システムはその先の話で、置いて動いたところが入口です。生成AIを使えば、ITを専門としない人でも、社員だけが使う小さな仕組みを形にできること自体は、もう疑わなくてよい段階です。ログインや認証のように、自分たちだけで扱うにはリスクの高い領域があり、詳しい人や専門家の力を借りる判断が要ることは、冒頭ページのとおりです。問うべきは、作れるかではなく、その先を引き受けてまで自分たちで作る意味があるか、です。

作った後に、何を引き受け続けるか

引き受けるものの中身を、先に見ておきます。自分たちで作ると、自社で引き受ける範囲が大きくなります。主なものは4つです。

• 直す人の時間。 締め日や承認の流れといった業務のルールが変わる。管理したい項目を増やしたくなる。使ってみて、例外が見つかる。そのたびに直します。直す作業はAIに頼めますが、何をどう直すか決めて頼み、直った結果が正しいか確かめる人の時間は要ります。
• ツールと環境の継続費用。 仕組みを動かす場所の利用料と、作る・直すためのAIツールの費用です。手持ちの契約の範囲で追加費用なしに始められることもあれば、業務で使い続けるうちに、動かす場所やAIツールの有料プランが要ることもあります。
• 動かす土台の変更への追随。 業務は何も変わっていなくても、動かす場所や使っているサービスの仕様が変わり、AIが書いたコードが頼っていた仕組みが変わって、そのままでは動かなくなることがあります。既製のサービスなら提供者が吸収している変化を、自分たちで受け止めます。
• 属人化。 作った本人にしか分からない状態のことです。本人が忙しくなる、辞める、興味を失う。そのどれかが起きた時点で、誰も直せない仕組みになります。

このうち一番大きいのは、見えやすい月額の費用ではなく、直す人と確かめる人の時間です。時間は見えにくく、本業を圧迫してから気づきます。作る前に、この4つを誰が引き受けるかまで考えておくと、「作れたのに使われない」を避けられます。本人以外も状況を確認して引き継げる状態にする備えは「作ったものは、業務に乗せられるか」で扱います。

既にあるもので、足りないのか

これを引き受けてまで、自分たちで作ることで何を得るのか。ソフトウェアには、一度作ればコピーして、多くの会社で使えるという性質があります。だから、どの会社にもある業務については、一社ごとに同じものを作るより、既製のサービスを使うほうが合理的になりやすいのです。作ることも、直し続けることも、法令や制度の変更への追随も、自社だけで引き受ける必要がなく、その対価を利用料として払います。世の中にすでに十分なものがあるなら、新しく作る必要はありません。

一方で、社員数十人の会社から見ると、既製のサービスが大げさに見えることがあります。自社では使わない機能が並び、その分まで利用料を払っている。単純な業務に対して、製品が重すぎる。自社の運用に合わせるために、設定や使い方に無理をしている。案件ごとに売上・材料費・作業時間を集計して採算を見る仕組みのように、会社ごとに仕事のやり方や計算のしかたが違い、既製のサービスではぴったり合わない業務もあります。こうした場合には、必要なものだけを小さく自分たちで作ることが、選択肢になります。

ただし、既製で足りないことは作る理由の候補であって、それだけで作るのが正解になるわけではありません。判断は、「作れるか」や「維持できるか」だけでもありません。既にあるものでは足りない理由があるか。その差を自分たちで持つ意味があり、作る手間と維持の手間や費用を引き受ける価値があるか。この二つがそろって、初めて作る側に傾きます。

作らずに済ませる道は、ないか

作る価値がありそうに見えても、いきなり「自分たちで作る」か「既製のサービスを買う」かの二択にはしません。作らずに済む道を、近いほうから順に探します。下に行くほど、自分たちで持つものが増え、引き受けるものも増えるからです。

選択肢	勤怠管理なら
今ある仕組みのままで済ませられないか	タイムカードとExcelの集計はそのままに、転記や検算の手順だけ減らす
既製のサービスを、そのまま使えないか	既製の勤怠管理サービスに乗り換える。安価で成熟したものが多い
今あるツールやサービスを組み合わせたり、自動化したりできないか	既製の勤怠サービスの集計を、給与計算のソフトに渡す作業を自動にする
足りない部分だけを作れないか	現場ごとの締めのように、既製で足りない集計だけを作る
それでも必要なら、一から作る	出退勤の記録から集計まで、自分たちで作る

上から順に当たって、それでも残ったところだけを作ります。既製のサービスで十分なら、本番の仕組みとしては作りません。

「足りない部分だけ作る」のも「一から作る」のも、方法は一つではありません。AIに頼んでコードを書く方法もあれば、kintoneのように、プログラムを書かずに画面の操作で業務アプリを組み立てるノーコードを使う方法もあります。ノーコードは作り方の違いであって、作らずに済ませる道ではありません。どの方法で作っても、引き受け続けるもの4つは形を変えて残ります。ノーコードでは、動かす場所の管理はサービス側が担いますが、作ったものはそのサービスの中に閉じます。

この業務は、内製に向くか

作らずに済む道を当たって、それでも残った業務は、内製に向くかを見ます。次の6つの基準で、どこに慎重になる理由があるかを見てください。当てはまる数ではなく、重い懸念が一つでもあるかを見ます。

基準	向く側	慎重になる側
データを自分たちで扱えるか	自社の中にあり、自分たちで取り出して使える。自社のExcelの表や記録	他社のシステムの中にあって取り出しにくい。利用方法に制約があり、外部への依存が大きい
漏えい・誤公開したときの影響はどれくらい大きいか	扱う情報を最小限にでき、漏れたときの影響が比較的小さい。会議室の予定、備品の一覧	個人情報、給与や健康の情報、顧客・取引先の情報、営業秘密。漏れると本人や相手先に影響が及び、会社の信用に関わる
直せる人がどこにいるか	社内にいて、時間を割ける。作った本人のほかにも直せる人がいる	作った本人しか直せず、その本人も本業が忙しい
既製のサービスで代替できるか	既製のサービスでは本質的に合わない。または、一部だけ足りず、その部分を補いたい	既製のサービスで十分に足りる
壊れたり間違えたりしたときの影響は小さいか	止まっても紙やExcelでしのげる。間違った結果が出ても、人が気づいて正せる	止まると受注・支払い・給与に響く。間違った結果が、気づかれないまま給与や請求に進む
業務を言葉にでき、正しい結果を判断できるか	誰が・いつ・何を見て・何を決めるかを説明でき、「この入力なら、この結果が正しい」と確かめられる	例外が多く、担当者の頭の中にしかない。何が正しい結果か、人が確かめられない

2つ目の基準は、「この情報が漏れたら、誰に、どの程度の問題が起きるか」で見ます。個人情報には、会社としての法令上の義務もあります。会議室の予約のような小さな仕組みでも人の名前や予定は入るので、「小さいから安全」とは言わず、扱う情報を最小限にできるかで見ます。考え方は基本編の「何を渡し、何を伏せるか」と同じです。

5つ目の基準に「間違えたとき」を含めるのは、コードの中身を細かく見ずにAIに作らせた仕組みでは、止まることより、動いてはいるが結果が間違っていることのほうが危ない場合があるからです。間違った集計は、気づかれないまま次の工程へ進みます。勤怠や給与につながる処理が、その代表です。

6つ目の基準に「正しい結果を判断できるか」を含めるのは、「この入力なら、この結果になるのが正しい」と自分たちで言えなければ、AIが作ったものが正しく動いているかを誰も確かめられないからです。この確認は、動いたものを実際の業務で使ってよいかを判断する基準になり、「直しながら、使い続けられるか」で扱います。

勤怠管理は、内製に向くか

冒頭の勤怠管理を、6つの基準に当ててみます。

基準	勤怠管理では	見立て
データを自分たちで扱えるか	社員の出退勤の記録は自社の中にあり、自分たちで扱える	向く
漏えい・誤公開したときの影響はどれくらい大きいか	社員の個人情報。出退勤の記録だけでも誰がいつ働いたかが分かり、給与や健康の情報まで持たせれば影響はさらに大きい	慎重
直せる人がどこにいるか	作った本人だけになりがち	慎重
既製のサービスで代替できるか	安価で成熟した既製のサービスが多い	慎重
壊れたり間違えたりしたときの影響は小さいか	止まっても一時的には紙でしのげるが、集計の間違いは気づかれにくく、給与に直結する	慎重
業務を言葉にでき、正しい結果を判断できるか	就業規則と締め日があり、言葉にしやすい。集計が合っているかは、手計算と突き合わせれば確かめられる	向く

勤怠管理は、AIで作れることを実感しやすい題材です。記録して、集計して、出力するという形が分かりやすく、動くものはすぐにできます。けれど、本番で使う最初の内製システムとしては、意外に難しい業務です。表の慎重になる側に加えて、法令や就業規則が変われば追随が要り、業務が続く限り保守も続きます。作れる。でも、だから作るべきだとは限りません。

それでも作るなら、小さく始める方法があります。既製のサービスで足りるところはそのまま使い、現場ごとの締めや直行直帰の扱いのように、自社固有の部分だけを補う。まず小さな範囲で試して、学ぶことを目的にする。今のやり方と並行して動かし、合うことを確かめてから切り替える。こうした形なら、勤怠管理でも始められます。慎重になる側の基準のうち、扱う情報の保護は「誰に何を見せ、何をさせてよいか」で、直せる人が一人になる備えは「作ったものは、業務に乗せられるか」で、止まったときと間違えたときの備えは「直しながら、使い続けられるか」で扱います。

対照として、会議室や社用車の予約は、扱う情報を予定と名前に限れば、漏れたときの影響は比較的小さく、止まっても声をかければ済みます。既製の機能で足りるならそれでよく、自社の使い方に合わせたいところがあるなら、最初の一つに向きます。顧客の連絡先や取引条件を扱う案件管理は、漏れたときの影響が大きいので、最初の一つにはしません。

この仕組みに責任を持つのは誰か

ここまでで作ると決めたら、始める前に決めておくことが二つあります。一つ目が、責任者です。ここでいう責任者は、この仕組みの運用に責任を持つ人、つまり業務の責任者です。業務をどう変えるかを決め、この仕組みを使い続けるかを判断し、問題が起きたときの対応を決め、誰に直してもらうかを決める人です。社員数十人の会社なら、たいてい経営者自身か、その業務をいちばん分かっている一人になります。

実際に直す人は、責任者と同じでなくて構いません。AIに頼んで直す社員でも、ノーコードで組み直す担当者でも、外注先でも構いません。小さな会社では同じ人が兼ねることも多いのですが、責任を持つ人と、技術的に直す人は、別の役割です。責任者が決まっていれば、直す人が忙しくなったり辞めたりしたときにも、誰が次の対応を決めるのかが曖昧になりません。外注に出すなら、作って終わりでなく、直す契約まで含めて結びます。

責任者のいない仕組みは、作った瞬間から誰のものでもなくなります。動いているうちは気づかず、直す必要が出た日に、誰も手を出せないと分かります。責任者を決めることとは別に、アカウント・契約・コードを作った一人だけが握っていないかは、「作ったものは、業務に乗せられるか」で扱います。

最初に、どの一つの業務から始めるか

二つ目は、最初の業務です。6つの基準で大きな懸念がない、小さな業務を一つ選びます。とくに効く目安は4つです。漏えい・誤公開したときの影響が比較的小さいこと。止まったり間違えたりしても、別の方法で業務を続けられること。正しい結果を人が確かめやすいこと。小さく始められること。この4つを満たすなら、どの会社にもある業務でも、最初の一つとして構いません。会議室や社用車の予約、備品の貸出などは、扱う情報を予定や名前、品名に限った小さな仕組みにすれば、候補になります。既製のサービスで足りる業務を選ぶなら、それは「作らずに済ませる道」の例外です。目的は学ぶことだと割り切り、本番に乗せるかは動いてから改めて判断します。

そもそもシステム化に向くのは、手順の決まった定型の仕事です。基本編の「プログラム・AI・人に振り分ける」で、定型の仕事はプログラムの領分だと扱いました。社内システムとは、その定型を自社の形で固めたものです。そのうえで、自分たちで作るかどうかを決めるのが、この記事で見てきた判断です。システムにできることと、自分たちで作るべきことは別です。

つまずきやすいところ

• 「作れた」を「動かし続けられる」と取り違える。 動くものができたのは入口です。引き受け続けるもの4つを誰が担うかまで決めて、初めて作る判断になります。
• 月額だけを費用と思う。 追加の費用なしに動かしていても、直す時間と確かめる時間はただではありません。
• 既製のサービスで足りるかを、確かめずに作り始める。 作れることは、作る理由になりません。作らずに済む道を上から順に当たるのは、作り始める前です。
• AIに「作るべきか」を聞いてしまう。 「作れるか」と聞けば、作れる方向の答えが返りやすいものです。向くかどうかを決める材料は、既製のサービスが自社の運用に合うか、直せる人がいるか、間違いに人が気づける業務かといった自社の中の事情で、渡さない限りAIは知りません。材料を渡して整理を手伝わせるのはよくても、決めるのは人です。「優秀だが自社を知らない新人」に、会社の方針を決めさせないのと同じです。

まとめ

「簡単に作れる」と「動かし続けられる」は別の問いです。AIで作れるようになったから作るのではなく、既にあるものでは足りない理由があり、その差を自分たちで持つ意味があり、作った後に引き受け続けるもの4つに見合う価値があるときに作ります。作らずに済む道を近いほうから順に探し、それでも残った業務を6つの基準で見て、責任者と最初の一つの業務を決めます。

作ると決めた業務は、次に、その業務そのものが整っているかを問います。「業務は整っているか」で扱います。6つの問いの全体は冒頭ページにあります。