技術的負債はプロジェクトの成功に含まれるか

某所でのつぶやきに対して、もにゃった人から意見を求められた。

「プロジェクトの成功って何ですか」

その質問の背景をこちらから尋ねる前に説明してくれた。コンテキスト的には冒頭の某所のつぶやきをみてその発言された方がいうプロジェクトの成功は誰の立場で言っているか、発言された方の影響力があるにも関わらず自覚のないような発言を見ているとよからぬ波紋がひろがのではないかと言ったいくつかの気持ちを織り交ぜてもにゃっているように感じられた。

結論から言えば、発言された方やその周辺の関係者を入れて話す機会を作ることで議論をしたい方の欲求は一旦、受け付けらることになった。召喚する相手がsnsで繋がっていると即座にグループを作れ、その場（＝意見を求められたそのタイミングで）でグループに招待するだけで忘れずに約束を果たせるのは素晴らしいと思う。

プロジェクトの成功とは何か

PMBOKの最初の方のページでプロジェクトの定義を読めばいいのだが、端的に言えば有期限性を持つ業務活動の目的を達成すれば良いのだ。目的は定性的な概念が多いため、目標を定量的に設定することが必要だ。このときの目標にKPIを設定することになるだろう。

このKPIにQCDSなどが設定される。

プロジェクトの成功とは誰のものか

 冒頭の意見を求められたところで、起因となったつぶやきの成功とは誰の立場で発言しているかと言うところが議論の最初に行われる確認ポイントととなる。

なぜ誰の立場でが確認ポイントになると言う理由は、下図の行にあたる組織が誰に相当し、その立場でプロジェクトの定義が変わるからだ。

内製化する場合は、ベンダやサブコンは組織内の主管部署に置き換えればよく、その場合はサブコンやサブサブコンは存在しない。

何れにしても、プロジェクトに関わる立場が変わればプロジェクトのスコープが変わると言うことだし、図から最大のスコープを持っているのはオーナ自身であることが明らかだ。

それを踏まれば、プロジェクトはオーナのものだと考えるのが妥当であるが、世の中的にはPMBOKを含め、ベンダの立場で語られることが多いし、前に取り上げた日経の記事は記事内で行われるアンケートの回答者の偏りで変わってしまっている。

技術的負債をどう取り扱うか

 冒頭の質問者のもにゃった疑問は、よくよく聞くとプロダクトライフサイクルの最初のプロジェクトで制約事項から本来は考慮される技術的負債を抱えたままリリースしてしまい、それは2つ目のプロジェクトにマイナスの遺産相続されてしまうのでそこが耐えられないと言う。

プロジェクトマネジメントが適正に適用されるのであれば、技術的負債を作り込まないように作業標準化がなされているはずである。

なされているはずのものがなされていないのは、本来は適用される作業標準化をネグらなければならない制約条件若しくは前提事項が優先されたと言うことだ。

これはプロジェクトをデリバリする役割からオーナに伝え、プロジェクトとして意思決定される議案である。これを踏まえていなければ、技術的負債はデリバリするチームが勝手に行ったことであり、オーナサイドから見れば、デリバリするチーム側の負担で解消しなければならない。

逆に、技術的負債を織り込む可能性があるとオーナと議論し、オーナ同意で制約条件や前提条件を飲むとしたら、それはそれで構わない。オーナが決めたのだから。

あるあるなケースでは、技術的負債を抱えることもNGだし、制約条件も織りこめと言われる場合は、それを実現する方法に置き換えるか、スコープを分割し、プロジェクトをさらに細分化し、細分化したスコープをプロジェクトとして執行することが望ましいし、現実的である。要は、技術的負債を防止するための作業量を織り込んだ工数を見積もりし、予算が合わないなら予算の合わせたスコープにせよと言うことだ。