投稿者: 沼田 勇作

  • (8月1日通信)社員の仕事を把握できないのは、報告不足ではない

    特集【会社の見える化】— 社長視点

    社員に聞かなければ、会社の現在が分からない。その状態を「社員からの報告が足りない」と考える経営者は少なくありません。しかし、報告の回数を増やすだけでは、会社はかえって見えにくくなることがあります。

    本当に見直すべきなのは社員の姿勢ではなく、日々の仕事から生まれた事実が、経営判断まで届く仕組みです。

    報告は「現在」ではなく、切り取られた説明である

    たとえば、ある受注について社長が「もう納品できるのか」と尋ねたとします。営業は受注済みだと答え、担当者は作業中だと答え、経理は入金条件を確認中だと答えるかもしれません。どの答えも間違いではありませんが、見ている時点と範囲が違います。

    さらに、社員は質問を受けてからメール、表計算、チャット、紙の伝票を調べ、事情をまとめて説明します。社長の手元に届くのは、現在の業務そのものではなく、誰かが後から編集した「現在についての説明」です。その間にも仕事は進みます。

    週報を日報に変えても、この構造は変わりません。報告を詳しくするほど、書く側と読む側の負担が増え、肝心の仕事とは別に「報告を作る仕事」が大きくなります。

    仕事をした記録が、そのまま経営情報になる

    必要なのは、報告のための再入力ではありません。受注を登録した、見積もりを承認した、部材を手配した、作業を完了した、請求書を発行した。このような業務上の出来事を、それが起きた場所で一度だけ記録することです。

    一つの事実を一度記録し、現場には「今日処理する案件」、管理者には「期限を過ぎた案件」、社長には「売上見込みと障害」というように、役割に応じた見せ方をします。画面は違っても、見ている原本は同じです。

    このとき大切なのは、数字をきれいなグラフにすることではありません。社長が知りたいのは、売上の総額だけでなく、どこで止まり、誰の判断が必要で、放置すると何が起きるかです。見える化とは、事実を眺められる状態ではなく、次の判断を選べる状態です。

    「進行中」という言葉を会社で定義する

    仕組みを作っても、「対応中」「確認中」「ほぼ完了」といった言葉の意味が人によって違えば、現在は見えません。状態には、誰が見ても同じ判定ができる条件が必要です。

    • 受注済みとは、顧客の発注意思と金額が確定した状態
    • 着手可能とは、必要資料と担当者と期限がそろった状態
    • 完了とは、成果物を渡しただけでなく検収条件を満たした状態
    • 要判断とは、決める人、期限、選択肢が明らかになった状態

    こうした定義は、システム会社に決めてもらうものではありません。自社が何をもって仕事の節目とするかは、経営そのものです。代表者が大本の構造を理解していれば、どこを社員に任せ、どこに専門家を加えるべきかも判断できます。

    最初に、社長が繰り返している質問を三つ集める

    大がかりなシステム導入から始める必要はありません。まず一週間、社長が社員に尋ねた質問を記録してみてください。「今月いくら売れそうか」「あの案件はなぜ止まっているか」「今日、私が決めることは何か」といった質問です。

    次に、それぞれについて、答えの根拠となる事実はどこで生まれるか、誰がいつ記録できるか、何分前までの情報なら判断に使えるかを整理します。三つの質問に同じ原本から答えられる小さな仕組みを作れば、見える化の価値を具体的に確かめられます。

    社員に聞くこと自体が悪いのではありません。対話は、新しい考えを生み、例外を理解するために使うべきです。会社の現在を毎回聞き出すために使っているなら、仕組みが肩代わりできる仕事が残っています。

    報告不足ではなく、情報の通り道の問題

    社員が誠実に働いていても、仕事の事実が別々の場所に閉じ込められていれば、社長には見えません。反対に、業務の記録と経営の画面がつながっていれば、社員は報告書を作る時間を減らし、社長は例外と判断に集中できます。

    「もっと報告してほしい」と伝える前に、報告し直さなくても分かる構造になっているかを確認する。それが、会社の見える化の出発点です。

  • (7月30日通信)ノーコードを学ぶのが危険なのではない。「ノーコードだけ」を仕事にするのが危険なのだ

    「今からノーコードを学ぶのは危険です」という動画を見ました。

    動画で挙げられていたのは、ノーコードだけを身につけて仕事にしようとする場合の、三つの問題です。

    一つ目は、誰でも扱いやすいため、作業単価が上がりにくいこと。
    二つ目は、参入しやすいうえにAIの支援まで加わり、競争相手が増え続けること。
    三つ目は、簡単なWebサイトなど、初心者が受けていた案件そのものを、発注者がAIで処理できるようになってきたことです。

    この見方には、私もおおむね賛成です。

    ただし、危険なのはノーコードそのものではありません。ノーコードツールの操作方法を覚えることと、価値のあるシステムを作れることを、同じだと考えてしまうことが危険なのです。

    「誰でも使える」は、ツールとしては長所、職業としては弱点になる

    ノーコードツールの最大の長所は、専門の技術者でなくても扱えることです。

    ところが、その操作自体を商品にしようとすると、この長所がそのまま弱点になります。依頼者自身でもできる作業であれば、当然ながら高い報酬はつきにくくなります。AIによって操作や制作がさらに簡単になれば、価格競争は一層激しくなるでしょう。

    これはノーコードに限った話ではありません。

    テンプレートに文字と画像を入れるだけのWeb制作、指示どおりに生成AIへ入力するだけの文章作成、決められた項目を表計算ソフトへ転記するだけの作業も、同じ方向へ進みます。

    「そのツールを使える」だけでは、専門性を維持しにくい時代になりました。

    それでもノーコードはなくならない

    では、ノーコードは不要になるのでしょうか。

    私は、むしろ利用範囲は広がると考えています。

    CMSの管理画面や表計算ソフト、業務アプリの設定画面も、広い意味では複雑な処理を画面操作で扱えるようにした仕組みです。ノーコードとは、コードが消えた状態ではありません。誰かが書いたコードを、利用者が意識せずに使えるようにした状態です。

    この仕組みは、業務の試作に非常に向いています。

    まず画面を作り、実際の担当者に触ってもらう。業務報告を入力してもらい、不足している項目や承認の流れを確認する。関係者から「あの項目も必要」「この順番では使いにくい」といった意見を集める。

    言葉だけで要件を決めるより、動くものを見ながら仕様を発見する方が早い場面は多くあります。その段階で、CMSや表計算サービスを使うことには大きな意味があります。

    つまり、ノーコードは「完成したシステムを作る魔法」ではなく、「業務を見える形にして、必要なシステムを発見する道具」として使えばよいのです。

    AI時代に価値が上がるのは、作業ではなく判断である

    生成AIは、HTMLやCSSだけでなく、プログラムのコードも書けるようになりました。

    その結果、コードを一文字ずつ入力する速さの価値は下がっています。一方で、AIが出したものを読み、目的に照らして正しいかを判断する価値は上がっています。

    Webサイトであれば、スマートフォンで崩れないか、表示が遅くないか、入力チェックが機能しているかを判断する必要があります。

    業務システムであれば、さらに重要な判断が加わります。

    • 誰が、どの情報を見られるのか
    • 誰が、どの処理を実行できるのか
    • データをどの単位で管理するのか
    • 変更前の状態を後から確認できるのか
    • 複数の更新を一つの取引として矛盾なく処理できるのか
    • エラーが起きたときに、どこまで元へ戻せるのか

    画面が動くことと、会社の業務を任せられることは別問題です。

    生成AIにコードを書かせることはできます。しかし、会社の資産や責任の境界までAIへ丸投げすることはできません。何を正しい状態とするのかは、会社側が設計しなければならないからです。

    試作はノーコード、本番の責任は設計とコードで持つ

    私は、ノーコードとコードを対立させる必要はないと考えています。

    たとえば、受付、業務報告、アンケート、簡単な進捗確認であれば、CMSで入力画面を作り、表計算サービスへ情報を蓄積するところから始めてもよいでしょう。まず使ってもらい、現実の業務に合う形へ直していけばよいのです。

    しかし、その情報を請求、会計、在庫、給与、権限管理などへ結びつける段階では、試作品の延長で作ってはいけません。

    会社の資産を変化させる処理では、データの構造、権限、承認、取引の一貫性、変更履歴を整理し、必要に応じて様々なオープン・ソース・ソフトウェア(公開されているソフトウェア)などを使って、人間が把握できるコードとして実装する必要があります。

    ノーコードで画面を作りながら仕様を見つける。
    コードで業務上の責任と整合性を保証する。

    この二段階を分けることが、AI時代の現実的な内製化だと思います。

    学ぶべきなのは、ツール名ではなく「境界線」である

    今からノーコードを学ぶこと自体が危険なのではありません。

    危険なのは、特定のツールの操作方法だけを覚え、そのツールで対応できない問題まで解決できると思い込むことです。

    学ぶ際には、少なくとも次の点を意識する必要があります。

    • そのツールで安全に扱える業務はどこまでか
    • どの段階からデータベースや権限設計が必要になるか
    • AIが生成した結果を自分で検証できるか
    • 将来ツールを変更するとき、データを取り出せるか
    • 自社の業務と会社資産の構造を説明できるか

    ノーコードの操作だけを売る人の仕事は、AIによって減るかもしれません。

    しかし、現場の業務を理解し、ノーコードで素早く試作し、必要な部分を設計とコードへ移せる人の仕事は、むしろ増えるはずです。

    AIとノーコードが省いてくれるのは、制作にかかる手間です。設計者の責任まで省いてくれるわけではありません。

    これから学ぶべきなのは、特定のノーコードツールではなく、ノーコードをどこまで使い、どこから先をコードで管理するのかという「境界線」なのです。