お使いのブラウザは最新版ではありません。最新のブラウザでご覧ください。

CNET Japan ブログ

ソフトウェア開発方法論はビジネスモデルが先でしょ

2008/12/29 00:08
  • このエントリーをはてなブックマークに追加

プロフィール

山田ひさのり

私がプロジェクトマネジメントを実践したり学習したりしていく中で、ためになった考え方やノウハウを紹介していこうと始めましたが、その後ケータイ/ソーシャルビジネスを中心の情報発信に変化しました。暫くの間更新が滞っていましたが、私の転職をきっかけにグロースハック/ハッカーの情報を発信するグログとして投稿を再開しました。
ブログ管理

最近のエントリー

私はよくソフトウェアのプロジェクトマネジメントの書籍を読みます。読まないまでも本屋で同ジャンルの本が平積みしてあるコーナーで足を止め、パラパラと書籍を流し読みすることは日常茶飯事です。多くのプロジェクト管理本を読んでいると、「プロジェクト管理はこうあるべき」、「正しい見積なくしてプロジェクトの成功はない」、「無謀なスケジュールのプロジェクトがまかり通っている」などのフレーズが多数出現しますが、私はそれを目にする度に、「おいおい、ちょっと見方が浅くないかい?」と思うのです。それは「ソフトウェア開発方法論がビジネスモデルとセットで語られていない」ということです。ソフトウェアという産業は他の産業と組み合わさることでよりレバレッジが効く 産業です。そしてその組み合わせ先となる産業は実に様々であり、ソフトウェアの開発方法論はその組み合わせ先産業のビジネスモデルにの影響を強く受けると私は考えています。よりわかりやすく言うと、

  • 物流産業 + ソフトウェア 

の場合と、

  • 映画産業 + ソフトウェア

の場合では取りうる開発方法論は明らかに異なると思うのです。しかしながらソフトウェア開発方法論の書籍を見ていると、組み合わせ先残業のビジネスモデルが話題になることはありません。でもこれは考えてみるとある意味当然と言えます。組み合わせ先の産業なんて無限に存在するわけですから、それぞれのケースについて1つの書籍書くこと自体無理があります。では特定の産業との組み合わせについて書けばどうかという話もありますが、これは対象読者が狭まるため、あまり良い方法とも思えません。結局は多くの組み合わせ先産業に共通する一般論としての開発方法論を記載することに留まるのが自然で、恐らく世の中の開発方法論について書かれた書籍はほとんどがそのコンセプトで書かれていると思われます。

私はケータイサイトの構築・運用に関するプロジェクト管理を生業としています。つまり私の組み合わせ産業はケータイ業界であり、私の理論で言えば、私のソフトウェア開発方法論はケータイ産業のビジネスモデルに依存するということになります。ここでいうケータイ産業とは携帯電話産業ではなく、ケータイを使ったサービス産業のことです。

私は携帯電話を利用したサービス産業のことを『ケータイ業界』と呼んでいます。「携帯」ではなく「ケータイ」とあえて書くところがミソで、私の中では「携帯」と漢字で 書くと携帯電話端末そのものやその端末の開発に関わる業界を指し、「ケータイ」とカタカナで書くと携帯電話を利用したサービスとそのサービスに関わる業界を指します。これは携帯電話の保有率が1人1台を突破し、もはや携帯電話がコミュニケーションツールとして(明示的に)意識されることすらなくなったことを受けて、私の中で区別している概念です(若い女の子が携帯電話を「ケータイ」と普通に書くことを起源としています)。

私はケータイ産業でもエンタメ系のお仕事をすることが多く、着うたや電子コミックの販売サイトを主に手がけてきました。ここで私の所属するケータイ産業(特にエンタメ系)のビジネスの特長について軽く説明したいと思います。主な特長は以下でしょうか。

  • 開発期間は2週間〜3ヶ月程度
  • キャンペーン用のケータイサイトを作ったり、本格的な物販サイトを構築したりなど規模は様々だが、概ね顧客から上記のスケジュールを提示されることが一般的
  • 高度な技術を求められることは少なく、「PCの劣化版」としてのケータイサイトの構築を求められることが多い
  • 開発人員は1人〜(多くて)20人程度
  • PMは開発出身者がほとんど
  • 最優先事項はリリース期間の最短化であることが多く、RFPに品質の記述が盛り込まれることは少ない

全体的な印象としては短期リリースであることです。エンタメ系のケータイサイトは、販促媒体として用いられることが多いため期間限定性が強く、そのため短期リリースを迫られることがほとんどです。これはどういうことかというと、例えばある飲料メーカーとレーベルがタイアップして、「飲料を購入したらQRコードからのアクセスで、着うた1曲プレンゼント」などというキャンペーンがあったとします。レーベルとしては飲料販売を販促手段として利用したいわけですので提供される楽曲は当然旬なものになります。つまり時期的な制約が非常に強くなるのです。締め切りに遅れる=旬な時期を逃す=費用対効果が薄い という式が成り立つため、企画内容は「決められた期間でできるもの」という発想が先行します。

これはシステム系の業界から転職して来た人には結構なカルチャーショックらしいです。

一般的にソフトウェア開発は数%の例外処理のためにかなりの開発工数を費やすしますが、上記のような発想でシステムを構築する場合、「数%の例外処理が工数を圧迫する」と判断されるとその例外処理の実装自体を行わない場合もあります。これは「まれに発生するユースケースを全くフォローしない」ということを意味しており、もちろんシステム的には良いわけはありません。しかし数%の例外を犠牲にすることで90%の利益を享受できるのであればそれはビジネスにとって成功と言えるかも知れません。なぜなら発注側にとってはそこまでしてでも「このタイミングを逃すわけには行かない」という強い要求を満たすのですから。このような要求を満たそうと思った場合、当然開発方法論もそれに最適化されたものとなります。私の経験ではほとんどの場合以下のような開発手法が採用されます。

  • 画面遷移をベースとした最小限の要件定義
  • マイルストンをベースとしたスケジュール作成
  • 短期リリースによって顧客の確認ポイントを多く設け、フィードバックはそのタイミングで都度実施
  • ごくまれなユースケースへの対応の放棄
  • 問題発生時の対応方法は関係者による都度対応が基本(=リスク管理コストの放棄)
  • 品質基準は唯一「機能要件を満たしていること」のみ

「これが開発手法なの?」という声が聞こえてきそうですが、これが現実なので包み隠さず書かせて頂きます。また我社の名誉のために弁明させてもらうと、現在でもこのような開発手法を続けているわけではありません。リスク管理やWBSを用いたスケジュール作成など、それなりの手法を取り入れています。

上記の開発方法論は一般的には 悪しき習慣 とみなされると思います。しかし上記の方法論を採用して顧客のビジネスチャンスを成功に導いた実績があるとしたらそれは悪なのでしょうか? 私はそうは思いせん。なぜならソフトウェアは他のビジネスをサポートしてこそレバレッジが効く技術だからです。この場合であれば「ビジネスタイミングを逃さない」という最大要求を満たしてこそソフトウェアが存在する本当の意味があると私は考えます。よってその最大要求を満たすために考え出された(=実際満たしている)開発手法が一概に悪だとは言えないと思うのです。

もちろ私は上述した方論論が最適だと言うつもりも、締め切り先行だから仕方ないと思うこともありません。本投稿で私が言いたかったことは以下です。

  • ソフトウェアの開発方法論はビジネスモデルとセットで論じられるべきで、ビジネスモデルのPriorityに合わせて開発方法論も適切に調整されるべき

これは知ってるようで意外と知らない事実だと思います。世の中の多くのプロジェクトマネジメント書籍がビジネスモデルに言及していないことからもそれが伺えます。なので世の中のソフトウェア系のプロマネの方は、[ビジネスモデル ⇒ 開発方法論] の順序でプロジェクトマネジメントシステムを作り上げなければならず、そして最適な開発方法論はビジネスモデルを詳細に分析することで自然と導かれるものだと私は考えています。なので皆さんも開発方法論を検討する時は、ビジネスモデルの存在を強く意識することをお勧めします。

※このエントリは CNET Japan ブロガーにより投稿されたものです。朝日インタラクティブ および CNET Japan 編集部の見解・意向を示すものではありません。
運営事務局に問題を報告

最新ブログエントリー