私が勤めだした頃の情報システム部門は非常に小さな組織で、ミッションも漠然としており（というか、当時は右も左もわからなかったのでそこはちゃんと上司が明確なミッションを持って取り組んでいたかと思いますが）、ただひたすらにシステム開発というのに専念できる組織でした。
そこには小さな組織ながら、エンジニアとしての仕事の楽しみというものを感じられる環境でしたし、組織自体もエンジニアを育てていこうという目的を感じられる場所でした。
時は流れて、現在は当時に比べたら非常に大きな組織となっていて、与えられるミッションも厳密になってきており、何よりも不景気のあおりもあってか情報システム部門の運営に関わる大きなコストというものに、会社としても懸念を示すようになっています。
こういった状況だと人を育てることさえもなかなか難しい環境となります。
エンジニアの端くれとして仕事をしている自分にとっては、こういった環境で仕事をするエンジニアの立場というのは憂慮すべきことだと感じたりします。
情報システム部門におけるエンジニアの立ち位置
組織が小さな頃というのは非常に多くの内製のプロジェクトをこなしており、自分たちの能力がそのプロジェクトに直結するような仕事が中心でした。
しかし、変革のスピードが求められたりそもそも自分たちに無いノウハウを導入するためには、外注してSIerへ委託するなど、外部のリソースを利用することが多くあったりします。
これは、企業内のIT活用が促進され、業務との結びつきが必然となったりと時代の変革により、エンジニア自体の業務形態も変わっていたことも理由としてあるかと思います。
しかし、こうした業務形態の変化により情報システム部門としてのエンジニアの立ち位置や役割というものも大きく変わってきたりしています。
外部のリソースを活用することが中心になってくると、どうしても情報システム部内でやっていく業務といえば要件定義や外部設計など上流工程が中心になってきます。
それはエンジニアの仕事ではないとは言いませんが、本来システムの動作や仕様について事細かに把握するためには実際にそのシステムを作り運用していくというのが一番だと思いますが、そういった業務を経験するメンバーが減ってくると、エンジニアとしての基礎能力というのは低下の一途を辿っていきます。
ひいては情報システム部門自体のエンジニアとしてのスキル能力も低下することになってしまいます。
で、こういったことをいうと大抵お偉い方は「もっと頭を使うより高度な仕事をやって欲しい」と言ってきたりもするのですが、あまりその高度な仕事をするコンサルタントのような人は周りで見かけたことは無かったりもして、より懐疑的にもなったり。
そもそもエンジニアの数倍もする単価でそういった人を雇い入れては、プロジェクトを掘り起こし計画化しては断念しての繰り返しをしていたりするのを横目で見てて、こんな仕事をすればよいのか！なんて思えるはずもなかったり。
閑話休題。
要は今やエンジニアのエンジニアとしての仕事というものをこなしつつも、組織としてのニーズを満たすための能力も身に着けていかなくてはなりません。
昔は、技術だけを中心において注力できた仕事が、うまく立ち振る舞うための様々な角度の能力が必要になってきたりしていると思います。
それが、ある程度の経験を経てのことであれば当然よいかと思いますが、入社間もないエンジニアにも同様の事が求められていくと基礎能力が定着する前に変に上辺だけの知識を持った人しか育てられなくなってきますし、何よりもエンジニア自身のキャリアパスも描けません。
イニシャルコストより気になるランニングコスト
内製化が好まれなくなったのはそのスピード感やノウハウ以外に、運用フェーズでのランニングコストの大きさが気になるからというのもあったりします。
外部に委託するのと同等の能力が社内にあると仮定すれば、イニシャルコストだけで見れば内製化をした方が断然安く抑えられたりもします。
これは、主に人件費を中心に置いた場合の話ですが、その他のメリットとしてもコミュニケーションが円滑に取れ、プロジェクトの路線変更にも柔軟に対応ができ、そこで得たノウハウを定着することも出来たりするわけです。
しかし、その安いイニシャルコストよりもシステムのライフサイクルを見た場合の長期的なランニングコストを見て判断を渋られたりもします。
規模が大きくなるに比例して多くのエンジニアを雇い入れる必要がありますし、内製することによりそのエンジニアをその後も抱え込む必要があります。
これは、組織の運営コストとして大きなリスクになると捉えられたりもしますし、情報システム部門など社内の開発業務を中心におくと、仕事にも波が出るためその案件が終わった後の話がどうしても気になったりもします。
もちろん、仕事など自分たちでいくらでも生み出せたりもするわけですが、情報システム部門の場合はそれが会社として利益を生むような仕事でもなかったりするため、多くのエンジニアを抱え込むのはどうしてもマイナスの要素に見られがちです。
組織の一員になったエンジニアは、その後のキャリアを生み出せる土壌を作る必要がありますし、教育も重ねていく必要が出てくるでしょう。
そういったコストもランニングコストの中には含まれたりします。
なので、大きな案件を対応する場合にスポットでエンジニアを雇い入れたりして対応することになったりしますが、そういった人たちは社内のリソースではないため、そもそもスキルレベルが上がったりノウハウが蓄積することにはなったりしません。
運用後に大きなトラブルや改修を加える場合に、再度そういった人たちを雇ったり外注するのを見れば、果たしてランニングでも総合的に見てコストが抑えられるのかは疑問に持ったりもするのですが、そういったのは不確定な要素でもあり、明確にわかる教育コストと比較するとどうしても前者の方が選択されがちだったりもします。
人を育てる組織への提言
もちろん多くのエンジニアを雇い入れ、エンジニアの楽園を作ることがよいとは思いません。
組織としてのミッションをクリアするためのバランスを取れた要員を配置することが必要と思います。
ただ、現状ではそのバランスというものをあまり考慮せずに、少数精鋭という名の下にひどくエンジニアに負担のかかる組織であったり、効率化を勧めるあまりに頭でっかちになりIT部門というのが形骸化した組織というものも多くあるのではないでしょうか。
人を育てる組織というのは、その組織を作り運営する側の人間が明確なビジョンを打ち出していかないとなかなか進みません。
大抵のエンジニアは自分たちで何でもやりたいと思ったりもするものです。
しかし、そこにはギャップが存在しておりコストや納期を優先するあまりに上の考え方は、目の前の案件をこなすことへ偏った運営になっていたりもします。
酷い場合は、自分たちだけで出来ることなのに実行することでコストがかかることを気にするが故に何もさせないことを選択するということもあったりします。
やることが決まったことにはスピード感を持って対応したいといったりするのに矛盾が出たりしているわけです。
何でもかんでも自分たちでやることには、確かに社内のリソースが無限にあるわけではないので難しい場合もあるでしょう。
しかし、社内のエンジニアの能力を適用すべき場面というものも数多くあるはずです。
そして、組織の運用で訪れる多くのトラブルも、そういったエンジニアたちの能力に左右されたりもしており、決して人を育てるべきではないと思っているわけではないと思います。
内製を適用すべき場面というもを見極め、社内のエンジニアのピースを当てはめていくことで成長を促していくことも組織運営上必要なことかと思います。
なので、組織ミッションをクリアすることだけに傾倒した考えというのは止め、効率化だけを考慮するのではなく、エンジニアを活かしてその成長や教育の場を作り出していくことも重要になっていくでしょう。
そのミッションに優秀なエンジニアを育てることというのも片隅にでも入っているかと思いますしね。