システムエンジニアはビジネスをどこまで理解するべきか

その時々で重心は変わってよい

システムエンジニアリングを主な仕事にしている人が、ビジネスや事業についてどこまで理解するべきなのか考える機会に出くわした。
このテーマは昔からずっとあるが、個人的な結論としては、その人のエンジニアとしての「成長ステージ」(やれること(Can))、「描いているキャリアパス」(やりたいこと(Want))、「求められる役割」(やるべきこと(Should))という3変数によって答えは変わってくるということだ。
また、この3変数それぞれの重み付けについても、その人の置かれている環境によって変わるはずだ。(例えば企業に属している場合は、「求められる役割」(やるべきこと(Should))の重み付けが大きい、など。)

「成長ステージ」(やれること(Can))
・1つの技術的領域を鍛えているのか、複数の専門領域を横断的に鍛えているのか
・若さとポテンシャルを武器に仕事をしている最中なのか、老練の匠をいかんなく発揮しているのか
など

「描いているキャリアパス」(やりたいこと(Want))
・イケてるOSSプログラマーになるのか、幅広い技術を駆使して全体をコントロールしたいのか、経営に近いところで戦略策定したいのか
・スタートアップの創業メンバーになって0 -> 1を生み出したいのか、事業を 1-> 10にグロースさせられる人材になりたいのか
など

「求められる役割」(やるべきこと(Should))
・起業者としてゴーイングコンサーンに責を負っているのか、企業者の一メンバーとしてのアウトプットを磨いているのか
・一人情シスとしての何でも屋なのか、専門家なのか
・システム開発会社の人なのか、事業会社の人なのか
など

自分の市場価値を最大限アップさせるためのレバレッジ方法を念頭に置き、エンジニアとして成長するための学習リソース(時間、エネルギー、お金)をどう配分するのか考える習慣を身に付けたい。

できる必要はないかもしれないが知っている必要はある

ITアーキテクトの知識体系としてITABoKがある。
世界最大のITアーキテクチャ専門団体のIasa Globalが作成したものだ。
ITABokは複数の章立てで構成されており、その中に「ビジネス･テクノロジー戦略」について記述されている。
詳細は原本を見るとして、定義されているケイパビリティは9つある。これらはどれも事業戦略として外せないものだが、ユニークなのは「アーキテクチャ方法論とフレームワーク」というケイパビリティが定義されていることだ。
ITアーキテクトの役割は、「ビジネスモデル」を駆動させる最適な「テクノロジーモデル」を設計、導入、維持することであるため、当然ながらビジネスについての理解も必要と言うわけだ。

//ビジネス･テクノロジー戦略のケイパビリティ
・ビジネスの基本
・戦略の開発と適正化
・業界分析
・ビジネスの評価
・投資の優先順位づけとプランニング
・要件の探求と制約分析
・コンプライアンス
・アーキテクチャ方法論とフレームワーク
・リスクマネジメント
ITABoK Version2 P.24より

これらのケイパビリティはさらに、ITアーキテクトとしてのレベルに応じて具体的な目標に細分化されている。
どこまでアウトプットを出すのかについては、ITアーキテクトをどの程度目指すのかによる。
しかしながら、いちシステムエンジニアにおいても、ビジネスサイドが話していることを「理解し把握できる」ことは最低限求められると思う。
(「ビジネス」というアセットに対して、どういったAPIを用い情報を取得するのかが定義されているプロトコルを知ろう、という解釈でよい。)

悩みは尽きない

システムエンジニアは、プログラマーやコーダーの役割とは違い、エンジニアリング(工学技術、または人の生活に役立てることを目的とする技術)を通して問題や課題を解決することに価値があることについて反対する者はいないと思う。そして、企業は事業継続・事業開発がテーマである為、企業で働く限りはビジネスを「知ること」は必須要件となるわけだ。
それは起業している場合はさらに「できる」ことも必須要件になってくるのかもしれない。
一方で、それは分かってはいるのだが、テクノロジー世界のトレンドや技術推移、専門性はどんどん変わっており、そういう分野の知識や経験を深めることに学習リソースを割きたいという個人的欲求もあり、そことの葛藤は永久に続きそうだ。