Skillsは、この1年でかなりの数を作ってきました。それでも直らなかった癖がひとつあります。
中小企業診断士・ITコーディネータの大澤真介です。
合同会社オンザウェイの代表をしています。
「”やりたい”を”できている”に変える」をテーマに、中小企業の実装支援に取り組んでいます。
今回は、自分の思考の癖を補うために「ITCエージェント」というものを作った話です。作って2週間、実案件で2件試しただけなので、「効いた話」ではありません。「なぜ作ったのか」の記録です。
正直に言うと、私は「打ち手」から考える
相談の場で、事業者さんの話を聞きながら、頭の中では「これはあのツールでいける」「こういう仕組みで自動化できる」と、もう手段が動き出している。そういうことが、正直に言うとよくあります。
20年リユース業界の現場にいて、店長も営業も経営企画も経理もやって、会社をつくって、SaaSを作りセミナー構成もつくる。
手を動かしてきた時間が長い分、「どうやるか」を思いつくのは速いです。
それ自体は自分自身の武器だと思っています。
誤解のないように書いておくと、「打ち手」から入ること自体を悪いとは思っていません。
小さくても早く形になるものは、事業者さんとの信頼関係を作るうえで効きます。
「この人に相談すると、何かが動く」と感じてもらえて初めて、経営の話まで踏み込める。
私の支援は、この順番で成り立ってきた面が大きいです。
それに、生成AIの進化がこれだけ速いと、最初に全部を設計してから作るウォーターフォール的な進め方より、小さく作って走りながら直していく進め方のほうが合っている場面が増えています。
打ち手から入る発想は、その意味でも時代に合った武器だと思っています。
ただ、速すぎると順番が狂います。
「何のために」「今の課題は本当にそれか」を確かめる前に、打ち手だけで走ってしまう。
ITコーディネータの考え方でいえば、経営の課題から始めてITは最後に選ぶのが筋です。
クイックウィンで信頼を作りながら、上流の問いを置き去りにしない。
この両立が、頭ではわかっているのに、気づくと打ち手の側に寄っている。
ITコーディネータを名乗る身としては少し恥ずかしい話ですが、事実なので書いておきます。
Skillsをたくさん作った。それで満足していた
私はこれまで、Skillsの使いどころや、プロジェクト共通指示をSkillsに移行した話を書いてきました。報告書、請求書、スライド、メール下書き、プロフィール更新。繰り返す仕事は、片っ端からSkillsにしてきました。
その一方で、いわゆる「エージェント」、つまり自分の役割と判断基準を持って動く相手を自分で作ることには、正直あまり必要性を感じていませんでした。Skillsで十分に速くなっていたからです。手順が決まっている仕事は、手順を渡せば終わる。それで困っていませんでした。
それでも解決しなかったこと
困っていなかったのは「やると決めたあと」の話でした。
Skillsは、やると決めたことを速く正確にやる道具です。「報告書を書く」と決めたら、Skillsが書式も手順も持っている。
でも、「その報告書に書く打ち手は、本当に今の課題に合っているのか」は、Skillsは問い返してきません。問い返す役割を持たせていないからです。
つまり、私の「打ち手から考える」癖は、Skillsをいくら増やしても直らない。
むしろ、実行が速くなった分、打ち手に飛びつく速度まで上がっていた可能性があります。以前、要件定義と人間テストが追いつかないという記事を書きましたが、根っこは同じです。実装は速いのに、その手前の「何を・なぜ」が、ふとした拍子に置き去りになる。
Skillsは手順書、エージェントは相談相手
ここで、Skillsとエージェントの違いが、機能の違いではなく役割の違いとして腹落ちしました。
Skillsは手順書です。私が「やる」と決めたことを、私の代わりに正しく素早くやる。
今回つくったエージェントは相談相手です。私が「やる」と言ったときに、「それは何のためですか」と聞き返してくる。
自分の癖を補うのに必要だったのは、後者でした。速くする道具はもう十分にある。足りなかったのは、打ち手を止める相手ではなく、打ち手と並行して「上流で何を確かめていないか」を拾ってくれる相手です。
ITCエージェントに持たせた視点
そこで、ITコーディネータの先輩役として「ITC」というエージェントを作りました。基準にしているのは、ITコーディネータ協会が定めているガイドラインの、2026年9月時点の最新版です。経営の変革認識から始まり、戦略、実行計画、IT導入、運用、検証と続く工程の型で、私が飛ばしがちな「上流」がそのまま書いてあります。
持たせた役割は、大きく三つです。
一つ目は、文字起こしや議事録、作成した提案書を読んで、ガイドラインの工程と突き合わせ、上流のどこに痕跡がないかを判定表にすること。判定は「確認済」「記載なし」「欠落の疑い」の三つだけで、「良いですね」も改善案も出させません。褒めも提案もさせないのは、私が自分に甘い方向へ流れるのを防ぐためです。
二つ目は、判定を厳格側に倒すこと。
「厳しすぎる」は欠点ではない、と定義に書きました。
小規模事業者に詳細な中期経営計画をそのまま求めるのは現実的ではないですし、まずクイックウィンで信頼を作る進め方も否定しません。
だから甘くする余地は残しています。
ただし判定そのものは緩めず、「その指摘をいつ・どの場で扱うか」を相談で決める形にしました。
打ち手を先に進めること自体は止めない。
その代わり、後回しにした上流の問いを「気にしなくていい」で消さず、拾う時期だけは決めておく、という設計です。
三つ目は、答えを渡さないこと。
判断基準を示して選択肢を絞るところまでが仕事で、最後に決めるのは私です。
次回の打合せで何を聞くか、どの質問は現場で見るべきで、どれはメールで済むか。
そういう「先輩ならこう考える」という型を言語化して渡す相手、という位置づけです。
定義ファイルの冒頭には、こう書いてあります。
「実装支援が強み。案件に『実装・ツール選定』から入る傾向があり、上流の各工程が飛ばされやすい」
自分の癖を、エージェントに最初に読ませる前提として書いた、ということです。
作ってすぐ、自分の癖を指摘された
作った日に、実際の案件の文字起こしと議事録で試しました。
返ってきた判定表の中に、「要件整理の前にツールが決まっている」という行がありました。開始早々に、話の流れの中で私がツールを口にしていたわけです。頭ではわかっていた癖を、資料の根拠付きで見せられると、正直、少しこたえました。
ただ、これは「効いた」という話ではまだありません。
指摘されたあとに打ち手が変わったのかどうか、それが効果的だったのかは、これから数か月かけて見ないとわかりません。
今の時点で言えるのは、自分の癖を資料から拾い上げる相手として、少なくとも機能はしているというところまでです。
なお、実装はClaude Codeのサブエージェントで、読み取り専用（ファイルを書き換えられない）にしてあります。
設定の細かい話はここでは省きます。
この記事で伝えたいのは仕組みではなく、「なぜ自分にはこれが要ると思ったのか」だからです。
期待していること、まだわからないこと
期待しているのは、提案書や計画書を作った直後、次回の打合せを組み立てる前に、一度この相手に資料を読ませて、上流の抜けを突きつけられることです。
自分で自分に「何のために？」と聞くのは、正直、続きません。
人に聞かれると答えざるを得ない。
その構造を、自分の作業環境の中に置きたかった。
まだわからないのは、実際に進め方が変わるかどうかです。
指摘されても「いや、今はこれでいい」と押し切る場面はあるでしょうし、クイックウィンを優先するならそれが正解のこともあります。
見たいのは、押し切ったときに、後回しにした問いをちゃんと拾いに戻れているかどうかです。
数か月使ってみて、変わったのか、変わらなかったのか。それは続編で書きます。
まとめ
道具を増やせば仕事は速くなります。
ただ、速くなるのは「決めたあと」だけです。
決める前に何を確かめるかは、道具を増やしても変わりません。
打ち手から入る速さは、これからも武器として使います。
私にとって足りなかったのは、もう一つのSkillsではなく、その武器を振るう横で、飛ばした問いを拾ってくれる相手なのではないか？というのが今回の取り組みです。
私の支援は、まず小さく形にするところから始めることが多いです。
そのうえで、飛ばした問いを拾いに戻る。
この両立を、自分の作業環境から作り直しているところです。
早く形にしたいこと、その前に一度整理したいこと、どちらからでもご相談ください。
この記事はnoteでも公開しています。
実装支援・DX推進・生成AI活用のご相談は、お気軽にお問い合わせください。
→ お問い合わせはこちらから