開発現場は日々の仕事の場であるとともに、学びの場でもある。先輩エンジニアが過去に直面した困難の数々、そこから学んだスキルや考え方を紹介する。
檜山です。今回は、私の「運命の出会い」をご紹介します。
プロジェクトでは、自分とは違う視点や考えを持っている方々と出会い、一緒になって1つのゴールを目指します。その中で、他者との違いから多くの気付きが得られることも、プロジェクトの良いところだと思います。
いま、私がそう思うのは、この出会いがあったからかもしれません。
アプリケーションは、たいてい領域別に「縦割り」にして開発しますが、この全領域にかかる「横断的な」技術がアーキテクチャです。どのアプリケーションからも参照されるシステムの基幹部分です。
このアーキテクチャを請け負うアーキチームで、私は出会ったのです。あの方々と。
前回「1人チームで悩む新人。『この作業って意味あるの?』」で紹介したテストツールの運用が軌道に乗り、システム品質も安定しだしたころ、カットオーバーに向けてデータの整合性をチェックする仕組みづくりを任されました。
データの整合性チェックとは、
[正] 手続きAを完了して、手続きBに移ったデータX
[誤] 手続きBにいるのに手続きAを完了した形跡がないデータY
このケースでのデータYの存在をチェックすることです。これも、システムの品質担保をするうえで大切な仕事です。
この整合性チェック機能開発の話がきたとき、私は、
品質管理チーム(=私):整合性を担保しなくてはならないポイントの洗い出し
アーキチーム:洗い出したポイントをチェックするシステムの作り込みと組み込み
という役割分担かな、と思いました。
けれど実際、作業開始前のミーティングに出てみるとあまり作業に境目がなく、「ゆくゆくはアーキチームの一員になるのかも」とぼんやりと感じました。
さらにこのミーティングでは、アーキチーム、リードのMさん(年齢的には私の2歳上)が、「すでに出来上がりのイメージをしっかり持っていた」ことに驚きました。
Mさんがイメージと背景をしっかり教えてくれたおかげで、私もしっかりしたイメージを持って、チェックポイントの洗い出し作業に取り掛かることとなりました。
こうしてイメージを持って作業して良かったなと思う点は、作業中に質問や疑問が出てきても、最終形から逆算して自分で答えが出せたことです。
「自分の作業が全体にどうかかわるか、ということを意識して仕事しないと一人前になれない」と思ったのもこのときです。
作業自体は以前行ったテストツール導入時のチェックポイントの洗い出し作業と似ていたので、ER図や設計書、アプリチームへのヒアリングを駆使することで、無事完了。
作業完了と同時に、アーキチームへ異動。そのまま私も実装メンバーとなったのです。
1年もしないうちに3チーム目を迎える新人は私以外におらず、「なぜ……」と少し気がかりではあったものの、そのころには上司のMさんがあこがれの存在になりつつあったので、一緒にこのまま仕事ができるんだなぁ、とうれしく思っていました。
Copyright © ITmedia, Inc. All Rights Reserved.