開発プロジェクトにも有効な「80:20の法則」:情報マネージャとSEのための「今週の1冊」(49)
開発期間やリソースは限られているのに、やらなければならないことが増えてしまいがちな開発プロジェクト。しかし、少し考え方を変えると、効率化の大きな可能性が見えてくる。
プロジェクトを変える12の知恵
「業務プロセスを完全に正しく分析して、そこからシステム機能要件を完全に正しく抽出し、完全に正しく定義する」。そうすれば「下流工程で追加や変更は起こらない」――開発プロジェクトに携わっている人なら、このような一文を読んだ瞬間に文句を言いたくなることだろう。できればとっくにやっていると。だがプロジェクト関連に限らず、書籍やインターネットに溢れているハウツーには、セオリーだけを述べて、実践に役立つ情報までは示してくれないケースが多い。その点、本書「プロジェクトを変える12の知恵」はそうした言いっ放しの作品とは異なり、冒頭の一文にこう続けるのだ。
「でもそんなのムリですよね? 確かに『完全に正しい要件定義』は理想形の一つだと思います。でもおそらく『完全に正しい要件定義』に挑戦しようとすると、おそろしくカネがかかることでしょう」「私たちが目指しているのは、精緻さではなく、的確さです」。
要件定義や課題管理など、プロジェクトにはやるべきことが数多くある。だが「(要件定義で大切なのは)精緻さではなく、的確さ」という一言が象徴しているように、あらゆるミッションは「何が求められているのか」という“目的”をとらえることが確実・効率的に実現するための基本となる。そして目的が分かっていれば、注力すべきこともおのずと見えてくる――本書はそうした考え方に基づき、どうすればセオリーを実現できるのか、ITコンサルティング会社、ケンブリッジ・テクノロジーズ・パートナーズが蓄積してきた実践的なノウハウを伝授してくれる作品なのである。
例えば要件定義なら、ユーザーに希望された機能要件の「全てを実現するわけではない」ことを前提に考える。ユーザーが欲しているのは、「望む機能を全て搭載したシステム」ではなく「ビジネスに役立つシステム」だ。そして望まれる「各要件の重要性は一様ではない」。中には「毎日使う絶対に必要な機能」もあれば、「一年に一回しか使わない機能」もある。よって、真に必要な機能のみに絞り込んだ方が、きちんと使いこなせるし、開発期間とコストも抑制できると説くのだ。
ただ、要件を絞り込むためには、まずユーザーが希望する要件を全て「出し切る」ことが求められる。要件定義を固め、手戻りや二度手間を防ぐためには、ユーザーの“納得”が不可欠となるためだ。
そこで要件定義書には「やること」だけではなく「やらないこと」も、その理由とともに記録しておくべきだという。そうすれば、全要件について採用の可否を“検討した記録”が残る。これにより、関係者の思いがくすぶり続けて、後で蒸し返される可能性が低くなるほか、仮に蒸し返されても、採用しなかった理由とともにその要件を記録してあれば、無駄な議論や手間を抑制できるためである。
筆者はこうした「目的」から考えるコツとして、「80:20の法則」を紹介する。ご存じの通り、「経済活動のほとんどの結果は、少ない要因から成り立っている」ことを示したパレートの法則だが、これは今日、「利益の80%は20%の優秀な社員によって」、「売り上げの80%は20%の商品によって」もたられさているなど、あらゆる分野に適用されている。筆者はそうした例を挙げて、プロジェクトにも適用できると説くのだ。
すなわち、「80%の成果は20%の時間(やコスト)で達成される」というわけだが、この考えを念頭に置いておくと、「時間(やコスト)を掛け過ぎていないか?」「余計なところまでやっていないか?」「期待した程度以上にやっていないか?」「他に優先度の高いタスクはないか?」という意識がおのずと働くようになるという。むろん「80:20の法則」をプロジェクトのすべてに適用できるわけではないが、「あれもこれも」では時間とコストがオーバーしてしまう。よって、「大半の成果をより少ない時間で達成する」という意識を常に忘れず、「目的」に照らして「できることは何か」「最低限、すべきことは何か」と、やるべきことを絞り込んでいく考え方が大切なのだという。
では具体的にはどうすれば良いのか? 本書はそのための“知恵”を豊富に紹介している。「ゴールにそぐわない議論はしない」「定期的にチェックポイントを設ける」「20分ルールを設け、必要以上に悩んで止まらない」といったキーワードも、全て「80:20の法則」にのっとったものだ。こうした言葉に興味を感じた向きは、ぜひ手に取ってみてはどうだろう。課題に対して“真っ向勝負”になりがちな人ほど、効率化の大きなヒントを獲得できるかもしれない。
- 人はなぜ不正を働くのか?
- なぜIKEAは世界中で支持されるのか
- 今こそ「メディア」を考える
- 部下を信じ、尊敬する
- ご機嫌取りになれ
- “暗い未来”に漫然と向かわないために
- 1つの行動が社会を変革する
- あなたには確固たる「ミッション」があるか?
- 「会社に行きたくない」人ほど会社に依存している
- 失敗の2大パターンは“精神論とお役所仕事”
- コミュニケーションは、ツールではなく人が行うもの
- 社員が疲弊している会社は、経営層とITに問題あり
- ロジカルシンキングで成果が出ない訳
- 手段ばかりを求めていると、結果は出せない
- 「技術へのこだわり」という日本企業の根深い病
- 日本軍とまったく同じ、日本企業の“敗戦理由”
- “技術だけ”では、開発プロジェクトは失敗する
- 断捨離で、業務とシステムはもっと快適になる
- 仕事でモメたくない人のための教科書
- その油断と慢心が“炎上”を招く
- 本当は怖いフェイスブック
- 組織も自分もダメにする「自分大好き」という病
- 災害対策、コスト削減、システム改善は全て同じ問題
- あなたなら、自社システムをどう攻撃する?
- “想定外”から1年、見て見ぬふりはしていませんか?
- ナイトライダーも示唆する人とシステムのあるべき関係
- アップルが成功し、ソニーが失敗した理由
- 貴社のビジネス、ITシステムに“マインド”はあるか?
- 何のために働くのか? その回答はシンプルそのものだ
- 事故を起こす企業の特徴は、「責任者が不明」
- スマホ導入は、セキュリティポリシー設定がキモ
- 失敗は、「簡単なこと」「当たり前のこと」で起こる
- ITがどれほど進展しても、経営の基本は変わらない
- コピペやお絵かきが得意な人は“中毒”の疑いあり
- 情報は、人間関係があって初めて有効に活用できる
- “顧客”や“ユーザー”との関係作りを見直そう
- システム導入・浸透のポイントは“楽しさ”にあり
- “当たり前”を覆すチャンスはまだまだ埋まっている
- ソーシャルメディア・リテラシが収益を左右する
- 技術者はアーティストであり、製造業者ではない
- 分析するのは「ツール」ではなく「人」である
- ブランドは、消耗品である
- 当然のことを当然にこなすための指南書
- リスクを知っていてこそ、スマホは使いこなせる
- 個人でも企業でも、“ナンパ野郎”はウザいだけ
- 「見える化」だけでは、ビジネスは進まない
- 2ちゃん、ニコ動、外務省。次の標的は貴社のサイト!?
- あなたの会社は「突然死」の危機にさらされている
- BCPは、業務部門と情シスが連携して初めて成功する
- 仕事や人生、そして復興にも、秘策はない
Copyright © ITmedia, Inc. All Rights Reserved.