上記の広告は1ヶ月以上更新のないブログに表示されています。
新しい記事を書く事で広告が消せます。

役に立ったらぽちっとよろしく。 人気ブログランキングへ

以前おいらがいた会社の営業は最強だった…。およそ売れると思えんものを売ってくる。バカバカ売るのでシステム部門はどんどん忙しくなり場当たり的に人員が投入される。で、きちんと勉強する時間が無くなり、よけい技術力が鈍る。ぶっちゃけ売れなければ、まだちゃんと自分達を省みる時間があるんだけど…。つまり、営業が上手すぎるのも会社全体としてみると他の部門を堕落させかねない…。

え…自分が堕落した理由を営業のせいにするなって…?大丈夫!おいらは自分の部がどんなに忙しくても、業務そっちのけで技術を磨くKYだから(爆)。…さてさて、そんなKYなおいらがお送りするブログももうすぐ十回目…今回はそんな腕のいい営業にもまかせちゃいけない、プログラマが顧客にヒアリングすべき事について。(…毎度前フリが長いけど本題はここから。)

残念な事に現在のプログラミング言語や開発手法は完璧じゃない。どこかを柔軟にすれば、どこかが固定化される場合が多い。例えば、サブクラス化一つみても、サブクラスの追加は楽だが、そのインタフェース部分の変更は、サブクラス全体に変更が及びコストが高くつく。これはサブクラス化を伴うデザインパターンにも同じ事が言える。特にパターン化されている場合、どこの変更が楽でどこが難しいかが研究しつくされている。例えばVisitorパターン[Gof]の場合、Visitorの種類はどんどん増やせるが、それをacceptする側の種類を増やすのはコストがかかる。(間違って種類が増える要素をacceptする側に持ってくると、悲劇が待ち構えている。)

クラス図

つまり、ヒアリング時点で業務モデルのどこが増える可能性があり、どこが固定的かを知る必要がある。もちろん、営業がプログラミングにおけるそうした事情を把握してヒアリングしてくれればいいわけだけど、あまりあてにしてはいけない。なぜなら、ここを間違った時の痛さを一番知っているのは営業でなくプログラマなわけで、営業の人はあまりリアリティを持ってくれていない場合が多い。で結局、組織内でリアルさに差があると後々トラブルになる事が多いので、「なんでこんな時間がかかるんだ」「あんたらがちゃんと聞くべき所を聞かんからよ!」という争いになる。

そんな事にならんためにも、プログラマにとって重要な事はプログラマ自身で!って事ですな。…ん?そうすると話ベタのおいらは…プログラマとして失格ってオチですか…泣笑。

スポンサーサイト

役に立ったらぽちっとよろしく。 人気ブログランキングへ

コメント
この記事へのコメント
コメントを投稿する

トラックバック
この記事のトラックバックURL
この記事へのトラックバック
Copyright © ふらふら技術者の日記 All Rights Reserved.
Powered by FC2 Blog
上記広告は1ヶ月以上更新のないブログに表示されています。新しい記事を書くことで広告を消せます。