AIで事業・組織・仕事の進め方を再設計。Webシステム開発・教育事業を経営｜AI駆動開発・業務改善を現場で実践｜開発体制の変化、営業・採用のAI化、FDE/社内AI推進人材について発信
Joined October 2009
- Tweets12.4K
- Following1.6K
- Followers3.6K
- Likes31.9K
Pinned Tweet
引き続き、増員のため、エンジニア募集しております📣
業務システムのリニューアル案件で、仕様書作成やコーディングの多くをAIが担当しています。
そのため、実装スキル以上に重視しているのは、
・複雑な業務システムの理解力
・曖昧な要件を整理、具体化する力、言語化力
・顧客や開発チームとの調整力
・AI生成物の検証、改善提案
・指示待ちではなく主体的に動けること
業務系システムの開発経験、要件定義・基本設計、リプレイス経験、AI開発経験がある方は特に歓迎です。
※リモート希望の方からたくさんご連絡いただいていますが、コミュニケーションのため出社必須となります
ご興味あるエンジニアさん、該当するエンジニアをご提案いただける企業様は、DMでご連絡ください📩
ドメイン知識はめちゃくちゃ大事。
特に作業がAIに代替されるようになって、ますます重要になっていると思う。
今関わっているプロジェクトでは、参画して1ヶ月程度はがっつりドメイン知識をキャッチアップしてもらっています。
リモートやスポット、副業の業務委託だと、ドメイン知識のキャッチアップスピードが落ちることが多い。
私自身、業務知識をインプットする時間が充分に取れない関わり方をして、充分なパフォーマンスを出せなかった経験もある。
これからは、業務にどこまで深く入り込めるかも重要になってくると思うので、受注側はもちろん、発注側もその期待値を明確にして、キャッチアップ計画なども折り込む必要がある。
3年以上お願いしていた業務委託のフロントエンドエンジニアとの契約を更新しないと決まった。仕事ができない人ではなく、フロントの実装をお願いすれば速いし、アラートや問い合わせ対応もかなり積極的にやってくれていた。
なんだけど長年一緒にやっている割に、ドメイン知識が全然身に付いていない。
「〇〇の部分をお願いできますか？」と依頼するといまだに「〇〇ってなんでしょうか？」と返ってくることもある。
これまではそれを差し引いても十分助かっていたけど、AIによっていよいよ「それじゃあ厳しいな」という話になった。
実は直近の3ヶ月は契約を継続するかの見極めも兼ねて、タスクの抽象度を上げ、ドメイン知識の絡む部分から考えてもらうようにした。
だけど結局、「何からやったらいいでしょうか？」と聞かれることが多くて、うまくいかず。頑張ろうとしてくれていたのは伝わってきたけど。
与えられたタスクをこなす働き方から、自分で課題を整理する働き方に変えるのは、分かっていても簡単じゃないんだろうな。
AIで仕事は速くなっているはずなのに、なぜ会社は儲からないのか？
生成AIを業務で使う企業は86.4%。
一方、売上・利益の向上を効果として挙げた企業はわずか3.9%。
これ、AIの性能の問題じゃなくて、経営の問題なんじゃないだろうか。
3時間かかっていた仕事が30分で終わっても、会社の人件費は変わらない。
浮いた時間で何をするのか。
どの業務をなくすのか。
どう売上や利益につなげるのか。
そこまで設計しなければ、単に社員の仕事が楽になっただけで終わってしまう。
これから必要なのは、AIを使える人ではなく、AIで生まれた生産性を事業成果に変えられる人。
AI導入の次に必要なのは、経営そのものの再設計だと思う。
出典：ThinkingAI「2026年 企業のAI活用レポート」
最近、届く案件情報や求人を見ていて、AI活用スキルを求めるものがかなり増えたと感じる。
少し前までは「使えるとプラス評価」くらいだったのに、今はClaude CodeやCursorなどのAI駆動開発経験を前提にしている案件も出てきている。
気になって調べてみたら、求人要件にAI活用経験・スキルが登場する割合は
2024年：1.7%
2025年：9.3%
2026年：26.0%
わずか2年で約15倍。
「AIを使える」は、加点要素から採用条件に変わりつつあるんだと思う。
今後は、ただ使えるだけではなく、AIを使って何を実現できるか、成果物の品質まで責任を持てるかが問われそう。
定期的に、HPに載せてる画像の変更のご依頼をいただく。
制作当時の元データがPhotoshopで、今はもうPhotoshopは解約しているんだけど、AIに頼んだら、差し替えた画像を生成してくれた。
しかも、画像の差し替えからプルリクまでやってくれる。
以前はデザイナーとエンジニアがそれぞれ担当していた作業が、今はAIへの指示だけでここまで進む。
AIによる代替って、個々の作業だけじゃなく、職種をまたいだ一連の工程で進んでいるんだと思う。
デザイナーの8割弱、AIを毎日利用 「キャリアに不安」半数超す
nikkei.com/article/DGXZQOUC1…
「関われなかった領域に裁量を持て、楽しさを感じる」といった前向きな反応の一方で、「専門性・強みが分からなくなった」という声も上がりました。
保守契約していない、PHP5系で動いている古い社内システムのバージョンアップを相談され、見積を出したものの、担当者が社内の予算承認に苦戦しているらしい。
システムは今も問題なく動いている。
更新しても新機能が増えるわけではない。
だから、決裁者からすると費用対効果が見えにくい。
でも、古い環境を使い続けるほど、将来の障害対応や改修が難しくなるリスクはある。
こういう予防的なIT投資って、本当に予算を通すのが難しい。
技術的な必要性だけでなく、放置した場合のリスクや将来コスト、業務への影響まで説明する必要がある。
ふわっとした要望を、何も理解してない人が、仕様に落とし込まずに、AIでポン出し資料化してきて、それを開発側がそのままAIに読ませて実装したら、本来必要のない機能が追加されてしまったことがあった。
その後対策として、AIに渡す前に「これはこういうことですか？」みたいなやりとりをしたけど、本人もよく理解していないので、話が噛み合わない。
理解してない人にAIポン出しさせて、なんとなくそれっぽいアウトプットを出させるのは、やめた方がいい。
自社開発やりたいっていう人多いけど、自社サービスやってたら、障害が発生したら夜間でも土日でも対応が必要になります。
前にSESの営業さんに「まぁ仕事してれば障害対応で夜間や土日対応もありますし」って言ったら「弊社ではそんなこと一度もありません！😤」とキレ気味に言われたんだけど、そんなヌルい環境に慣れちゃってたら自社サービスなんてしんどいのではないかと思いますが、どうなんでしょうね。もちろん人によるとは思いますが。
もしよかったら招待コードどうぞ！
パーソナルAIエージェント「Muse」をチェックしてみよう。参加後48時間以内に[設定]で私のコードを利用すると、私たち両方が10億のMuseトークンを獲得できます。
コード: KFW29E
muse.ai/join
AIで仕事を効率化しても、給料が増えるとは限らない。
これ、システム化の時代から同じなんですよね。
昔、事務員時代、社内業務を自分でシステム化して、1人で2人分の仕事をこなせるようにしたことがある。派遣は1人契約終了して、人件費はコストダウン。
でも給料はまったく増えなかった。
バカバカしくなって退職したけど、今のAI活用でも同じことが起きている。
会社は生産性が上がって嬉しい。
でも、社員には効率化するインセンティブがない。
効率化の成果をきちんと測定して、評価や報酬に還元する仕組みが必要だと思う。
採用・マッチング領域へのAI代替は、かなり進みそう。
実際、弊社でも、エンジニアの要員情報やスキルシートが大量に届くので、AIで候補を絞り込んでる。
過去の面談議事録、採用結果、その後の活躍まで見て、条件に合う人をピックアップ。
面談しないと分からないことはあるけど、書類選考には十分。
採用やSESのマッチングも、一次選定を人間がやる必要はなくなっていくと思う。
増員が必要になったら、信頼しているSES会社に人を集めて欲しいと依頼します(今回はそれでも足りなかったのでXでも募集しました。募集内容は固定投稿をご覧ください)
参画エンジニアの所属してるSES会社から、無茶な要望が来ることがたまにあるので、間に取りまとめてくれる会社が入ってくれてると、とても助かるのです。
そういう調整にコストがかかるのは当然ですよね。もちろん中抜きするだけの会社もあるでしょうけど。
多重下請けって、単純に「中抜きしたい会社が多いから」だけで残っているわけではないです。
そもそも背景には、高度成長期に案件が一気に増えて、人材が足りず、いろんな会社から人を集める必要があったことがある。
-------------------------
・1950年代〜1960年代
高度経済成長とともに企業の設備投資や情報処理需要が拡大
・1960年代後半
ソフトウェア産業が本格的に発展。大手メーカーを中心とした外注関係が形成
・1970〜1980年代
大規模システム開発が増加し、多層的な請負構造が発達
・1990〜2000年代
受託開発、人月単価による取引、外部人材の活用が定着し、現在につながる構造が強まる
-------------------------
そこで「足りない人材を外部から集める」という慣習が生まれ、年月をかけて構造化され、今の多重下請けにつながっている。
この構造によって利益を得ている会社がいるのも事実です。
ただ、現場側にとって都合がいい理由もある。
それは、結局「知っている人に任せた方が楽」ということ。
元請けの担当者に、昔から付き合いのあるパートナー会社の担当者がいる。「人が足りないから集めて」と言えば、その人が自社・他社を問わず人材を集めてくれる。
その会社の担当者にも、さらに下に付き合いの長い会社や仲の良い担当者がいて、またそこに「誰かいない？」とお願いする。
システム導入案件を例に挙げると、上流のポジションに仲良い会社の人、類稀に優れた人材が入れれば、その人が自社の社員やさらに下請けの会社の人材を入れたりして、下のメンバーをまとめてくれるので管理もしやすい。
ただ、そういう優秀な人材は当然単価も高いので、その人一人を提案しているだけでは、提供する会社としても利益を確保しづらい。
そこで、優秀な人を上流に入れたうえで、構築フェーズに入ったら自社の開発要員や若手を追加で入れる。
上流の人にチームをまとめてもらいながら、若手を育成し、会社としても利益を確保する。
つまり、きれいな組織図だけで商流ができているわけではない。
「この担当者なら任せられる」
「この人に頼めば集めてくれる」
「この人が上にいれば現場を回してくれる」
みたいな、担当者同士の長年の人間関係や信頼関係で商流が固定されているケースも多いと思います。
だから、一番下の会社が元請けに「直接取引しませんか」と言っても、
「すでにあの会社経由で取引しているので、直接は難しいです」
となることがある。
単純に一社抜けば終わる話ではなく、その会社や担当者が持っている人脈、調達力、現場との関係性までセットになっているのです。
AI失業への対策として、就業支援やリスキリングを進めるのはわかる。
ただ、AIで減るのは主にPC上の定型業務。一方、AIを使って業務を再設計するような上流の仕事は、そもそもポジションが少ない。
行ける人は上流へ行くのが良いけど、全員をAI人材への転換を政府として支援することは、現実的ではないと思う。
個人的には、人手不足の業界への労働移動が進むのが良いと思っている。
AI失業の問題は、リスキリング+産業間の労働移動をどう実現するかという話になると思う。
🤖 Made with AI
PHPのバージョンを上げたことで、だいぶ長いこと更新止まってたWordPressとプラグインのバージョンを上げる必要がある場合は、21万で対応出来ないとか全然あると思う。
プラグインが更新版が出てないケースとかもあるし。
Xでエンジニア募集して、何社かご連絡いただきましたが、リモートのエンジニアを抱えて、リモート案件を探してる会社さんが多かった。
もしかしてリモート人材がダブついてるのかも？と感じました。
引き続きエンジニア募集してますので、ご提案お待ちしてます。募集内容は固定ツイートにあります。
保守契約のないお客様から、PHP5.6で動いている古いシステムのバージョンアップをご相談。
昨年、同じお客様の別システムをPHP5系から8系へ移行した時は、数ヶ月かけて慎重に対応したけど、今回は急ぎたいとのことなので、AIエージェントを活用して、どこまで効率化できるか試してみます。
今日のエンジニア面談で、能力差を強く感じた。
業務内容を「AIが作ったものをリリースまで持っていく」と説明したとき、以前面談した方は「テスト業務ですか？」と質問。
一方、今日の方は説明を聞いて数分で、データ移行について具体的な質問。そして、まさにプロジェクトが抱えている課題を指摘。
同じ説明を聞いても、見えているものが全然違う。
この違いは、抽象的なゴールを具体的な課題やタスクに落とし込めるかどうか。
これはエンジニアに限らない。売上や利益といったゴールを、具体的な施策や行動に落とし込むのも同じ能力。
AIが実行を担う時代、この能力の差がますます大きくなると思う。
そして今日面談したのは、Xでの募集を見てご連絡くださった方でした。とても良い出会いでした✨