年が明け、「大学入学共通テスト（新しいセンター試験の正式名称）」のニュースが流れてくる時期になりました。これに合わせて、来年2025年度の大学入学共通テストから、新たに「情報」科目が出題されるというニュースが各所で報道され始めています。国公立大学をはじめとする大学入試選抜に、この成績が使われる場合が出てきました。
「情報」という教科は2003年度から始まり、内容としては情報リテラシー（ネットモラルや情報化社会の価値、等）に関するものが中心でした。2022年度からの新課程「情報Ⅰ」は、情報デザイン・ネットワークデータ・プログラミング・問題解決……と、実際にプログラミングというツールを利用しながら課題解決する教科になりました。数学が、公式をはじめとする数学的知識を利用しながら、課題解決する教科なのと似ていますね。
私自身は社会人になってから、システム開発プロジェクトの仕事にアサインされた後に、必要に迫られてプロジェクトマネジメントやプログラミングを泥縄式に勉強したタイプですので、「高校でプログラミングや問題解決技法の学習機会があるのは、いいことだなー」と、この変化を好意的に見ています。ただ思い返してみると、机上で勉強していた当時と様々な経験をした今では、考え方が変化したなぁと思うこともあります。
そこで今回は、事業部PMというロールを担うに当たり、“経験を積むことによって変わってきた”PMの心得3か条をご紹介したいと思います。
1．ゴールは「決まっている」のではなく「決めるもの」
多くの事業部PMは、企画を受けてシステム開発のマネジメントをせよと言われており、システム開発の工程の責任者という位置付けでアサインをされているのではないでしょうか。
私自身、まだPMにアサインされて日が浅かった頃は、上流工程で決まった企画をどう実現するのか、ということに心を砕く（砕かれる？？）ロールであると考え、企画で決まった事は“動かしてはいけない”と思っていました。しかしPM経験を積んだ今では、ただ決められたことを実現する役割ではなく、事業目的を達成するための手段を磨き上げるロールだと考えるようになりました。
プロジェクトには人や期間、コスト等の制約があり、企画フェーズで考えていたことが、必ずしも実現出来るとは限りません。また、プロジェクト進行上の様々な事象により、企画フェーズで決められていたことが実現できない状況になることもあります。
このような時、「当初の仕様が実現出来ないので諦める、リスケする」という選択肢もあると思います。一方で、事業目的と手元のリソースを勘案し、少しでも事業目的が達成出来るように近付ける、新たな手段を考えるという選択肢も存在します。
PMとして経験を積み、上流工程への目配りも出来るようになってくると、企画が実現困難な状況になった際に真っ先に考えるのは「少しでも事業目的の達成に近付くために、どうしたらいいか？」になっていきました。また、そもそも、プロジェクト参画時の目的意識が「システムを作ること」から「事業目的を達成すること」に変わっていったように思います。その結果、システム開発における大きな失敗が減っていきました。
もちろん、勝手に易きに流れてはいけないのですが、経験からの学びでPMとしての動き方が変わった“1つ目”は、「（開発の）ゴールは決まっているものではなく、決めるもの」と思えるようになったことでした。
2．「報告で管理する」のではなく「報告を元に調整する」
事業部PMをやっていると、開発会社や運用構築、準備しているメンバー、製品の告知を行っている営業現場等から、様々な報告をもらうようになるかと思います。その報告は多くの場合、作業分解構造図（WBS）に基づく進捗報告や各フェーズゲートで提出される品質報告書等、プロジェクト管理ルールに基づいた報告書という形で提出されてくることになっていると思います。
PMになった当初、私は付け焼刃な勉強しかしていなかったため、進捗報告等に書かれている数値を元に定量的な把握をすることで精一杯。「進捗率が現段階で40％って、大丈夫ですか？」程度のフィードバックしか出来ません。まさに、報告書の数字を管理している“だけ”の人になっていました。
この時は、「進捗出来ていないこと」を課題と考えてしまっていたように思います。だた、この捉え方では「休日を潰して、進捗率を上げろ！！」という手段しか取れないんですよね……、実際のところ。この定量的な管理そのものは必要なことなので、否定はしません。ただ、進捗が思わしくないプロジェクトは出てくる数字も悪く、数字の悪さを指摘しても何も改善しない……そんな悪循環を引き起こしてしまう状態に嵌っていたように思います。
経験を積んでいくと、「なんで数字が悪いんだろう」「というか、この数字が悪いことって本当に問題なの？」と考えるようになっていきました。数字の裏にある事象を捉え、問題なのかどうか判断する。問題だと判断したら、何を調整すべきなのかを考える……と、行動も変わってきたように思います。
結果として、プロジェクトを一緒にやっていた方々から、総括時に「やりやすかった」「楽しかった」と言われることが増えたように思います。このような考え方は、プロジェクトマネジメントのツールや技法を表面的に学んでいた時には、「知っている」けれど「分かっているつもりで出来ないこと」でしたので、自分の経験からの学びでPMとしての動き方が変わった“2つ目”だと思っています。
……とはいえ、未だに数字を見てはドキドキし、一喜一憂し、泣き笑いをしていますので、今後も精進が必要だなと思っています……。
3．「機能が完全か」ではなく「利用者にとって最適か」
今回最後に取り上げるのは、プロジェクト全体ではなく、受入テスト・ユーザーテスト工程における経験です。私は初めてシステム開発に参加した際には、受入テストは何故必要なのか、疑問を持っているような若者でした。
「システムの仕様を合意し、その通りに作ってくれているのであれば、受入テストなんていらないじゃないか」
「システム仕様通りに作れていることを、開発会社は担保してくれよ！」
今から考えるととても暴論なのですが、そんなことを本気で思っていました。そんな私に、システム開発を教えてくれたある方が「君は今、世の中に一つしかないものを作っているんだよ。それが“正しい”って判断出来るのは、君だけじゃない？」と言葉をかけてくださって初めて、「ああ、受入テストは必要なんだ」と思ったのです。
その上で、そこでいう“正しい”の捉え方が、経験を積むことにより変わってきた……というのが、経験からの学びでPMとしての動き方が変わった、“3つ目”の変化です。
「受入テスト」では、基本設計書などに書かれている仕様を元にテスト項目書を記載し、それが確認出来れば開発品質は担保された、と判断していた頃がありました。もちろん、その考え方でのテストは、必要です。但し、それで必要十分かというと、そうではないと今は考えています。
一つ一つの機能が正しくつくられていても、システム設計者が期待する通りの使い方を利用者がしてくれる保証はありません。想定していない使い方をしたらどうなるか、といったことは、基本設計書に書かれている機能をそのままテストしても、発見することは難しいです。つまり、起点が設計書である限り、機能が完全であることは担保できても、“利用者にとって”正しいものなのかの判断はできないという事になります。
PM経験を積むことにより、「利用者はどのように使うのかな、その結果どうあってほしいのかな」と推測するようになり、受入テスト工程においても「それを考えることが、求められていることなのだ」と思うようになりました。つまり、「利用者にとって最適」＝「正しい」と考えて、受入テストをするということです。この場合の受け入れテスト方法は機能確認では無く、「シナリオ」や「行動ベース」のテストを行うことになります。その結果、製品が世の中に出た際、致命的なバグを抱えているようなことは減ったように思います。
ちなみに──今は、開発を担う会社の一員なので、ここからポジショントークをしますが──万が一、設計書に書かれていないことでバグを発見した場合、無理に開発会社に修正を押し付けようとしてはダメですよ。その為に、開発そのものが破綻してしまうこともありますから！ ただ、事前に利用者最適でテストをすることにより、注意喚起したり、次の機会に直す等、様々な手段が取れるよう、調整していきましょう！（以上、ポジショントークは終了です！）
今回は事業部のPMというロールを担う方々、事業部PMとして初めてプロジェクトに向き合う方に向け、経験を積むことによって変わったPMの心得3か条を書きました。他にも色々変わったと思えるところはあるのですが、「PMって楽しい！」と思うきっかけとなったのが、この3つの考え方を身につけた頃だったように思います。「考え方をちょっと変えると、PMロールってなんだかんだ言っても楽しいよ！」ということを最後にお伝えし、本稿を締めたいと思います。
加藤 彰浩
（業務・システムコンサルタント）
株式会社セブン‐イレブン・ジャパンを経て、2006年にベネッセコーポレーションに入社。採点サービスの物流基盤デジタル化プロジェクトを皮切りに、新規サービス立ち上げおよび既存サービスの維持・改訂におけるPM/PMOや商品責任者として、戦略立案から企画推進、システム開発、業務運用構築までを一貫して手掛ける。2022年11月クラスメソッドに参画。prismatixのコンサルタントを担当。
この記事をシェアする
プリズマティクスのサービス
Keyword
Follow Us
