公開日時: 2007/10/03 14:06
著者: 草木生(そうもくしょう)
残念ながら今回も編集部からの督促で書いている。
前回はいつ書いたか忘れるほど前である。
相変わらず、システムの作りに関して書かせてもらう。
業務システム開発は、乱暴に言えば、デコンポジション(分解→分析)とコンポジション(再組立・実装)からなるが、私が担当しているのは、デコンポジションである。
スキルパスでは、良く、コンポジション→デコンポジションとされるようだが、私の場合は当てはまらなかった。全く実装でのスキルが身に付かず、分析への転進で生き長らえてきたからだ。
このコンポジション→デコンポジションという考え方は、
(株)永和システムマネジメント 平鍋 健児氏が簡単に説明してくれている。
分析モデル→<設計>→設計モデル
↑ ↓
<分析> <実装>
↑ ↓
問題→<テスト>← 解
左下の問題からスタートして時計回りに進むのである。
そして、左を上流といったり、デザイン工程としたりするのである。
右が実装であり、下流とも称される。
SE、システムエンジニアはどちらを担当しているかというと、会社によって違うらしい(笑)。
双方を経験して思うところに、両者共通のスキルとしての「抽象化の扱い」がある。
分析は、現実の業務を抽象化することであり、その抽象化概念を実装するためにはコーディングという、抽象化の極地の技法を使う。
今の私の専門である左側の分析におけるスキルとして、ヒアリング能力を追加しなければならない。
ユーザ・業務のプロと会話して抽象化していくには、適切な質問を行い、回答を理解して確認できるというヒアリング能力が必要なのである。
もしくは、翻訳力か。
システム=問題とすれば、実装は解に至るプロセスを記述するところにある。
これは、異なる事象から類似の原因を類推して、ユーザとともに確認作業を行うことに他ならない。
非常に抽象的な書き方になったが、メタモデルを扱っているとこうなるらしい。
機会があれば、ヒアリング能力の身に付け方を書いてみたいと思う。
0 件のコメント:
コメントを投稿