技術は変わるが開発の失敗原因は変わらない:情報マネージャとSEのための「今週の1冊」(55)
クラウドサービスが進展し、「ITは利用する時代になった」などと言われ始めて久しい。だが、システム開発の基本はどんな時代になっても決して変わらない。
ヒューマン・コミュニケーションで成功する情報システム構築
クラウドサービスやパッケージ製品が充実し、企業にとってますます情報システムを利用しやすい環境になっている。だがシステム構築の現場では、「毎日のように徹夜したり、出社拒否となった部下の説得に自宅に赴いたり、身体を壊して入院したり……」。なぜいつもプロジェクトは予定通りに進まないのか、なぜシステム構築が失敗するリスクは高いのだろうか。それはシステム構築で求められるものが「あいまい」になりがちなためだ――。
本書「ヒューマン・コミュニケーションで成功する情報システム構築」は、プロジェクトの失敗要因として、開発関係者間のコミュニケーションの在り方に着目した作品である。冒頭で挙げた「求められるものがあいまい」というのは、システムは「ある意味、どのようにも作れる」という意味だ。よって、「どんな機能のものをどう作るかは、人対人のやり取りの中で決めていく」必要があるのだが、往々にして「開発者同士」「発注者と受注者」「担当者と管理者」のコミュニケーションが十分ではない。本書では、これがほとんどの失敗プロジェクトの原因であるとして、多数の失敗パターンを挙げつつ、システム構築を成功に導くコミュニケーションの方法を具体的に紹介しているのである。
例えば、コミュニケーション不足の典型例として「要件定義が終わった気になる」ことを挙げている。本来なら、まずは「対象となる業務を俯瞰して全体像を把握」し、「業務の規模感、問題点や課題が潜在している場所、合意形成しなければいけない利害関係者などを明らかに」する必要がある。
だが、「目先の検討課題にばかり目が向かってしまい、その都度場当たり的な解決策を抽出してしまう」。また、要件の具体化に当たり、「解決しやすい業務課題や構築しやすい業務機能にばかり目が」向いてしまう。この結果、確かに要件定義書は作るのだが、「全体として整合性が取れた解決策を」見出せていなかったり、「本質的な業務改善に結びつかない」ものになっていたりして、結局は失敗するというわけだ。
筆者はこれに対して、「情報システム構想で定義した全体概要をもとに全社でウォークスルーを実施し、業務機能に漏れがないか、課題抽出に偏りはないか、利害関係者は正しく抽出されているかを確認する」べきだと述べる。これによって漏れや不備が検知された場合、即座に軌道修正しなければ、利害関係者の反発や不信を買い、「合意を得るための膨大な戻り作業や追加作業が発生するか、場合によってはプロジェクトの破綻を招いてしまう可能性もある」ためだ。
「やった気になるテスト」も失敗の代表例だという。ご存じの通り、テストには「不具合を検知するためのテスト」と「品質を保証するためのテスト」がある。前者は「単体の機能に不具合はないか」「機能間の結合に不具合はないか」といった観点からシステムの動作を検証し、後者は「業務機能や他システム間連携の整合性は確保されているか」「業務運用に耐え得るシステムとなっているか」などを確かめる。
だが現実には、納期に追われて、こうした目的の違いを認識し、それに応じた観点や検証基準をきちんと設定しないまま、ただ漫然とテストを行ってしまう。加えて「開発とテストは相反する役割」であるにもかかわらず、開発者がテストを兼務することも多く、これが余計にテストが軽視される一因となっている。著者はこうした現状に対し、重要な問題を見落として後で大幅な手戻りが生じることのないよう、テストについても関係者間でコミュニケーションを取り、「システム構想の中で、どのように品質を保証していくのか、テストの基準とやり方を十分吟味」するべきだとして、その具体的な方法を紹介するのである。
興味深いのは、プロジェクトで起こりがちな事象だけではなく、“人”にも失敗原因を見出している点だろう。例えば、優先順位付けの考え方がなく、「できます」「頑張ります」といった声を重視する「体育会系のノリ」のプロジェクトマネージャ、「担当範囲ではない」などと言って業務現場からのコミュニケーションを拒絶するシステムエンジニア、要求に一貫性がなく思いつきで要求を挙げてしまう業務現場担当者、そして「改革を掲げることで満足し、情報システム構築が開始されれば、全て現場の担当者に丸投げしてしまうような経営者」などだ。著者は「こんな関係者がいると必ず失敗する」とばっさり切り捨てている。
本書ではこうした見解を基に、「コミュニケーションは場を作ることから始まる」として、全関係者を同じ方向に向かわせるための目標設定や役割分担、ルール作成の在り方などを詳しく解説。 また、的確な結論を導き出す議論の方法や協力関係の築き方、ツール活用も含めた円滑なコミュニケーションのテクニック、そしてプロジェクトの礎となる人間関係構築の重要性など、開発成功に求められる要件を全方位的に網羅している。
ただ、本書の大きな特徴は、セオリーと呼べるような基礎的な問題解決策・回避策にフォーカスした教科書的な仕上げとしている点だ。よって、開発・運用の現場経験が長い人にとっては、すでに知っているか、体験済みの話ばかりかもしれない。だが、そもそも開発失敗の最大の要因は、多忙な日々に流されて、ありがちな事象・問題を見過ごしてしまうこと、言い換えれば、基本をないがしろにしてしまいがちな姿勢にある。その点、本書をその時々の状況に応じてひも解けば、今プロジェクトが失敗パターンに陥りかけていないか、明確に気付かせてくれるのではないだろうか。
またもう一つ、本書が示唆する重要なことは、典型的な失敗パターンは決してテクノロジにひも付いたものではないということだろう。すなわち、テクノロジのトレンドは時代とともに移り変わっても、人間がシステムを構築する限り、その基本的な失敗パターン、成功パターンは変わらないのだ。経営目標を基に、システムで実現したい要件を考え、絞り込み、計画期間内でシステムに落とし込む。このためには、関係者間の密接なコミュニケーションが不可欠になるというごく当たり前の事実を、本書を通じてもう一度見直してみてはいかがだろうか。
- 人はなぜ不正を働くのか?
- なぜIKEAは世界中で支持されるのか
- 今こそ「メディア」を考える
- 部下を信じ、尊敬する
- ご機嫌取りになれ
- “暗い未来”に漫然と向かわないために
- 1つの行動が社会を変革する
- あなたには確固たる「ミッション」があるか?
- 「会社に行きたくない」人ほど会社に依存している
- 失敗の2大パターンは“精神論とお役所仕事”
- コミュニケーションは、ツールではなく人が行うもの
- 社員が疲弊している会社は、経営層とITに問題あり
- ロジカルシンキングで成果が出ない訳
- 手段ばかりを求めていると、結果は出せない
- 「技術へのこだわり」という日本企業の根深い病
- 日本軍とまったく同じ、日本企業の“敗戦理由”
- “技術だけ”では、開発プロジェクトは失敗する
- 断捨離で、業務とシステムはもっと快適になる
- 仕事でモメたくない人のための教科書
- その油断と慢心が“炎上”を招く
- 本当は怖いフェイスブック
- 組織も自分もダメにする「自分大好き」という病
- 災害対策、コスト削減、システム改善は全て同じ問題
- あなたなら、自社システムをどう攻撃する?
- “想定外”から1年、見て見ぬふりはしていませんか?
- ナイトライダーも示唆する人とシステムのあるべき関係
- アップルが成功し、ソニーが失敗した理由
- 貴社のビジネス、ITシステムに“マインド”はあるか?
- 何のために働くのか? その回答はシンプルそのものだ
- 事故を起こす企業の特徴は、「責任者が不明」
- スマホ導入は、セキュリティポリシー設定がキモ
- 失敗は、「簡単なこと」「当たり前のこと」で起こる
- ITがどれほど進展しても、経営の基本は変わらない
- コピペやお絵かきが得意な人は“中毒”の疑いあり
- 情報は、人間関係があって初めて有効に活用できる
- “顧客”や“ユーザー”との関係作りを見直そう
- システム導入・浸透のポイントは“楽しさ”にあり
- “当たり前”を覆すチャンスはまだまだ埋まっている
- ソーシャルメディア・リテラシが収益を左右する
- 技術者はアーティストであり、製造業者ではない
- 分析するのは「ツール」ではなく「人」である
- ブランドは、消耗品である
- 当然のことを当然にこなすための指南書
- リスクを知っていてこそ、スマホは使いこなせる
- 個人でも企業でも、“ナンパ野郎”はウザいだけ
- 「見える化」だけでは、ビジネスは進まない
- 2ちゃん、ニコ動、外務省。次の標的は貴社のサイト!?
- あなたの会社は「突然死」の危機にさらされている
- BCPは、業務部門と情シスが連携して初めて成功する
- 仕事や人生、そして復興にも、秘策はない
Copyright © ITmedia, Inc. All Rights Reserved.