人月ビジネス、プロダクト、ウェブのサービス（2007年08月01日 小野和俊のブログ）
を読んで、過去の身近な失敗例を思い出しながら。
いまいる会社（バリバリ人月ビジネスの会社）においても、パッケージ商品開発は、数年おきに盛り上がるオリンピックのように実施してきた。
が、ことごとく外れ。幸い、身の丈から外れすぎていない投資であったため、会社の経営を揺るがすような事態には陥っていないが、パッケージやサービスなど、いわゆるプロダクトの開発は、人月ビジネスの経営者には「不老不死の薬」を求めるような「見果てぬ妄想」のようなものだと思う。
身近にも、「いまはまだ技術者派遣をやっているけど、人材と資金が集まったら、世の中に打って出られる何かを開発するんだ」と意気込んでいる若手の人月ビジネス経営者が、何人かいる。
そこで、稚拙ながら、自分の経験にもとづく「人月ビジネスの会社がプロダクト開発にチャレンジする際のアンチパターン」をあげてみた。
◆◆◆
アンチパターン１：夢一杯構想倒れ
典型例：「やるからには商品力のあるスゴいのをつくらないと！」とか、とにかく初めてプロダクト開発にチャレンジするときは、夢が過大に広がって、「どうせやるなら、あれもこれもやりたい！」という気持ちになりがち。特に実際に手を動かすわけではない経営者の側が。ターゲットが曖昧であったり、機能を盛り込みすぎたりして、資金ショートによりプロジェクト中断に陥るか、よしんば完成したとしても、果たして何を作りたかったのか誰にも分からないようなものが出来上がったりする。
処方例：とにかくスモールスタートに限る。しかも当たるか当たらないか分からないうえに尖った発想が必要な分野なので、一味違う感性を持った人で数多く企画開発してみることが重要だと思う。そこで例えば、社内から10人程度の凄腕をあつめて、1人につき1つの企画開発をさせる。そして競争させ、当たりそうな手ごたえのあるものを徐々に拡張・拡大させる。逆に、1人で企画しプロトタイプ開発しちゃうくらいの凄腕が10人もいない会社は、チャレンジはまだ早すぎるかも知れない。
と思ったら、
社員側に呼応するものがあればうまく行くことも「1000例に1つ」ぐらいはある。
人月ビジネス社長がパッケージビジネスを成功させる方法（2007年8月3日 福井プログラマー生活向上委員会）
とか、
人月ビジネスをやっている会社がパッケージビジネス（もしくはサービスビジネス）に移行する唯一の方法は、社長自らがアイデアを出し、社長自らがプロダクトを作る、もしくは陣頭指揮を執る、ということだ。
人月ビジネス社長がパッケージビジネスを成功させる方法（2007年8月3日 福井プログラマー生活向上委員会）
なんていう見識もあるので、もっとドラスティックなやり方が必要なのかも知れない。
例えば、10人の凄腕には、ビジネスになりそうなら社長になってもらって、人月社長は資本家、支援家に徹するというのもひとつの手か。
懸案事項：10人の凄腕は、目的・目標の意識づけと機会・環境の提供の仕方次第で、自らお金も稼ぎながら、さらに自分の時間を割いてでも企画開発をこなしちゃうかも知れない（故に凄腕）。だが、次第に企画開発が楽しくなってくると、当初業務のほうに力が入らなくなっていくかも知れない。10人の凄腕には後継者をつけて「おまえが自分の企画開発に注力したくば、自分の後継者を育てよ」といった配慮も必要であろう。
◆◆◆
アンチパターン２：技術者暴走浮世離れ
典型例：次第に、企画開発そのものが楽しくなってしまい、売れるかどうかではなく自分達が作りたいかどうかが主眼になってしまう。ある程度財務上の体力があって「やっぱり投資だから、暫く金が出て行くだけなのは仕方が無い」という感じの、中途半端にチャレンジ精神と許容力のある中規模会社に多いパターン。
処方例：アンチパターン1と似たような話だが、やはり、技術者に技術開発だけをさせてはいけない。自分達が使ってしまっているお金が累積幾らになっているのか、この先どれくらいのお金を使ってしまいそうなのか、お金をなるべく節約して開発を継続するにはどうするか、など最低限のことは本人達に意識させ、考えさせる。「そんなことを考えていたら集中できず良いものができない」などとのたまう技術者は偽者だから、一から叩きなおしたほうがよいだろう。
懸案事項：誠実な技術者であればあるほど、自分達が使っている金額を重く捉えてしまい、萎えてしまうかも知れない。上司たるもの、現状把握は厳しく行うように指導し、見通しについてはある程度楽観的な態度で、接してあげるべきだ。（しかし上司や経営者が本当に心から楽観的になってしまうと、このパターンが再発する。人知れず悲観的に見通して、あれこれ打つ手を考えることこそ、上司の仕事だ）
◆◆◆
アンチパターン３：戦線維持不可能孤立無援
典型例：企画開発費用はなんとか捻出できたものの、その後すぐに陳腐化していくプロダクトを改良しつづけるコスト、維持メンテナンスのコスト、問合せ対応などのコストまで考えきれていないケース。大抵は開発フェーズが終わった後に担当者が1人くらい残されてそれらを細々とやらされる。嫌気がさして担当者が辞めると、誰も分からなくなってそのプロダクトは天寿を全うする。
＃それがパッケージソフトなら、在庫の山が人知れず会社の倉庫奥深くに眠りつづけ、大掃除のときに後輩に発見される。
処方例：自分の経験では、これといった妙案がない。強いてあげるならば、開発するものを、自分達（自社）自身もユーザとして使いつづけられる内容にする。あるいは、最初から不特定多数をターゲットにせず、非常に友好的で協力的な得意先などで、使いつづけてもらえるものから開発を始めるなど、維持メンテナンスコストを補填できるようなビジネススキームを最初からビルトインしておく必要があると思われる。さらに言えば、設計時点で、それを運用していくとどんなコストが発生しそうか（金額だけでなく）、を考えられるような技術者が求められる。
懸案事項：上記の処方において、自社や特定の得意先に特化しすぎると、マニアックな独自仕様が増えていく可能性がある。仕様策定時に必ず汎用化を意識する（さらっと書きながらすごく難しいことだと思うが）、あるいは標準機能とアドイン／カスタマイズ機能をソフトウェア構造的に独立性を保ちながら実装するなど、深い技術力と、安易に妥協をしないような「折れない心」が必要である。
＃妥協に妥協を積み重ねた結果、パッケージと称しながら数十にも及ぶ「微妙にアレンジされたシステム」が出来上がり、もはや誰にも全体像が把握できないシステムが、身近にある。あな恐ろしや。
◆◆◆
パターンも各処方例も、他にいろいろあることは明白。小野さんのblogコメントにも「上手くやる方法」を書けば本一冊書いたって終わらない、とある。
レールなきところに道を見出すのがこの種の経営であろうから、きっと方法論にこだわりすぎても、イノベーションは生まれないということなのだろう。
しかし少なくとも、自分達の状況が「まずい状況に向かいつつあるのか」「良い状況が生まれそうな気配があるのか」現在位置を知るための観点を取り揃えておく必要はあるだろうと思われる。
関連記事１：明日の自分を創る
関連記事２：SE/PGという言葉で安易に技術者を区分けしてしまう行為自体が問題だ
関連記事３：これはうまくいかないと思うぞ。「国家レベル・デスマーチ・プロジェクト」に認定！
関連記事４：たしかに本当の大変化はこれから始まるのかもしれない。でもその前に大崩壊が
