アーキテクトを目指すITエンジニアは、変わらないスキルを身につけよう！
新しい技術が次々と生まれては廃れる、移り変わりの激しいITの世界。そこでは、一般に「ITスキル」と定義される項目の中にも、時間の経過と共に近い将来の陳腐化が予想されるものが少なくありません。しかしながら、その一方で、「変わらずに必要なスキル」というものも確実に存在します。例えば、要求分析や機能分析、データ分析といった上流工程のスキルがそれにあたります。
情報システムを活用するユーザー企業の考えは明確で、前者についてはITベンダの力を借りる、外部から調達するなど、「お金で買う」という考えが顕著です。
後者については、最適なシステムを構築していくためにユーザー企業自身がしっかりとその能力を保持している必要があると認識しており、スキルアップに余念がありません。
しかし、そうだからといってシステム構築やITサービスを提供する側のITエンジニアが、後者の能力を持たなくていいのでしょうか？
答えは「否」です。ITエンジニアこそ、特にアーキテクトを目指すなら、「変わらずに必要なスキル」は持つべきだというのが筆者の考えです。そうでなければ、限られた範囲での設計や開発はできても、企業のアプリケーションやインフラのアーキテクチャを設計することはできないからです。上流工程でのアウトプットである要求モデル、機能モデル、データモデルが理解できなければ、全体像がつかめず、いつまでも全体最適ができず、部分最適に終始してしまうことになります。
そうすると、プログラム開発、プログラム設計、システム設計と積み上げ方式でいかないと、上流工程の担当ができず、時間がかかるし、第一そのチャンスに恵まれるかどうか分からない、という声が聞こえてきそうです。
別の観点でいうと、過去の経験は貴重ですが、ITエンジニアにとってそれが足かせになっているのも確かです。「どうあるべきか」「何のために」という目的意識と推進力が重要です。ITエンジニアは、開発を多く経験しているがゆえに、視野が狭くなって限定的になり、クリエイティブではなくなる傾向が確実に存在します。特に上流工程のモデリングの部分は、下流から上がってきたITエンジニアではうまくこなせず、技術ベースさえ理解できていれば下流工程が未経験であってもデザインセンスのある人の方がうまくこなせることが多い、というのは疑いようのない事実です。
■モデリングの考え方
ここで、「モデリング手法」について簡単に触れておきます。
システムを構築する際には、現状分析から入ることが一般的です。現状がどうなっているか分かっていないと、課題や問題点の理由・根拠が不明確になり、結果的にいいシステムを構築することができない可能性が高いからです。
現状を調査する際には、組織ごとに調査を進めることになります。仕事は組織単位に実施されているからです。言い換えると、現状分析は組織ごとに調査した寸断された情報からスタートします。
顧客から注文を受けて商品を出荷し、代金を回収することを考えてみましょう。システム構築側から見ると、顧客から注文情報が来て、最終的に商品が出荷され、請求して入金があり、売り上げを立てるという流れですが、これを組織単位に記述すると次のようになります。
- 営業が顧客より注文を受け、在庫を調べて引き当てた後に出荷指示書を倉庫に回す(データインプット)
- 倉庫は出荷指示書に基づき配車手配・在庫情報を更新する。また、在庫量が少ない場合は発注する
- 営業が出荷処理を確認後、請求の手配をする
- 経理は請求の手配に基づき、請求書を発行する
- 入金が確認されれば売り上げに計上する
このように、組織ごとに細切れの仕事のスタート/エンドが発生しています。つまり、現状調査はこの単位で行うことになるわけです。これらの情報から組織の枠を取り払い、抽象化（論理化）して機能（ファンクション）の単位にまとめていくのが、システム構築における上流工程の機能分析に当たります。この作業を「モデリング」と言い、成果物を「ファンクションモデル」と言います。
そして、この現状を表したファンクションモデルに、システム要求を反映することによって、あるべき姿、To Beファンクションモデルができ上がることになります。
要求分析や機能分析では、モデリング手法としてロジックツリー形式でまとめることが多いですが、EAの機能分析では、DMM（ダイヤモンド マンダラマトリクス）なるものを用います。DMMはファンクションを放射型に記述していきますが、筆者は人間が一番理解しやすい階層型の方が好みです。
つづく
コメント
インドリ
はじめまして。高橋さん。
記事の内容は概ね賛成です。
ただ一つ気になる点があります。
それは上流工程の技術だけと限定して書いている点です。
実装技術にも変らないor変り難い部分があります。
例えば、コンパイラ・OS・ネットワークプロトコル・データベースマネージメントシステムなどは古典的なアルゴリズムや技法を使って実装されています。
それに変化が早いように見えますが、やっていることはほとんど変っていません。
つまり、情報処理技術も根源的には変化がほとんどないのです。
ですから、上流だけ特別なものとして書いて欲しくなかったです。
というのも、そういった上流優位な考えこそこの業界を悪くしていると思うからです。
高橋秀典
インドリさん、
コメントありがとうございます。
おっしゃるとおりですね。私の書き方は、アプリケーションアーキテクトを指しているので、読む方に混乱を与えるかもしれません。
次回のコラムで分かりやすくします。ありがとうございました。
私自身がメインフレームのSE時代から、RDBのアーキテクチャを使って設計、実装をしていました。RDBは当初メインフレームのプラットフォームでリリースされましたが、パフォーマンスが話にならない点や、使う側が物理テーブルを意識しないといけなかった点から、とても業務システムには採用できませんでした。
しかし、アーキテクチャは優れていて、DB大好きの私はとりこになったものでした。ですので、リレーショナルのアーキテクチャをもとに設計し、実装は階層型やネットワーク型に落としていました。
これは、インドリさんの言われるように、システム構築全体を通して必要な、まさしく「変わらないスキル」ですね。
ありがとうございました。
ビガー
ビガーです。
一般論としての現状(AsIs)から理想の姿(ToBe)を実現する手順が書かれていますが、
そもそもToBeモデルを本当の意味で理解できているお客様は非常に少ないと感じています。
この辺りのコミットメントの仕方や泥臭い部分であるAsIsモデルをどこまで正確に
モデル化すべきかについての指針などの具体例がないと「魂」が感じられず、
読み手としては少々物足りないです。
次回以降を期待しています。
高橋秀典
ビガーさん、
コメントありがとうございます。コラムニストの高橋です。
顧客が理解できているか、この点についてはおっしゃる通り、日々の仕事に追われて余裕が無く、希薄になっていることは否めません。
私は、アセンブラのコーディングから積み上げてきた経歴で、長らくITサービスを提供する側です。ここ5年ほどは、ITサービス企業、ユーザー企業を問わず人材戦略の立案・実行を支援するコンサルティングサービスを提供していますが、はっきり言って、ユーザー企業とITサービス企業の人材の違いが明確です。
ITサービス側の人間としては寂しく悔しい限りですが、それは歴然とした差と感じています。
あくまで私の経験の範囲内ですが、違いをざっくり言うと、物事を大きく捉えることや思考力、チャレンジ精神、事業戦略を中心に考える、などといった点です。
ユーザー企業では、「戦略」という言葉を普通に使います。ITサービス企業では、経営層からもあまり聞くことができません。この辺りにも、その一面が現れていると感じます。
もちろん、ITサービス側にも優れた人はいらっしゃいますが、全体として私は「？」を付けざるをえません。
IT業界では、過去に人を集めるだけでビジネスになった時期が長く続きました。その影響が大きいと考えていますが、強いて言えば経営層や管理層の差と言えなくもありません。
ITSSをきっかけに、何とかITサービス企業の底上げを目指して、2003年から2年ほどかけてビジネス抜きで、首都圏だけでなく地方回りもしましたが、概ね経営層の不理解や信念のなさ、保守的な管理層の考えなどの壁が厚くて高く、意気をそがれてしまい、モチベーション低下につながりました。
というバックグランドがあって、エンジニア側を叱咤激励する意味もこめて、あえてユーザー優位な表現を使いました。
いただいたご意見を無駄にしないよう、次回からも心がけていきます。
ありがとうございました。
ビガー
ビガーです。
意図が伝わっていなかったので再度。
>そもそもToBeモデルを本当の意味で理解できているお客様は非常に少ないと感じています。
確かにお客様側の質の問題もありますが、理解できるように噛み砕いて説明する
責務がエンジニア側にあるという意味です。
そのツールとして、モデリングやAsIsの分析結果をどのようにコミットメントに
使うかを決めると思いますが、その辺りの詰め方を高橋さんはどのように具体的に
実施されているかを聞いてみたいということでした。
この辺りは、確かに食べていけるスキルになりますね。実装技術は、需要ありきですから。
高橋秀典
ビガーさん、
なるほど、分かりました。
少しずつこのあたりを書き進めていこうと思っていました。
今まで翔泳社のEnterpriseZineや＠ITでもエンジニア向けに色々書いてきましたが、今ひとつ反応が悪いような気がして、どうもしっくり来ませんでした。
もともとシステム構築から人材育成に乗り出したのも、何とかエンジニアの地位を上げたり、モチベーション高く仕事が出来る環境ができないかという気持ちからですが、企業相手のコンサルテーションが生業なので、私自身がうまく伝えることができないのかと、悩んだりしていました。
今回思い切ってエンジニアライフにチャレンジしてみて、それなりに意見をいただいたり、興味を持っていただけるのが分かったので、俄然やる気になりました。ありがとうございました。
少しでも参考にしていただけるよう、いい内容にしたいと思っています。
ビガー
ビガーです。
ぜひ参考にさせていただきたいので期待しています。