《第1回》中堅ITコンサルタント奮闘記|大規模プロジェクトの立ち上げに挑戦
はじめまして。株式会社SHIFT ITコンサルティング部の久野(きゅうの)です。
SHIFTはソフトウェアのテスト会社のイメージが強いかもしれませんが、上流から下流まで、トータルでソフトウェア品質保証サービスを提供しています。
そのサービスの1つにPMOサービスがあります。全3回の予定で、大規模プロジェクトに参画したSHIFTの中堅コンサルタントのお悩み相談を通して、PMOサービスで起こりがちな課題について一緒に考えて行きたいと思います。
第1回では、大規模プロジェクトに参画した中堅PMが、プロジェクトの立ち上げに直面しています。従来のQCD管理を重視したシステム構築の開発プロセスだけでなく、DAAE(ダーエ)の概念を取り入れることで、さらにお客様のビジネスに貢献できることを学びます。
第2回では、SHIFTが提供している「上流から下流までトータルの品質保証」について、「本当に必要な品質とは何か、品質はどうやって作りこむのか」を探って行きます。
第3回では、マルチベンダーでのシステム構築が当たり前になった昨今、マルチベンダーゆえの問題とその時にどう対処すればいいのか、考えたいと思います。
第1回 大規模プロジェクトの立ち上げに挑戦
先輩さん:珍しいじゃないか、いつも自信満々の中堅君が俺に相談なんて。
中堅くん:やめてくださいよ。今回のプロジェクトは、経験したことがない規模で、かつ、対象の業務範囲も広くて、今までと勝手が違って思うようにならないんです。。。
先輩さん:中堅くんの役割は?
中堅くん:PMOの役割で、お客様のPMの方を助けてプロジェクトを推進しないといけないんです。PMの方はPMが業務部門から来た方でシステム開発には詳しくないそうです。
先輩さん: 大抜擢じゃないか!そんな大きなプロジェクトを任されるなんて。頑張れよ!力になれるか分からんが、俺でよければ何でも聞いてやるぞ。
スピード重視か品質重視か
中堅くん:関係部署も多いんですが、特に営業部門と製造部門の意見が食い違っています。営業部門は現行のシステムの開発期間に不満を持っています。納期回答を早くしたい、車の出荷予定日を早く見たい。1年半も待てない。早くやれと。
それに対して、製造部門は小手先の改修ではなく抜本的な見直しが必要だという考え方です。受注から出荷までのリードタイムを短縮したいし、在庫も減らしたい。全体の設計を検証して要件が実現できることを確認してから開発に着手しないと真の問題を解決できない。腰を据えて取り組まないと品質の悪いシステムになってしまうことを心配しています。
先輩さん:なるほどね。どちらの言い分も正しい意見だと思うよ。
中堅くん:そうなんです。だから困っているんです。
先輩さん:どちらか一方に決めることはないんじゃないかな。ビジネスニーズに合わせて臨機応変にやれば良い。営業部門の要件は、基幹システムは変更せずに、フロントエンドの仕組みで対応できる。
DAAE(ダーエ)って知ってるかい?
中堅くん:SHIFTが提唱しているシステム開発の概念ですよね。Design Agility Assembly Economic Quality。サービス提供スピード重視、できた機能からリリース、Agile開発をベースにした考え方ですよね。
先輩さん:そう。スピードを重視して、きっちりした要件定義はやらずに、できた機能からリリースしていく。品質のポイントは経済品質という考えだ。使ってもらって、エンドユーザーからのフィードバックで改善していく。
中堅くん:営業部門の要求にピッタリです。でも、製造部門は納得してくれないと思うんです。
先輩さん:製造部門が要求しているバックエンドの改革は間違いがあってはいけないから、確実性を重視して機能仕様を担保する進め方があっている。スピードを要求されている施策はDAAE、確実性を要求される施策は従来の開発プロセス、組み合わせたらどうだい。ハイブリッド型と呼ぶんだ。それなら営業部門も製造部門も両方とも満足できる。
もちろんタイミングを合わせる難しさはあるが、DAAEの概念と従来の開発プロセスのいいとこ取りができる。
中堅くん:分かりました。やってみます!
プロジェクトの施策が決まらない
中堅くん:ところで、プロジェクトの施策についても、営業部門と製造部門で衝突しています。営業部門は受注を受けたらすぐに出荷できるように在庫を持てと言っていて、製造部門は過剰在庫を抱えることになるから受注生産にするべきだと言っています。
先輩さん: なるほど。ありがちなことだね。組織の長は組織の利害代表者だからね。でも中堅君の腕の見せ所じゃないかな?まずは、誰かに決めてもらおうとせずに、自分が決めるつもりで考えてみたらどうだい。
中堅くん:まさか!そんなの無理ですよ。そんな立場じゃないですよ。PMOですから。
先輩さん:お客様がプロジェクトの施策が決まらず困っているなら、それを解決するのも俺たちの役割だよ。プロジェクトの施策は、お客様のビジネスの課題解決や目標達成と一致していないといけない。そのためには、お客様から中期経営計画や年度計画を見せてもらえば、業務上の課題や方針を読み取ることができる。
たとえば、お客様満足度向上の施策として納期回答のリードタイム短縮が書かれているかもしれない。在庫金額削減のための在庫回転率向上が書かれているかもしれない。といったほかにも、会社のビジネスの状況や業界の動向を調べて、会社の強みや弱みを分析する方法もある。
施策を決める判断基準は、その施策を行うことによる投資対効果だ。ビジネスにどれだけ貢献できるか示すことができれば、組織の利害に左右されなくて済む。組織外の第3者立場の中堅君だからこそ客観的な意見を出せるはずだ。
中堅くん:分かりました。やってみます!
何を達成できたらプロジェクトの成功と言えるか
先輩さん:プロジェクトの目的を決めたとして、プロジェクトの目標も設定しておかないといけないよ。 目的は「何のためか」、目標は「何を達成するか」だ。
プロジェクトの目標は、ビジネスの目標と一致していないといけない。
1つ目の話題では、スピードと品質の両方の要求に応えることを話したよね。急を要するビジネスニーズに対してどれだけの開発期間で実現できたかも1つの指標だ。2つ目の話題では、ビジネス視点で施策を決めるという話をした。ビジネス視点のKPIを目標に設定すべきなんだ。
たとえば、営業部門なら納期回答のリードタイム、製造部門なら在庫金額。
中堅くん:なるほど。。。
先輩さん:プロジェクトが進むにつれて、システムを本番稼働させることがプロジェクトの目的に置き換わってしまうんだ。システムを本番稼働させるためなら、あらゆる妥協が許されてしまう。本番稼働できないと責任問題だからね。そんなプロジェクト、身に覚えがあるだろう?
中堅くん:否定できません。。。
先輩さん:システムが本番稼働したらプロジェクトが成功したと喜ぶのはとんでもない錯覚だよ。ビジネスの目標を達成できて初めてプロジェクトが成功したと言える。だから、プロジェクトが立ち上がったタイミングで目標を設定しておく。後になってから設定するのは難しいからね。
中堅くん:よく分かりました。やってみます!
これで中堅くんのプロジェクト立ち上げは上手くいきそうですね!
今回は、「プロジェクトの立ち上げ」という状況における、3つのポイントを紹介しました。
ポイント1:スピードと品質の両方の要求に応える
DAAEの概念を導入することにより、スピードを重視したビジネスニーズにも応えることができます。
ポイント2:お客様のビジネス視点で意思決定を促す
お客様のビジネス課題を把握して、プロジェクトの施策を検討、助言する。
ポイント3:ビジネスの目標と一致したプロジェクトの目標を設定する
プロジェクトの成功とは、ビジネス上の目的を達成することです。
▶次回
《第2回》中堅ITコンサルタント奮闘記|本当に必要な品質保証を考える
上流工程から下流工程まで品質保証のお悩みについてお答えします。
▶最終話
《第3回》中堅ITコンサルタント奮闘記|マルチベンダー体制のシステム開発に四苦八苦
SHIFTのコンサルティングサービス
お客様のビジネスニーズに応え、ビジネスの目標を達成するため、SHIFTには多種多様な業界で経験を積んだメンバーが在籍しています。多様性のあるバックボーンをもつメンバーを適材適所にアサインすることによって、上流から下流までトータルでサービスを提供できる体制を作り上げています。
https://service.shiftinc.jp/service/consulting/
__________________________________
お問合せはお気軽に
https://service.shiftinc.jp/contact/
SHIFTについて(コーポレートサイト)
https://www.shiftinc.jp/
SHIFTのサービスについて(サービスサイト)
https://service.shiftinc.jp/
SHIFTの導入事例
https://service.shiftinc.jp/case/
お役立ち資料はこちら
https://service.shiftinc.jp/resources/
SHIFTの採用情報はこちら
https://recruit.shiftinc.jp/career/