« ブログを書く理由? ヒマつぶしですが、何か?(ウェブを炎上させるイタい人たち/ひなげし) | トップページ | ちょうど就職氷河期だったんで、コミュニケーション能力が必要でした(Googleに学ぶ幸福な職場/センダン) »

ハイエンドマシンなんて飾りです。偉い人にはそれがわからんのです(ジオン軍の失敗/腋芽(わきめ))

 ども、パッケージ拡販担当をやってたおぢさん、たいちろ~です。
 まがりなりにもコンピュータ用のアプリケーション販売ってをやってますが、これには2つの流れというか考え方があります。ひとつは”お客様の仕様(*1)にあわせてカスタマイズを加える”ってやり方と、もうひとつは”お客様の仕様をパッケージに反映させる”というやり方。言い換えると、前者はバリエーションを増やす、後者はバージョンをUPするということになります。
 まあ、一長一短あるんですが、どちらも上手くやらないとコストばっかかかることになります。で、うまくやらなかった事例として参考になりそうなのが、今回ご紹介する”ジオン軍の失敗”であります。

0398

写真はたいちろ~さんの作成。庭のトマトにできた腋芽です。


【本】ジオン軍の失敗(岡嶋 裕史 アフタヌーン新書)
 ”機動戦士ガンダム”の一年戦争時のジオン公国において、なぜかくも多様なモビルスーツが開発されたのか?(*2)
 プラモを売りたいが為のバリエーションではなく(たぶん)、いろんな種類の機体を作ってしまう技術屋さんの性に政治決着の尻拭いと、製品開発のリアルでもありがちな失敗を描いた本です。
【家庭菜園】腋芽(わきめ)
 トマトなんかを育てると、本枝と支枝の間に第三の枝が出てきます。これを腋芽といって、ちゃんととらないと、ムダな枝ばっかり増えて実が充実しなくなります。家庭菜園の基本ですが、ついついサボりがち(反省しています)


 バリエーションを増やすというやり方は、良く言うと状況に合わせて個別に改良を加えていくことなので、短期的には効果が上がります。上記の例でいうとお客様の固有事情に合わせて変更をするので、その分のお金がもらえれば売上も上がりますし、お客様にとってパッケージより使いやすいものになります。
 ただ、このやり方の問題は、複数のバリエーションが同時に存在するので共通的な仕様変更(法制度対応とか)があると短時間で複数のお客様に対応する必要があるし、ソースコードの管理も大変になるので、長期的には利益を圧迫することになりかねません(*3)。
 ガンダム世界でのこの例が大戦初期の名機”MS-06F ザクⅡ”。当時のTVアニメ版では通常の緑ザクとシャア専用の赤ザク(MS-06S)ぐらいですが、後のOVAを含めるとかなりのバリエーションが存在するとのこと。まあ、ガンダムってオープンソース的なところがあるので(*4)、全てが製作者側の意図ではないんでしょうが、本書では生産ラインの増殖や、開発リソースの分散の問題点を指摘しています。
 実際のビジネス現場から見ても、この指摘は正鵠を得ていると思います。

 じゃあ、バージョンアップ型がいいかというと、長期的にはソースコードが少なくメンテナンスコスト自体は減少するとか、先行のお客様のノウハウが反映されているので使いやすいとかのメリットはありますが、短期的にはお客様の要望に対応しないことになるので、基本性能がそれなりのレベルに達していないと売れないという課題もあります。また、仕様に対するある程度の割りきりがないと、限りなく肥大化するリスクがあるし、旧バージョンのサポート問題もあります。一般のパソコンユーザの方はピンとこないかもしれませんが、ビジネスユースではけっこう古いOSが現役で動いていたりするので、どこまで過去に遡ってサポートするかを見極めないと、こちらも動作保障のためのテスト工数が膨らみかねません(*5)。その辺は割り切りの良い外資系とウェットになんとかしようとする国産系の違いが如実に出たりなんかがでて面白いですが。

  ガンダム世界でのこの例が水陸両用機の最高傑作”MSM-07 ズゴック”。優秀性を評価されながらも、現場の意見を取り入れたための開発遅れとか、高コスト化とか、作者の岡嶋 裕史の採点は辛め。

  だが、やはり技術開発はどこかで見切りをつけなければならない。
  製品というものは、精査すれば常に問題点を内包するものだし、
  改善の余地のあるものである。
  しかし、改善要求にすべて対応していては、いつまでたっても製品は完成しない。
  完成したとしても、あらゆる機能を盛り込んだ使いにくい
  あるいは現実的な値段でないものになる。

              (本書より抜粋)

 つまり意味のないハイエンドなシステムってのは、フラッグシップ的な位置づけはともかく、ビジネスには寄与しないことになりかねません

 誤解の無いように言っときますが、実際に会社の中でものづくりをやっている人は真摯に取り組んでいるんでいて、より良い製品を作ることに情熱をかけています。ただ、腋芽をちゃんと取らないとムダなエネルギーばっかり使って実を結ばないように、適度な剪定をしないと良い結果には結びつきません。これは技術者の問題というよりマネジメントの問題。なので、マネジメントについては開発をしない営業とか、予算責任者を参加させないとまずいんじゃね? と思うのはそんなに間違っちゃいないと思うんですが・・・(*6)。

 ”ジオン軍の失敗”という名前からオタク本かと思われるかもしれませんが、立派な失敗学のビジネス書です。裏表紙の解説に”立てよ! エンジニアよ!”とありますが、ガンダムファンであればエンジニア以外の人にも読んで欲しい本であります。

《脚注》
(*1)仕様
 まあ、コンピュータ業界でこれほど便利な言葉はありません。
 設計フェーズにおいて、どのようなインプットでどのように処理してアウトプットを出すかとかを決めるのを”仕様決め”と言います。すべての仕様を決められれば理想的ですが、なかなかそうはいかないのがプロジェクトの常。そうなると人間は往々に自分の都合の良いように解釈するので出来上がってみて”それはこうじゃない”といった齟齬が発生してしまいます。なので、仕様を最初にいかにきっちり決められるかがリスク回避の最重要課題。
 とはいってもバグを”仕様だ!”と言い切るのは論外ですが・・・
(*2)なぜかくも多様なモビルスーツ開発が開発されたのか?
 とはいえ一点もののマシンがバトルする従来のアニメから見れば、同一機種を複数で運用するとか補給とかいう兵器運用思想を持ち込んだのは画期的ではありました。
(*3)長期的には利益を圧迫することになりかねません
 あえて売上と利益を別けて書いているのは、いったん作ったアプリケーションにも維持するためのメンテナンスコスト(要員の人件費や管理費等)がかかっているので、売上が上がってもそれ以上にコストがかかって利益が上がらないという状況が発生するからです。
(*4)オープンソース的なところがあるので
 簡単に言うと、ソースコードを公開し大勢の人間がアプリケーションを開発して再頒布できるのがオープンソースです。
 今でこそメジャーな設定の”ミノフスキー物理学”ってのも、元々は発行の雑誌”月刊OUT 別冊 ガンダムセンチュリー”(みのり書房)に掲載された解説が後付けで公式設定となったもの。
 同人誌活動のハイエンドといえなくもないですが・・・
(*5)動作保障のためのテスト工数が膨らみかねません
 ビジネスユースのサーバーではデータベースソフトやミドルウェアがからんで来るのでかなり条件が複雑。とりあえず動くけどバグが出ても直せないとかいう状況も発生します。
(*6)開発をしない営業とか、予算責任者を~
 一般論ですが、営業は”この機能だと幾らぐらいで、これぐらいのユーザにしか売れない”という総売上側からものを考えるのに対し、開発者は”この機能を作るにはこのぐらいの費用がかかるので、それを回収できるには幾らぐらいの金額で何ユーザに売る必要がある”的なコストありきの考え方をします。
 なので、マネジネントの人はこの両方から落とし所を考えないと、結果的にとんでもないビジネスプランが出来かねません。

« ブログを書く理由? ヒマつぶしですが、何か?(ウェブを炎上させるイタい人たち/ひなげし) | トップページ | ちょうど就職氷河期だったんで、コミュニケーション能力が必要でした(Googleに学ぶ幸福な職場/センダン) »

アニメ・コミック」カテゴリの記事

家庭菜園」カテゴリの記事

コメント

コメントを書く

(ウェブ上には掲載しません)

トラックバック

この記事のトラックバックURL:
http://app.cocolog-nifty.com/t/trackback/528774/48795233

この記事へのトラックバック一覧です: ハイエンドマシンなんて飾りです。偉い人にはそれがわからんのです(ジオン軍の失敗/腋芽(わきめ)):

« ブログを書く理由? ヒマつぶしですが、何か?(ウェブを炎上させるイタい人たち/ひなげし) | トップページ | ちょうど就職氷河期だったんで、コミュニケーション能力が必要でした(Googleに学ぶ幸福な職場/センダン) »

最近の記事

最近のコメント

最近のトラックバック

無料ブログはココログ