TOUCH THE SECURITY Powered by Security Service G

コラム

2019.08.29

エンジニアの失敗学 ~その2 ドキュメントを書くということ~

弊社インフラチームを牽引するベテランエンジニアが、敢えて過去の失敗談を語る「エンジニアの失敗学」シリーズ2回目。失敗は成功のもとと言いますが、皆さまの清く正しいエンジニアライフの為にも、教訓として是非ご一読くださいませ。

1.実績と評価のギャップ

ある会社のWindows NT4.0からXPへの更新プロジェクトで、マスター設計から展開までを主担当としてやらせてもらった時の事。

お客様やベンダとの交渉にはじまり、(今の目で見ればまだまだ稚拙ではあったが)当時におけるXPの新しい思想や経験に基づく対策をふんだんに盛り込んだ設計を実現するなど、プロジェクトはそれなりに成功した。

30歳になるかならないかの年頃で、かなり大きなことを主体的にやらせてもらったこともあり、人の心理として考えれば有頂天になるのも…ある意味当然か。

しかし、プロジェクトの成功とそれを実現するための技術力は評価してもらったものの、自分の思っている評価との間に「コレだけやったのにこの評価?」というギャップがあることには何となく引っかかっていた。

2.おろそかにしていたこと、マイナス評価の理由

実はこのプロジェクトで私はドキュメントの作成をほとんどやれていない。とにかく発生した事象に対して解決策を見つけ出し、解決して設計に反映させた時点で終了。そういったスタンスで仕事をしていたのだ。当時はそういった場当たり的な前進が許された雰囲気もあって、そういう体質に自身も依存しきっていたと思われる。

上司も「技術面ではこいつにやらせるしかない」という想いの反面、「このままでは何も残せない」という危惧もあり、私が対応した際のメールや手順メモ、誰かが再現できるレベルの資料を、私に片っ端から提出させて、第三者がドキュメント化している有様だった。

3.上司から課せられたこと

このプロジェクトが一旦終結し、その会社の運用業務に配属替えとなった際に、上司からこんな課題を与えられた。

  • 人に何かを伝え、自分以外の人にやらせて、全体のクオリティを底上げすること
  • アウトプットを残し、次世代につなげる体制を作ること

「これらができなければ、いずれどこかで失格の烙印を押されて中途半端になってしまう。」「より先のステップに行ってもらうためには、ここを是が非でも改善させなければもったいない。」恐らくそういった想いもあったのだろう。しかし当時の私は血気盛んで、その裏にある意味までは読み取れていなかった。

そして後の実体験 ―― 私と他メンバー、それぞれの仕事におけるクオリティのバラつきについて、お客様より指摘される ―― を通じ、技術レベルに関する底上げの必要性を肌身で感じ、改善に取り組むことに。

4.苦にならなくなったきっかけ

とにかく「まずは書き、更新すること」を意識して実践。これを1~2年続けていった頃だろうか。ある時依頼された技術調査で、A3用紙1枚程度のまとめが意外と好評となった。

「ドキュメント書けないと聞かされたていたけど、いいモノ書くね」

そんな声を聞くようになって、ようやく書くことが苦にならなくなり、まとめ方のコツも自分自身で会得することができた。

ある程度自身でアウトプットしながら、他者の良いドキュメントに数多く触れたことも功を奏したのではないだろうか。遠回りではあったものの、自分の身をもって経験値が得られたことに大変意義を感じていている。

アウトプットすることを意識する、自分に欠けているものの指摘を素直に受け入れる、これが失敗から学んだことだったと思ってます。

記事一覧に戻る