構築、運用、保守。
社内システムの構築から保守・運用までを担当する情報システム部門において、この業務は明確なチーム編成にわけられて担当している場合があったりします。
または、担当者が決まっていたり。
で、その保守・運用をするメンバーから見れば構築をするというのは、結構うらやましい状況に感じることも。
保守・運用者の立場
ざっくりと保守業務って？といえば、構築されたシステムの改善や障害の原因解明や復旧にあたる業務で、運用業務はシステムに対するオペレーション（起動や停止、データの入力や補正など）や監視業務がそれにあたったりします。
これだけ見てもわかるように、大体は定型化されている業務だったりもしますので、目新しい作業というものがなかったりもします。
「メールシステム運用者の苦悩 」においても書いたことですが、そこに人を配置させておく必要はあるものの、それを保守・運用するだけのモチベーションを与え続けることが難しい立場であるかな、というのが自分が体験したことからも感じることだったりします。
新人に経験をつませるため、というような観点からその業務を与え、そこからのステップアップのキャリアパスを与えるのであれば良いのかもしれませんが、一般的に外部のサービスよりライフサイクルが長くなりがちな社内システムにおいては、そこに人を縛りつけ続けざるを得ない体制上の問題もあったりします。
こういった業務は、効率化するためと称してマニュアル化を推進し、「誰でも業務が行えるようにしよう！」という幻想に縛られたりもします。
確かに誰でも業務が行えるというレベルまでマニュアルを作り、保守・運用の業務に工数をかけない組織運営作りというものはできるかもしれません。
しかし、次の問題は「マニュアルがエンジニアを育てないのではなかろうか 」に書いたように、ひどくマニュアル化された保守・運用要員が育ち、応用が利かずに定型外の業務ができないという状況に陥ったりします。
定型化された保守・運用業務では、新たな技術的な要素を取り込む要素が無かったりもしますし、仕様を考えるにしてもごく一部の限られたものになったりします。
それは、今の構築されたシステムありきで考えられるところもあり、その枠を逸脱できない制約があったりもするわけです。
構築するという業務への憧れ
保守・運用業務を行うものにとっては、定型化された保守・運用というものを業務とすることで、それ以上の範囲を逸脱できない制約に縛られて仕事をしてたりします。
仕様は構築時点で決められ、保守に必要な設計書を読み、構築時点で潜在化していたバグをつぶし、すでにサービスインしたシステムへのオペレーションを淡々とこなす。
もちろん、改善案などを提出すること可能でしょうけど、大規模な改善策となると保守メンバーではなく、新たなプロジェクトとして立ち上がり、システムに改良を加えていくということもされたりします。
また、長く定型化された業務を繰り貸していると、その課題への問題意識さえもなる、という要員さえも出てきたりします。
それを繰り返すことが自分の仕事なんだ、と言い聞かせんばかりに。
そう考えると、ひどく構築をする業務に対し、華々しい世界であるかのような憧れさえも出てきます。
保守・運用というのはあまり時間に縛られることが無かったりもしますが、一方でプロジェクトに参加すると時間に追われ、客からのクレームとプレッシャーに耐えながらも仕事を進めるというような苦労もあったりします。
しかし、それでも自分たちで仕様を決めたり、作り上げたり、技術的な要素の利用判断をできたり、という喜びがあるでしょう。
自分たちでシステムの全体像を考え、取り入れる技術を選定し、客との提案折衝に臨むこともできたり。
そこには自分たちの意見を集約することができ、コントロールすることも可能な場合もあります。
エンジニアというものが、何かを作りそれを育て上げていくものとして捉えるならば、構築するという立場の業務は保守・運用を行うものと比べ、随分と華やかにみえるな、と感じるのではないでしょうか。