Comments
Description
Transcript
1 システム開発上流工程と 主要なドキュメント
.1 システム構築プロジェクトの現状と課題 1 システム開発上流工程と 主要なドキュメント ドキュメント・レビューを効果的に行うには、まず現状認識を正しく行い、問題意識を持 つことが重要である。その上で、なんのためにドキュメントをレビューするのかという目的 を、しっかり押さえておく必要がある。ドキュメント・レビューは、単に成果物としてのドキュ メントの正当性や妥当性を評価するだけにとどまらず、プロジェクト管理の基礎を成すも のである。 そこで、本書では特に、プロジェクトの成否に影響の大きな上流工程にかかわるドキュ メントを中心に、レビューを行う上での視点やポイントについて解説するが、形式化され たドキュメントだけでなく、プロジェクトを通じて生成される形式化されない種々のドキュメ ント（ホワイトボードのメモなど）や口頭での打ち合わせなどのレビューにも使えるもので ある。 システム構築に限らず「ものづくり」というのは、意図した「もの」に関する情報を、いか に最終的な形としての「もの」に正しく伝えるかというところに成否が掛かっているといっ ても過言ではない。つくるものが複雑、大規模になり、完成までの工程や関係者が多くな ればなるほど、情報の正確な伝達は難しくなるのが当然である。したがって、形式化され ているかいないかにかかわりなく、情報が正しく伝わっているかを途中段階で適宜、確 認し、早期にリスクを発見し予防策をとっていくことが、成功率を高めるためのプロジェク ト管理の基本である。 1. システム開発上流工程と主要なドキュメント 1.1 システム構築プロジェクトの現状と課題 （1）プロジェクトの成功率 ある調査では、システム構築プロジェクトの成功率は約 30％程度だといわれている。こ れは、国内の調査だけでなく、欧米の調査においてもほぼ同程度の結果となっている。 ここで成功といわれているのは、品質・コスト・納期、いわゆる QCD（Quality、Cost、 Delivery）を当初の目標どおりに守り、完了できたプロジェクトのことである。また、プロ ジェクト完了後の運用フェーズまで含めて、当初のプロジェクトの目的を達成できたかど うかまでを含めると成功率は、さらに悪化するといわれている。実に低い成功率だといえ るだろう（図 1. 1）。 3 回に 1 回しか、 QCD を満足する結果を得られないのである。世の中にはさまざまな 業種があり、さまざまなプロジェクトが存在するが、このように成功率の低いプロジェクト はほかに類を見ないのではないだろうか。あの宇宙開発のロケット打ち上げでさえ、成 功率は 70∼90％である。そして、このような低い成功率が許容されているプロジェクトと いうのもまた珍しい。ロケットの打ち上げが、3 回に 1 回しか成功しなかったり、プラント建 設が 3 回に 1 回しか成功しなかったりしたとしたら、大問題とされるのではないだろうか。 このあたりは、システム構築プロジェクトは、まだまだよちよち歩きの赤ん坊と同じなので、 成功率が低くても仕方がないと社会的に一人前の大人として見られていないのだろうか。 あるいは、ロケット打ち上げプロジェクトに比べて、重要度が低いのだと見られているとし たら残念なことだ。 一方で、ロケット打ち上げやプラント建設などのプロジェクトで、設計審査を実施せずに 着工することなど考えられないが、システム構築プロジェクトでは、必ずしも設計審査が 十分に行われていないという実態もあるように思われる。 いずれにしても、意図したものや要求されたものを、所定の QCD を満たして完成でき ないのであるから、システム構築プロジェクトが未成熟な分野であることは間違いなさそう である。 .1 システム構築プロジェクトの現状と課題 品質・コスト・納期を守り、 中止 成功 目的・目標を達成できた。 不成功 図1.1 システム構築プロジェクトの成功率 では、失敗とされる 70％はどうなっているかというと、そのうちの 40％はコスト・納期を 超過するか、品質を落とすなどしながらも、なんとか完了したプロジェクトである。そして 残りの 30％は、途中でキャンセルされ、結局最後まで完了しなかったプロジェクトである。 プロジェクトを途中でキャンセルして白紙に戻してしまうかは、国民性や組織風土の違い などにより国内と欧米では、若干、数字が変わってくるようである。 日本では、規模が大きくなればなるほど関係者に配慮して、完全に失敗プロジェクトと してすべてを白紙に戻すような決定が行われることは少なくなるようだ。それでも、規模 が小さいからキャンセルするのかというと必ずしもそうではなく、数億円・数年かけたパッ ケージ導入プロジェクトを、実用開始直前に自社の業務に適用することができないことが 判明したとしてキャンセルし、開発費用を損金処理するというような記事を国内の事例で も見かけることがある。関係者は、決していい加減な気持ちでプロジェクトを遂行したわ けでも、安易にキャンセルしたわけでもないだろう。それこそ社運をかけて人材やリソー スを投入していると思われる。 しかしながら、建設業界などでは、数億円・数年かけた建設プロジェクトが完成している にもかかわらず、実用化直前にキャンセルになり、建設物を取り壊したり、廃墟のままに したりというような事例はほとんど聞くことがない。 このように、他業界ではめったに起こりえないことが、システム構築プロジェクトでは実 際に少なからず起きているのが現状である。まして、コストの超過、納期の延長、品質に 対する利用者の不満などは、調査に見るまでもなく日常的に身の回りで起きているので はないだろうか。 このようにシステム構築プロジェクトは、意図したとおりに完成することが非常に困難な 1. システム開発上流工程と主要なドキュメント 「ものづくり」分野であるという認識が改めて必要である。 ソフトウェア工学が誕生してから 50 年余りが経過したが、建築工学に比べれば歴史が 浅く、まだまだ、意図したとおりの「ものづくり」ができるほど成熟してはいないといわざる をえない。また、システムや業務というもの自体が、目に見えるものではなく、極めて概念 的なものであるため、意図を言語で伝えることが主体となっていること、最終成果物であ るソフトウェアも言語であること、利害関係者が複雑に関与することなどが、さらに「ものづ くり」という面での状況を悪化させている。 自分の意図するところを正確に言語で表現できるというのは、ある意味、特殊な能力を必 要とするのである。ほとんどの「ものづくり」では、意図するところを言語による表現ととも に、最終的な完成の形態をスケッチ画などで伝えることができるが、システム構築の場合 は、業務フローやシステム構成図などで表現したとしても、それは、システムの姿を抽象 的に代弁するにすぎず、決して、完成の形態を直接的に表現したものではない。画面や 帳票のスケッチ画なども存在するが、それは、システムのユーザ・インタフェースという極 めて部分的かつ表面的な要素を示しているにすぎず、システムの本質を表したものでは ない。 システムの本質、特に完成した形態となるソフトウェアの実態は、コンピュータ言語に よって記述された論理の集合体であり、その意図を初期の構想段階で正確に図示するこ とは、原理的に不可能なのである。これから作ろうとするものの意図を十分表現すること ができず、完成の形態が不明確であるということは、当然、完成に至るまでのコストや納 期の見積りも正確に行うことは困難となり、品質目標も曖昧になりがちになってしまうので ある。 その結果、設計結果や完成したシステムが意図したものと違うということになり、その後、 なんとか意図したものにあわせようとしてさまざまな努力が重ねられるが、結局、コスト・納 期を超過し、品質も不十分という「失敗」に終わっているのが現状である。 （2）主な失敗の原因と課題 それでは、一体どのようなことがプロジェクトの失敗原因となっているのだろうか。これも .1 システム構築プロジェクトの現状と課題 さまざまな調査や、失敗事例研究などが行われたりしているが、常に上位に上げられる のが、トップマネジメントの関与欠如、目的や要件定義の不明確、要求仕様の変更、利害 関係者の調整不足、不十分な見積り、要件と設計の不整合などである（図 1. 2）。 これらは、技術的というよりは、それ以前のプロジェクトのあり方やコミュニケーションと いった人的要素に起因したものばかりである。これも言語活動を主体とするシステム構築 プロジェクトの特異性だといえよう。そもそも、トップマネジメントの関与が欠如していると いうことは、プロジェクトの目的や目標をトップが明確に伝えることが困難であるため、シ ステム部門やメーカに任せ切りにしてしまう傾向があるということだ。トップが意図するとこ ろを十分に関係者に示すことができず、また、関係者が説明する内容を十分に理解でき ていないという状況の中で開始されるのが、システム構築プロジェクトである。 ○トップマネジメントの関与欠如 ○目的や要件定義の不明確 ○要求仕様の変更 ○利害関係者の調整不足 ○不十分な見積り ○要件と設計の不整合 図1.2 主な失敗の原因 はじめのボタンのかけ違いがこのような状況であるから、その後の要件定義や設計で 意思疎通がうまくいかないのも「推して知るべし」である。 例えば、製造業の経営者であれば、これから開発する製品についてはもちろんのこと、 機械設備の導入に当たっても無関心であったり、目的や必要理由をしっかりと理解でき なかったりということは考えられない。しかし、ことシステム構築プロジェクトになると、投資 金額の大小にかかわらず経営者が適切に関与すべきところで関与していないということ が発生している。この原因は、経営者が情報技術というものの本質を十分に理解してお らず、自社にとっての価値を測ることが困難であるためと考えられる。なぜなら、コン ピュータをはじめとする情報技術が出現してから歴史も浅く、現在の多くの経営者は、コ ンピュータというものにじかに触れたことが少なく、プログラミングなど行った経験は皆無 であろう。 1. システム開発上流工程と主要なドキュメント しかも、情報技術の進展スピードがあまりに速く、とてもキャッチアップできるものではな い。これに比べ、ハードウェアの世界は、幼少のころから自動車模型に触れたり、学校で も理科工作などの授業などがあったりと、皮膚感覚で「ものづくり」を理解しているところが ある。つまり、多くの経営者にとって情報技術は、概念的なものでしかなく「得体のよく知 れないもの」なのだ。 このような状況を少しずつでも改善していくには、情報技術をよく知っている人間が、 しっかりと経営者に対して説明責任を果たしていく必要がある。 しかし、これまで情報技術側の人間は、いわゆる、プログラマに代表されるように、専門 用語を並べてばかりで、なにを話しているのかよく分からないと評されてきた。これは、 情報技術を扱う上で、コンピュータに向かい合っていさえすればよく、経営者に情報技 術の本質や有効性などを情報戦略としてまとめ、経営戦略との関係を適切に説明する機 会が少なかったことも一因であろう。これが、よくいわれる「経営と情報技術の断絶」であ る。 最近でこそ、マスコミなどが情報システムの大きな事故を取り上げるようになったり、テ レビコマーシャルでも情報技術関連のものが流れるようになってきたりしており、経営者 も情報技術に対する関心を向け始めたものの、まだまだ、根本のところでは、状況が改 善されてきているとはいいがたい。 今後も引き続き、経営者の情報技術に対する真摯な関心・関与に基づくさらなる学習と 情報技術関係者の説明責任を果たすことによる「経営と情報技術の融合」に向けた相互 理解の努力が必要とされる。 システム構築プロジェクトの立ち上がりにおいて、経営者の関与が欠如しているため、 本来の目的が曖昧になり、これが要件定義の不明確にもつながっている。目的が曖昧な 上に、業務側の利用者も経営者と同じように情報技術に直接触れた経験がないのがほと んどである。それでも、情報化の初期段階で、単に手作業でやっていた伝票処理を、コ ンピュータで計算するというようなケースでは、その目的も明確であり、要件を伝えるのも 簡単であった。 手作業でやっている計算手順をプログラマが理解して、それを、コンピュータが理解で きる言語（プログラミング言語）で表現すればことたりたからだ。しかし、昨今のシステム構 築プロジェクトでは、その目的も経営上の競争力を強化するためであったり、経営戦略を 実行する道具であったりと高度化しており、そのため業務プロセスを大きく変更することも 少なくない。このような状況では、業務側の利用者が完成システムの形態を明確にイメー .1 システム構築プロジェクトの現状と課題 ジし、求める要件を正確に表現し伝えることが急に難しくなってくる。 たとえ、明確にイメージできたとしても、それが正しいという保証はどこにもない。その 要件定義で、経営上の目的を達成することができるのかと経営者に問うてみても、やはり、 明確な答えは返ってこないのである。極論すれば、「使ってみなければ分からない。 やってみなければ分からない」ということも決して不思議ではない。 要件定義が不明確であるから、当然、その後の要求仕様は変更が多発するし、利害関 係者の調整も不十分なまま進むこととなる。利害関係者を集めて調整しようにも、肝心の トップマネジメントが適切に関与しないので、目的や要件定義が不明確となり、その結果、 部門利益や個人利益が最優先されるため、利害が相反して調整がつかないのである。こ ういった複雑かつ不可解な状況では、正確な見積りをすることも非常に困難である。さら に、情報技術の高度化や複雑化、開発期間の短期化などが見積りの困難さに輪をかけ ることになる。 このように不明確な目的や要件定義、要求仕様の変更多発、不十分な利害関係者の調 整、不十分な見積りの上で、設計作業が展開される。設計作業は、要件定義や要求仕様 を満足するために、最終的にコンピュータやネットワークといった実体の上に、具体的な 実装を展開していく作業である。ここでは、不明確さや曖昧さというものは基本的に受け 入れられない世界であり、 YES／NO の論理世界である。 設計者は、要求仕様を満足するために YES／NO を選択していくことになるが、その 拠り所となる目的や要件などが不明確では、適切な選択を行うことが困難である。困難で あるが、これを決めなければ実装することができないので、ある意味、独断で設計者が 選択したり制約条件を決めたりしていく。その結果として、当初の目的や要件と設計の間 で不整合が発生してしまうのである。これが、品質・コスト・納期に影響を与えることは、想 像に難くないであろう。 システム構築プロジェクトの主な失敗原因と課題は、コミュニケーションという一言では 語りつくせないほど、意思伝達にかかわるさまざまな課題が存在するのである。トップマ ネジメントの意思や利用者の意図を正しく、開発者に伝え、開発者の意思を正しく、利害 関係者にフィードバックしていくことが重要であり、それが、システム構築プロジェクトを適 切にマネジメントするための基本である。この時、自分の意図や意思を、口頭ベースの 言語コミュニケーションだけで正確に伝えられる人間は少ない。また、図表だけでも正確 に伝わらない。ISO9000 や金融商品取引法（日本版 SOX 法）などでも内部統制を確立 するためにプロセスの文書化から始めるのは、業務やシステムといった概念的なものを 1. システム開発上流工程と主要なドキュメント 「見える化」し評価するためである。 したがって、システム構築プロジェクトにおいても、適用する開発プロセスがなんであ れ、表現方法がどのように形式化されているかは別にして、「ドキュメント」は、意思を伝 達し評価するための重要な道具である。道具の形式や作法の正しさが重要なのではな い。あくまで、そこに表現されている内容が、意思を正しく伝えているかを適宜、評価し フィードバックすることが重要なのである。