コーポレート・エンジニアリングを追いかけて
この記事は、corp-engr 情シスSlack（コーポレートエンジニア x 情シス） Advent Calendar 2019の4日目の記事です。
ござ先輩というHNで、ITプランナーという肩書を勝手に標榜して、頑張っています。得意領域は、BPRを念頭に置いたIT戦略立案〜オペレーション設計〜要件定義までの「システム企画」を作って、落として、デリバリーする支援です。業種・業態は何でもOKです。
ITで組織を変える＝コーポレート・エンジニアリング
ITで出来ることを大きく括れば「事業を作る」か「組織を変える」の2つに集約できると思います。前者はプロダクト開発、後者をコーポレート・エンジニアリングと呼ぶと、自分の中ではスッキリします。情シスが担うべき機能は、後者のコーポレート・エンジニアリングです。また、単純な母数で言っても、後者に従事される方のほうが多いでしょう。
システム要求とは？永遠の課題への挑戦
システム要求を適切に導くことが、いかに難しいか。
何が難しいかといえば、業務担当者(非エンジニア)とエンジニアの相互理解の難しさ、プロトコルの違いを翻訳することに尽きると思います。
起点となる課題・問題は、とても抽象度が高い。その抽象度を具体化するにしても、図や文章ベースでのコミュニケーションで抽象度のレベルを適切にコントロールして要件定義へと持っていくのは、「しっかりやりましょう」というお題目で済ませられるほど、簡単ではありません。
議論の枠組み・良く練られたアウトプットのフォーマットがあったとしても、議論が空中分解するケースもあります。WHY→WHAT→HOWへと移っていくなかで、そもそもの軸がブレるから。
また、これはプロトコルが違うからしょうがないと思うのですが、業務担当者・管理者・経営層の方々は、抽象度高めの経営・業務レベルの議論や提案については関心を持ってくれますが、具体的なシステム要件になると、途端に関心が薄れる。お金の話(要はいくらかかるの)に関心事が終始しやすいと思います。
導入する責任を持つ我々からすれば「そーゆーとこだぞ。具体的にどうやってオペレーション設計すれば、期待するメリットを享受できるのか。何を変更しないと駄目で、変更によって業務負荷が上がる懸念をどう払拭するか。そこをしっかりやって欲しいんだぞ。」みたいな話を詰めたいわけですが、それをやると一気にトーンダウンする印象があります。そんなのお前らが考えることだろ、ぐらいの勢いで。
システム要件というのは「見積作ったら、同時に発注も作りたい。」的なやつですが、ホンマは「見積データを作ったら、同時に発注データを作る。ほう。それは項目は一緒でいいのか。発注先はどうやって決めるのか。単価はどこで取るのか。商材や業種等によって、発注内容が変わることがあるのか。」みたいな話を詰めないと、使い物にならないのですよ。
その熱量をユーザーサイドが持てないのは、不思議でしょうがない。お前の会社のことじゃねーかと。「武闘派CIO」としてご活躍されている友岡さんの以下の記事に書かれた言葉を、そのまま贈呈させて頂きます。
ベンダーを呼んで、現場の人の話す課題をそのまま放り投げて、「これを全部解決しろ、君たちは専門家だろ！」と涼しげな顔するエンタープライズ情シスの実に多い事。トラブルが起こると「ベンダーがミスをしました。」と平気な顔で社内アナウンスを垂れ流す情シス。こうした「手配師情シス」は組織ごと滅んだ方が良いでしょう。
https://note.com/tomooka/n/n562c9d30b1ba
要件定義の本質は、データモデリングだと思う
業務担当者とエンジニアの相互理解を高める最良の方法は、データモデリングの議論が出来ることだと感じています。
ソフトウェアはデータの操作しかできない。が、すべての企業の業務はデータのCRUD操作を中心にヒトやモノ(サービス)が動く。情報の構造や流通する経路に従って、組織が動く。であれば、企業内に流れるデータの構造を変えたら、業務は変わる。
データには構造があって、それはRDBであれば二次元表で表現されるって話が落ちれば、業務内容からデータモデリングの議論が出来るようになるのは、Pythonのコードを1から書けるようになれよりも、全然簡単だと思うんですね。
「テクノロジーの持つ制約」を決めるのは、データモデルじゃないのかな。僕はそう感じています。
業務としてやらなあかん作業と、その裏で作られるデータの構造を見据えて仕様のインプットに足る議論できるようになれば、お互いハッピーじゃないかなぁ。
えっ？おかしなこと言っています？ 僕。大丈夫ですか？(by イチロー
というわけで、次のバトンを渡します。トリング＠武相荘さん、よろしくおねがいしまーす。