1. デブログ.fm - AIで生産性を上げるエンジニアログ
  2. なぜ作れるようになっても組織..
なぜ作れるようになっても組織の悩みは消えないのか?
2026-11-06 24:54

なぜ作れるようになっても組織の悩みは消えないのか?

おたよりを送る

デブログfmは、現役エンジニアのinadyが、日々の業務で試したAI活用術や最新ツール、効率化のノウハウをシェアします。https://podcast.devlog.fm

番組の感想やリクエストは #デブログfm まで。番組のフォロー、星★(レビュー)いただけると嬉しいです!

▼参考資料▼
なし

▼取り上げた話題▼
前回のエピソード025では、AIに仕事を渡すと楽になる一方で、自分で悩んで考える楽しさがなくなっていくという話をしました。今回はその問いを組織まで広げ、誰でも作れるようになった今も作ることが悩みではなくなり、その差について業務をSkillsに落とせるかとまずAIに聞けるかと作ったものの責任だと話しています。予算の確認や進捗の催促のようなデスクワークにはコードベースというリファレンスがないため、Grok BotやMuse、Dotsで任せるにはSkillsが必要だと話しています。Skillsを書けない人が多いのは判断の理由や目的を言語化できないからで、解像度の高いSkillsが一度できれば生産性は上がりますが、品質が低いと使われません。AI導入支援ではClaude Codeに聞いた人と要望だけの人がいて、原因は現状維持バイアスと間違える不安で、1to1で数時間のハンズオンが成功パターンだと話しています。顧客へ出すアプリや提案資料は会社の責任で、GMOやIDCフロンティアの攻撃に触れ、数年前に対策を優先していればGMOの件は防げたかもしれず、権限と責任の委譲が組織のスピードを上げると話しています。

▼チャプター▼
作ることは悩みではない
日常業務のスキルズ
言語化できない壁
AIに聞けるかの差
聞かないと聞けない
ハンズオンの成功体験
作ったものの責任
判断とリーダーシップ
クロージング

感想

まだ感想はありません。最初の1件を書きましょう!

00:00
今日のポッドキャストではAI時代に
おける組織の差というのは作れることではなくて業務を
スキルにいかに落とせるか
まずAIに聞けるか作ったものの責任は誰が
持つかで決まる
決まってきたなという話をしてみたいと思っています
前回のポッドキャスト025ではAIに仕事を渡すと
仕事は楽になるんだけれども自分で悩んで考える
楽しさがなくなっていくなという話をしたんですが
今日はこの個人の私の問いを組織まで広げていろいろ
前回のポッドキャストから1ヶ月くらい経ったので
いろいろ悩んで考えてやってきたことについて
言語化して話していきたいというふうに思っております
結論から言うとですね誰でも作れるようになったAIに
よって誰でも物を作れるようになったので
もはや作ることは
悩みではなくなったなというふうに思っていて
じゃあその次の悩みは何かそれをどうやって
解決するかという話をしていきたいというふうに
思っておりますは
まず最初に最初のトピックですけれどもスキルズに
ついてちょっと話をしていきたいと思います
私の中でもスキルズっていうのは
そのスキルズという概念が出てきてから
かなり使っていて
また最近しばらく使っていなかったんですけど
最近また一生懸命作るようになりました
この背景についてから
まず話していきたいと思うんですけれどもまずなんで
一生懸命作っていたかというと以前のAIって
そんなに賢くなかったですよねっていうのがあるので
スキルにああしてこうしてって
書いておかないと思ったように動いてくれなかったので
一生懸命書いていたんですけれども
最近の
AIモデル自体の性能がすごく良くなったので
特に書いていなくてもこのコードベースをが
いっぱいあるので
そのコードベース読んだ上であ多分こういう風に今まで
コードベース書いてるのでえユーザーからの依頼は
こういう風にやったらいいんだろうなってことを
自立的に判断してやってくるようになりましたとで
むしろスキルズをちゃんとメンテナンスしてないと
スキルに書いていることとユーザーが言ってる事と
コードベースが違うみたいなことが起きて
むしろ生産性が下がるみたいなことが起きて
来たりするのでスキルズっていうのは最小限にしていて
ちょっとメンテナンスとかも最近はあんまりやってい
なかったっていうところではありますが
また最近力入れてやってきているんですねこれは
どういう領域で使っているかというと
コーディングというよりかは
日々の日常の仕事業務エンジニアリングじゃない仕事の
スキルの改善ってのは結構やっています例えば
予算を守れているかどうかその毎日コストをチェックし
ましょうとか
あとは毎日タスクそのプロジェクトいくつか
やってるのそのプロジェクトの進捗がどう
なっているのか誰に催促しないといけないのかこれは
AIで作業できるのかみたいなところの
ルーティンワークみたいなところ自分が
日々やりたいことをスキルにするみたいなことで
この日常業務をスキルにしています
これなんなんでこういうことを
積極的にやろうやるようになったかというと
まさにGrokbotの登場ですね
03:00
このポッドキャストでもね何回かに分けて
Grokbotがいかに
ブレイキングチェンジなのかっていう話はしてきたと
思うんですけれども
Grokbotのやっぱり凄さっていうのは
日々の業務エンジニアリングじゃない業務で
凄い使えるからっていうところでしたよねと
Grokbot以外にも最近は日本でMuse
Facebookが
提供してるMuseとかあとはdotsですね
あとはAnthropicからも同じようなツールが
出るんじゃないかなっていう話が出て噂が
出てきておりまして日本でももうまもなく
使えるんじゃないかなと思うんですけれども
そういう感じで
いわゆるAI
なんですかね
チャットツールAIボット君みたいなやつが最近増えて
来ていますけれどもそれによって普段のいわゆる
ホワイトワーカー的な仕事デスクワークの仕事が
かなりAIで作業を依頼しやすくなったように
なったなというふうに感じております
この日常業務においてスキルズがなんで大事かというと
これは大抵はコーディングだと思うんですけれども
コーディングにはリファレンスがありますよねとで
リファレンスと言ってるのは今既にあるコード
ベースっていうのがリファレンスですとで
今までこういう風な実装があるから
この実装に追加するんだって
こういう実装だよねってのは
なんとなくわかりますとなのでスキルとかなくても
いい感じに綺麗にやってくるんでくれるんですけれども
デスクワークにおいては
こういうリファレンスがないわけですよね自分の頭にの
中にしかなくてそれを
毎日一生懸命やっていたっていうところなので
AIが知ってるリファレンスがないという状態なので
スキルズが大事
つまり手順書っていうのがとても大事になっていきます
それでこのスキルズさえちゃんと整備して自分が何を
やってるのか何をやりたいのかどういう
判断をしているのかっていう言語化さえすれば
日々の業務ほとんどの割合私の体感ですけど
AIがやってくるようになったのでこの日常業務に
おけるスキルズを
いかに明確にクリアに書くかっていうところが
とても大事な時代になってきたなというふうに
思っているんですが
それでここでの問いはですねスキルズを上手に
書けない人って
意外と多いなっていう発見があったということです
それはつまるところ自分がやってる業務プロセスを
なんか言語ができないっていうところに
あったんですね
皆さんの仕事もそうだと思うんですけど何かその1から
10まで手順があってもう機械的に
もう言われた通りやればいいってものではない仕事のが
大半だと思っていて途中に
意識ってその機械的に判断できないけど
こういう時はこうだよねみたいななんですかね
ニュアンスをつかんで
判断するっていう仕事いっぱいあると思います
この
ニュアンスっていうところの言語化が
できないという話ですねなんで
その判断をしているのかとかそもそもその仕事で
何解決したいんでしたっけとかそういうところが
06:00
見えていないと
いけないという話ですね
自分一人でやってる仕事であればそれで
いいんですよそのニュアンスでやってるそれが今まで
回っていたのででもでもそれを
AIにやらせようとそれをスキルにしようとしたときに
いい感じにやってっていうわけには
いかないんですよねえそれはなんでどういう背景が
あってどういう時にどういう判断をしないと
いけないのかっていうのは必ず言語化しないと
もちろんAIも仕事することができないのでそれを
言語化しないといけないんですけれどもそれが
苦手な人が多いという話ですね
一方で私もそうですねエンジニア
プログラムをずっと書いて来ているので
こういう判断っていうのを言語化する頭の中で
言語化するというのは結構得意だと思っています
頭の中で条件分岐書いたりとかしてこういうロジックの
時はこうだよねみたいなことをま瞬時に
理解できるように鍛えてられていると思うんですが
エンジニア以外の方だとそもそもそこと
やってきていないそういう職種じゃないので
やってきていないので
なんとなくやってます以上の言語化のテクニックが
ああまだ身についていないというかまだ
上達していないというところが大きいんじゃないかなと
見ていて思ったところです
じゃあですね
じゃあエンジニアにスキル書かせたらいいじゃんと
すべての業務っていうパターンもあると思うんですけど
それもそれで難しいんですよね何でかというと
そのエンジニアはそのある人が
やっている業務の解像度がほとんどないからですよね
やっぱりこのスキルを作るときにはその仕事をやってる
人が一番解像度高くプロンプト書けるはずなので
やっぱりその人がスキルを書けるようにならないと
いけないと思っています
そしてそのスキルを一度でも作ってしまえば性能の高い
AIに理解しやすいスキルズを一回作ってしまえば
その人本人の生産性もすごい上がりますし周りの人も
すごい助かるわけですよねそのスキルを使って
同じ業務をしている人がもし複数いたとしたら
それを展開すればいいわけですから
周りの人もすごい助かるとただただし
品質の低いスキルだと
そもそも本人も使いづらいし周りの人なんか
使うはずもないですよねというところがあるので
いかに自分の仕事を言語化して階層を高く
スキルにしてプロンプトにして上げるっていうことを
鍛える日々鍛えていくってことが
大事だなっていうふうに思ったという話ですはでは
ちょっと次の話に行きたいと思うのでさっきの
スキルの書き方みたいなところのヒントにもなると
思うので次の話繋げて聞いていただければと
思うんですけれども
私は最近
業務におけるAIの導入支援っていうのを組織で
やっていますとある部署に何個かの部署に
アサインされていてその人のその部署が
どういう仕事やってるかをリストアップして対話し
ながらじゃあこれAIで効率化できるのねっていうか
これAI使えばもっとそのいいものが
作れるね作れるよねみたいなことを対話しながら
09:00
やっているんですけれども
それをやっている中で
AIをとってもよく使いこなしている人と
まだまだ使いこなしに課題が
あるなっていう人がいるといるんですけれども
すごく明確な差があります
これの差は何かというと
まずAIに聞けるかどうかっていうことなんですよね
まだまだ使いこなしがこなれてない人と話を
するとじゃあ
こういうことやりたいですという資料はいっぱい持って
来てくれるんですよねABCDEって
こういうことやりたいこういうことやりたいって
いっぱい持って来るんですけれども
じゃあこのAからEの間の中で
AIに聞いたやつありますかとこれどうやってやれば
いいですかって聞いたやつありますかっていうと
どれも聞いてないんですよね
じゃあ一方ですごい使いこなしてる人はどうかというと
じゃあ同じにABCDってのがあって
私に来るときにはもうABCD全部
Claude Codeに聞いて
作業進めてるんですよね
ABCDはもう自動化できちゃいましたと依頼に聞いて
対話しながらやりました
ただこのEについてはなんかこれアプリ作った方が
いいって言われたんですけどちょっとわかんなくて
ちょっと一緒に考えてもらえませんかみたいなこと
言ってくるんですよね
この差って何かっていうと
ただAIに聞いたかどうかの差だと思うんですが
なぜ聞かないのかっていうところが
ちょっと私の中でも疑問点だったんですけれども
いよいよいろいろ観察してヒアリングしている中で
分かったことが二つありまして
それでAIを使いこなすのが
まだ上手ではない人二つ原因があると思っていて
一つ目が聞かないこと二つ目が聞けないことですね
一つ目聞かないというのは今の仕事を例えばAIとかを
使って効率化したいもっと改善したいっていう
モチベーションがないっていう話です
これはちょっとモチベーションがないっていうのは
ちょっとネガティブな感じですけども要は
現状維持バイアスですね
今のやり方でいいというふうに思っていると
誰しもあると思いますその
こうしたら
いいのになっていうのは周りの人すごい思ってるけど
いやいいんだとこれでっていうのはあると思ってます
私もいっぱいあると思います
それが一つ目ですよね
これは
周りの人が
ちょっと声をかけてあげるっていうのが一ついいかなと
思っていてえそれってなんでこういうふうな手順で
やってるんですかとかそれってもしかして
めんどくさかったりしませんかとか一言言って
あげるだけであ確かにこれめんどくさいっすって
なるのでちょっと周りから声をかけて
あげるっていうところが解決策かなと思っています
もう一個が
聞けないっていうところですよね
これは
いろいろヒアリングすると
やはり不安が先行しているですよね
間違えるのではないかとかこれをやっていいのでは
12:01
いいんだっけみたいな不安が
先行してしまうっていうところがあると思っています
このAI
ツールが
発展したばかりの
もうちょっと一年とかちょっと前ぐらいであれば
すごい不安だってことも私も納得しますし
確かにやばいことを結構やり
がちでしたとただ今のAIツールって
非常に賢いモデル自身がすごい賢いので
いやそんなにやばいこと
そもそもやらないので結構その不安っていうのは
杞憂というかそそれは
半年前とか一年前の不安ですよねみたいなところが
結構あるのでこの不安っていうのを
取り除いてあげる必要があるかなと思っています
これを成し遂げるには
成功体験を積むってことが一番大事だなと思っていて
一度ハンズオンして
一緒に問題を解決するとその後もあれもこれもと
自立的にやれる
人が非常に多いです非常に多いというか多分私が
対話した人は全員そういう状況になります
聞かない聞けないっていう状態から
一度じゃこれClaude Codeに聞いて
やってみましょうかってやってみると
もうその後はもうあれもこれもなん何でも自分で
自立的に改善をしてで本当に
困った時だけ聞いてくるみたいな
相談してくれるみたいな状態になるので
これは非常に大きいのかなというふうに
思っておりますなのでやはり
一緒にやってみるってことが大事
全体研修みたいなものでこうばって教えるのも
あれいってるいってると大事だと思うんですけれども
それ以降はもうワンツーワンで一緒にやって
ええどういう仕事をやってるんですかどういう業務
やってるんですかその業務なんでやってるんですか
それでどういう価値をお客さんに
提供してるんですかとかちょっと対話しながら
やってみたりとかじゃあそれちょっと自動化してみ
ましょうかということでちょっと一旦私の前で
今やってる仕事をAIにやるやら
やらない前提で自分がやってるときにどうやって
やってるんですかってやってもらってる中で
なんかこう操作しますよねポチっと
押したとえちょっと今ちょっと待ってくださいと
今なんでそこクリックしたんですかこの
ボタン三つありましたよねこう一二三とボタンでなんで
この一番目クリックしたんですかって
聞くとあこうこうこういう理由でって
言ってあなるほどそういう理由が
あったんですね次のページ行ってで
何かまた操作しますよねえちょっと待ってくださいって
今の操作ってな何したんですかみたいなことを聞くと
僕がくっつこうとその人の仕事の解像度が上がる
あ確かになんかよくわからずやってましたけど
言語化するとこういう理由ですねみたいなことが
出てきますと
それを持ってじゃあ今言語ができたので
それスキルにしてみましょうかとかじゃあこれスキルに
15:01
できたのでこれをスケジュールにしてみましょうかとか
じゃこれもうアプリにしちゃいましょうかとかあまあ
コードにしても全自動にしてしてしまったら
どうですかみたいなこう対話を
する一度対話をして成功体験が
もたらされるとあとはもう勝手にどんどんやって
やってくれるようになるなっていうのが
学びでした
つまるところそのAIを
使いこなせるかどうかっていうのはAIに
聞けるかどうかっていうところなんですが聞けるように
なるためには
一旦
ワンツーワンで数時間一緒に作業をやってみて
背中押してあげるというか助走をつけてあげることが
一番の成功パターンだなというふうに思っておりますは
最後のトピックに行きたいんですがこのように
スキルズとかを整備しますとかAIと対話しながら
いろんな人が
ツールを作ったり自動化したりバイブコーディングで
アプリを作ったりすることによっていろんなものが
できてきますよねと
そうなってじゃあそのアプリお客様に
提供しようとかいうのも当然加速してきます
こうするときに何が起こるかというと
作った者の責任って誰が持つんですかっていう話が
とっても重要になってきますよね
昨今その例えばGMOの件で
あるとかIDC Frontierのサイバー攻撃の
問題もありますけれども
いろんなサービスを世の中に提供すると
そのセキュリティを担保するっていうのが
とっても重要になってきます
あとは
セキュリティ攻撃がなかったとしても
いやこんなクソみたいなアプリを
俺に提供するのかみたいな
ブランドの毀損みたいなところもあるかなと思っていて
これは結構気をつけないといけないところだなと
思っていますこれはアプリだけじゃなくて
例えばお客様への提案資料とかもそうですよね
法人のチームとかがもういかにもAIで作り作った
変な
文字文字シーゼともうAI特有の言い回しがふんだんに
入った提案資料お客様に
持って行っていいんでしたっけっていう
それであAI使いこなすことはいいんだけど
そのクオリティで大丈夫なんでしたっけみたいなことが
とっても重要になって
来ていますよねとこれは皆さんご理解のとおりだと
思うんですが
これはですね組織である以上もどうしようもない
この何ですかね品質責任みたいなところは
必ず決まってる問題かなと思っています
この対比は個人開発だと思っていて個人って
とっても気が楽なんですね私も個人開発で
しょうもないアプリケーションiOSアプリをいくつか
作っているんですけどとっても気が楽です
何か問題起きてももう個人の責任だし
そもそもなんかお客様のユーザーデータを
集めるようなアプリを今のところ作ってないので気が
楽だったりするんですけど
18:00
組織っていうのはそういうわけにはいかないですよね
例えば私が何かミスをしたっていうのは当然社内では
私のミスなんですけども外から
見ると会社のミスですよねお客さんも言ったときに
イナディさん私イナディさんがやらかしたんだとは
思わないですよねどうしても社長社長の
せいだとかですねその会社のせいだっていうふうに
扱われるというところがありましなので
詰まるところその責任っていうところは
ああ必ず取らないといけない
個人もそうですけど会社の場合はそれがややこしくて
当の本人じゃなくて会社として責任取らないといけない
その会社としてリスク負っているその
とある誰かが脆弱性のあるアプリを提供して
しまとあるエンジニアが脆弱性を含んだアプリを
世の中に出してしまった結果会社としてのブランドが
下がってしまうっていうところが起きてしまうので会社
個人のミスが会社に影響与えるっていうところが
当然ありますよねっていうところが
これがAIによってどんどん拡大して
いってるってことですね物を作れば
作るほどこの責任っていうのは問われてくるですけど
この作るスピードが上がってきたし誰でも
作れるようになったので
これを全員で負わないといけないこう作る問題と責任を
取る問題っていうのが
いろんな人が考えていかないといけないフェーズに
なってきましたというところですね
以前であれば
基本作って世の中に出すのはエンジニアだったり
するのでこうエンジニアだけエンジニア組織の中で
判断していればよかったのがこれがもうありと
あらゆる職種の人みんなとそれそれを
所属する部門長とかも含めてみんなで
意思決定判断していかないといけないっていう時代に
なってきていますという話ですね
例えばGMOの件
これは
サイバー攻撃にああのあってしまったんですけども実は
数年前からこの問題は
指摘され指摘されていましたという噂ですけれども
じゃこれを真摯にややるのかやらないのかそのわけも
わからない人のこう提案っていうのを
聞かなかった聞かないようにしたっていうのはこれは
誰かの判断ですよね
それは社長だったのか現場の部門長だったのか現場の
メンバーだったのかわからないですけれども
この問題が起きる数年前にセキュリティ対策が
第一優先だという判断意思決定をし
どこタイミングでしておけば
防げたかもしれないという話であることは
間違いないですね
つまり作ることが組織において問題ではなくなってきた
今
判断がとっても重要になってきていますと
そしてその判断は誰がするかということですね
組織組織において
100%自由ってことはないないという話は
さっき話した通り責任問題が
とめ必ず
決まと思うので会社の中にはルールっていうのがあって
承認っていうものがあってっていう
21:01
段階が
ありますよねというものがあるってのが
当たり前ですよねそれは自由と
責任の天秤っていう話だと思っていて
自由であるってことは責任が付きまとう自由が
少ないっていうことは責任は誰かが
持っているということだと思うんですが
そういうことですとなのでこういう時代その誰でも
部門のメンバー誰でも簡単に物を作るように
なった時代においては素早く正確な判断をする
リーダーシップってのがとっても大事に
なってきたかなと思っております
このリーダーシップがしっかり備わっていないと
現場のメンバーが勝手に判断して暴走してしまって
何か問題を起こすとか逆に判断その
誰かリーダーが判断をしたものがミスっているとそれも
同じ問題が起こるしその判断が遅い例えば
AIによってスピードが上がってるのにその意思決定を
するまで一ヶ月も二ヶ月もかかってしまっていたら
全く意味がないので速い素早い正確な判断をする
リーダーシップが今の組織には
とても大事だなというふうに思ってあります
これは当然社長が
全部引き取ってしまいなさいっていうことだと
全然回らないのでそういう意味ではなくって
やっぱり権限と責任の移譲という話だと思っております
何かこうやりたいっていう時に
ええ自分の部門の部門長にも聞かないといけないし
こっちの部門長にも聞かないといけないし
あっちのセキュリティチームにも聞かないといけないし
あっちの経理部門にも聞かないといけないしで
それ全部でいいって言ったら今度社長がダメって
いってみたいなことだと
誰が責任持ってるんですかって
こう曖昧だったりするしスピード感もないので
もうこの
領域の責任者はこの人ですこの人がいいって
言ったらいいんです
その代わり問題が起きたら
この人のせいですみたいなことを
明確にしてスピード感を上げていくでこの
判断の正確性を上げていくっていうのは
このリーダーの役割ですよねっていう役割分担を
もっと明確にやっていかないと
組織のボトルネックっていうのはこの判断のところで
あることには間違いない
ちょっと繰り返しになりますけども作ることが
問題ではなくなってきたので
判断いかに意思決定をしていくかっていうのは
組織の価値に繋がっていくのでいかに
正確な判断をする
リーダーがいるかっていうところが今後の企業の価値に
なってくるのではないかなということ
個人的に考えているという話でございました
はいということで長々話しましたけれども今回は
AI時代の組織のあり方というかメンバーの仕事の仕方
リーダーシップみたいな話をしてみました
前回のエピソードでは自分で問いを立ててから
AIに渡すっていう個人の話をしたんですけれども
今日は組織レベルでも同じですよねと
まずはAIと対話しながら問いを立てて
24:01
作業を明確にしてAIに作業渡しましょうとで
作ったものの責任は明確にしましょうっていうことを
まとめで話してみましたえ皆さんは
この点どう思いますでしょうかなかなか難しい問題だと
思いますけれどももしご意見等あれば頂ければ幸いで
ございますということで最後に番組の
紹介をさせてくださいこの番組Devlog FMは
YouTube、Apple Podcast、Spotify
などで配信しておりますご感想リクエストなどもし
ございましたら #デブログfm で
つぶやいていただくかコメント欄いただけますと
幸いですまたサブスクライブチャンネル登録も
ぜひぜひよろしくお願いいたします
それでは次回の配信でお会いし
ましょうご視聴ありがとうございました
24:54

コメント

スクロール