エンジニアとしてどうあればいいのか、企業の期待とどう折り合いをつけるのか、激しく変化する環境下で生き抜くための考え方

アーキテクトを目指すITエンジニアのための問題分析

»

 前回は、アーキテクトを目指すなら「変わらないスキル」を身に付けるべきとのお話をしました。

 システム分析を中心とした上流工程、特にアプリケーションアーキテクチャにスポットを当てましたが、もちろん上流、下流全般に通じる「変わらないスキル」も間違いなく存在します。

 例えば、DB設計のアーキテクチャから実装の考え方や、OSなどの考え方もまさにその内容でしょう。今回は、システム分析の初めのステップになる「問題分析」についてお話しします。

 図はシステム構築の概略図です。

System_analisys2

 さらに次の図で、システム分析の概略をまとめました。

System_analisys

 お気づきでしょうが、全体の概略図では「問題分析」は見えてきません。なぜなら「問題」は「要求」の裏返しだからです。大事だけれど見えにくい。「問題分析」とは、現行システムについての問題指摘、または企業経営観点から提起された問題を吟味し、問題の本質や特質を把握し、有効な解決策を策定できるように図るための第一歩です。

 システム分析の最初のステップである問題分析の必要性は以下の通りです。

  • 本質的な問題提起にを深堀りする
  • 長期的システム計画との整合性を確保する
  • 的を射たシステム分析や問題解決のための情報を得る

 下の図は問題の検討側面を表したものです。

System_analisys_problem_analisys_2

次に、問題の識別と実態調査は以下の観点で実施します。

  • 長期計画との整合性
  • 問題の関与者
  • 問題の重要性/大きさ
  • 問題の構造
  • 問題の原因
  • 問題の環境
  • 問題の特性
  • 問題解決の感度

●関連問題の洗い出しと整理

System_analisys_problem_analisys2_3  

●重点課題の設定

 体系的に整理された問題を重点課題候補として評価し、「何をすべきかを」決定します。重点課題候補評価の基準としては、システム開発のごく初期の段階であるため、次のような側面が重点的に評価されるべきです。

  • 外部環境との整合性:「不確実性下での」評価
  • 技術的可能性
  • アプローチ間または内部の整合性
  • 問題解決に対する有効性

 先に述べましたように、基本的には問題は要求の裏返しであり、問題分析をして次に要求分析をするというより、問題から解決のためのシステム要求を順次導き出すという位置づけとなるでしょう。

 また、文章だけでは理解しにくい面もあり、私の経験上の話が中心ではありますが、皆さんのお役に立てば幸いです。

 次回は、問題分析での重点課題を受けて「要求分析」に入っていきます。

Comment(2)

コメント

ビガー

要求しておいてレスが遅れました。みなさんのコメントがないのが個人的に悲しいです。。
そもそも問題とは何か(問題の定義)を具象化するアプローチを体系化することは
とても意味があると思います。今後の高橋さんの体験に基づくエッセンスを感じたいです。

多分ですけど、システム分析や開発する上で発生する「問題の定義」を実現するメソッドが
実は今回の話とリンクするであろうと勝手に推測しています。
エンジニアの現場感覚の段階になればみなさんのレスポンスも上がるんじゃないかと
思いますので今後も期待しています。

高橋秀典

ビガーさん、

 コメントありがとうございます。

 ITは、ビジネスにおける最強の武器ですが、あくまで手段だと思っています。
ビジネスを成功に導くために重要な役割を果しますが、今回のようにそれに強く踏み込んだ話になると、いきなり興味が無くなるエンジニアの方が多いと感じています。
 また、書き手からしても、面白おかしく書くのが難しい領域でもあります。

 ビジネスモデルによっては、今でもメインフレームの方が向いているシステムもありますし、逆に最新技術を駆使しないと実現できないものもあります。
 エンジニアには、環境の変化に柔軟に対応、もっと言えば一歩先んじる感覚が必要だと、常々思っています。

 一方で、もちろん役割分担は必要で、スペシャリストとして実装技術を追いかけて行くエンジニアも必要ですし、アプリケーション、インフラも含めたアーキテクチャを設計するエンジニアも必要です。

 趣味的に仕事ができれば一番幸せなのですが、例えば技術だけを追いかけて、もし本来のIT化の目的を軽んじているならば、その段階でジ・エンドです。

 何も行きたくも無い別のキャリアを目指す必要はありませんが、どのエリアに従事するにしても、IT化の目的をしっかり認識し、手段が目的にならないようにするのは、ITに係わるエンジニアとして当然のことと考えています。

 そういう意味でもビガーさんの言われるとおり、こういった内容にもっと興味を持ってくれるエンジニアが増えればいいですね。

 以前も書きましたが、私がエンジニア個人向けに何かを書く場合、いつもぶつかる壁です。今までは、何度かチャレンジした後、結構あきらめてしまうことが多かったのですが、こういう実践的な話を伝える場が少ないので、何とか今回は続けていければと考えています。

 今後もご支援よろしく願いします。

高橋秀典

コメントを投稿する