ウィリアムのいたずらの、まちあるき、たべあるき

ウィリアムのいたずらが、街歩き、食べ物、音楽等の個人的見解を主に書くブログです(たま~にコンピューター関係も)

開発論から考えると、成功哲学も多少は、意味あるかもしんない。(多少は、だよ ^^;)

2005-03-21 17:36:46 | 開発ネタ
 前のブログで、「PMBOKのスコープ計画とスコープ定義をまじめに捉えて、ここで成果物を出力するものまで規定できれば、開発は楽になるし、ユーザーも開発費は低減できる(が、実は、これをちゃんとやることは、無理。そのことは今後書いていくが、その方向にむかって、努力することは可能だ)。」って書いたけど、なんで、「ちゃんとやることが無理」なのかについて。




 実は、開発の初めに、
   最終的に、どんなシステムにするか、
   システムが出来たら、どういう風に利用するかということを、
 ユーザーが、イメージしていない場合が結構ある。

 最近のベンチャーや中小企業のおやじさん(社長さん)の中には、「もうかればいいんだ!」とか、「とにかくもうけさせろ」という話をする人もいる。
 そういう人にとって、会社が、儲かるかどうかが重要で(会社もシステムもマネーゲームの道具)、どんなシステムを作るかは興味が無いっていう場合もある。

 そこまで行かなくても、どんなシステムにするかを決めるのがSEの仕事というふうに考えている人もいる。
 (っていうことは、社長はSEの奴隷って言う意味になるし、社長の生きている意味ってあるのか?っていう問題になるんだけど、儲かればいいのよ、結局、その人はね)。

 そういう人に、どういうシステムを作りますか?って聞いても、「とにかく俺が、儲かるようにすればいいんだよ」といわれるだけだ(実はこの言葉、あるベンチャーの社長から言われた言葉だ ^^;)。

 



 普通の経営学の考え方だと、

 ビジネスモデルというのがあって、それをコンピューターなどを使って実現していくという形なんだけど、

 現実的に、そのビジネスモデルをやりたいから、会社をつくるとか、システムを開発するという人は、ごく少数で、

 まず、「金を儲けたい」という考えが先にあり、「そのためには、こんなビジネスモデルをすればいいんじゃないか」という方向で考える人がおおい。

 まず、こういう会社のシステムを開発すると、お金を切り取ることができない場合がおおい。
 (儲かんなかったら、仕様が実現できてない=金を払わないという論理に陥る)

 なので、まあ、こういう開発は、やめておこう。
 でも、営業も、金儲けしたい人間だから、同じ人間を呼んじゃって、こういう人をユーザーで拾ってきちゃうのよね。

 ただ、そういう状態でも、「最終的こういう方向にもっていく」という像をありありと、自分の中で描いておくことは、システムの作り手としては、おさえておいたほうがいい。それが、「その方向にむかって、努力することは可能だ」と書いた意味。




 そこで思い出されるのが、成功哲学。

 成功哲学っていうと、ポジティブシンキングで、そこはウィリアムのいたずらは、「開発には使えない」と思っている。

 なぜななら、営業の場合、100個の取引で断られても、1個の取引が成功すれば、営業としては成果ありということになる。その場合、めげないことが重要だ!だからポジティブシンキングが必要となる。必要な能力は、運鈍根といえる。
 ベテランとしての条件ともいえるかもしれない。

 しかし、開発の場合 、たとえ、100個の開発が成功しても、1個の開発に失敗しただけで、すべての名声と信用を失い、利益も全部吐き出して、損失になるっていうことがあるよね、某大手コンピューター会社さん(某大学病院のこと (^^)v )
 必要な能力は、この場合、プロとしての条件だ。プロの条件はゴルゴ13いわく

 10%の才能と
 20%の努力と  (=努力ではどうにもならないことがあるということ)
 30%の臆病さと (=謙遜とリスクヘッジってことだとおもう)
 40%の運だ

 なので、臆病さを持たない、ポジティブシンキングは、むしろ危険だ。




 ウィリアムのいたずらがいいたいのは、そこではなく、成功哲学では、最終目標をありありと描くようにする。ここが大切だ。システム開発でも、最終目標をありありと描くことが重要だ。
 そうすることにより、なにが必要か見えてくる。

 だから、「金を儲けたい」という中小企業のおやじの考えは、その時点で却下だ。
 いくら儲けて、どうなりたいのかを、語っていない。

 「女をはべらして、高級外車にのって、勝ち組みの景色が見えるマンションの最上階を買い取りたい」というのなら、「女を何人はべらすか」、「車は何を買うか」とか、具体的にブレイクダウンできる。そうすれば、いくら儲ければいいかが、くめる。

 そうすれば、「うーん、かたぎの商売では、もうけられないね。」とか、「株で、一発勝負を3回やれば(一発なの3発なの??)」とか、やるべきことの議論は出来る(やるかどうかは別問題だよ)。


 だけど、ただ、「お金を儲けたい」では、どの規模のお金を儲けたいのか分からない。
 そのために、お金儲けの通論である、株を勧めたり、いまのビジネスの延長を勧めたりする。
 しかし、株は、ある一定以上の金額を投資しないと、儲からない(手数料で取られてしまう)。
 なので、結局、「金を儲けたい」っていう考えですら、「いくら儲けたい」という出力を先に考えることが重要で、それを放棄している以上、この客は、儲ける資格はないのだよ。




 ということで、システム開発でも、最終的な出力を、ありありと目の前に描くことが重要なのだ。で、それには、シナリオをつくったり、プロトタイプをつくったり、フィージビリティスタディやったりするんだけど、そういうことが重要だと言う人は、ユーザーにも、SEにもいない。

 だから(システム開発も失敗するので)システム開発の本も売れるし、
    (成功しないので)成功哲学の本が売れるんだけどね。

  • X
  • Facebookでシェアする
  • はてなブックマークに追加する
  • LINEでシェアする

営業とコンサルの暴走による開発費高騰をPMBOKで抑えられることは、あまり知られていない

2005-03-21 15:54:10 | 開発ネタ
 前回のブログで、「入力から分析してしまうと、大変なことになる。」と書いたことについて。
 システム開発を、入力や、開発の通論(業界の一般的なシステムの作り方とか)、パッケージソフトの利用から入ると、ものすごいオーバースペックになって、開発費が高騰したり、場合によっては開発できなくなったりしてしまう。

 これは、実例から入ったほうがわかりやすいので、まず、例を挙げます。




 おなじみ??「夕食支援システム」において、
 これで、夕飯を出前してもらうのに、商品マスタが必要だ!というところで、商品マスタから入ると、大変なことになるのですよ!

 だって、お店によって、商品って、全然違うもん!

 マクドナルドに誰かが買いに行く場合
   17クーポン利用1個
   (=てりたまバーガー+チキンフィレオ+チキンマックナゲット+ドリンクM2個)
      ナゲットは、マスタード
      ドリンクは、ホットコーヒーで砂糖とミルクつき
            とコカコーラ

 それと、石焼いもの屋台
   Aさんは、やきいも小3個
   Bさんは、500グラム
   Cさんは、やきいも1000円分
 (どうも、焼き芋やさんって、グラムでも、個数でも金額でもかえるみたい。。。経験値より)

 それと吉野家の豚ドン、大もりつゆだくで。

っていうのを、マスターにしろ!っていわれたらどーする(^^;)

 1つのお店、一つの商品でも、単位が違うし(石焼き芋のケース)、セットだとしても、いろんなバラエティがあるし、クーポンもある、さらに、吉野家の豚ドンにいちゃっては、マスターにはのってない注文もできちゃう(つゆだくとか)。

 で、このマスター設計から入ると、暗礁にのっちゃうんですよ。




 実は、これ、出力から考えると、かんたんです。

 実は、この商品マスターって、DBにいれなくってもいいんです。
 最終的には、発注表をみて、発注ができれば、
 商品マスタは、なくったって、いいんです。

 つまりですね、ショッピングカートで、商品マスタDBを持たない形式っていうのがありますが、
あれと同じように、発注時に、発注用の商品名と数量、金額を受け取り、それをDBに入れるようにします。
 ユーザーは(Webかなんかで)商品を選択していって、発注ボタンを押すと、発注用の商品名をjavascriptで作るようにします。
 そうすると、各お店ごとにWebページをつくって、夕食の商品と数量が選択できるようにして、発注するとき、発注用の商品名と数量、金額を受け取るようにすればいいのです(そのインターフェースは共通化する)
 うーん、わかりにくいけど、わかったかな。

 用は、どんな商品でもかまわなくって、商品マスタを持たないかたちのショッピングモールのCGIを利用すればできるってことなんだけど。




 でも、入力から入って、商品マスタを作ろうとすると、まあ、この共通の商品マスタっていうのはできないし、通論から入ると、この手のWebサイトのマスタは、全部RDBに入れて作るので、かなり複雑なDB構造になってしまう。

 でも、結果から考えると、これって、フリーソフトの(DBを持たない形の)ショッピングモールのCGIと同じ作りとわかる。
 さらに、もし、そのフリーソフトのCGIを利用するとなれば、すぐに取り組めて、開発費は、ただ(は極論だけど、フリーソフト利用だから、相当金額は低い)はずだ!




 営業さんとか、コンサルの場合、こういうシステムは、こういうソリューションという通論を持っていて(たとえば、CRMなら、当社のなんとかパッケージ、ERPなら当社のERPソリューション)、それを売りつけようとするわけよ。
 そうすると、そんなのいらなくても(オーバースペックになっても)それ(=自社の売り物商品)にあわせるから、開発費は高騰したりするのね。

 また、コンサルを頼む場合、お客さんの出力に合わせるというより、知識を売り物にして、「これは、こうあるべき」論で考えることが多い。そうすると、入力のマスタから「こうあるべき」で定義しちゃうのね。

 たとえば、商品マスタは、こういう機能をもつべきとかね。。。
 そうすると、(今回の夕食支援システムのように)出力から考えたら、商品マスタなんて、どうでもいいような場合でも、りっぱなものを作ろうとして、結局、開発費高騰なんてことになりかねない。




 じつは、こういう事態を避けるため、PMBOKでは、スコープ計画で、「成果物」を定義し、スコープ定義で、「成果物を実現する」方法を考える。
 たとえば、さっきの夕飯支援システムなら、成果物の毎日の発注表を作るため、それを実現する方法ということで、フリーソフトのCGI利用でもOKなわけ。

 でも、ふつう、この成果物って、そこまで考えないで、「成果物は、バイナリとドキュメントでドキュメントは要求仕様書と、画面設計書とファイル設計書」などという形式だけしか考えないので、あんまり役にたたず、こういう開発時高騰をまねくわけよ。

 だから、PMBOKのスコープ計画とスコープ定義をまじめに捉えて、ここで成果物を出力するものまで規定できれば、開発は楽になるし、ユーザーも開発費は低減できる(が、実は、これをちゃんとやることは、無理。そのことは今後書いていくが、その方向にむかって、努力することは可能だ)。




 いいかえると、(うるぐすディスカバリー風にいうと) 営業とコンサルの暴走による開発費高騰は、PMBOKのスコープ計画で、成果物を具体的に定義して、それに基づいて入力を考え、スコープ計画をたてれば抑えられることは、あまり知られていない。

  • X
  • Facebookでシェアする
  • はてなブックマークに追加する
  • LINEでシェアする