【読後感想②】プロジェクトマネジメントの基本が全部わかる本｜橋本 将功
akippa株式会社でWebプランナーをしている谷口です！
前回から引き続き<読後感想>を書いていこうと思います。
今回は「プロジェクトマネジメントの基本が全部わかる本」です。
↓前回ご紹介した「プロダクトマネジメントのすべて」と同様、WEBサービスのプランナーに必要な一般的なIT知識やノウハウを得たいと思って見つけた一冊です。
"似た内容の本を2冊読んでみて共通する部分があれば、きっとそれはそういうことなんやろ"ということで、あえて2連続でプロダクト/プロジェクトマネジメント全般に触れている本を読んでみました。
まず初めにどちらも読み終えて感じた2冊の違いについて触れておきます。
「プロダクトマネジメントのすべて」はプロダクトの4つの階層（Core、Why、What、How）の概念を軸に、プロダクトを成功に導くための戦略と具体的なアプローチが示されていました。
一方で「プロジェクトマネジメントの基本が全部わかる本」は計画立案→見積り→要件定義→設計→テスト→リリース→保守改善といった、開発の一連の流れに沿って解説しています。
また各フェーズごとに「〇〇がうまくできず苦労している」といったQ&Aが差し込まれるのですが、これがすごくわかるーーってなります。
個人的には本書のほうが実体験と照らし合わせて読み進めやすかったです。
[Q] 費用の超過請求やスケジュールの延長など、プロジェクトのQCDに関するハードな調整に気おくれしてしまい、交渉がどうしても苦手です。少しでも心理的な負担を減らして、交渉をうまく進める方法はないでしょうか？
[A] QCDに関する交渉は大変ですよね。私もいつも苦労しています。交渉の内容がシビアなだけに、ある程度の心理的な負荷がかかってしまうのは仕方ないとは思います。以下の点に気をつけて交渉を行うと、少しでも心理的な負荷を下げると同時に、相手の反発を下げて交渉をスムースに進めることができるようになります。（以下具体的な手法へと続く…）
↑akippa社員はみなさん汲み取ろう歩み寄ろうとしてくださる方々ばかりなのですが
それでも自分の中では交渉ごとに対して未だぼんやり苦手意識があったりします
本書で印象に残った内容をいくつかあげていきます。
全体的な観点で検討して取りまとめていく
それぞれのメンバーや関係者が異なる判断基準や利害をもっているため、全体像をまとめて共有する人がいないと、それぞれの担当者の専門領域と他の専門領域で齟齬が発生してしまいます。
<中略>
立場や専門性が変われば主要な関心事も変わり、こうした異なる関心事をもつ人々が実施するタスクをうまくつないでいくことがプロジェクトマネージャーに求められます。
<中略>
組織にとってプロジェクトがどのように貢献できるのかを全体的な観点で検討して取りまとめていくのも、プロジェクトマネージャーの役割です。
依頼元からの要望を機能要件に落とし込む際、途中で開発計画を変更したり機能を追加する必要がでてきた際など、あらゆる場面でこの「全体的な観点で検討して取りまとめていく」というスキルが必要だなと日々痛感しています。
全体をみろ！俯瞰して考えろ！と意識はしていても、実際のMTGの場になると点の話を深ぼってしまいがちです。
全体的な観点を持つためには、社内の各部署が日々達成しようとしている目標や業務内容、ユーザーがサービスやプロダクトに対してどのような感想や要望を持っているかといった目の前のことに留まらず、会社の長期目標やサービスの方向性といった大局的な部分をきちんと理解することが必要だと感じました。
顧客が本当に必要だったもの
「顧客が本当に必要だったもの」というネットで有名な絵があります。これは正しいプロダクトをつくるのがいかに難しいかを皮肉っぽく描いたものです。
上の図では「顧客が本当に必要だったもの」は簡易的なタイヤのブランコだったにも関わらず、1枚目のそもそものヒアリングの時点で少しずれてしまっています。
そして前に触れたように、それぞれ専門領域が違う担当者の間で齟齬が発生してしまうと、顧客（依頼元）が求めていたとものとは全然違う、あるいはtoo muchな機能になってしまう可能性があります。
言葉にすると月並みになってしまいますが、こうならないためにも、依頼元との最初のコミュニケーションはもちろんですが、開発フェーズに関わらず関係者への報告やすり合わせは大切だなと改めて感じました。
テストは欠陥を見つけるためのもの
テストはソフトウェアが完璧であることを証明するために行われるものではなく、欠陥を早期に発見して対処するために行うものであるという認識を関係者で共有することが重要です。
ソフトウェア開発やテストに対する意識をこのように変えれば、関わる人たち全員が前向きに、そしてより緻密なチェックができるようになる気がしています。
最後に
本書ではエンジニア領域だけでなく、フォント、トンマナなどのビジュアル・アイデンティティやUI/UXといったデザインに関する内容や、請負と準委任の違いといった外部ベンダーとの契約といった内容も網羅的に解説されています。
特にデザインに関しては、デザイナーさんとのコミュニケーションを円滑にするために理解を深める必要があるなと常々感じているので、次回以降の読後感想でデザインに関する書籍を取り上げることもあるかと思います。
今回も最後までご覧いただきありがとうございました！
この記事が気に入ったらサポートをしてみませんか？