プログラマ時代の振り返り
システム開発のプロジェクトでは、提案段階にてすでに、スコープや工数、スケジュールがほとんど決まってしまうことが多い。なぜなら、プロジェクトがスタートしてから、これらを変更する場合には、見積し直し、技術レベルでの妥当性の検討、社内での説得、お客さんまたはお客さんの上司を含めたステークホルダーとの金額、スケジュール交渉など、提案段階と同じか、それ以上の努力が必要になる。 また一度決めたことを覆す場合には、会社の信頼にも多少の影響があるかもしれない。実際にこれらのことを考えなくてはならないプロジェクトマネージャーまたはプレセールスエンジニア、営業は大変な労力が必要になる。
私はプログラマ時代は上記のことは考えたこともなった。自分の技術力を上げることやこれから開発するシステムをどうやって動作させるかということに注力していた。普通のシステム開発プロジェクトは、工数、スケジュールともに余裕がないことも多く、プログラマは時間的余裕のない中で、設計とコーディング、テスト、サーバ管理、環境設計などをこなさなければならない。技術だけでも多方面の知識が必要になる。そんなわけで日々の勉強内容は技術にかたよっていた。技術以外の振り返り機会としては、四半期に一回行われる面談があった。ここでは技術と一旦離れ、例えば「業務を行う上で今後も継続していきたい自身の取組みや仕事をする上で周りと連携するための施策」などを聞かれたが、ここでも「バグを出さないようにデータや条件分岐を抜け漏れなくテストすること」や「チャットや対面でチームメンバーと積極的に進捗報告や仕様相談をすること」など、やはり技術に片寄った考え方をしていた。また「業務の中での問題点、失敗したことについて」は、「バグや問題があったときに、その経緯や原因の説明を長すぎず短すぎず要点をおさえて行うこと。また何か問題が起こったときに、積極的に問題解決に関わったり提案をしていくこと」を考えていた。
最近、仕事をしていくために重要なことは、想像力だと考えている。プログラマ時代に考えていた、バグがあったらすぐに簡潔に報告することは、当たり前だと思うし、もっというならバグを作り込まないことのほうが何倍も重要だ。お客さんによってはバグが発見されるたびに報告義務があるし、カットオーバー後の障害になってしまうかもしれない。プロジェクトマネージャーや営業はこれらを説明しなくつはならないため、多大な労力と精神力を使わざるを得ない。ちょっとしたバグがきっかけで、大きな労力が必要になるということをもっと心掛けるべきだったと思う。
