Views: 130
後編です
なんとかして、会社をよくしていきたい。
（そして給料が上がったらいいな）
と考えた僕はいくつかの案件でベンダーへの発注を行わずに
改修業務を社内メンバーにより実施することで、
お金をグループ内で回すようにしたらい、いいのでは
と考え、内製化に取り組んでみました。
とくに会社では内製化を推進しているわけでは無く、
自分や同じ部署の意見を総合して、内製化した方が
低コストで開発でき、メリットが多いと考えました。
では、これまで設計からテストを外注していたところを
全工程自社で担当してみるという計画でプロジェクトを
推進した結果、どうなったのでしょうか。
結論としては僕のキャリアアップ（給料アップ）という観点では失敗でした。
内製化の実績、経験、ノウハウがゼロの状態から始めるのは
案件規模が小さかろうとその難度は激烈に上がります。
やはり自前で開発するということは設計、製造、テストの
各工程の成果物の書き方、ソースの書き方のような細かいレベルから
一つ一つ決めていき、開発者を教育したうえで作業を割り振り
推進していく必要があります。
例えば設計書のテンプレート、記載ルール、記載粒度について
いちいち定める必要があります。
テンプレートや記載ルールが存在しない状況では、成果物
ひとつ満足に作ることができません。
このことがわかっておらず、僕が根拠もなくできるんじゃないか程度の考えで
初めてみた内製化案件において僕は壁にぶち当たりまくることになります。
はじめてのプロジェクトマネジメント業務であり、それだけでも未経験で
難度は高かったと思います。
さらに、誰もノウハウを持たない内製化に舵をきってしまったため、
プロジェクトの全体を満遍なくみきることができなくなりました。
結合テスト完了したが、その先のことがなにも未着手という
絶望的な状況の中、大した説明もなくプロジェクトを途中で外されました。
プロジェクト計画については役員の決済をもらった上で進めて
いるので、僕の独断で進めたわけではないのですが、
結局この案件に関しては、僕が戦犯のような扱いをうけることになりました。
この時の失敗が、この後のキャリアに響いたなと思っています。
内製化したはいいが、当時プロジェクトにいたメンバーがことごとく
転部や退職したことにより、保守のノウハウが失われてしまったことも
大変痛いです。
局所的に内製化してみたところで、日常的にアプリ改修の実務に携わっていないと
アプリ改修は行えません。
ベンダーロックインという課題に対して、個人のアイデアレベルで
部分的に手を入れたとしても、結局は失敗する可能性が高いです。
会社や上司のバックアップや運用保守や要員教育も見据えた
全体最適な計画を立てて行わないと解決しないような、大きな課題です。
思い含めて色々書きましたが、何が言いたいかというと
個人の思いのみで会社を良くしよう、変えようとは考えないようにしましょう。
会社や上司から「課題をなんとかしてほしい」というリクエストを受けた時に提案し、
関係者の理解やバックアップを万全の状況にした上でアクションをとるべきです。
感情の赴くままに動くと、しっぺ返しをくらいます。
また、会社を良くしても給料は上がらな位可能性があります。
評価者に認められて、昇格しないと給料は上がらないようになっています。
最短距離で報酬を増やしたいなら転職を検討した方が確実と思います。