初めてのシステムを担当したとき、リーダーであるあなたはその構成や採用している技術、仕組みなどを新鮮に感じるはずだ。それと同時に、「自分でも担当できるだろうか」という不安の気持ちを抱くだろう。

 それでもいくらかの期間がたてば、そのシステムにも慣れてくる。システムの挙動や運用方法を掌握できるようになり、メンバーも同様に作業に慣れて、効率が上がる。リーダーとして非常に居心地がよい環境が出来上がる。

 しかし、この居心地のよい“慣れ”がとても怖い。こういう状況は、リーダーやメンバーの心のスキや怠慢を生み、重大なミスを招いたり、新たな挑戦を阻害したりする。今回はそんな状況を打開する「居心地のよい“慣れ”を壊せ」というルールを紹介しよう。

経験済みなのに手戻りが次々発生

 プロジェクトにおける居心地のよい“慣れ”は、むしろ壊した方がよい。知らず知らずのうちに考え方が保守的になり、自分やメンバーの成長を妨げるからだ。仕事への慣れが現場に蔓延すれば、過去の経験に固執してしまい、新たな変化に対応しにくい。

 筆者はかつて、そのことを強く知らされた経験がある。担当していたシステムで、ある追加開発が持ち上がったときだ。電子メールの送信機能を追加するプロジェクトだった。筆者は過去、同様の機能を別のシステムで担当したことがあり、何の問題もなくプロジェクトは進むと思っていた。

 ところが、実際にプロジェクトが始まると、試練の連続だった。対象のシステムでは、採用するパッケージソフトが以前とは異なり、単位時間当たりの処理件数は桁が違っていた。それでも「まあ過去のやり方で何とかなるだろう」とたかをくくっていたが、実際はそんなに甘くはなかった。

 要件定義を無難にこなし、設計へと進んだときだった。この段階で、電子メールの送信機能を実装するためのベースとなる機能がパッケージソフトにはないことが分かった。アーキテクチャーは複雑になるが、シェル(ユーザーの操作をOSに伝えるソフト)を組み合わせて実現せざるを得なかった。

 実装の段階に入ると、思い通りの動作をしてくれず、そのつど設計に立ち返る「手戻り」が次々発生した。続くテストでも、重要な要件だった単位時間当たりの処理件数を達成できない問題が起こった。以前経験したシステムの数倍の能力を持つサーバーを用意したにもかかわらず、性能が全く出ない。送信処理が競合し、送信メールをうまくさばけないのが原因だった。このタイミングでも当初立てた設計内容を再び見直すはめに。こうして想定していない作業が立て続けに発生したことで、プロジェクトは遅れに遅れた。

 想定外のこれらの作業だが、見方を変えれば事前調査の甘さが原因だった。根底には、なまじ経験があったために、変化に鈍感になっていたことが挙げられる。

 ユーザーからは追加費用を得られず、赤字プロジェクトとなった。その後、上司から厳しく叱責されたのはいうまでもない。このとき上司からいわれた言葉が、とても染みた。「プロジェクトで同じ技術は二度使えないと思え。そのつど自分の中の基準値を修正しろ」―。“慣れ”によって技術に対する基準値が固定化し、事前調査を怠り、新たな変化に対応できなかったのだ。当たり前の準備さえ怠らなければ、ある程度問題は防げたはずだった。

基準値を見直し変化に対応する

 読者の中には「リーダーがすべての技術を追う必要はない。そんなの技術に詳しいメンバーや専門家に任せればよい」と思う人がいるかもしれない。しかし、その場合でもリーダーは固定観念にとらわれず、常にアンテナを張り、柔軟かつ迅速に変化に対応できなければいけない。そのためには、自分の基準値を技術の変化に合わせて見直せる感覚を養わなくてはならない。

 技術は日進月歩である。最近ではクラウドサービスを使ったサーバー環境の構築や、スマートフォンを活用した業務システムの実現など、新しいサービスや技術を利用する機会が増えている。こうしたプロジェクトでは、これまでの経験やノウハウが役に立たないどころか、むしろ悪影響すら及ぼしかねない。居心地のよい“慣れ”をあえて壊し、リーダーとして新たな成長をつかむことも重要な流儀である。

大森 久永(おおもり ひさなが)
1998年に日立製作所入社。以来、銀行システムのSEとして従事。2003年から2年間、旧UFJ銀行に出向。2005年に三菱東京UFJ銀行のDay1統合プロジェクトに参加。インターネットバンキングの構築プロジェクトで、PMとして約600人のメンバーを率いた。