華やかに始まったプロジェクトも時の流れとともに衰退し、今となってはあの時の栄光と熱意はどこに？といったチームの惨状を見ることはしばしばあります。
ユーザーに提供するサービスの場合は、そのユーザー離れにより衰退していく様を利用する立場としてよく目にしますが、社内情報システム部門のそれは構築・運用チームは存在しており、その会社のシステム基盤として維持・管理はしていかないといけないんだけど、チームとしての士気は下がりきっていてどうしようもない状況というのはより悲惨な光景かもしれません。
何でそんな状況にいたったんでしょうか？
1. 外部リソースの総動員
プロジェクトの始まりは極めて華やかだったりします。
予算が確保され、タスクフォース的にその道のプロが要員計画に組みこれます。
そこには下請けやコンサルタントなども含めて大量の外部リソースが流入してきます。
プロジェクト運営において、外部リソースを使うのはスケジュールであったり、そもそも自社にそのスキルやノウハウが無いという状況であれば外部から取り入れるというのは至極当たり前のことではあるのですが、現場のエンジニアから見たらあまり外部のリソースに頼る状況うれしいものではありません。
自分たちだけではできないのか、という信頼されていないような疑念を持ったりしますし、自分たちの畑を荒らされるのが嫌だという気分にもなってきます。
自社の文化と合わない人も来たりして、プロジェクト期間中は職場の雰囲気がだいぶ変わることもあり、ホームなのにアウェイ感が出て仕事のやりにくさを感じ出すエンジニアもいます。
特に、プロジェクトによって招き入れた人がプロジェクトマネージャやオーナーのつてだったりした場合は最悪で、職場内での立場が逆転することさえあります。
こうなってくるとますますチームや組織への不満や信頼がなくなってくるわけです。
2. 残らないスキル
プロジェクトは当然紆余曲折ありながらもゴールへと着地します。
しかし、社内情報システムの場合はここがスタートラインです。
長い長い運用フェーズの始まりです。
リリース後の1年近くはシステムが安定しなかったり、プロジェクトの制約により延期された機能の実装、ユーザー部門からのフィードバックを受けてブラッシュアップの期間が続きます。
そして、システムは安定期に入ります。
こうなってくるとプロジェクト開始当初にいた大量のリソースは当然不要になりますので、1人また1人とチームを去っていきます。
残るのはアップデートされていない大量のドキュメントと口伝によるノウハウです。
そして、その情報はますます陳腐化していきもはや誰も真実の仕様をしらないか、一部の生き残りが生きる伝説として重宝されだしたりします。
プロジェクト期間中のコアメンバーが外部リソースで塗り固められていた場合、社内にはそのスキルを持っている人がいないので、もはや末路は火を見るより明らかで触らぬ神になんとやらと言うように触れないシステムが不良資産として残るわけです。
3. 持てない愛着と誇り
不良資産を抱えたチームは当然それを保守・運用するモチベーションを見出しにくくなります。
自分が作り出したものであれば何時までも愛着によって維持できるかもしれませんが、他人が作ったものとなるとなお更かもしれません。
なんせ自分でもよくわからないシステムなわけです。
現状維持することに精一杯になっていますし、これは自分が作ったものだ！自分がこのサービスを動かしているのだ！なんて誇りを持てないわけですから、それをよりよい方向にしようなんて考えを誰も持たなくなってきます。
取りあえず動いているサービスを維持することが仕事となり、そのサービスがどう思われようと関係ない気分になってきます。
4. 存在しない危険因子
社内システムの場合、環境はなるべく安定するように意思決定されますので、ライフサイクルが長くなりがちですし、危険因子が少ないのでリスクをとるようなことを避けたりします。
なるべく動いている今の環境を活かそうとしますし、外部サービスのように別のサービスによって客を持っていかれたり食いつぶされるというリスクがありません。
これによってシステムは安定するかもしれませんが、誰もそこに作る楽しさや運営する喜びを見出すのが難しくなってきます。
「システム部を変えよう！」なんてスローガンが常套句のように毎年発表されますが、危険因子がない分、自分たちにさえ変え方がわからなかったりします。
当然社内からの圧力や不満というのは肌で感じることがあるので、変わらなきゃいけないという焦りを持つことはあるのですが、変わることでのメリットより変えることでのリスクを嫌います。
安定した環境でのエンジニアは新たに得るものが無いのでスキルを磨いたり、多少火を噴いたりしつつも収束に向かって結束して乗り切ったときの達成感を得ることがないわけです。
変化が無いところにモチベーションは見出させません。
5. 主導権を握れない
モチベーションがあがらない仕事に対して自ら先導するような行動を取ることは難しいでしょう。
あえて行動するとすれば、自分たちに降りかかるリスクをなるべく回避しようとするマイナスのモチベーションです。
「いや、この時期は忙しいから無理だ」と自分たちを守るために機能改修の依頼を断り、「業務が回らなくなるからこういった機能を付けてくれないと困る」という部分最適化した依頼がユーザー部門から来たりしてその応戦だけに多くの時間を費やしているシーンをよく見かけます。
ユーザー部門もシステムのことはわからず、自分たちの業務をよりよくするためという名目であれやこれや注文を伝えてくるわけですが、当然業務的には正しくともシステム運営的に正しいとは限りません。
システム部門が面倒が無いように行動をすることで、やがて当初の綺麗に設計されたコードは崩れ落ち、受身のシステム部門は何時までも主導権を握れずにいます。
言われるままに追加したいくつもの使わないボタンが画面を埋め尽くし、めったに使わない機能に多くの工数が費やされそして消えていきます。
自ら主導権を握れず握ろうともしないので、システム部としての存在意義を発揮できないでいるわけです。
まとめ
見てきた中での一例として書いていきましたが、後手後手に回る計画がますます身動きを取れない組織を作り出していきますし、今を乗り切るための安易な施策が未来の組織をどんどん壊していきます。
やはりシステム部というからにはその中心にはエンジニアがいないと成り立たないと思いますし、そのエンジニアのモチベーションを上げるためには、自分たちがその業務やサービスをコントロールしているのだという、中の人としての意識を芽生えさせてあげるということにあるのではないかと感じています。