The Dragon Scroll

Be just and fear not.

ふりかえり〜(14)プロジェクト管理屋

私の思いとして、案件の丸投げはやりたくありませんでした。
要件定義から設計〜製造工程以降もきっちりとおさえる。
そうでなければ、SEとしての楽しみがありません。
スキルや経験を積む機会をみすみす、逃すことになります。
丸投げをした場合、SEはプロジェクト管理屋にすぎなくなります。


しかし、会社は、営業的な動きをSEにも求めていました。
案件獲得、提案活動という営業的な動きと、
設計工程におけるSE的な動きと、
プロジェクトの管理というPL的な動きと。
私は、段々と目の回るような忙しさに陥り始めました。


その上、あるPJへの支援要請が入りました。
そのPJの主導権は、昔から開発を担当している協力会社さんにありました。
我々側には、ノウハウの蓄積がなく、業務仕様もそもそも専門的
すぎて全くわかりません。
呆然となりました。
打ち合わせに参加しても、電柱にようにそこにいるだけ。
当然、顧客からは、「何しに来てんだこいつ」という冷たい視線が
送られます。
視線だけでなく、PLは、顧客と協力会社と、自社の3社間で板ばさみに
なり、間もなくふらふらになっていきます。


このまま、訳が分からないまま、PJが終わるのを待つのも
余計な苦労をしない分済むかもしれません(責任はPLが取るし…)。
しかしながら、それは、エンジニアとして、少なくとも私にとっては
耐え難いものでした。


データ構造・データフローをおさえるところから始めました。
機能は、山のようにあります。しかしながら、データが持つ意味
をおさえられれば、そこからシステムや業務を理解する突破口となります。


これが、PJの最終盤に起きたデータ移行上の問題、パフォーマンス問題で
役に立ちました。
鬱病になってはいけませんが、困難に対し、「逃げない」粘りは
エンジニアにとって当然必要であり、その方が「逃げる」ことより、
得てして良い結果を生むと、私は信じています。