プロジェクトファシリテーターのじゅんです。
私は、携帯電話や通信機器に関する大規模システムや金融系の大規模システム、会計業務の新規システム導入などのプロジェクト運営と支援を数多く行ってきました。
その中で、技術的に高スキルを持ったプロジェクトメンバが集まったとしてもプロジェクト運営が破綻してしまうケースがあります。
そのようなことにならないようにするために、私が普段使用しているシステム化プロジェクトを成功させる原理原則17か条を紹介します。
今回ご紹介する内容は、IPA（情報処理機構）と呼ばれる機関が公開している情報が元になっています。
IPA（情報処理機構）は、日本におけるIT国家戦略を技術面、
人材面から支えるために設立された経済産業省所管の中期目標管理法人となる独立行政法人です。
このIPAでは部会や研究会が多く存在し、多くのシステムベンダーの経験則から今回紹介するようは資料や報告書が提供されています。
今回紹介する内容は、多くの企業におけるプロジェクト運営やシステム開発プロジェクトの経験からまとめられた資料を元にしています。
普段のプロジェクト運営にお役立てください。
スポンサーリンク
IT化がうまくいかない！そんな悩みをいつも抱えていませんか？
受注者に言いたいことが伝わらない
プロジェクトの途中で役員からちゃぶ台返しに合う
使いやすいシステムが導入されない
発注者が曖昧な表現ばかりで何を言っているかわからない
こんなことを感じたことはないでしょうか。
ユーザ企業とベンダ企業との間での会話、同じ社内でも事業部門とシステム部門でこのような会話は多く見受けられます。
業務をシステム化したり、システムを導入したり、新規事業を立ち上げるためのシステムを構築したり、する場合は、
要件定義と呼ばれる「システムでこうしたい！」ということを明確にする工程が存在します。
開発手法には、ウォーターフォール型やアジャイル型などがありますが、
手法が変わったとしても「どのようなシステムや仕組みにしたい」と言ったような内容は必ず必要です。
そんな時に先人たちがまとめてくれた原理原則を頭に入れて、プロジェクトに反映させて進めるだけで、
成功率が格段にあがります。
あたりまえのようなことが書かれているのかも知れませんが、一つでも収穫があると嬉しいので見てみてください。
発注者と受注者の定義についてはこちらの記事を参考にしてください
システム化プロジェクトを成功させる17か条を活用してプロジェクトを成功させよ！
システム化プロジェクトは技術背景や経験値が違う関係者が多く集まってプロジェクトを進めます。
そのため、空気を読んだり、行間を読んだりする、言わなくてもわかるよね！ということが通用しません。
そうならないようにするための17か条です。
読んでみるとすごく当たり前のことを書いているように思いますが、この当たり前のことを疎かにしたがためにプロジェクトが破綻してしまうケースもあります。
想定していた投資費用が倍になった。
いつまでもシステムが稼働しない。
プロジェクトそのものが一向に進まない。
システムリリース直前になって動作が違っていることが発覚した。
こんなことが当たり前のように起きてしまうのがシステム導入プロジェクトです。
それらを少しでも防ぐことができるように原理原則として17か条を紹介します。
この原則はプロジェクトを進めるにあたってプロジェクト関係者全員が改めて認識合わせをすることでプロジェクトが成功しやすくなります。
少なくとも、プロジェクトマネージャはこの原理原則を頭にいれ、日々のプロジェクト運営に役立てていただけると嬉しいです。
それぞれの具体的な解説に関しては、別記事でご紹介しようと思っております。
（準備中）
システム化プロジェクトを成功させる17か条
プロジェクト全体
- 関係者それぞれの想いを理解する
- 要件定義は発注者の責任である
- プロジェクト関係者にシステム化方針・狙いを徹底的に周知する
- 要件定義書をプロジェクトの羅針盤とすること
- 取り決めは明確に合意と承認を行い、記録に残すこと
工程／イテレーション
- プロジェクトの成否を左右する要件は工程を止めてでも確定させること
- ステークホルダーの合意を得てから次工程に進むこと
コスト
- 見積もりと契約は多段階に分けて行うこと
- システム化実現の費用は、関係する費用すべてを洗い出し、スコープを明確にすること
- システムのライフサイクルコストを意識して投資判断・費用算出を行うこと
要件定義
- 要件定義書では、機能要件・非機能要件を具体的に精緻化すること
- 要件に記載のある内容＜のみ＞が、実現されることを認識すること
- 要件は可能な限り数値化すること
- 要件はプロジェクトが進むにつれて膨らむ傾向が高いことを認識する
- 「今と同じ」という要件の場合であっても具体的に要件を記述する
- 要件定義は、運用を想定した業務システム定義をすること
- 要件定義は、発注者は要件を伝え、受注者は認識合わせを行うこと
IPAのIT化の原理原則を修正して作っています
前述した17か条は私がプロジェクト運営をする時に使用している内容を掲載させていただきました。
実は、この17か条ですが、IPAの資料をそのまま使用したものではありません。
IPAの資料のコンテンツは素晴らしいのですが、実際に使おうと考えた時にちょっと使いづらい以下のような点があったので
プロジェクト関係者に説明しやすいように修正して使用しています。
（もちろん元ネタを付け加えてです。）
・17か条の表現が否定形や現象の説明が多く、聞いても行動に結びつかない
・カテゴリわけもされていないため、プロジェクトのどのポイントで意識をすればよいか分かりづらい
という先人の知恵を使い倒して成功確率を上げましょう
IPAの資料に記載されている原理原則は以下のようになっています。
【１】ユーザとベンダの想いは相反する
【２】取り決めは合意と承認によって成り立つ
【３】プロジェクトの成否を左右する要件確定の先送りは厳禁である
【４】ステークホルダ間の合意を得ないまま、次工程に入らない
【５】多段階の見積りは双方のリスクを低減する
【６】システム化実現の費用はソフトウェア開発だけではない
【７】ライフサイクルコストを重視する
【８】システム化方針・狙いの周知徹底が成功の鍵となる
【９】要件定義は発注者の責任である
【１０】要件定義書はバイブルであり、事あらばここへ立ち返るもの
【１１】優れた要件定義書とはシステム開発を精緻にあらわしたもの
【１２】表現されない要件はシステムとして実現されない
【１３】数値化されない要件は人によって基準が異なる
【１４】「今と同じ」という要件定義はありえない
【１５】要件定義は「使える」業務システムを定義すること
【１６】機能要求は膨張する。コスト、納期が抑制する
【１７】要件定義は説明責任を伴う
本日の提案｜プロジェクトを成功させるためにIT化の原理原則17か条を活用しましょう！
・システム化プロジェクトを成功させる17か条を頭に叩き込みましょう！
・プロジェクト関係者と共有しましょう！
・活用しなくても知っているだけでどこかで役に立ちますよ！
IPA資料との対比表
私が使いやすいように表現と順番を変更していますので、元のIPA資料との対比を以下に書いておきます。
出典：【IPA】SEC BOOKS：実務に活かすIT化の原理原則17ヶ条
https://www.ipa.go.jp/sec/publish/tn10-001.html
投稿者プロフィール
- プロジェクトファシリテーター
-
フリーランスのITコンサルタント として、CIO代行サービスで多くの企業をサポートしています。
企業のIT戦略 立案・実行支援を行い、
ITを活用した情報システム の導入・マネジメント支援しています。
IT利活用 に関して気軽な相談から経営に関わる支援まで幅広く受け付けています。
普段私が仕事をする時にお客様やプロジェクトチームの方々に実際に話している内容をたくさんの方々に届けます。
DX（デジタルトランスフォーメーション）が好きすぎるので「DX王子」と呼ばれています。
最新の投稿
仕事術2024年8月29日面談前に職務経歴書などの提出をお願いする理由を解説します！
フリーランス2024年3月22日フリーランス年収1000万を目指すなら「誰の言葉か？」が重要
仕事術2024年3月19日なぜオンラインミーティングを録画するのか！？メリットしか無いからです！
フリーランス2024年3月4日50歳以上のエンジニアに送る！あなたに仕事がない理由
