週末を前に、私たちはコーヒールームに少し立ち寄り、同僚として意見を交わします。これが「5 つの質問」という連載記事のスタイルです。この連載では、経験豊富なプロジェクトマネージャーにそのベストプラクティスを伺っています。
今日お会いするのは Jan Fischbach 氏です。氏は組織コンサルティング会社 CommonSense の代表であり、Scrum イベントのトレーナー、そして新しい働き方の文化のための freiräume.camp の共同運営者でもあります。
1. Fischbach さん、あなたが好んで用いるプロジェクト管理の手法は何ですか。
私たちのお客様が支援を求める理由は、主に二つあります。一つは組織プロジェクト（たとえば ERP ソフトウェアや文書管理システムの導入）、もう一つはアジャイルな業務体制（Scrum など）の導入で、これももちろん組織プロジェクトの一種です。どちらの領域でも、私たちは主に Scrum を用います。
コミュニティでは Scrum をプロジェクト管理手法としてではなく、チームのプロセスとして、また優れた製品を開発するための手段として捉えています。そして私たちのプロジェクトで重要なのも、まさにそこにあります。製品を提供し始め、それを継続的に改善していくチームを育てることです。私たちにとってプロジェクトの仕事とは、不確実性のもとで成果を出すことを意味します。プロジェクトは承認されるのではなく、資金を投じられるものです。タスクやスケジュールの計画を話し合う前に、そもそもどのような成果を出すべきなのかについて、チーム内で十分な共通理解が必要です。その際、私たちは PRINCE2 の製品ベースの計画、Earned Value Management（ANSI 748）、Benefits Management（Ward/Daniel）、Performance Based Project Management（Alleman）、User Story Mapping（Patton）、Impact Mapping（Adzic）などを活用します。
実際の不確実性がどれほど高いかを、経営層やチームはしばしば過小評価します。そのため私たちは、プロジェクトの不確実性を説明するのに Shenhar/Dvir のダイヤモンドモデルを用います。重要なプロジェクトでは、モンテカルロ・シミュレーションで日程とコストの確率を検証することをお勧めします。主要な作業パッケージについて三点見積もりを行い、乱数を使って 1,000 通りのシナリオを一度見てみると、最初の計画が実はかなり起こりにくいものだと気づくことがよくあります。
ちなみに Ken Schwaber 氏と Jeff Sutherland 氏は 2017 年 11 月に Scrum Guide の新版を公開しました。
2. 大規模なプロジェクトではソフトウェアを使いますか。使う場合、どのソフトウェアですか。
私たちはソフトウェアの大ファンというわけではありません。それはソフトウェア自体のせいではなく、その使われ方によるものです。私たちが目指すのは、一か所に集まって働く安定したチームです。それには、空いた壁一面、付箋、フリップチャートがあれば十分なことが多いのです。チームメンバーが複数の拠点に分かれている場合は、電子的な支援が役立ちます。ただしその場合でも、私たちはボードを写真に撮って共有の保管場所に保存する方法を好みます。
私たちのお客様は JIRA や Trello をよく使っています。しかし、これらのツールではチームが処理できる以上の速さでデータ量が増えていきます。せっせとデータが入力され、必須項目がどんどん増えていくため、維持管理はますます手間がかかります。やがて、何が提供済みで、どの作業がまだ残っているのか、誰も把握できなくなります。ページの読み込みや検索にも時間がかかるようになります。一部のメンバーは仕事を片づけるためにソフトウェアを回避するようになります。そのような場合は、まず利用を止めて立ち止まってみるのがよいでしょう。そもそも私たちはこのソフトウェアで何を実現したかったのか、と。もちろん多くの製品で未処理事項を管理したり工数を計上したりもできます。しかし、ソフトウェアは本当にそのために役立つべきなのでしょうか。
3. プロジェクトでお気に入りの習慣（リチュアル）は何ですか。
私は Story Mapping をとても好んで使います。お客様のもとには、いつも非常に優秀な社員の方々がいらっしゃいます。多くの場合に欠けているのは、物事に対する共通の視点です。そこで Story Mapping が本当に役立つと感じています。一、二時間ほど時間を取り、プロセスや製品構造をより深く理解し、そこから作業の重点を導き出します。その後のリファインメントや計画のイベントでは、作成したマップを参照します。
4. プロジェクトの成功要因のうち、最も過小評価されているものの一つは何だとお考えですか。
a) 成果で考えること。プロジェクト管理に関するさまざまな調査（たとえば PWC の Insights and Trends: Current Portfolio, Programme, and Project Management Practices, The third global survey on management）を見ると、プロジェクトが失敗するのは PM の知識不足が原因ではない、という結論に至ります。むしろ、プロジェクトの仕事に対する私たち自身の理解が妨げになっていることが多すぎると考えています。プロジェクトの仕事とは、タスクリストやコスト計画を作って管理すること以上のものです。それは不確実性のもとで成果を出すことを意味します。最も重要な問いは常に、私たちは何を提供し、何を変えたいのか、ということです。ERP プロジェクトでは、技術システムを用意すること自体が目標ではありません。利用者は特定の機能を必要としています。納品書や請求書を印刷したいのです。DMS プロジェクトも、文書を保管することが目的ではありません。チームで業務を完結させることが目的であり、そのために文書が必要なのです。プロジェクトの後に、私たちはどのような能力を身につけ、あるいは以前よりうまくできるようになりたいのでしょうか。
b) プロジェクトは承認されるのではなく、資金を投じられるものである。プロジェクトはあまりにもしばしばコストの発生源と見なされます。アジャイルのコミュニティはこの点で見方を変えてきました。彼らの視点では、実施されるのはプロジェクトではなく、それによって利益を生む（あるいは節約する）製品が（先行して）資金を得ているのです。アジャイルの視点から、そしてちなみに PRINCE2 の視点からも、経済性（Business Value、Business Case）が前面に置かれます。お客様がプロジェクトのコストを見積もった後、私はよくこう尋ねます。会社がその二倍から三倍を稼げるようにするには、具体的にどの働き方を変える必要がありますか、と。これはとても興味深い議論になります。真にアジャイルな文脈では、プロダクトオーナーはプロジェクトリーダーではなく、一人の事業家なのです。
5. あなたにとって最大の時間泥棒は何ですか。
焦点の定まらない会議: 私は Scrum を高く評価しています。セレモニーが再びイベントに戻るからです。Scrum の各イベントには明確な焦点があります。何かを計画するか、成果を見るかのどちらかです。一人の人が何をしてきたかが問題ではありません。評価されるのは成果だけです。これがエネルギーを解き放ちます。よくないプロジェクトには、長すぎるリストを延々と読み合わせるステータス会議があります。そこでは大人が再び小学生になり、なぜ宿題をやらなかったのかを先生に説明するのです。ひどい話です。非現実的な計画の原因をなくす代わりに、人にプレッシャーがかけられます。この仕組みは機能しません。
過負荷: 私たちのお客様は皆、進行中の作業のリストが長すぎます。あまりにも多くを抱え込んでいるのです。すべてを同時にこなそうとします。あちこちの現場を切り替えること自体に多くの時間がかかります。同時に 5 つのプロジェクトを抱えると、社員は自分の時間の 4 分の 3 をプロジェクト間の切り替えに費やすことになります。プロジェクトのステータス会議に出席し、議事録を書いたり読んだりし、引き継ぎを行います。これらはすべて、成果には何の価値も加えないのに、膨大な労力を要する作業です。
お時間をいただき、ありがとうございました。次のプロジェクトのご成功をお祈りします。
このブログ記事についてご質問やご意見がございましたら、ぜひフォーラムへのご投稿をお待ちしております。
