Hatena::ブログ(Diary)

yvsu pron. yas このページをアンテナに追加 RSSフィード

2008-06-20

深い業務知識が必要なのは案件の提案者と要件定義者

SIerが必要としているのは業務知識だという都市伝説エントリで、誤解されたのは、「SIerは深い業務知識が不要だ」というふうに私が主張していると思われたことですね。

誤解されるのは、もちろん、私の書き方が悪かったせいなので、続きを書きます。


SIerで深い業務知識が必要とされる人がいます。案件の提案者と要件定義者です。営業がお客様のところから案件を持ってくると、その案件に関する深い業務知識を持っている人がアサインされ、提案書と見積りを作ります。この役割の人は、深い業務知識が必要です。

無事に案件が獲得できたとしましょう。お客様のところにいって要件をつめるのですが、このときのメンバも深い業務知識が必要です。しかし、全員が深い業務知識を持っていなくても大丈夫。全体の半分弱くらいのメンバが深い業務知識を持っていれば大丈夫だと思います。案件の難易度にもよりますが、一人が業務を深く理解していれば大丈夫な場合もあります。

最初は深く業務を知らなかった残りのメンバも要件定義を通じて、少なくてもそのお客様に関しては、深く業務を理解できるようになります。


要件定義が終わると次は、外部設計をおこないます。外部設計の呼び方は、各社によって違うと思いますが、要件定義顧客が理解できるレベルで具体化することです。この外部設計のメンバは、深い業務知識を持っていなくても大丈夫だと思います。基礎的なことをおさえておけば、後は、要件定義をしたメンバからレクチャーを受けながら設計を進めていくことができます。


つまり、深い業務知識が必要なのは、案件の提案者と要件定義者だけで、残りのメンバは、後から勉強して基礎を身に着ければ間に合うのです。

業務知識が不要だとはいってませんよ。外部設計を行なうには、業務知識が必要です。ただし、その業務知識は後から勉強しても間に合うということです。

また、外部設計を行なうには、業務知識と同様に、この要件をどうやって実装に落とし込むかというスキルが必要です。どうやって実装するかのイメージなしに設計したものは、そのままではまともに実装できないからです。


技術力だけがあればいいなんていってませんよ。外部設計を行なうには、業務知識が必要です。しかし、それと同時に、「要件をどうやって実装に落とし込むかというスキル」も必要なのです。

でも、今の多くのSIerは、業務知識を重要視するあまり、「要件をどうやって実装に落とし込むかというスキル」をあまりに軽視しすぎているので、それはおかしいといっているのです。


深い業務知識というのは、私の経験上、要件定義をやらないと身につきません。外部設計をしてもシステムの一部しか担当しないので、知識が深くならないのです。

要件定義をやれるメンバというのはごく少数です。しかも、もともと深く業務を知っているメンバが数人はいるので、要件定義をやったことのない人が参加できるというのはものすごく「稀」な機会ということになります。深く業務を理解している人の数を増やすのは難しいのです。


じゃ、要件定義にかかわれない人は、スキルアップできないかというとそんなことはありません。「要件をどうやって実装に落とし込むかというスキル」も非常に重要です。このスキルは、技術力のある人が、外部設計を何度もやってみないと身につきません。


この「要件をどうやって実装に落とし込むかというスキル」を今のSIerは、あまりに軽視しすぎていませんかというのが私の言いたいことです。

深い業務知識を持った人ももちろん重要ですが、そういう人は、大量生産できません。にもかかわらず、プログラミング力を軽視して、業務知識を重要視しすぎているから、こんなことが起こるのです。

どうも会社では、僕に上流工程を任せようとしているようです。しかしながら僕は、上流工程にはまったく興味がありません。上流工程のほうが付加価値が高いし儲かるということは一応知っているつもりですが、設計をしたり人の調整をしたり、なんていうことは好きでもないし、得意でもないのです。まだ入社して2年目にもなっていないわけですし、もっと実際のコードに触れていたいと強く思うのです。

それにしても、上司根本的な勘違いをしているような気がしてなりません。上流工程が儲かるのは、それだけ付加価値が高いからです。付加価値が高いということは、それだけ難しい仕事だということです。僕にそんな仕事ができるだなんて、何を間違ったらそんなことを思えるのでしょう。僕は何一つ実績など挙げていないのに、です。

意外な歴史 - シークの日記

「要件をどうやって実装に落とし込むかというスキル」なしで、外部設計をするから、実装できない設計になってしまうのです。


深く業務を知っている人が、高く売れるのは、大量生産できないからです。にもかかわらず、何の策もなく業務重視のやり方をとるから、一握りのSuper業務SEと数多くの中途半端に業務を知っていてgdgdな設計書を書く人を生み出してしまうのです。

この中途半端な人は、自分の仕事結果が中途半端なことを知っているので、仕事に満足感をもてません。さらに困るのは、gdgdな設計書を実際に実装させられる人たちです。実装できない設計書を実装しろといわれるのだから。


日本のSIの生産性が低いといわれるのは、このようなSIerの思考パターンがもたらしているんじゃないかと思います。


SIerには、「要件をどうやって実装に落とし込むかというスキル」をもったSEを育てつつ、その中の何人かがSuper業務SEになっていくというキャリアパスを提案したい。そうするとこで、SI全体の生産性をあげつつ、みんなのスキルも向上します。

hirohiro 2008/06/20 12:48 ひがさんの考えてられる要件定義と外部設計の違いをおしえてください。
見積もりをだすには新規ものだと外部設計まで、修正ものだと影響範囲調査などのある程度の内部設計までしないと
だせないとおもうのですが、どれぐらい見積もりと実際のバッファを考えてられますか?

bebe1973bebe1973 2014/11/23 20:13 >SIerには、「要件をどうやって実装に落とし込むかというスキル」をもったSEを育てつつ、その中の何人かがSuper業務SEになっていくというキャリアパスを提案したい。そうするとこで、SI全体の生産性をあげつつ、みんなのスキルも向上します。

銀行業務SEの経歴がもう20年超えてるけど
要件を実装に落とし込む作業を専念するような仕組みだと、その作業の中で「業務を深く知るSE」が生まれる可能性はかなり低いですね。
このやり方で一番まずいのは「毎日の作業の中で、業務を深く知るSEが生み出されるきっかけを、SE本人のモチベーションに依存している」事

貴方の考えは、毎年一定の確率で普通のSEが業務を深く知るSEに昇華する事を前提にしていますが、
言われるがままに要件定義を外部設計に落とし込む作業を日々続け、いつまで経っても「中途半端な業務知識しか知らない」SEが大量生産されている現実を無視していると思われます。

だから業務観点でのバグにそういうSEが気がつけないし、
深く業務を知るSEの数が少ないから、それらのバグを全て事前に感知することが出来ない。

この問題は業務を知る人がきちんと工数を貰って業務を知らない人を教育しなくてはならないという話であります。
それと、あなたは要件定義者が外部設計や詳細設計をできないと決めてけているような節がありますが、これは大きな誤解じゃないのですか?
私から見た感じ「要件定義を外部設計に落とし込む」作業をしているSEの多くが、色々な勘違いをしているシチュエーションを良く見かけますが、それは要件定義書の記載が悪いのではなく、業務知識がない設計者が要件定義をまともに理解できない事に起因しています。

こういった人たちに対して業務知識を教え込むのが有識者の使命なのですが、
少数の有識者が業務知識を多数に展開していく工数は膨大です。
だからこそ、外部設計を作る人は、より要件定義ができる程度の業務知識が求められていくようになるのであり、
それが開発の効率化につながるのですよ。

投稿したコメントは管理者が承認するまで公開されません。

スパム対策のためのダミーです。もし見えても何も入力しないでください
ゲスト


画像認証