1人チームで悩む新人。「この作業って意味あるの？」：システム開発プロジェクトの現場から（18）（2/3 ページ）

[檜山亜紗美，アクセンチュア・テクノロジー・ソリューションズ]

1人チームでの奮闘

　このチームでの最初の仕事は、窓際への席替え。先輩に「早めの窓際族」とからかわれながら初仕事を終え、まずはチームの目的を把握すべく、「マネジャー」に聞き込みを。体制図ではわが離れ小島は、薄い線で1カ所だけ大陸とつながっていて、その大陸のマネジャーが私の上司になったのでした。

*＠ITでは通常「マネージャ」と表記しますが、「マネジャー」はアクセンチュア・テクノロジー・ソリューションズでの役職名なので、本記事では「マネジャー」と表記しています。

　マネジャーいわく、「システムがあるべき動きをしているか」「日々のプログラム改修によって、関係のない他プログラムの処理に不具合が発生（＝デグレ、Degrade）していないか」を監視する自動テストツールを導入・運用してほしいとのこと。

　導入するテストツールの選定はすでに終わっていたため、私はツールで監視するに当たって必要な、システム独自の情報を集め始めました。

　設計書でクリティカルパスを確認したり、各サブシステム担当者から監視ポイントをヒアリングしたり……。巨大なものに見えていたシステムの全体像や重要ポイントがどんどんつかめてくるにつれ、その輪郭がはっきりとしてくるのを感じ、すっきりそう快な気分でした。

　そして、集めた情報をツールに反映する作業を開始。ここからは、数々のプロジェクトへツール関連のアドバイスやサポートを行ってきた社内組織に助けてもらいつつ行いました。その社内組織というのが、現在の私が所属しているStrategic Delivery Office（以降、SDO）でした。

　どうすればうまく運用できるか、こうしないとツールが定着しないなど、多くのアドバイスを受け、ほぼ予定どおりに作業を終えることができました。このころから、SDOにはどんなノウハウや事例があるのだろう、事例を次に生かしていく仕事って有意義だな、楽しそうだな、参画してみたいな、とぼんやりと思っていました。

疎外感に悩む、1人チームの新人エンジニア

　かくして無事導入されたツール。実際にツールが動きだし、日次バッチで障害やデグレを検知し始めたときは、システム全体の品質を保つという大役（と少なくとも私は思っていた）を1人任されたうれしさをかみしめていました。

　しかし一方で、すでに多くの案件を抱え、連日仕事が山積みのアプリケーションチームへの障害検知の報告が続くと、なんだか心苦しさを感じてきました。チーム単位での役割を果たしているとはいえ、自分がまるで、ただ文句をいうだけのクレーマー的存在に思えてきたのです。そして、プロジェクトにあまり貢献（参画）できていないような疎外感に悩み始めました。

　初めはうれしかった1人チームが、だんだんつらくなっていきました。

　大きなプロジェクトにいるのに、1人チーム。しかも、文句いうだけで何もしていないじゃないか、と。

協力会社のAさん参画。もう1人チームじゃない！

　そんなある日、

　「彼、今日から同じチーム。よろしく！」

と、マネジャーから協力会社のAさんを紹介するひと言が。

　人が増えるということは、なんだ、やっぱり大切な役割のチームなんだ！ 何にもできてないわけじゃないんだ！

と、心の中で密かにテンションを盛り返しました。

　かくして、やっと声を大にしてチームと呼べる規模になったわが小島では、Aさんはテストツールを引き継ぎ、品質管理の精度を高めるべく新たな監視ポイントの追加作業を。私はAさんの成果物のレビューをしつつ、カバレッジ測定やバグの分類・検知率の算出をという形で、活動をさらに活発化していきました。

　あれ、なんだかんだいって、小さいチームはいろいろ経験できて楽しい。私は再びホクホクし始めました。

　そして、「数字をいかに見せるか・駆使するか」という領域に触れたとき、いよいよコレは創造的で面白い！ と、私のテンションは最高潮に達したのです。