システム開発とシステム運用とどちらが価値を増やせるエンジニアになれる機会があるか

エンジニアが仕事、つまりプロジェクトに参画する１つの括り方として、新規又は再構築によるシステムリプレースのシステム開発をするシステムインテグレーション（以下SI）とリリース後のシステム運用、維持、改修を何うアウトソーシング（以降OS）に分けられる。

さて、エンジニアがシステムに積極的に価値を付加することができるのはSIとOSのどちらだろうか。

エンジニアが自身の技術力を向上させる機会を作れるのはどちらだろうか。

一つの見方として、こう捉えることができる。SIは契約に基づき、決められたスコープを実現するため、Tobeを実現することがプロジェクトのゴールになる。プロジェクトの成功は契約に書かれた（若しくは提案された）要件が実現できることである。最初から１を実現することが求められる。

アジャイル開発はどうだろうか。最小のコストで必要なものだけを提供する。契約上は、固定幅のワークロードが準委任契約、若しくはタイム＆マテリアルでなされるだろう。実現したいことがゴールだとしたら（不確かなゴールにアプローチするたの手法なのだから契約の範囲で委託元の要求を実現するという意味ではそれはスコープかもしれない）やはり期待される１を実現すると言っても良いのではないか（思いつきなので間違いがあるかもしれない）。

OSはどうだろうか。

システムが実運用に移り、利用され、価値を発揮するようになってもリリースされた価値はいつまでも１なのだろうか。パッケージやOSの修正プログラムなど、システムが期待するシステム運行を行えるようにメンテナンスすることは１の価値をキープするために行われる。

予算が確保されていれば、機能改善が行われることもある。こともあるというのは、一度作ったら釣った魚に餌をやらぬ主もいるからである。

OSにおける機能改善では価値は増えるのだろうか。使ってみて初めてわかる価値の過不足がある。それを現場で間近で知ることができるのはOSのエンジニアである。ただ、機能に対する価値の過不足が委託元からあれこれ言われているようでは、システムの価値は把握できていないのと同じではないか。

OSのエンジニアは実際に使われているシステムの価値を第三者の目で、専門家の目で評価する機会に恵まれている。

つまり、顧客が望む、価値のあるITを提案できる立場にある。

システム運行が安定していれば、計画的な作業が年間を通して組み立てられる（4四半期も先になればザックリ感しかないが）。システムが価値を発揮している間に次期システムに適用する候補技術の習得や実現手法を学ぶ時間がSIより作りやすい。

SIではそうした大局的な立ち位置で物事を考えるにはスピードが早すぎ、余裕もない。

ただ、OSでやりがちなのは受け身になってしまうことである。これが体制的に染み付くとパフォーマンスが出ないエンジニア集団になってしまうので日々の運用に少しずつ新しい技術要素なり、手法を取り入れる組織の文化が必要となる。これはマネージャの仕事である。

さて、OSこそ、価値を増やせるという考え方はどうだろうか。