コンテンツにスキップ

社内システムを作る

生成AIの進歩で、社内システムを自分たちで作るハードルは大きく下がりました。AIは、コードを書くだけでなく、どう作るかを一緒に考え、直し、動作を確かめるテストを用意するところまで、開発の多くの部分を手伝ってくれます。専門の開発チームがなくても、自社向けの小さな仕組みを作れる範囲は、大きく広がっています。実際に、経営者や業務の担当者が自分で社内の仕組みを作った例も出てきました。

小さく作って、試してみる。それは、もう現実的な選択肢です。

ただし、動けば終わり、ではありません。試しに動かしている間は見えなかった問題が、実際の業務で使い始めてから一つずつ顔を出します。会社の仕組みとして使う段階で大きく困らないために、作る前、動くものができてから、使いながら、それぞれの段階で考えておきたいことがあります。実務編は、それを知って進むための地図です。

「動く」と「会社の仕組みとして使える」の間

Section titled “「動く」と「会社の仕組みとして使える」の間”

会社の仕組みとして使うということは、社員が毎日の業務をそれに乗せ、そこにある記録を信じて動く、ということです。勤怠の集計が合っていなければ、そのまま給与計算に進みます。見せるつもりのなかった情報が、見えてしまうこともあります。作った人しか分からない仕組みなら、その人が忙しくなった時点で、誰も手を出せなくなります。どれも、動くものを作れるかどうかとは別の話です。

AIがどれだけ手伝ってくれても、任せきりにできないことがあります。何を、なぜ作るのか。何を正しいデータとし、誰に何を許すのか。動いたものを、業務にどう組み込み、実際に使ってよい状態か。使い始めてから、誰がどう直し続けるのか。こうした判断と確認は、人の側に残ります。とくに、AIが作ったものが、実際の業務で使ってよいものになっているかを確かめ、判断するのは、人の役目です。

自由が増えるぶん、引き受けるものも増える

Section titled “自由が増えるぶん、引き受けるものも増える”

社内の業務は、これまでも、Excelや既製のサービス、パッケージソフト、kintoneのようなノーコードのツール、以前からある社内システム、あるいは人手で回してきました。SaaSのように、提供者が基盤や運用の多くまで含めて提供するサービスを使う場合にも、自社の業務に合うか、どのデータを使うか、誰にどの権限を与えるか、どんな運用ルールにするかは、利用者の側で考えます。一方で、ログインや認証、セキュリティ対策、動かす環境やバックアップ、障害対応や更新を含む安定した運用は、提供者の側があらかじめ設計し、作り、運用しています。利用者が意識しなくても、システムを安全に安定して動かすための多くの部分を提供者が担っていて、利用料にはそれが込みになっています。

自分たちで作ると、提供者が引き受けていたこの部分の一部まで、自分たちで考え、管理することになります。作るハードルが下がった代わりに、それまで利用料に含まれていた責任の一部を、自分たちで引き受けるということです。自由度が増えるぶん、責任の範囲も広がります。そのときに何を考え、何を確かめておく必要があるのかが、実務編で見ていくことです。

技術をすべて分かる必要はない

Section titled “技術をすべて分かる必要はない”

社内システムを自分たちで作るといっても、技術的なことを全部自分でできる必要はありません。多くの部分はAIに任せられます。ただし、ログインや認証の仕組みのように、難しく、間違えたときの影響が大きく、自分たちだけで判断するにはリスクの高い領域もあります。そこを自分たちで扱うのか、詳しい人に確認してもらうのか、専門家に任せるのか。実務編が目指すのは、経営者自身が、何が重要で、どこが難しく、どこにリスクがあるのかを分かったうえで、自社で決めることを決め、作る人・AI・詳しい人に確認することを見分けられる状態です。技術の詳細まで理解しなくても、判断に必要なポイントは押さえられるようにします。

実務編を読むと、AIに社内システムを作らせる前に何を決めておくか、動くものが出てきたときに何を確かめるか、使い始めてから何を備えておくかがつかめます。AIへの頼み方やツールの操作は出てきません。その手前にある、システム開発と運用としての判断だけを、ITを専門としない人に向けて見ていきます。

基本編では、生成AIとは何か、どう頼めばよいか、自社の仕事にどう当てはめるかという、AIを使ううえでの基本的な考え方を扱っています。実務編は、その先で、実際に社内の仕組みを作ることを考え始めた人に向けた内容です。先に基本編を読んでいなくても読み進められます。AIそのものの性質を確かめたくなったら「AIの正体を知る」へ、業務を仕組みにする前の分解と振り分けは「自社の仕事に当てはめる」へ戻ってください。

対象とするのは、社内で使う仕組み

Section titled “対象とするのは、社内で使う仕組み”

社員が社内の業務で使う仕組みなら、勤怠管理や備品の予約のような、どの会社にもある業務に限りません。案件ごとに売上・材料費・作業時間を集計して、案件単位の採算を把握する仕組みのように、会社ごとに業務や計算のしかたが違い、既製のサービスではぴったり合わないものも含みます。こうした仕組みは、これまでは、Excelで複雑に管理する、既製の仕組みに業務のほうを合わせる、個別にシステム開発を依頼する、といった選択肢になりがちでした。そこに、生成AIを使って自社に合った仕組みを内製する、という新しい選択肢が加わっています。自社独自の仕事のやり方に合わせた仕組みを作りやすくなったことは、生成AIで内製することの大きな価値の一つです。

一方、顧客や取引先、不特定多数の人が使うWebサービスは、ここでは扱いません。外に公開すると、セキュリティや認証、攻撃への対策、安定して動かし続けるための運用、利用者への対応など、さらに考えることが増え、ここで扱う範囲を超えるためです。

では、社内で使う仕組みを作るとき、具体的に何を考えればよいのでしょうか。実務編では、一つの業務を社内システムにするときに考えたいことを、時間の流れに沿って3つの段階に分け、6つの問いで見ていきます。

  1. そもそも自分たちで作るべきか(作る意味があるかを決める)
  2. 業務は整っているか(何を仕組みにするかを決める)
  3. そのデータは何で、どれを正とするか(何を正しいデータとして扱うかを決める)
  4. 誰に何を見せ、何をさせてよいか(誰に何を許すかを決める)
  1. 作ったものは、業務に乗せられるか(会社の業務として使える状態かを確認する)
  1. 直しながら、使い続けられるか(変えたり壊れたりしても、使い続けられるようにする)

6つの問いは、作り始める前に全部を満たしておくチェックリストではありません。作る前の4つも、最初から完全に設計しきるということではなく、後から変えにくいことを先に決めておく、という程度で足ります。小さく作って動かしてみて、5と6を考えながら育てていく。その途中で、決めていなかったことに気づいたら、前の問いに戻って決め直せばよいのです。

各記事では、共通の例として勤怠管理を取り上げています。自社の業務を一つ思い浮かべながら読むと、問いへの答えが具体的になります。すでに作り始めている場合は、気になる問いから読んでも構いません。