今ではAIがプログラムを書いてくれる時代になった。
コードを書く速さは、昔とは比べものにならない。
しかし、システム開発のプロジェクトが炎上したとき、AIがプログラムを書いてくれるだけで、その混乱を収めることができるだろうか？
私は、そう簡単ではないと思っている。
もうずいぶん前、まだソフト会社に勤めていた頃、炎上た大きなプロジェクトに、途中から一人のSEとして派遣された。しかも外部スタッフである。
プロジェクト全体では数億円規模、端末は150台、1000人以上が働く組織のシステムだった。どこの、どんなシステムだったのかは、ここでは書けない。
このプロジェクトは最終的に立て直すことができ、そのシステムは今も運用されている。
当時を振り返って印象に残っているのは、技術的な問題解決だけではない。PMがどのように判断し、メンバーに何を伝え、チームを一つにしていったのかということだ。
炎上しかけた現場に現れた3人
システムはすでに本稼働を迎えていたが、いつ止まってもおかしくない状態だった。
現場は4人ほどの小さなチームで対応しており、私の最初の仕事は、ある人が書いたプログラムの修正だった。まず何をしているのか、そのプログラムを読み解くところから始まった。
そこへ、メインベンダーの本社から2人のPM（プロジェクトマネージャー）と1人のリーダーがやってきた。年齢は私と同じくらい。
3人とも上質なスーツをびしっと着こなしていて、とにかくかっこよかった。今でもその姿を覚えている。
ここから、本格的な火消しが始まった。
第1部 PMの覚悟
最初に行ったのは、記者会見のようなプレゼン
3人が最初に行ったのは、プログラムの修正でも、メンバーへの作業指示でもなかった。
関係者の前に立ち、現在の状況と今後の計画を説明したのだ。
まるで記者会見のようだった。何が問題なのか。これから何をするのか。どのように立て直していくのか。
堂々とした、説得力のあるプレゼンテーションだった。
聞いている側が「この人たちなら何とかしてくれるかもしれない」と思えるような内容だった。
炎上したプロジェクトでは、現場だけでなく、お客様も経営者も不安を抱えている。その不安の大きな原因は、何が起きていて、この先どうなるのか分からないことだ。
だからこそ、責任者が関係者の前に立ち、現状と方針を説明することには大きな意味がある。
火消しは、技術的な問題を解決するだけでなく、関係者の信頼を取り戻すことから始まる。
当時のPMたちの姿から、そう学んだ。
人を投入しても、すぐに作業を始めない
次に行われたのは、必要なメンバーの投入と現状の整理だった。
PMは、ある期間に必要な人員を投入する計画を立てた。しかし、集まったメンバーがすぐにプログラムの修正を始めたわけではない。
最初の2週間ほどは、現状調査と課題の洗い出しに使ったのだ。
ブレーンストーミングを繰り返し、何が問題なのかを徹底的に出し合った。そして、問題を整理したうえで、スケジュールと実行計画を立てていった。
私は、こうした場には、ある程度饒舌な人がいたほうがよいと思っている。
立場や担当に遠慮せず、疑問に思ったことや気づいたことを口にできる人が必要だからだ。
問題があっても、誰も口にしなければ、その問題は表に出てこない。
私自身、頼まれもしないのに意見を言っていた。すると、プロジェクトの火消しメンバーに加えてもらえたのだ。
炎上しているときほど、すぐに手を動かしたくなる。
しかし、何が問題なのか分からないまま作業を進めても、別の問題を生み出すかもしれない。
まず全体を把握し、問題を整理してから行動する。
これは、私が今取り組んでいるWITS整理法の「行動前にデザインすべし」という考え方にも通じている。
もちろん、どんなプロジェクトでも2週間調査すればよいということではない。重要なのは、闇雲に作業を始める前に、問題の全体像と優先順位を明らかにすることだ。
PMを信じて任せた経営者の度量
もう一つ、忘れてはいけないことがある。
それは、PMを信じて人員の投入を決断した経営者の存在だ。
すでに大きな問題を抱えたプロジェクトに、さらに人とお金を投入する。これは簡単な判断ではない。
しかも、投入した人員をすぐにプログラム修正へ向かわせるのではなく、まず現状調査と課題整理に使うのだ。
目の前で問題が起きているときに、その判断を受け入れるのは勇気がいることだったと思う。
しかし、PMが責任を持って計画を立てても、必要な人員や時間が与えられなければ、立て直しは進まない。
PMには責任を引き受ける覚悟が必要だが、経営者にも、任せると決めた人を信じて支える覚悟が必要だ。
お客様との難しい交渉を引き受ける
火消しの最中には、お客様側のPMと開発側のPMとの間で、難しい交渉も行われていた。
ときには喧嘩腰になりながらも、互いに譲れないところを主張し、決めるべきことを決めていく。
私たちメンバーには、そのすべてが見えていたわけではない。
しかし、PMたちが表に立って交渉を進めているからこそ、メンバーは自分たちの作業に集中できた。
システム開発では、仕様や作業範囲、スケジュールなど、関係者の利害がぶつかることがある。
そうしたときに判断を先送りしたり、現場のメンバーに交渉を任せきりにしたりしていては、問題はなかなか解決しない。
必要な判断を行い、ときには相手とぶつかりながらも話を前に進める。
PMの覚悟とは、単に責任を取ると宣言することではなく、難しい場面から逃げずに、自分が矢面に立つことなのだと思う。
力量の分からないモニタリングをしながらメンバーに任せる
私自身、このプロジェクトで忘れられない経験がある。
最初は、他の人が書いたプログラムを読み解き、修正する仕事をしていた。
その中で気づいた問題点をPowerPointにまとめ、何が問題なのか、自分なりに整理して指摘した。
そして最終的には、メインのプログラムを私に任せてくれたのだ。
私は炎上後に参加した一人のスタッフにすぎない。PMたちにとって、私がどの程度の力量を持っているのか、まだ十分には分からなかったはずだ。
それにもかかわらず、重要なプログラムを任せてくれた。
これは本当にすごいことだと思った。
経験や実績が十分に分からない相手に、重要な仕事を任せるのは簡単ではない。
ただ、問題点を整理して自分の意見を伝えることと、その相手を信じて仕事を任せること。この両方があったからこそ、私は重要な仕事に取り組む機会を得られた。
もちろん、任せることと、丸投げすることは違う。
PMには、任せる相手を見極め、仕事を進められる環境をつくる責任がある。
しかし、どれだけ慎重に判断しても、最後には人を信じて任せる決断が必要になる。
PMの覚悟とは、自分が矢面に立つことだけではなく、メンバーを信じて重要な仕事を託すことでもある。
あのとき任せてもらった経験は、今でも強く心に残っている。
第2部 メンバー全体の連帯感
「俺らはプログラムを作っているんじゃない」
当時のPMたちは、日々いろいろな名言を放っていた。
その中でも、今でも忘れられない言葉がある。
「俺らはプログラムを作っているんじゃない。システムを作っているんだ。」
この言葉は、私の中に強く残っている。
一本一本のプログラムが正しく動くことと、システム全体が正しく動くことは違う。
それぞれのプログラムが正常でも、データのつながりや処理の流れに問題があれば、システムとしては機能しない。
さらに、システムが動いても、それを使う人たちの仕事が回らなければ意味がない。
担当するプログラムだけを見ていると、どうしても全体の目的を見失いがちだ。
この言葉は、メンバー全員に、自分たちが何のために仕事をしているのかを思い出させてくれた。
AIがプログラムを速く作れる今だからこそ、改めて考えたい言葉だ。
私たちが目指すのは、プログラムを完成させることではなく、システム全体が正しく動き、仕事が回る状態を実現することなのだ。
毎日の情報共有と、一緒に過ごした時間
プロジェクトでは、夕方になると毎日ミーティングを行い、その日の作業内容や問題点を共有していた。
誰が何をしているのか、どこで問題が起きているのか、翌日は何をするのか。
日々の情報共有によって、メンバー全員が状況を把握できるようになっていた。
そして、仕事が終われば一緒に夕食を食べ、休日にはボーリングに行き、花見もした。
正直に言うと、今いちばん覚えているのは、みんなで遊びに行ったことかもしれない。
チームは大阪弁の人がほとんどだった。
中には、旅行中に呼び戻され、「1日だけ」のつもりで応援に来た人もいた。
ところが、結局そのままプロジェクトのメンバーになり、大阪弁までうつって「エセ関西人」と呼ばれるムードメーカーになっていた。
やはり関西は、ギャグあってのノリである。
一見すると、仕事とは関係のない話のように思えるかもしれない。
しかし、こうした時間を一緒に過ごしたことで、メンバー同士の距離が縮まり、遠慮なく話せる雰囲気が生まれていたように思う。
もちろん、一緒に食事をしたり遊びに行ったりすることが、チームづくりの必須条件ではない。
重要なのは、互いのことを知り、困ったときには相談でき、問題が起きたときには率直に意見を言い合える関係をつくることだ。
連帯感は、単に仲がよいということではない。同じ目標を理解し、困難な状況でも互いに協力できる関係があることだと思う。
出来る人が、できることをする
このプロジェクトで、もう一つ印象に残っているのが「出来る人が、できることをする」という考え方だ。
年齢や立場、経験年数に関係なく、それぞれが得意なことを生かし、足りないところは互いに補い合っていた。
私は、プログラム開発の経験がないメンバーに、開発とはそもそも何なのかというところから教えた。
この人ならきっと伸びるだろうと思い、知っていることをいろいろ伝えた。
その人は今、その組織で部長をしている。
一方で、私自身も教わる立場だった。
データベースのチューニングでは、私より8歳ほど年下の若い専門家に教えてもらいながら作業を進めた。
年齢が上だから知っているとは限らない。経験が長いから、すべてに詳しいわけでもない。
できる人が担当し、分からないことは知っている人に教わる。
そうした関係が、自然にできていた。
「出来る人が、できることをする」
当たり前のように聞こえるが、実際の組織では、役職や担当範囲にとらわれて、なかなか実践できないこともある。
チームの力とは、全員が同じことをできるようになることではない。それぞれの持つ力を生かし、互いに支え合いながら、一つの目標に向かって動くことなのだと思う。
感覚ではなく、数字で改善を確認する
当時、システムの速度改善で中心となったのは、SQLの書き方だった。
一つひとつの処理をモニタリングし、セオリーに沿って改善していった。
実行時間は秒単位で計測した。
実は、私が時計を買うときに、秒針のある時計を必ず選ぶのは、この経験からだ。
「何となく速くなった気がする」では、改善したとは言えない。
修正前に何秒かかっていたのか。修正後に何秒になったのか。
数字で確認して、初めて改善したことが分かる。
今であれば、応答時間やエラー件数、処理件数などをKPIとして設定し、改善状況を継続して確認することもできる。
これは、以前書いた鉄工所の原価管理の記事にも通じる。
儲かっていると思っていた取引先が、実際に原価を計算すると赤字だった。感覚だけでは見えなかった問題が、数字によって明らかになった。
改善は、実施することが目的ではない。何がどれだけ良くなったのかを、事実で確認することが大切だ。
テストと稼働は、舞台のようにシナリオで進める
テストの進め方も印象に残っている。
テストシナリオを事前にしっかり作り込み、そのシナリオに沿って確認していった。
稼働前日、プログラムを配信した後のテストでも、あらかじめシナリオを用意した。メインシステムを担当する人が記載し、その後、各担当者が必要事項を記載していく。
何分でオペレーションを行い、何分で結果を確認するのか。そこまで決めて進めていたのだ。
まるで、台本を用意して舞台を演じるかのようだった。
本番になってから「次は何をするのか」「誰が確認するのか」と相談していては、時間ばかりが過ぎてしまう。
事前に手順と役割、所要時間、確認方法を決めておくことで、関係者が迷わず動けるようになる。
もちろん、シナリオどおりに進まないことも想定しなければならない。想定外の問題が起きたとき、誰が判断するのかも重要だ。
そして、無事に稼働したからといって終わりではない。
稼働後も毎日のミーティングは続いた。
システムは作って終わりではなく、安定して使えるようになって初めて、その役割を果たす。
こうした一つひとつの取り組みを積み重ね、プロジェクトは無事に立て直された。
そして、そのシステムは今も運用されている。
炎上プロジェクトを立て直すために確認したいこと
ここまでの経験を、今のプロジェクトにも生かせるように整理してみる。
炎上しているプロジェクトだけでなく、これから大規模なシステム導入を予定している場合にも、確認しておきたいことだ。
PMと経営者の覚悟
- PMが関係者の前に立ち、現状と今後の方針を説明しているか
- 作業を急ぐ前に、問題の全体像と優先順位を整理しているか
- 立場に関係なく、問題点を率直に指摘できる場があるか
- PMが顧客との交渉や必要な判断を引き受けているか
- 経営者がPMを信じ、必要な人員と時間を確保しているか
- PMがメンバーの考えや行動を見て、重要な仕事を任せられているか
メンバーの連帯感と実行力
- メンバー全員が、何を実現するためのプロジェクトなのかを理解しているか
- 毎日、進捗や問題を共有する仕組みがあるか
- 困ったときに相談でき、互いに教え合える関係があるか
- 改善の効果を数値で把握し、KPIとして確認できているか
- テストや稼働の手順、役割、時間が明確になっているか
- 本番稼働後も、問題を確認して改善を続ける体制があるか
すべてにチェックが入ることが目的ではない。
大切なのは、チェックが入らない項目について、なぜできていないのかを考え、次に何をするかを決めることだ。
AI時代でも変わらないこと
AIの進歩によって、プログラムを作る仕事は大きく変わってきた。
当時、私たちが時間をかけて読み解いたプログラムも、今ならAIが解析を手伝ってくれるだろう。SQLの改善案を出したり、テストケースを考えたりすることもできる。
しかし、炎上したプロジェクトで最初に関係者の前に立ち、現状を説明して信頼を取り戻すこと。
問題を整理し、何を優先するか決めること。
お客様との難しい交渉を引き受けること。
そして、まだ力量の分からないメンバーを信じて、重要な仕事を任せること。
これらは、AIが支援できても、最終的には人が判断し、責任を持たなければならないことだ。
振り返ってみると、あのプロジェクトには、いくつもの信頼関係があった。
経営者はPMを信じて任せた。PMはメンバーを信じて仕事を任せた。そしてメンバー同士も、互いに教え合い、支え合いながら仕事を進めた。
その根底には、お客様との信頼関係を取り戻し、システムを安定して使えるようにするという共通の目標があった。
プロジェクトの火消しに重要なのは、PMの覚悟とメンバー全体の連帯感。そして、それを支える相互の信頼関係なのだと思う。
これは、現在、中小企業の業務整理やシステム活用の支援に関わる中でも、大切にしている考え方だ。
最後に、少しだけ個人的なことを書いておきたい。
当時は毎日ドキドキしながら仕事をしていた。それでも、私自身は、このプロジェクトがとても楽しかった。
優れたPMに出会い、重要な仕事を任せてもらい、仲間と教え合い、ときには一緒に遊びながら、一つの目標に向かって仕事をした。
あの頃、一緒に過ごした人たちのことは、今でも忘れられない。
お金をもらいながら、こんな貴重な経験をさせてもらえたことは、何という幸せだったのだろうか。
コメント