https://tech.youtrust.co.jp/entry/2026/03/19/110316

🚀 はじめに

こんにちは。YOUTRUSTでエンジニアをしている平野（YOUTRUST / X）です。

今回はテックブログ3本目の執筆になります。過去の記事はこちらです。

ここ1〜2年で、開発の現場が大きく変わったと感じています。

CursorやClaude CodeなどのAIコーディングツールが普及し、以前なら数日かかっていた実装が数時間で終わるようになりました。自分自身も、AIを使い始めてから明らかに手を動かすスピードが上がりました。

そんな中で、ふと疑問を持ちました。

開発は速くなった。しかし、仕事全体のスピードは速くなっているか？

この問いをずっと考えていて、自分なりに気づいたことや意識するようにしたことをまとめてみました。あくまで個人の経験や考えですが、同じようなことを感じているエンジニアの方の参考になれば嬉しいです。

🤔 人間がボトルネックになっている

正直に言うと、「AIで開発が速くなった」と言いながら、AIで稼いだ時間を別のところで溶かしてしまっているケースが多いと感じています。

具体的には、こういう場面です。

コードを書くのは速くなったのに、レビュー待ちで1日止まる
意思決定が必要な場面で、直接話せば5分で終わることにテキストの往復で時間を溶かしてしまう
AIキャッチアップに熱心だけど、それがチームに還元されず個人の体験で完結してしまっている

共通しているのは、ボトルネックが技術ではなく人間になっているということです。

実際、生成AIの登場以降、エンジニアに求められるスキルとしてコミュニケーション能力を挙げる声が増えてきています。逆に、プログラミングスキル単体の重要度は以前ほどではなくなってきているという調査結果もあります。

技術力の差がつきにくくなった分、それ以外の部分で勝負する時代になってきました。

自分はまだエンジニア4年目で、正直なところ技術力だけで勝負できるタイプではありません。これまではエンジニアの価値 = 技術力だったので、そこに引け目を感じることもありました。しかし、AIによって技術力の差が縮まってきた今、自分にとってはチャンスだと思っています。技術力以外の部分──コミュニケーションや組織への貢献で価値を出せる時代になってきた。だからこそ、この記事で書いていくことを日々意識しています。

もちろん、技術力の差がなくなったとは思っていません。コードを書く速さの差は縮まっても、設計能力や技術的な判断力によるアウトプットの差はまだあります。技術力がある人の思考回路から盗めることはたくさんある。そこはむしろAIを活用しながら積極的に学んでいきたいと思っています。

一方で、技術力だけで生きてきた人にとっては、知識や技術を持っているだけでは不十分で、それをどうチームに還元し、組織全体の成果を上げるかまで考えられないと、強みがAIに置き換わっていく可能性があります。

こうした状況の中で、自分が日々意識していることが大きく3つあります。

💬 コミュニケーションで詰まらせない

無反応が一番の悪

速さ = 信頼。これは自分の中で確信に近い考えです。

自分が即レスを意識しているのは、シンプルに自分がされる側の経験からです。すぐ終わるような確認や意思決定なのに、返信が来なくて半日止まる。しかも相手がボールを持っている間、自分の頭の中には「あれまだ返ってきてないな」が消化されないタスクとしてずっと残り続ける。この認知負荷を常に抱えている状態が個人的にとても嫌です。

これは、逆の立場でも同じです。自分が返信しないことで、相手の頭の中に同じ認知負荷を押しつけている。相手の思考をブロックしている。テンポよく仕事を進めたいからこそ、自分は相手にそれをさせたくないと思っています。

即レスは相手の頭を空けてあげる行為です。

ただ、即レスは即答じゃなくていい。完全な回答が用意できなくても、スタンプを押すだけでも全然違います。「確認します」「○日までに返します」の一言だけでも、相手は「ちゃんと受け取ってくれた」とわかる。大事なのは、自分がどう受け取ったかを早く伝えることだと思います。

この積み重ねが信頼になります。「この人はいつも反応が早い」「すぐ対応してくれる」という体験が重なると、自然と「この人を頼ってみよう」という関係性につながっていく。即レスは特別なスキルではなく、信頼を積み上げる最も再現性の高い行動だと思っています。

そして、レビュー待ちや返答待ちが発生すると、チーム全体がブロックされます。AIで開発スピードが上がっても、コミュニケーションのボトルネックが残ると全体のアウトプットは変わりません。ここを意識しないと、AIの恩恵がエンジニア個人だけに留まってしまいます。

ゴール逆算でコミュニケーション手段を選ぶ

テキストで送るか、直接話すかは、あくまで手段であって目的ではありません。

でも意外とここを考えずに、とりあえずテキストで送ってレスを待つ、というパターンになりがちです。直接話せば5分で終わることが、テキストの往復で1日かかることがあります。

自分が意識しているのは、最終的なゴールに早くたどり着くために、どの手段が最適かを考えることです。

温度感や緊急度を伝えたい → 直接話す
その場で認識を合わせたい → 直接話す
記録を残したい・複数人に共有したい → テキストで送る

特に「テキストで送るほどでもないこと」を何となく送ってしまうのは、チーム全体のコミュニケーションコストを上げてしまっています。直接話してからテキストで内容を残す、という順番も有効です。温度感が伝わった状態で記録にもなりますし、レイヤーが上がるほど相手は忙しいので、この順番がより重要になると考えています。

出社日の使い方

弊社はハイブリッドワークを採用しています。火・木は緊急ではない限りMoku Moku Dayとしていて、実装に集中できる時間が確保されています。

出社日：月・水・金

この出社日をどう使うかが、チームのアウトプットに直結します。自分が意識しているのは、意思決定が必要な話題は出社日に寄せることです。非同期コミュニケーションでは意思決定のスピードが落ちるので、出社している日に集中して解決する。逆にリモートの日は、とにかく作業に集中できる環境として使う、という使い分けです。

「ちょっといい？」が気軽に生まれる場、相手の雰囲気や表情から状況を読める場、偶発的な会話からアイデアや課題発見が生まれる場。それがリモートにはない出社の一番の価値だと思っています。

相手の状況を把握して動く

少し変な話かもしれないのですが、自分は日々一緒に働くメンバーのカレンダーと、直接関係ないSlackのやり取りも見るようにしています。

「なんでそんなこと把握してるの？」と引かれることもあります。

しかし、個人的にはかなり重要なことだと思っています。カレンダーを見ると「今日は午後MTGが詰まっているからパツパツだな」「このMTGで何かが決まりそうだから、その後に話しかけよう」という判断ができます。Slackのやり取りを見ていると、自分がヘルプに入れそうな場面や、先に把握しておくことで後から来た話にスムーズに入れる場面がわかります。

相手の状況が見えると、コミュニケーションの取り方が変わります。レスが遅くても「MTGが多いからか」と理解できる。タイミングを考えて声をかけられる。結果として、あらゆるコミュニケーションがスムーズになり、意思決定や課題の特定が早くなります。

これはあくまで自分のやり方であって、手段は人によって違っていいと思います。大事なのは常に一緒に働く人のことを考えて、どんなコミュニケーションが最適かを考えることだと思います。

信頼関係はすべての土台

ここまでコミュニケーションの話をしてきましたが、その土台にあるのは信頼関係です。そしてこれはコミュニケーションだけでなく、この後に書くチームへの還元やAI活用の浸透にも通じる話です。

「これ聞いていいのかな？」と考える時間は、すごく無駄です。気軽に聞ける状態を普段から作っておくことが大事で、技術力があっても近寄りがたい人は、結果的にチームのアウトプットを下げてしまっています。

自分の経験として、上の立場の人から気軽に話しかけてもらえると「聞いていいんだ」という空気が生まれて、すごく動きやすくなります。信頼関係は「待つもの」ではなく「自分から作りにいくもの」だと思っていて、自分も周りのメンバーに対してそう意識するようにしています。

受け取る側の姿勢も大事

コミュニケーションの話をすると、「伝え方」にフォーカスされがちですが、受け取る側の姿勢も同じくらい大事だと思います。

「Slackではこう話してください」「このように伝えないとわかりません」と言うけど、自分からは相手に興味を持とうとしない。「急にそんな話されてもわからないので、もっとわかりやすく説明してください」と言うけど、なぜ相手がそう伝えてきたのかを考えようとしない。こういう場面を見かけることがあります。

もちろん、伝える側が意識すべきことはたくさんあります。それは大前提です。しかし、受け取る側も相手の状況や意図を理解しようとする姿勢がないと、コミュニケーションは一方通行になります。コミュニケーションは双方向。「伝え方が悪い」で思考を止めるのは、少し受け身すぎると自分は考えています。

🔄 知識・技術を組織に還元する

「感想」で終わらせない

自分も含めてですが、AIのキャッチアップをしていても、それを感想としてSlackに流して終わりになっているケースが多いと感じています。

新しいツールを試した、便利だった。それだけでは個人の体験で完結しています。大事なのは「それをどうチームに浸透させるか」まで考えることだと思っています。

これまでは「その人にしか持っていない知識・技術」が価値でした。でもこれからは、それをどうチームに還元し、組織全体の成果につなげるかを考えられる人が求められるようになってくると感じています。

自分自身も、キャッチアップした内容を感想として残すだけで止まってしまうことがあります。でも本当は、チームにどう浸透させるか、仕組みとしてどう定着させるかまで考えないと、せっかくの知識が組織のアウトプットにつながらない。

個人が速くなるだけではなく、チーム全体が速くなる仕組みを考えられるかどうか。自分自身の課題でもあります。

指摘で止まらず仕組みで解決する

同じ課題が何度も話題に上がっているのに、そのたびに指摘するだけで終わっていることはないでしょうか。レビューでの指摘もそうですし、チームや組織の課題でも同じことが言えます。

同じことが繰り返されるなら、それが起きなくなるように仕組みで解決できないか考える余地があります。Linterの設定を変える、テンプレートを整備する、ドキュメントに落とす。「指摘する」で止まらず「仕組みで根本解決する」まで持っていくことが、チームのアウトプットを継続的に上げることに繋がるはずです。

正直に言うと、自分自身もここはまだ十分にできていません。日々の業務の中で後回しにしてしまうことがあります。でも、ここをやれるかやれないかで、エンジニアの価値は変わってくると思っています。だからこそ、これから意識的に取り組んでいきたいと思っています。

自分の技術力や知識をメンバーに浸透させるにはどうすればいいか。AIなどを活用して効率的に浸透させることはできないか。そこまで考えて動くことが、組織に還元するということだと考えています。

🌐 組織全体にAI活用を広げる

非エンジニアはどこに使えばいいかわからない

AIが大事なのはわかっている。でもどこにどう組み込めばいいかわからない。

非エンジニアの人と話していると、こういう状態の人が多いです。「やってみたいけど最初の一歩が踏み出せない」という状態です。業務フローを見て自動化できる箇所を特定する素養がないと、AIが便利だとわかっていても活用に踏み出せません。

ここにエンジニアが入る価値があります。エンジニアは業務を分解して、どこが自動化・効率化できるかを見極める力を持っています。この力を開発以外の場面でも活かせると、組織全体へのインパクトが大きく変わります。

実際にやっていること

自分は、非エンジニアの人との雑談の中でAI活用の話が生まれることが多いです。

最近だと、他部署の方から「AIを活用したいけど、何から手をつければいいかわからない」という相談を受けました。いきなりツールを導入するのではなく、まずは「AIってこうやって活用するんだよ」というところからレクチャーして、一緒に業務フローの棚卸しをするところから始めています。今は週1で定例を開きながら、どの業務がAIで代替・効率化できそうかを一緒に探っているフェーズです。

答えを教えるだけでは難しいことが多く、一緒に進むスタンスが大事だと思います。AI活用の勘所さえ掴んでもらえれば、あとは自然と活用が進んでいくことが多いはずです。だからこそ、最初の伴走が重要だと考えています。

まだ始まったばかりですが、こうした取り組みを他のチームにも広げていきたいと思っています。

ビジネスサイドとの信頼を積み上げる

こうした活動を続ける上で土台になるのは、ビジネスサイドとの信頼です。

自分が意識していることの一つに、簡単な改善要望を爆速で対応するというのがあります。AIで開発が速くなったからこそ、社内の要望やユーザーからの要望にできるだけ早く応えたい。もちろん施策の優先度は重要です。でも、誰がどう見ても「それはあったほうがいいよね」というもの──優先度をつけようとすると下がってしまうけど、対応すれば確実に良くなるもの──はさっさと対応した方がいいと思っています。

「この人に相談したらすぐ対応してくれた」「一緒になって考えてくれた」「自分のことを気にかけてくれている」。こうした体験の積み重ねが信頼になり、次の相談につながります。

組織全体でAIが使われるようになると、成果の向上幅が全然違います。エンジニアが開発チームの中だけで価値を出すのではなく、チームの外に出てビジネスサイドと一緒にAI活用を考えられると、エンジニアの存在意義が一段上がると思います。

開発チームに閉じず、ビジネスサイドからどれだけ信頼されるか。これが今後のエンジニアの強みになっていくと考えています。

💡 これから意識していきたいこと

AIがコーディングやテストといった「How（どう実装するか）」を担えるようになった今、エンジニアの仕事の重心は「Why（なぜ作るのか）」「What（何を作るのか）」を深めることに移ってきていると感じています。

弊社でも4月から開発フローが刷新され、要件定義や仕様作成のリードをエンジニアが担う形になります。PdMが定義した要求を深く理解した上で、何を作るか・どう振る舞うかを自分で考えて定義するところまでがエンジニアの仕事になる。ただ仕様どおりに作るだけではなく、上流から主体的に関わることが求められるようになります。

AIが実装を速くしてくれる分、この上流の部分にもっと時間と思考を割けるようになったとも言えます。

正直、自分はここがまだまだ足りていません。特にユーザーへの理解の部分です。データ分析やユーザーインタビューからのインサイト分析など、ユーザーが本当に求めているものの解像度をもっと上げていく必要があると感じています。

要件を定義し仕様を作るということは、「ユーザーにとって何が価値か」を自分の頭で考えるということです。そのためには、常にユーザーが求めるものを追い続ける姿勢が欠かせない。ここはこれから意識的に取り組んでいきたいと思っています。