ITエンジニアリングと ひとことで呼ばれるが、いろいろな在り方があると考える。
エンジニアリング・・・ものづくりと解釈する。パッと思いつくのがプログラミングによるアプリケーション開発だ。プログラミング言語やフレームワークを駆使して、業務要件・機能要件を実現するアプリケーションを開発する。
ITインフラの領域ではどうだろう。ネットワーク機器やサーバ機器、OS、ミドルウェアなどをセットアップして、アプリケーションが動作する環境を構築する。性能や可用性などの非機能要件を満たすITインフラ環境を構築する。
これらはいずれも日本ではSIerやSaaS・パッケージベンダが多く担っており、僕自身もSIerに所属してITインフラのエンジニアリングをなりわいにしてきた。
SIerでエンジニア、そして営業の仕事をする中で気付いたことがある。システムには必ず利用する人・運用する人が存在することだ。
システムをつくったところで、誰かに使わなければ無価値である。また、維持に手間がかかる、再現性が低い、トラブルが多いといった運用が不便なシステムは維持コストが高く、アプリケーションの価値を毀損する。
このことに気付いて以降、どうすれば利用性・運用性が上がるのか？ という使う人の観点を大事にしてエンジニアリングに取り組んできた。
ところがである。SIerの立場でのエンジニアリングには、たまにどうしようもないエンジニアリングが存在する。
ひとつ、SIer側組織のイケてない統制が働くとき。主に品質に関する、過剰で柔軟性のない統制。こちらは今回のテーマから逸れるので深掘りしない。
もうひとつ、要件がイケてないとき。使われない機能、運用性の低い構成、機能過多・性能過剰な製品の適用。これらがプロジェクトの頭から要件として決定していると、矛盾に気付いたところでエンジニアリングでカバーするのにも限界がある。
そんなイケてない要件を組むのは誰か。顧客である。コンサルや営業がコントロールしている場合もあるが、それでも決定の責任は顧客にある。
イケてない要件にぶつかったとき、いつも不思議だった。どうして こんな要件になってるんだろう？ どんな合理性を持って この仕様を決定したのだろう？ 知りたい。そして できることなら この不をなんとかしたい。
そんな思いで顧客に近づいた。
ITインフラの領域で主に要件をコントロールする顧客は情報システム部門、いわゆる情シスだ。
情シスに近づいてみると、イケてない要件を組むに至る いろいろな事情があることがわかった。
適切な要件を組む知識や経験がない、ITベンダにロックインされている、政治的な取引の背景がある、時代遅れの規程が定められている、事業部門に無理難題を要求されている、などなど。
あるべき論を語るだけでは なんともできず、一筋縄ではいかない。だが中の担当者も苦しんでいる。なんとかしたい。なんとかしないと適切なエンジニアリングができない。
社員として情シスに入るのが一番早道か、と思いつくが早計だ。担当者として入っても権限がない。部長として入るだけのキャリアは まだない。そもそも情シス自体の組織内でのプレゼンスが低い。
実際に社員として入ったことはないのだが、朱に交われば赤くなる。組織に絡め取られるのがオチだと想像がつく。
そんなこんなで ここ数年、なんとかして外から要件の起点から変えていきたいと提案やら支援やらに取り組んできた。
やってみると、情シスの仕事は かなり深い。
組織内で稼働する情報システムの統制を司る存在である。領域はとても広い。
領域でいうと自社開発アプリケーション、業務システム、ITインフラ、デバイス、それらにまつわるデータとセキュリティ。プロセスでいうと企画、要件定義、導入、運用・保守。そして、これらの領域とプロセスを統制する規程や標準を策定する。
担当者が浅く広くなるのも仕方ないぐらい、情報システムの全部が詰まっている。
今、とあるスタートアップ企業向けの情シス立上げに取り組んでいる。
新規の立上げなので自由が効く一方、あまりに領域が広すぎて どこから手を付けるか、どこまで手を広げるか悩んでいる。改めて情シスのスコープやフレームワークを勉強しているところだ。
情シス立上げの仕事は、組織のITを統制する標準規格の設計。これもひとつのエンジニアリングだ。
ITの本質が詰まった、とても おもしろい領域だと思っている。
Discussion