乐胖代购免代理版

入江眞 - Google Cloud Partner Top Engineer 2024
- 認定スクラムプロフェッショナル・スクラムマスター
- 認定人間中心設計専門家
- 人間中心設計推進機構評議委員

はじめに

こんにちは、NRIの入江です。
先日 Google Cloud Next Tokyo '24 が2024年8月1日、2日の2日間開催され、NRIはPlatinumスポンサーとして協賛し、ブース出展とスポンサーセッションで参加しました。
Day2におけるスポンサーセッションではありがたいことに機会をいただき、満員御礼の中「生成AIを成長エンジンに！金融業界のアプリ開発現場におけるマルチモーダルAI活用」というタイトルで登壇させていただきました。

今回のブログでは生成AIという文明の利器と、ソフトウェア開発の現場における導入について考えてみたいと思います。

包丁やダイナマイトのような文明の利器然り、 “技術“というのは良い側面と気をつけなければならない側面があり、両面を知った上で適切に利用していくことが重要です。昨今の生成AIにおいてもリテラシーと倫理観、そして活用する方向性の見極めが重要になっているのではないでしょうか。

社会学的に・倫理的に生成AIという技術に向き合うことで、それを現場適用する際に、どういったアプローチが有効になり得るのか考察し、一部事例をご紹介します。

ピープルウェア

本記事では重要なキーワードとして「ピープルウェア」を取り扱いたいと思います。

「ピープルウェア」とは、「ハードウェア、ソフトウェアと共にコンピュータ技術の3つの中心的な側面の一つを表す用語である」（出典_Wikipedia：ピープルウェア）と表現されており、人間の組織論、チームワークやその生産性、チームにおける心理学など社会学的な側面全てを包含するものを指します。
この用語が広く普及したのは1987年に出版された「Peopleware: Productive Projects and Teams（著者：トム・デマルコ、ティモシー・リスター）、以下Peopleware」によるものだと言われています。

そこで、書籍で言及されている内容から、初版から約40年経ってもなお技術では解決できない課題（＝ピープルウェア上の課題）をピックアップし、ピープルウェアを補完・アップグレードする生成AIの可能性を考えてみます。

実際のところ、ソフトウェア開発上の問題の多くは、技術的ではなく社会学的なものである

ピープルウェア起点で私たちの働く環境、そこで起こっている問題を見つめる時に最も重要で、かつ、最も忘れられがちな観点が章のタイトルであると思います。（参考図書,第１部/第１章）
なぜ忘れられがちなのか。これも書籍内で言及されており、「ハイテクの幻影」と称されています。

どうして新任のマネージャーは技術的問題には十分時間をかけて考え、人間的側面には時間を割かないで良いと信じ込むのだろう？
それは、おそらくハイテクの幻影のせいだろう。
（Peopleware第1部・第１章より）

これは、多くのソフトウェア開発現場において、マネージャー、チームリーダーは組織マネージメント、次年度の仕込み、生産性向上、突如発生する障害対応といった、切羽詰まった状況に立たされており、そんな時に生産性向上に効果があるという技術的ラエトライル*1に飛びついてしまうということです。
そして技術的ラエトライルが効果をもたらすのはソフトウェア開発工程においてコーディングやテストなど局所的であることが多く、顧客との対話、設計書作成、受け入れテスト、バージョン管理、システムの切り替えなどたくさんある全体のデリバリーを早めるほどの効果があるかというと、なかなか疑問なのではないでしょうか。

もちろん、エンジニアは新技術を使った製品開発や業務自動化することで生産性を上げようとしますが、実際のところ、ソフトウェアは顧客との対話、多数のプロジェクトチーム、エンハンスチームとの協調の中で開発するので、ハイテクビジネスというよりも人間関係ビジネスに包含される形で仕事をしています。
そう考えると、土台である人間関係ビジネスを大事にしないわけにいかないでしょう。

例えば、ソフトウェア障害が発生した際に、ポストモーテム*2を行い、プログラム修正のみで障害対応が完了となる現場がどれくらいあるのでしょうか。
SRE（Site Reliability Engineering）の一環としてチームはポストモーテムを行うことも多くなったと思います。ポストモーテムは人ではなく環境・プログラムに対してあらゆる自動化、仕組み化で再発防止を試みます。
しかし、有効なポストモーテムには、顧客・チームメンバー・他システム担当者との信頼関係が構築されており、心理的安全性が保たれていることが大前提となります。

エンジニアの生産性を蝕むもの

生産性を上げないといけない、しかし、むやみに“技術的ラエトライル”に飛びつくのも良くない。そうなると、開発現場にいるエンジニア一人一人の生産性を技術的ではないアプローチ（＝社会学的アプローチ）で向上させることが重要になってくるのではないでしょうか。ここで、いくつかPeoplewareで言及されている生産性を阻む要素を紹介します。

①プログラムは夜できる

残念なことに、業種を問わず、設計や開発に携わる人にとって生産性が一番高まる時間帯は、打ち合わせや電話など割り込みタスクのない、誰も出社していないような早朝か、深夜残業するかということです。そのような意味では、コロナ禍で浸透・定着したテレワークはエンジニアの生産性を上げるのに一定の効果があったのだと思います。

②頭脳労働時間 vs. 肉体労働時間

なぜ、割り込みタスクのない状況が大事なのでしょうか？

アーキテクトやプログラマのような業種においては、心理学でいうフロー状態*3になっていることが理想と言われています。時間が経つのを忘れるくらい没頭していつの間にか4時間経っているというような経験は誰しもあるのではないでしょうか。
一般的に、フロー状態になるには約15分程度の集中が続く助走時間が必要と言われています。しかし、オフィスでは上司から呼び止められたり、同僚から相談されたり、割り込みタスクによって作業を中断されたりとフロー状態に至ることがないまま、会議が始まってしまう。この繰り返しで、真に生産性が高まる瞬間まで到達することなく、業務時間が終了しています。

しかし、困ったことに業務時間と肉体的疲労は業務についている限り蓄積していくので、フロー状態に到達しうる深夜残業は、ホワイトな働き方を標榜する現代社会においてはNGとされます。

③通知、通知、また通知

代表的な割り込みタスクは、緊急の障害対応や電話によるものだったのではないでしょうか。しかし、現代ではメールと電話の中間にあるようなチャットツールもその仲間入りしてしまいました。（Peoplewareでは「電話、電話、また電話」という章タイトル）

チャットツールはコミュニケーション自体への生産性を爆発的に上げてくれました。しかし、エンジニア一人の生産性という観点において、これほどフロー状態への導入を阻害するものはないのではないでしょうか。電話よりも多方面から、バイネームでのメンションだけではなく、グループチャットという形でもあらゆる通知に巻き込まれてしまいます。

①から③をわかりやすくまとめた図がこちらになります。

エンジニアの生産性を保つということ

もう少し大きな単位でエンジニアの生産性を保つということがどういうことなのか、考えてみたいと思います。

IT企業という想定でBSとPLを例にしてみました。

企業は資産を生み出し、その資産で売り上げをあげて、利益が生まれます。そしてその利益を次の投資・資産作りに活用するわけですね。
IT企業において資産を生み出すのはエンジニアなので、エンジニアの集中力を最高の状態にするということは、生産性向上に直結します。事業を運営する上でのとても重要なことだということです。2025年の崖問題に端を発するDXが叫ばれる昨今、重要性が増していくかもしれません。

ピープルウェアを補完する生成AI活用

ここまで、壮大な文脈づくりをして参りました。簡単にまとめると以下になります。

開発現場における多くの問題は技術的な問題ではなく社会学的な問題である
エンジニアの生産性を保つにはフロー状態に入りやすい環境が必要
エンジニアの生産性は企業のバランスシート上も重要なファクターになってくる

では、私たちはいつまでも社会学的な人間力みたいなもので乗り切っていくしかないのでしょうか。
私は、生成AIの活用がこの課題を解決する糸口になると考えています。

私たちは技術的ではなく、エンジニアを取り巻く社会学的な課題を解決するために、ソフトウェアではなくピープルウェアを補完するために生成AIを利用する取り組みを行っております。具体的には、知識を属AI化させ、人のフロー状態を阻害するような情報収集・問い合わせを極力減らすために生成AIを用います。

DevOpsのサイクルにおいては、OPERATE・PLAN・CODEの部分が今までも自動化されづらく、上記で挙げたような社会学的な課題が発生しやすい工程だと考えます。

OPERATE：調査・問い合わせ、障害コール
PLAN：有識者頼みの設計、情報収集のための会議
CODE：熟練のプログラマに頼るレビュー構造

SREの一環としてトイル*4を自動化するように、システム開発の現場における社会学的トイルを生成AIアプリでサポートしていくというアプローチです。

①OPERATE with 生成AI

ここでは、ユーザから問い合わせがあった場合の問い合わせ回答フローを例にあげます。
これにより、エンジニアを問い合わせ起点の割り込みタスクから防御し、問い合わせへの回答速度向上にも寄与します。

システムの仕様に関するドキュメントは事前にデータストアとして構築。
調査・問い合わせがOps担当にくる。なかなかユーザは言語化しづらいので、画面キャプチャなどを受領することを基本とし、DLP^*による個人情報のマスク処理をかける。
個人情報がマスクされたテキスト・画像データを取得。
Agent Builderに対して、テキストベース・画像ベースの質問を行う。
Agent Builderから質問に合わせて回答をもらう。

（補足）

DLP（Data Loss Prevention）: データ漏洩や不正な情報の流出を防止するためのセキュリティ対策技術やポリシーのこと。
Ops担当者が Google Cloud Storage バケットにアップロードとしていますが、実運用上はサードパーティの製品(JIRAなど)やGoogle Forms / Appsheetなどと接続することになるかと思います。
DLPによるPII（個人識別用情報：Personally Identifiable Information）のマスクはアプリケーションの特性に応じて検出器の調整が必要になります。
Agent Builderには複数のUIがあり、Ops担当者の取り扱うケースに応じて検索エンジンのような体験がよいのか、チャットベースのUIがよいのかは検討が必要です。

②PLAN / CODE with 生成AI

次に、開発する際の設計やコーディング時に生成AIを活用する例を紹介します。これにより、

有識者頼みの設計・情報収集のための会議を削減
マイクロサービスごとの文脈ができてしまうが、それを学ぶことの認知負荷も高まっているため、マイクロサービスごとの良さを生かすために、使うことができます。

主にGeminiをフル活用していくことになりますが、開発の規模、PLANからCODEへのシームレス具合（AgileとWFの違いとか）、セキュリティレベルに応じて準備しておく環境は異なると思います。

ポイント

WFでアーキテクト・SEが設計をする際に、既存のソースコードと見比べつつ、ベストプラクティスを参考に最適解を模索していくという、少し壁打ち相手が必要なシーンでは、Vertex AIでGeminiとのマルチターンなコードチャットが有効でしょう。
AgileにPLANからCODEへシームレスに移行していくことが可能であれば、Cloud Code + Gemini Code Assistでアジリティを高めにいくことが良いでしょう。
セキュアな環境・統制が求められ、かつ大規模・ミッションクリティカル・マイクロサービスレベルで分離可能なプロダクト開発を行う場合、Cloud Workstationsを用いてセキュアでコントローラブルな開発環境を構築し、その中でCloud Code + Gemini Code Assistを用いて開発することが生産性と統制レベルのバランスをとる解の一つになるでしょう。

忘れてはいけないのは、作って終わりではないということです。

例えばリリースポイントに対して並行プロジェクトが開発をしているかもしれませんし、そのリリースポイント全体での総合的なテスト、受け入れテストが発生するかもしれません。また、Opsへ引き継ぐ際に説明可能な状態で設計思想・仕様書などのドキュメントを作る必要があります。そのドキュメントが「OPERATE with 生成AI」で登場したドキュメントとして運用のベースになるからです。

まとめ

今回は、ハードウェア、ソフトウェア、ピープルウェアという、ソフトウェアの開発現場における3つの側面のうちピープルウェアに注目しました。
そして、この生成AI時代に、ソフトウェアエンジニアを取り巻く社会学的問題、とりわけ、エンジニアの生産性を阻害する要因に着目し、その属人性を生成AI活用によって属AI化していく取り組みを紹介しました。

生成AIはもちろん、新しい技術には常に倫理観が求められ、悪い結果にならないよう技術自体と技術の意義について常日頃キャッチアップしていくことが重要だと思います。

生成AIも使い方次第で攻撃的な道具もなりうるし、技術的ラエトライルなのかもしれません。
ぜひ、一緒に未来で答え合わせしましょう。