【読書メモ】プロジェクトマネジメントの基本が分かる本
会社の同僚から紹介されて読んでみました。
Webマーケターとして事業会社で働いてるとプロジェクトマネージャーと協業したり、自分自身がプロジェクトマネジメントを行うシーンが少なくない頻度であります。
我流でなんとかここまで頑張っていましたが、改めて基本を学びたくて本書を手に取りました。
今回は特に興味深いと思ったポイントをまとめてみようと思います。
1.プロジェクトマネジメントの仕事とは？
プロジェクトマネジメントとは球拾い
プロジェクトマネジメントを一言でいってしまうと球拾い。
練習している選手の周りでボールを拾い集めてサポートするのと同じように、プロジェクトメンバーが気持ちよく働けるように先回りして障害やリスクを取り除いたり、トラブルを最小限におさえたりする地道で細かい作業の積み重ね。
プロジェクトとメンバーを守ることが仕事
著者自身が過去にたくさんの失敗や苦労を積み重ねる中で思い返していた言葉が「プロジェクトマネージャーはプロジェクトとメンバーを守るのが仕事だ」というもの。
プロジェクトマネージャーが課題に立ち向かう際の基本スタンスだと思います。
2.プロジェクトとは何か？
プロジェクトの定義
プロジェクトとは、いまある状態からあるべき状態にするために行うスタートからゴールまで続く複数の業務。
プロジェクトの成功とはなにか
プロジェクトには「目的」と「目標」がある。
この2つの単語は見た目が似ているため、混同して使われることがあるが、プロジェクトの成功を考える際は明確に分けて理解しておく。
一言でいうと、プロジェクトの目的はプロジェクトが向かうべき最終的な到達点、プロジェクトの目標はそのプロジェクトで達成すべき基準のこと。
プロジェクトの目的とは
プロジェクトの目的とは、そのプロジェクトを
実現することで最終的に達成したいゴールのこと。
たとえば、業務システムを開発するプロジェクトであれば、プロジェクトの目的は「業務効率を改善して○億円規模のコストカットを実現し、リモートワークにも対応して働き方改革の基礎になる」といったものになる。
ECアプリを開発するプロジェクトであれば、「自社商品の利用者により利便性の高い環境を提示して、新規顧客を獲得し、既存顧客に対しては顧客 1人あたりの売上を上げる」といったものになる。
プロジェクトの目標とは
プロジェクトの目標は一般にQCD（Quality：品質・Cost：コスト・ Delivery：納期）によって定義することができる。
たとえば、業務システムの開発プロジェクトでは下記のような形でQCDを決めていきます。
● Q：要件定義で必須と合意した機能要件と非機能要件を実装する
● C：初期開発の費用は 1. 5億円を想定する
● D：リリースは 2023年の 8月末を想定する
これらをクリアすることがプロジェクトが成功したかどうかの基準になる。
ただ、プロジェクトは「ヒト・モノ・カネ」のそれぞれの領域で不確実性が高く、QCDはトレードオフ（いずれか一つの要素を優先すると、ほかの要素の優先度は下がる）の関係にあるため、プロジェクトを進行する際に状況に応じて調整を行う必要がある。
プロジェクトの本質的な特性とは
プロジェクトの失敗率の高さはプロジェクトの
3つの本質的な特性に由来します。
3.プロジェクトマネジメント≠プロジェクト管理
進行管理は仕事の一部にすぎない
プロジェクトマネジメントはプロジェクトを「管理」することであると思い込まれていることが往々にしてある。
これはProject Managementの訳語として一般的に「プロジェクト管理」が当てられるから。
しかし、本来の「manage」という単語には、「物事の進行の責任をもつ」や「困難な状況でも協働して目的を達成したりプロセスを維持したりする」という意味がある。
プロジェクトの「管理」だけを主眼としてしまうと、「打合せで進捗を確認するだけ」や「タスクをメンバーに振るだけ」、「 Excelで予算や稼働時間の調整をするだけ」になってしまい、目的の達成に必要な判断や全体像の把握、事前の調整という重要な業務が抜け落ちてしまう。
プロジェクトマネージャーは計画に固執して管理に徹するのではなく、プロジェクトの実態をリスクの観点で把握してアクティブな調整を行ってそれを計画にフィードバックしていく必要がある。
プロジェクトマネジメントとプロダクトマネジメントの違い
上記2つの定義は人によって少しずつ異なりますが、著者はプロジェクトマネジメントとプロダクトマネジメントはあまり違いがないと考えているとの事。
プロダクトマネジメントは「製品（開発）のマネジメント」ですが、プロジェクトを成功させようと思うなら、プロダクトのマネジメントは
必須になるから。
たとえば、大規模な工事を適切にマネジメントして成功させようと思うなら、建築技術について無知なまま全体をマネジメントすることは不可能。
同様に、ITを利用するプロジェクトでプロダクト（システムやアプリ、Webサービスなど）で利用する技術について無知なまま成功させることは困難。
あえて違いをいうなら、従来のプロジェクトマネジメントは「ヒト・モノ・カネ」の3つの要素のうち、「ヒト（プロジェクトメンバー）」と「カネ（予算）」にフォーカスしているのに対して、プロダクトマネジメントは主に「ヒト」と「モノ（プロダクト）」にフォーカスしているといえる。
プロダクトマネジメントという言葉が昨今はやっている理由は、 ITの進歩によって事業において「モノ」の重要性が増していること、また「Excelをいじっているだけの偉そうなプロジェクトマネージャー」がいても事業は成功しないという反発のような考え方が背景にある。
4.タスクの遂行について
タスクの洗い出し
まずは、そのプロジェクトに必要なタスクをすべて洗い出す。プロジェクトの各フェーズで必要なこと（ What）を達成するためにどうすべきか（ How）を洗い出し、誰が（ Who）いつまでに（ When）実施するのかをリスト化する。
タスク名は「〇〇を〇〇する」と記載する
あまりタスクマネジメントに慣れていない場合、タスク名を「市場調査」や「ホーム画面の実装」のように名詞で記載することがある。
これは自分自身のタスクリストを管理する場合はなにをやるかがわかっているため問題にならないが、チームでタスクをこなす際は情報量が足りずよいチームワークにつながらない可能性がある。
たとえば、「市場調査の資料を作成する」や「ホーム画面を実装する」などの表現に変えるだけで、他の人が担当するタスクのイメージがわきやすくなり、チームワークにつながりやすくなる。
優先順位付けはクリティカルパス法を使う
タスクマネジメントの際にガントチャートよりクリティカルパス法を使うのが理想的。
クリティカルパスとは、プロジェクトを進めていくうえでスケジュールに影響が出る作業経路のことを指す。
クリティカルパス法ではタスクの前後関係が明確になり、「どのタスクを優先的に片付けないとプロジェクトが進まないか」を共有しながらタスクマネジメントを行うことができる。
5.開発手法の選定
ウォーターフォール開発の特徴
ウォーターフォール開発では要件定義、設計、実装、テストといったフェーズに区切ってプロジェクトを進める。
ウォーターフォール開発はフェーズごとに区切って進めることから、進捗の確認がしやすかったり、各フェーズの予算やスケジュールを明確にしやすかったりするメリットがある。
しかし、要件定義や設計のフェーズではドキュメント主体で合意を形成していくことになるため、ドキュメントに対する理解力や想像力が意思決定者やプロジェクトメンバーに求めらる。
また、実際にプロダクトとして形になるまでに時間がかかり、途中で生じた追加要望やフィードバックを生かして変更・改善しづらい性質がある。
その結果、プロジェクトの終盤になって「欲しいものとは違うプロダクトができた」というトラブルを生じやすい欠点がある。
アジャイル開発の特徴
そこで、こうしたウォーターフォール開発の欠点をカバーする観点から近年ではアジャイル開発が注目されています。
アジャイル（agile）は「素早い」や「機敏な」という意味の単語で、アジャイル開発とは短い期間で反復的に要件定義、設計、実装、テストを繰り返してプロダクトの品質を高めていく手法の総称。
アジャイル開発には、ソフトウェアエンジニアがペアを組んで基本設計を重視しながらプログラミングを進めていく「エクストリームプログラミング（ XP）」や、実際に動作するソフトウェアを適切な間隔で繰り返して、顧客にとっての機能価値という観点で開発を進める「ユーザー機能駆動開発」などもあります。
ただ、これらは日本ではあまり導入されておらず、日常的に「アジャイル開発」とされる場合はほぼスクラム開発を指していると考えてよい。
スクラム開発とはプロダクトの意思決定を行うプロダクトオーナー、チームをまとめるスクラムマスター、プログラミングを行うソフトウェアエンジニア、品質をチェックするテスターなどで構成されるチームがスプリントとよばれる一定の期間（通常 1-4週間程度）で反復的に開発を行い、画面や機能の実装判断、それらの品質の向上を行う開発手法。
6.プロジェクトが失敗する原因の約5割が要件定義
「要求」と「要件」を切り分ける
実現したいことと実現すべきことは異なる。要件定義でよくある失敗は、「発注者や意思決定者からの要求」と「プロジェクトの要件」を混同してしまうこと。
要求は「実現したいこと」ですが、要件は「実現すべきこと」なので、その意味は異なる。これを混同したまま要件定義を進めると、要求を伝えた側は後で「あれ、いったのにやってくれてないじゃん」という心理になり、プロジェクトの余裕が無くなった際にトラブルを招くことがある。
進め方のポイントは、発注者や上司から「要求」を一通りまとめて、具体的に検討を進めることで「要件」に落とすこと。具体的なテクニックとしては Excelなどで「要求」と「要件」のカラムを分けて関係者に共有しながら検討を進めると、自然と切り分けが明確になるのでおすすめ。
その際、要求の項目は「〇〇したい」という表現にし、要件の項目は「〇〇する」という表現にする。たとえば、サイトをリニューアルするプロジェクトの場合、「パソコンやスマホでもスムースに見られるようにしたい」という要求は、要件として「レスポンシブデザインにする」となります。
こうして要求と要件を書き分けることで、発注者や上司は自分達の要求を一旦受け止めてもらったという感覚をもちつつ、プロジェクト上の実施判断と分けて冷静にハンドリングしていくことができるようになるのです。
プロジェクトの目的を明確にする
どんなプロジェクトでも、背景にはビジネスとしての事情がある。
「多大な投資をしてプロジェクトを達成したにもかかわらず役に立たなかった」という事態は防ぐ必要がある。
企業の予算を使うため、ほとんどのプロジェクトでは企画段階で「なぜそれをやるのか（ Why）」について検討される。
しかし、社内決裁で多くの人のチェックを経ているにもかかわらず、実は特定の個人の思いつきや「アプリをつくってみたい」などのエゴから始まっていることは多く、最初から逆ザヤになっていてビジネスモデルが破綻していたり、マーケットニーズがまったくなかったり、技術的な理由から実現が不可能なケースは実は世の中にたくさんある。
中心的な人物のモチベーションにつながるため、個人の思いつきやエゴからプロジェクトの企画が始まることは決して悪いことではありませんが、プロダクトに社会的なニーズや技術上の実現可能性がなければ、プロジェクトが成功することはない。
また、「なぜそれをやるのか（Why）」が明確になっていないプロジェクトは、進める中でプロジェクトメンバーが次第に「これは何のためにやっているんだろう」と感じ始め、タスクの進捗が出なくなったり、関係者が責任回避的になることでトラブルが頻発したりすることで、失敗の確率が大きくなる。
プロジェクトの目的を明確にすることは、事業におけるプロジェクトの位置づけを明確にして投資判断ができるようにするだけでなく、プロジェクトメンバーのモチベーションを高めたり維持したりする意味でも非常に重要。
7.一般的なシステム要件の項目
一般的な「システム要件の項目」を本パートで整理しています。
システムアーキテクチャ
システムアーキテクチャは、プロダクトがどんなインフラ構成（サーバ、データベース、ロードバランサーなど）で稼働するのか、連携システムはどこにあるのかを図示する手法。
プロダクトで具体的にどのような技術を利用するか、その際にどのようなポジションの専門家が必要なのかを把握するために利用します。
機能要件一覧
機能要件一覧は、プロダクトがどんな機能をもっているのかを一覧化したもの。要件定義では多くの機能に関する要求が出されることが多いため、初期開発のプロジェクトではQCDの観点でなにを必須の機能要件とするかがもっとも重要な検討の1つになる。
機能要件だけでは優先度や必須かどうかの判断をすることは難しいため、ビジネス要件との兼ね合いや必要な工数との関連で検討するとよい。
画面遷移図
画面遷移図は、プロダクトがどんな画面をもっているのか、それらはどのようにつながっているかを図示する手法。プロダクトの画面数や機能一覧は見積りに大きく影響するため、要件定義の比較的早い段階で作成を始めるとよい。
シーケンス図
シーケンス図は、ユーザーの作業やプログラム、データの処理の流れや概要を図示する手法。シーケンス図は初期開発の設計時だけでなく、保守運用や改善の際にシステムの詳細を把握するためにも利用します。
とくに業務システムでは複数のシステムやサブシステムにまたがるデータ処理が存在することが多いため、認識を明確にすることがポイントとなります。
ER図・テーブル定義書
ER図・テーブル定義書は、プロダクトで利用するデータをどのように構造化するかを定義する手法。
画面や機能、 APIで利用するデータが適切に取り出せるか、汎用性や拡張性が確保されているかに留意しながら構造化を行います。
API一覧
API一覧は、プロダクトでどんなAPIを利用するかを一覧化したもの。開発するプロダクトの画面や連携するシステムがどのようなデータなのかを検討し、リストアップする。また、外部から提供されるAPIにどのようなものがあるかも把握しておく。
データ移行
データ移行は、開発するプロダクトで利用するデータを外部から移行する際の作業や方法を検討すること。データの変換や取り込みが十分に自動化できない場合は大きな工数がかかることがありますので、要件定義の際に早めに検討し合意しておく。
非機能要件一覧
非機能要件一覧は、プロダクトの対応デバイスや性能や安定性、冗長性、セキュリティ、コンプライアンスを満たす必要があるのかを取りまとめたもの。
プロダクトの対応デバイスについては、とくに Webサイトやアプリの開発の際に工数見積りや体制構築、技術選定で大きな影響をもつため、早めに検討し合意しておく。
プロダクトが保証するべき性能や安定性は、 SLA（ Service Level Agreement）として通信速度、利用停止時間の上限などの保証項目を合意することもある。
冗長性については、事故発生時の対策としてサーバやデータベースなどのインフラ構成を多重化したり、データを一定期間分バックアップするなどの検討をして合意する。
セキュリティについては、各企業で定められている基準を確認したり、プロダクトで必要なインフラ設計やアクセス制御などを検討したりして合意します。
コンプライアンスについては、個人情報や決済情報、機密情報の取り扱いなどを検討して合意します。
8.ペルソナ設計
御用聞きにならないために
どんなプロダクトでもユーザーがいるため、デザインはペルソナを設計してそのユーザーのことを考えながら行う。
完全に新規のプロダクトを開発するプロジェクトでは当初はユーザーが存在しないため、ペルソナを作成しないと意思決定者や声の大きい人が気に入るようなデザインをつくりがち。
しかし、そうしたプロジェクト内で影響力の強い人と実際のユーザーの好みやリテラシーが異なる場合、リリースした時点で失敗してしまう。
普段の生活でも「なんでこんなデザインになったんだろう」という製品に触れることがあったり、ネットで広告や製品のデザインが炎上したりすることがありますが、それはユーザーのことを考えず、関係者の好みや意見だけを反映した結果生まれるもの。
プロダクトのデザインはあくまでもユーザーに向けてつくる必要がある。
とはいえ、打ち合わせなどで発注者に面と向かって「あなたの好みはユーザーの好みとは違います」というわけにもいかない・・・。また、デザイナーやプロジェクトマネージャー自身がユーザーのことを正確に理解しているとは限らない。
そこで、ペルソナ（代表的なユーザー像）をつくって、「誰に向けてつくっているのか」を明確にしていくとうまく合意形成ができるようになる。
また、デザインは誰でも口を出しやすいため、意思決定者や声の大きい人のエゴが出やすく、ペルソナを設計してそれをプロジェクト合意の指針とすると、「いつまでもやり直しや細かい指示が出てきてデザインが終わらない」という事態を防ぐのにも役に立つ。
ユーザーインタビューの意見が正しいとは限らない
また、ペルソナ設計と並行してユーザーインタビューを行うこともある。
いわゆる「ダサピンク問題」（女性ウケを狙ってなんでもピンクにしてしまう問題）のように、ペルソナ設計の内容とユーザーのセンスがズレていないかチェックする際にとても有効に機能する。
ただ、通常はユーザーインタビューを統計的に意味のある形で意見をまとめるのは難しいため、量的な情報というよりは質的な情報として受け止める必要がある。
必ずしもユーザーインタビューの意見が「正しい」とは限らない。
リアルな意見として受け止めつつ、あまり個人の意見に引っ張られすぎないように気をつける。
自動車王ヘンリー・フォードが残したといわれる言葉に、「もし顧客に、彼らの望むものを聞いていたら、彼らは『もっと速い馬が欲しい』と答えていただろう」というものがある。
すでにあるプロダクトを客観的に評価する際にはユーザーインタビューはとても有効ですが、新しいものをつくる際にはあまり参考にならないことが多い。個人から集める意見と利用者全体の特性や傾向は明確に分けて判断するとよい。
9.「デザインを育てる」という発想をもっておく
プロトタイピングを活用する
「顧客が本当に必要だったもの」というネットで有名な絵がある。
これは正しいプロダクトをつくるのがいかに難しいかを皮肉っぽく描いたもの。
この絵の中でもっとも重要なポイントは「顧客が説明した要件」と「顧客が本当に必要だったもの」が大きく異なっている点。
プロジェクトでは「 Webサービスを発注者のいう通りにつくったけど、鳴かず飛ばずで終わった」とか、「業務システムを関係者のヒアリング結果に忠実に刷新したけど誰も幸せにならなかった」といったケースは実は頻繁にある。
プロトタイピングでUXを育てる
初期のデザインの際には将来事業の大きな枝葉を支えられるように、プロダクトの初期開発では限られた予算と時間の中で拡張性の高い丈夫な幹をつくるつもりでデザインしていくとよい。
注意点としては、プロトタイピングでは細かい設計を行わず、「とりあえず動く」ことを目的に作成するため、作成したものがそのまま本番のプロダクトに使えるわけではないこと。
プロトタイピングは要件定義資料や設計書などで難しい表現でプロジェクトを進めていくよりも圧倒的に関係者を巻き込んでいく力を発揮する。新規事業の検証でも非常に有効な手法。
10.技術スタックを選定する
技術スタックの選定はビジネスに影響する
設計の前段階として、技術スタックを選定しておく必要がある。
ITの分野では、技術スタックとはプログラミング言語やOS、ミドルウェア、フレームワーク、ライブラリなど、実際にプロダクトを制作する際に使用する技術の組み合わせを指す。
技術スタックはソフトウェアエンジニアに相談しながら決めていきますが、上記の各要素の詳細は専門書で確認しておくと会話がしやすくなる。
プロジェクトマネージャーは必ずしも自分で実装できるレベルまで理解しておく必要はありませんが、ソフトウェアエンジニアがいっていることを理解できる必要がある。
11.ITプロダクトのレビューで重要な観点
全般
プロダクトが想定されている通りに動作する設計になっているかをレビューします。機能要件や処理の正常系／異常系、性能要件、シーケンス図などでプロダクトの動作やデータの処理が適切な設計になっているかを確認する。
セキュリティ
プロダクトがセキュリティに留意した設計になっているかをレビューする。
個人情報保護に関する意識が高まっている昨今では、セキュリティ関連の設計で失敗して情報漏えいなどが発生すると、事業面での損害が大きいため慎重にレビューするように進行する。
とくに認証系（アカウント作成やログイン、パスワード変更など）や個人情報を送信するフォーム系、他のサービスやシステムと連携するシステム連携系、クレジットカードを利用した決済系、換金性のあるポイント系は悪意のあるクラッカー（ハッカー）に狙われやすいため、設計に隙がないかを重点的にレビューしなければならない。
これらの設計の際に他のプロダクトでは見当たらない仕様が出てきたら、「あれ、おかしいな」と立ち止まって、類似のサービスなどを調べて「当たり前の設計」がどうなっているかを確認するようにする。
シニアクラスのソフトウェアエンジニアはこうした適切な設計に詳しいため、とくにセキュリティ系の設計では積極的にアサインするようにする。
また、通信の暗号化やデータ構成、脆弱性対策といった基本的な対応も適切に盛り込まれているか確認する。
とくにセキュリティ要件が厳しい場合は、 WAF（Web Application Firewall）、 IPS（Intrusion Prevention System）、 IDS（Intrusion Detection System）といったアプリケーションや通信に対する監視や管理者への警告、あるいは不正な通信の遮断を行うシステムの導入が想定されているかも確認する。
インフラ
インフラが適切に設計されているかをレビューする。
要件定義の際に非機能要件で検討された内容に基づいて、適切な性能を発揮できるスペックのサーバやデータベースが構成されているか、事故時の対策として冗長化やバックアップなどが考慮されているかをシステムアーキテクチャなどで確認する。
また、テスト環境（実装した機能や画面などをテストする環境）やステージング環境（本番環境に類似する環境で表示内容の確認や性能面などをテストする環境）、本番環境（リリース後にプロダクトが動作する環境）がそれぞれ適切に設計されているかも確認する。
データベース
データベースが適切に設計されているかをレビューする。
ER図やテーブル定義書を確認して、各画面や機能、APIで利用するデータが適切に利用できるか、効率的な開発ができるよう柔軟性や拡張性が確保されているかなどをチェックする。
API
APIが適切に設計されているかをレビューする。
連携先のシステムに対する認証やセッション管理に関してセキュリティが十分確保されているか、データ取得の認可に関して必要最低限のデータが取得できるか（不要な個人情報などを取得しないか）を確認する。
これらはどれも重要な観点ですが、設計レビューでどの観点をとくに重視するべきかのウェイトは作成するプロダクトによって変わる。
たとえば、多くのユーザが利用するECアプリを作成するときはコンバージョン（購入）が効率化されるように画面の構成や機能の使いやすさを重視する必要がある。
また、企業の基幹システムで1つの処理が他の何億件ものデータに影響する場合はアルゴリズムの適切さを詳細に確認する必要がある。
これはプロジェクトマネージャーとしてそれまでの経歴と異なるプロジェクトを担当する際に、大きなミスにつながる可能性があるため、とくに意識して気をつけるようにするとよい。
たとえば、一般ユーザが利用するto Cのアプリを担当したプロジェクトマネージャーがto Bの業務システムのプロジェクトを担当する際、データ処理に関するレビューが抜けていて大きな失敗につながった、というケースはよくある。
12.「テストとはなにか」の認識を共有するソフトウェアテストの7原則
アプリやWebサービス、システムなどITを利用したプロダクト（ソフトウェア）では、物理的なものの確認ではないため、関係者にとって直感的に理解しづらい部分があります。
そこで、まず「テストとはなにか」の認識を共有する必要があります。
IT業界に長くいる人にとっては当たり前のことでも、発注者にとってはそうではないことも多いため、その認識がズレているとトラブルの元になる可能性があります。
その際、重要となるのがJSTQBという日本におけるソフトウェアテスト技術者資格認定の運営組織が提唱している「ソフトウェアテストの7原則」の考え方。その考え方について下記で整理されています。
本書内でも詳細に記載されています。
13.各テストの定義を確認する
一般的なテストとしては 11種類。以下、順に整理します。
なお、具体的な「誰がなにをやるか」について認識がズレていると作業の責任範囲やスケジュール調整の際にトラブルの元になりますので、テスト計画の前に認識をすり合わせておく。
ユーザビリティテスト
ユーザビリティテストは実装したソフトウェアが使いやすいかを確認するテスト。たとえば、 ECアプリを開発するプロジェクトで、画面の動きや購入までのステップがスムースに使えるかを確認するようなケースが該当する。
クリエイティブチェック
クリエイティブチェックはソフトウェアに掲載されている情報や画像に間違いがないかを確認する作業。
たとえば Webサイトなどで掲載するキャンペーン情報などは関係者や利用者への影響が大きいため、適切にチェックできるよう計画を立てておく必要がある。
とくにマスタデータなどを利用して自動で情報を大量に生成して掲載する場合は、データがズレていないかなどを目視で確認することになるため、大きな工数を必要とする可能性がある。
工数を見積らずにリリース直前で慌てて実施すると大きなミスにつながりますので、注意する。
単体テスト／結合テスト
単体テストは処理や機能を単体でテストすること、結合テストは複数の関連する処理や機能に関するテスト。
実装フェーズで実装タスクにサブタスクとして組み込んでおくことがポイント。ただし、大量のデータに影響する可能性がある処理の単体テストや、モジュール（プログラムの集まり）が複雑に連携するケースの結合テストなどは切り出して行うほうがより安全です。
リグレッションテスト
リグレッションテストはプログラムを改修した際に、想定外の影響が発生していないかを改めて確認するテスト。テストは工数やスケジュールを切り詰めることが多いため、リグレッションテストが適切に考慮されているプロジェクトは多くはありません。
しかし、リグレッションテストの観点がまったくない場合は「この欠陥は対応したのでもう問題はないはず」という思い込みによって、新たに発生した重大な欠陥を見落とす可能性がある※。
※参考記事
リグレッションテストとは？デグレーションの確認は必要不可欠！ - システム開発のプロが発注成功を手助けする【発注ラウンジ】
総合テスト（シナリオテスト、システムテスト）
総合テストは開発したソフトウェアが適切に実装されているかを全体的に確認するテスト。
通常、各画面や処理、機能などの単位に分けてテストケースを記載し、一定のシナリオ（流れ）に沿って複数人で分担して行います。
テストの性格上、（ほぼ）すべての実装が完了した後に実施する必要があるため、プロジェクトの大詰めのフェーズとしてマネジメントすることになります。
連携テスト（システム間テスト）
連携テストは開発したソフトウェアが連携するべき別のシステムと連動して動作するかを確認するテスト。
たとえば、 ECアプリで外部の決済サービスや在庫管理システム、基幹システムなどと連携が必要な場合などに実施する。
連携テストはデータのやりとりを確認するため、一見すんなり終えることができる印象を受けます。しかし、実際は正常系（データが正確に連携されるか）だけでなく、異常系（通信の異常や不正データが送信された際の処理が適切に行われているか）の確認やテスト環境の整備なども必要になるため、連携先のシステムを担当しているチームやベンダーとのスケジュールや体制の調整がポイントになる。
ここを甘く見積って全体スケジュールに影響が出てしまったり、実際の運用の際に大きなトラブルにつながったりすることがありますので、慎重に検討するようにする。
負荷テスト
負荷テストは開発したソフトウェアが実際の運用の際の負荷に耐えられるかを確認するテスト。
設計の際に負荷のかかりやすい部分をいかに分散したりカバーしたりするかを検討するとともに、負荷テストで実際にその設計の想定通り負荷に耐えられるかを確認する。また、想定を超えた際にはなにをすればよいかを想定しておきます。
とくに多くの人が利用するソフトウェアでは急激にアクセスやデータ処理が増えることで、動きが非常に遅くなって使いものにならなくなったり、落ちてしまってまったく利用できなかったりする状況が発生することがある。
これは利用者にとって不便なだけでなく、具体的な損害を与えてしまう可能性があるので、事前にツールを使ったり業者に委託したりして検証をしておく必要がある。
負荷テストの際に当初の想定を超えた際の対応を手順化しておくと、トラブルを未然に防いだり、早期に解決したりすることができます。また、負荷テストは基本的に総合テスト完了後に行うので、確実に実施できるよう総合テストが確実に完了できるタイミングを確認することがポイントとなる。
脆弱性テスト
脆弱性テストは開発したソフトウェアに脆弱性がないかを確認するテストです。セキュリティに関するリスクは事業面にまで及ぶ可能性がありますが、実はかなり軽視されている部分でもあります。
その理由は、脆弱性テストを実施するには総合テストまで確実に終わっている必要があり、初期開発のプロジェクトではどうしても「追加のスケジュールや予算」とみなされやすいから。
しかし、脆弱性テストを省くことは大きな事業リスクになりますので、とくにインターネットに公開するソフトウェア（アプリや Webサービス、システム）では必ず実施するようにする。
プロジェクトマネジメントの観点では、後で追加スケジュールや追加予算として調整が大変にならないように、プロジェクト計画や見積りの時点で想定しておく。
脆弱性テストはツールを利用して開発チームが実施することも可能ですが、より万全を期すには専門の事業者に委託するとよい。その場合は見積りの取得や実施タイミングの調整がよりタイトになりますので、スケジュール調整を慎重に実施する。
また、専門の企業に委託する場合でも、通常の脆弱性テストでは実装時の脆弱性についてはチェックできますが、要件定義や設計のミスまではチェックされません。設計面の確認をする場合はそうしたコンサルティングを委託できる企業や専門家を選定する必要がある。
受入テスト（検収）
受入テスト（検収）は開発したソフトウェアが要件通りに納品されているかを確認するテスト。
とくに請負契約や成果完成型の準委任契約では検収が支払い条件となっているため、必須のプロセスとなる。
そうした場合はベンダーが実施した総合テストや負荷テスト、脆弱性テストの報告書を基に検収を行うことになる。
その際は検収後に「契約不適合」を盾に安易な追加要求を突きつけられないよう、事前に検収の条件について文書で合意を形成しておきましょう。
発注者で受入テストを実施する場合は、ベンダー側はテスト計画と実施体制の構築について協力するようにする。
テスト駆動開発
テスト駆動開発は実装時にテストコードを組み込むことで人が何度も網羅的なテストを実施する工数を省くための開発手法。
テストよりも開発手法として語られることが多いですが、その目的はテスト工数の削減と正確性にある。
テスト駆動開発で重要な点はどのレベルのテストまでを自動化するかです。テストコードを書くにも工数が必要となりますし、適切なテストコードを書くには実装とは異なる専門知識や経験も求められます。
単体テストや結合テストではリグレッションテストまで含めて考えると、テストコードを書いたほうが工数が効率的であることが多くなります。
しかし、総合テストの自動化は専門のツールを使用する必要があるため、継続的な開発が見込まれる Webサービスや大規模な業務システムでなければ、工数の観点でかえって非効率的になるケースも多いでしょう。
テスト駆動開発の導入を検討する際は、テストコードを書く工数と効率化できるテスト工数を天秤にかけて検討するとよい。
14.プロジェクトの固定費
ITプロダクトが中心となるプロジェクトの場合、固定費には主に以下が含まれる。
●初期開発費用
●インフラ費用
●保守運用費用
●プロダクト改善費用
●分析・戦略立案費用
●カスタマーサポート費用
●利用するツールや有料ライブラリの費用
ここでは特にポイントだと思った費用を抜粋し概要記載しています。
初期開発費用
初期開発費用はプロジェクトで実際にかかった費用をまとめたものです。脆弱性テストなどの費用も忘れず入れておく。
インフラ費用
インフラ費用は、プロダクトが適切に動作するために利用するハードウェアなどの構築・維持費が該当する。自社内にサーバを置く必要がある場合は、ハードウェアのスペックなどを確認し、調達担当に見積りを依頼する。
昨今は AWSや Google Cloud Platformなどのクラウドを利用することが多くなっているため、その場合は提供されているツールを使ってオンラインで手軽に見積りをつくることができる。
インフラ費用を見積る際には、第 7章の「要件定義」で確認した非機能要件（アクセス数や冗長性など）と照らし合わせて実施するため、要件定義の際には「そのプロダクトがどのような性能や安定性をもっている必要があるのか」を各関係者と協議して検討しておく。
インフラを検討する際にとくに重要な非機能要件のポイントは下記の通りです。これらはプロダクトが通常時にどのような性能を発揮しているべきかや障害発生時、災害発生時にどのような対策がなされているべきかを決めるうえで欠かせない点。
●アクセス数（利用者数、アクセス頻度、同時接続数など）
●アクセスのピーク（時間帯や曜日など）
●応答性（画面の読み込み速度や APIのレスポンスタイムなど）
●冗長性（ 2重構造化など）
●耐障害性（サーバの設置場所の耐災害性、バックアップの頻度や保持期間など）
●必要な環境の数（開発環境、テスト環境、ステージング環境、本番環境など）
基本的にアクセス数、アクセスのピーク、応答性は 1台あたりのサーバのスペックに影響し（スペックが高いほど高価）、冗長性や耐障害性、必要な環境の数はサーバの組み合わせの数に影響する。
たとえば、プロダクトを運営するうえで、あるスペックのサーバが 1台 10万円／月で最低 3台必要で、冗長化（ 2重化）が必要で利用する環境が 3つ（テスト環境、ステージング環境、本番環境）の場合、月額で必要なインフラ費用は下記のような計算になる。
（10万円 × 3台） × 2（冗長化） × 3構成 ＝ 180万円／月
もちろん、テスト環境やステージング環境のスペックを落としたり、使わない環境のサーバを適宜止めたりすれば金額の調整は可能ですが、基本的な考え方はこの通り。
また、アクセスの軽減が求められる場合はCDN（Content Delivery Network：よく利用されるデータの読み込みを速くする仕組み）、セキュリティ要件が強く求められる場合は WAF（Web Application Firewall：アプリケーションへの不正な攻撃を検知したりブロックしたりする仕組み）やDSaaS（Deep Security as a Service：インフラへの不正な攻撃を検知したりブロックしたりする仕組み）などを必要に応じて構成に追加する。
インフラ費用は使用するサーバのスペックが大きく影響するためプロダクトの成長とともに増加します。サーバーのスペックを切り替えるとその都度階段型に増加するため、プロダクトが大きく成長した際にはその際の条件を踏まえて定期的に見直しを実施する。
保守運用費用
保守運用費用はインフラとアプリケーションの監視運用体制の費用です。これは監視運用体制を維持するために必要な人件費となる。
具体的に保守運用の工数を見積る際は、トラブル発生時の発注対応にプロジェクトマネージャーやディレクターにどれくらい窓口対応の工数が必要か、トラブル対応や各種アップデートでソフトウェアエンジニアがどれくらいの工数が必要かを算出しておく。
プロダクト改善費用
どんなプロダクトでもリリース後は軽微な改修や機能改善が必要なことが多いため、その工数もある程度想定して松竹梅の 3段階で毎月の費用をプラン化しておくと、発注者や上司も意思決定が行いやすくなる。
保守運用と改善をセットで契約を結ぶ想定の場合は、前項で説明した保守運用費用と改善費用を合わせて提示することもあります。
分析・戦略立案費用
新規事業で売上を立てたり、業務改善で効率性を改善したりするプロジェクトの場合、継続的に施策が成功しているかどうかを分析し、戦略を立案するための費用が必要となります。
その場合はデータアナリストやマーケティング担当者などの専門家の人件費を、保守運用費と同様に稼動ベースで費用として見込んでおきましょう。
この費用を見込んでおかないと、要件定義の際に決めたプロジェクト目的が達成されているのかどうかがわからず、「やりっ放し」の状態になってしまいます。
基本的に分析・戦略立案費用も改善費用と同様に工数を見積って毎月の費用として想定しますが、ベンダーがそれらのコンサルティング能力をもっている場合は、前項と同様に月々の保守改善費用に含める場合があります。
また、この分析・戦略立案では第 7章の「要件定義」で検討したビジネス要件の仮説が正しかったかどうかが検証されるので、発見した事実を踏まえて仮説をアップデートしていく必要があります。
利用するツールや有料ライブラリの費用
プロジェクトで利用する、ソースコード管理サービスやチャット、プロジェクトマネジメントツール、各種分析ツールなどの費用や、開発を効率化するための有料ライブラリや ASP（ Application Service Provider、プロダクトに組み込む外部企業のアプリケーション）の費用も忘れずに固定費として見積っておきましょう。
プロジェクトの変動費
プロジェクトの変動費には、主に「マーケティング費用」と「営業活動費用」があります。とくに新規事業では変動費の投資が売上の積み上げに影響します。損益分岐点の図で売上と変動費のそれぞれの傾きがどうなるかで「いつ黒字化するか」が変わり、またどれくらい投資すべきかが判断されます。
マーケティング費用
マーケティング費用は各種広告や各種プロモーション、コンテンツマーケティングなど、多様なチャンネルを利用してプロダクトの認知を広げ、見込み客をよび込むための費用です。単純に広告やコンテンツを出稿するための費用だけでなく、どのように自社のプロダクトや事業を見せるかに関するブランディング検討の際の費用も含みます。
セールス費用
セールス費用は見込み客が実際にプロダクトを購入する際の支援を行う際の費用です。とくに to Bの事業で重視される領域です。見込み客となる企業に対して営業活動を行うフィールドセールス、電話やメール・ダイレクトメールなどを用いて、見込み客や顧客に対して営業活動を行うインサイドセールス、営業活動のプロセスを改善するセールスデベロップメントなどのポジションがあります。
見込み客からの引き合いが増えると対応する人員も増加するため、セールス費用も変動費としてとらえることが通常です。
15.尊敬するプロジェクトマネージャーから学んだこと
最後に本書とは別で社内の尊敬するプロジェクトマネージャーから学んだことも追記しておきたいと思います。
企画領域における成果の定義とは？
①サービスがリリースされている状態
②サービスがグロース（※）している状態
※売上、業績KPI、ユーザー登録数、サービス利用率などが伸びている状態
社内で活躍しているプロジェクトマネージャーが得意なこと
✓プロジェクトの計画書作成や全体管理
✓システム概要図や業務要件の作成
✓サービス動線や画面遷移図の作成
✓パワポでポンチ絵を作成
✓コンプラ対応や契約スキーム作成
✓ビジネスモデルや売上/収支計画の作成
✓図解を使ったプレゼン資料
社内で活躍しているプロジェクトマネージャーはプロダクトマネージャーについてどう考えているのか？
プロダクトマネジメントは、製品やサービスなどの企画から開発、市場投入、そしてライフサイクルの管理までを担う考え方。そして、そのような役割を担うのがプロダクトマネージャー。
プロダクトマネージャーはWhat（何を作るか）とWhy（なぜ作るか）にこだわる。プロジェクトマネージャーはWhen（何を作るか）とHow（なぜ作るか）にこだわる。
プロジェクトマネージャーは主にどんな部署の方と連携するのか？
多岐にわたり法務/セキュリティ、サービスデザイン、プロダクト開発、マーケティング、Sales/CSなど。
私の場合は小さなプロジェクトを進行する際にPMとマーケティングが兼務になるような状態が多々ある。
PMOの仕事とは？
PMOの仕事は考えること。例えば下記。
✓ゴールやストーリーを考える
✓PJT課題をどう解決するかを考える
✓1日の業務設計(成果物)を考える
✓どんな成果物が必要かを考える
✓コンプラ調整の段取りを考える
✓仮設を立ててどのデータが必要かを考える
✓MTGのゴールとアジェンダを考える
成果ベースで仕事をして、中期スケジュールを作成していく。
その他 参考文献
【カルビー会長】成果に結びつくことだけやれ、余計なことはやるな
https://newspicks.com/news/2175010/
BPMNを整理することで成果物が整理しやすくなる
Business Process Model Notationの略。計画された業務プロセスの手順を最初から最後までモデル化するフローチャート手法。
以上です。
引き続き勉強を続けます。
この記事が気に入ったらサポートをしてみませんか？