「システムの問題地図」を読んでいると穏やかではいられません。
- ベンダーは言われたことしかやってくれない
- ユーザーが要件を決めてくれない
- PMOへの無駄な報告
- 情シスが使えない
- それくらいは情シスにやらせよう
- 運用でカバー
建築現場だって、他の職場だってあるのかもしれません。しかし、私が働き始めてから15年以上が経ってもIT現場はいまだに変わってないようです。
コンサルタントの立ち位置
コンサルタントはSEやプログラマーを抱えるITベンダーとユーザー企業の間に入ってプロジェクトの成功を目指します。
上流工程で構想を策定したり、業務要件を決めたりもしますし、PMOとして複数チームにまたがるプロジェクトの全体統括をすることもあります。
そのためベンダーとユーザーの間に立つこともありますし、ユーザー企業の業務部門と情シス部門の間に立つことも少なくありません。
契約不履行にならない範囲で職務を全うするベンダーの立場もわかりますし、所属部門や予算の範囲内で現場課題をなんとかしようというユーザーの立場もわかります。
コンサルタントも雇われの身ですので発注元を最優先するのはやむをえませんが、常にクライアント企業にとっての最善を意識して取り組んでいます。
だからこそ、冒頭のような自分達以外を否定してそれ以上何もしようとしない発言には穏やかではいられないのです。
運用保守の立ち位置
私はコンサルタントとしては珍しく、数年間のアプリ運用保守の経験があります。
アプリ運用保守チームは、開発チーム（ベンダーとユーザーの両方）がリリースしたシステムの運用や保守を行います。
運用とはマスターメンテナンスやログ監視などの定常的なものから、夜間バッチが異常終了した時の翌朝対応や場合によっては夜間の緊急電話などの非定型運用です。
保守とは、システムにバグがあった場合の修正対応や要望に応じた機能追加や変更です。小規模とはいえ要件定義、設計、開発、テストのサイクルをまわして本番にプログラムをリリースします。
ここでの経験により、「情シスにやらせよう」や「運用でカバー」と言われることに穏やかではいられないのです。
もちろんユーザ業務に影響を与えてはならないことは理解しています。だからといって、開発チームなどのあらゆるしわ寄せを吸収しながらクライアント企業の最善を考えるのには限界があります。
他の立場も経験することによる視点の広さと、工数面での心身の余裕が必要です。
相手を尊重すること。外を知ること
「システムの問題地図」を読んでいてなるほどなと思うのは、置かれた立場以外の部署や人を尊重していることと、決して井の中の蛙にならないよう外を知ることを勧めているところです。
アジャイル開発とかもてはやされてますけど、本番システムに影響出した時のことを知ることも重要。
ウォーターフォールで要件や設計を固めることにより初めて大規模な仕組みを本番に出せることも重要。
アジャイルで、クラウドで、などと生半可にかじった情報で進めるのは危険です。
一方で、パワーポイントで要件定義書を書き、エクセルで基本設計、詳細設計、単体テストケースからエビデンスまで全てとり、障害管理表をエクセルで運用して、という化石のような運用を当たり前と感じているのも危険です。
バージョン管理とかチケット管理の仕組みは進化しています。このあたり、シロウトだからでは済まされず、外を知っていくことは大事だと思います。
おわりに
あーすみません。現在はIT現場から離れてしまっているので実は上のようなことを大きな声で言える筋合いはないのです。
しかしながら、少しでも現場をよくしようと奮闘した経験から、書かずにはいられませんでした。
似たことを感じる方の代弁になれば嬉しいです。
そして、そんな方にぜひ「システムの問題地図」を読んでみてほしいです。
