コンテキストスイッチについてAI時代にもう一度考えてみた
法人・団体専用のパーティー会場検索サイト「会場ベストサーチ」を運用する株式会社アイデアログの取締役CTOの松川と申します。
長年「コンテキストスイッチ」は生産性を低下させる。という認識を持っていました。
Aプロジェクトのコーディングをこなしながら、Bプロジェクトの設計レビューの依頼を受け、Slackで連絡のあった質問やインシデントの調査を行い並列で仕事を進めるあれです。マルチタスクやマルチプロジェクトと言ったりもします。
プレイングマネージャー、管理職、経営層の人たちは、マルチタスクが基本であり、避けられない状況下と思っていて、今も昔も変わらないと思います。
また、マルチタスクは難易度が高く、1つずつ集中して取り組むよりトータルの時間が長くなる傾向にあります。これは、実際に経験をした方も多いのではないでしょうか。
コンテキスト(文脈)をあっちこっちに切り替える度に脳がエネルギーを使い、疲れることが原因とのこと。今回改めて、「コンテキストスイッチ 生産性」というキーワードでググると、以下の要約が出ました。
生産性への影響
コンテキストスイッチは、次のような理由で生産性を低下させます:
集中力の低下:
頻繁な切り替えは、集中力を維持することを難しくします。
エラーの増加:
集中力が低下すると、エラーが発生しやすくなります。
作業時間の増加:
元の状態に戻るまでに時間がかかるため、作業時間が長くなります。
疲労感の増加:
脳への負担が増加するため、疲労感を感じやすくなります。
記憶力の低下:
記憶を一時的に保持する能力が低下する可能性があります。
どれも、うなづけるものばかりです。では、対策はというと、
対策
コンテキストスイッチによる悪影響を軽減するためには、以下の対策が有効です:
タスクをグループ化する:
関連するタスクをまとめて処理することで、切り替えの回数を減らすことができます。
集中できる時間を作る:
ポモドーロテクニックなどの時間管理術を活用し、集中して作業する時間を確保します。
通知を制限する:
重要な通知以外はオフにするなど、気が散る要因を減らします。
休憩時間を設ける:
集中が途切れたと感じたら、短い休憩を取り、リフレッシュすることが重要です。
作業環境を整える:
整理整頓された環境で作業することで、集中しやすくなります。
シングルタスクを心がける:
同時に複数のタスクを処理するのではなく、一つずつ確実にこなすように意識します。
ツールを活用する:
タスク管理ツールやプロジェクト管理ツールを導入することで、タスクの進捗状況を可視化し、効率的に作業を進めることができます。
コンテキストスイッチは、現代の働き方において避けられない問題ですが、上記のような対策を講じることで、その影響を最小限に抑えることができます。
特に目新しいものはありませんし、心がけている方も多いかと思います。
生成AI活用を前提とした当社の開発現場で何が起きているか
生成AI活用は開発現場の業務プロセスや人材教育に革新的な影響を与えていることは言うまでもないですが、git hub copilot, claude code などのコーディングエージェントが登場してから、コードを書くという作業に大きく影響を与えています。
今後は的確にAIに整理された情報を与え、生成してくれたものに対するチェックがエンジニアにとっての大きな役割のひとつとなってくることは確定的なように思えます。
そうすると、並列でAIに指示を与え、コンテキストを頻繁に切り替えながら開発を進める、合間に必要な打ち合わせもこなす、といった仕事の進め方が、マネージャー層だけでなく、プレイヤー層についても発生してくることになります。
また、並列処理が得意なメンバーとそうでないメンバーとでアウトプットの量に差が出てくることも想定されます、
これは大変、脳が疲れますし、精神的にも結構まいってしまう側面があると思います。
実際に当社エンジニアでAIを活用した開発プロセスを模索しながら、自らの担当開発も推進しているVPoEは先日、Slackでこのような言葉を漏らしていました、
かなりのベテラン選手で、相当のタスク量を以前からこなす力がある人物なのですが、未曾有の情報処理量だったことが伺えます。
また、コンテキストスイッチの労力以外にも、現在、多くのテック系の企業が経験しているであろう、「レビュワーの負担増」「AIが生成したコードの理解が甘い状態でプルリクを出す」問題に対する悩みも多いのではないでしょうか。
では、どう対処するのか?
シンプルなのですが、まずは「休む時はしっかり休む」です。
昼夜問わず、文句を言わずにコードを作ってくれる生成AIにもっともっと指示して開発を推進したいという気持ちになってくる方も多いかと思いますが、人間には限界があります。
仕事以外の時間はきっちり頭を切り替えて、趣味のことをする、体を動かすなどして気分転換しましょう。しっかり休むのもプロの仕事です。
次に私が考える具体的な対処法ですが、「1日の計画を綿密に立てる」ことかと思います。
仕事を始める前に、計画や目標を定める習慣はAI時代以前から重要なことではありますが、AI利用を前提に、AIに任せることと自分でやることの整理を徹底的につけて、AIに振り回されないようにすることです。AI活用するにしても、情報を整理していない状態で指示を始めると、軌道修正に時間がかかったり、迷子になることがあり、このような事態を招かないためにも、事前の整理が大切です。
個人個人で好みは分かれるところですが、私自身は1日のタイプスケジュールを30分刻みくらいの粒度で落とし込むこともあります。
マークダウン形式などで、処理の詳細設計を書き、必要なデータソースもAIが解釈しやすい形式で揃えておくとよいと思います。判断ポイントとしては、自分で実装するにしてもイメージができるレベルまで落とし込めていると良いと思います。
もちろん、この情報収集・整理・準備の作業の一部をAIにサポートしてもらうというのはありですね。
こうすることで、脳の疲れが少しマシになった気がします。ご参考にしていただければと思います。
我々エンジニアは今後どのようなスキルアップをしてゆくべきなのか
AIがコードを生成しているからと言って、エンジニアは学ぶことをやめていいわけではなく、従前通りスキルアップに注力し続けることは変わらないと思います。
情報整理と円滑な情報流通のために
- 論理的思考力
- 構造化能力
- コミュニケーション力
といったビジネススキルが当然のように求められるようになると考えています。コードは書けるけど、これらの能力はイマイチ。。では専門職としての専門性・希少性・市場価値を生み出しにくくなってくるのではないでしょうか。
また、コードを書く量は減りますが、AIが生成したコードを理解し、ビジネス要件と異なる実装については的確に問題と修正を指示する、従前通りの「コードレビュー力」がやはり必要となると考えています。
システム運用・保守、パフォーマンス、セキュリティー、可搬性、可用性などのいわゆる「非機能要件」について、自分たちの組織やビジネスのフェーズにジャストマッチしているのかというジャッジも従前通り人間が判断してゆくと考えています。
そこで重要となるのは、表面的なハウツーではなく、「情報システム」というものについての原理原則についての深く広い知識と、開発現場での失敗経験を含めた「経験値」が求められてくると考えています。
技術書を読む際には理解して書けるようになることより、どのようなことができ、どのような課題解決ができるか、を頭の中にインデックスを作成するような身の付け方がよさそうかと思っています。
単純な例ですとSQLの文法を細かく覚えることより、SQLで結合ができる、データをグループ化できる、件数をカウントできる、合計値が計算できる、平均値を計算でるといったことは覚えていて、課題解決の引き出しとして必要な時に取り出せるが、具体的に書く必要はない、というイメージです。(簡単なSQLくらいであれば、さっと書ける必要があると思いますが。。)
激動の時代ともいえる大変な時代ですが、その分大きな可能性を秘めていることでもありますね。
必要以上に恐れず、状況を冷静に見て、楽しみながら自分たちのスタイルを確立していきたいと考えています。
Discussion