「プロジェクト」じゃないよ「プロダクト」だよ
はじめに
以前の翻訳記事を書いてみたのはここ
これに対して、「プロジェクト」ではなく「プロダクト」というマインドセットになってもらうことで説明がつくような事象に多く出会ったここ最近でした。
言語化することでさらに自分の脳内を整理するために記事化します。
2つの言葉の意味のおさらい
プロジェクト
「プロジェクトとは、独自のプロダクト、サービス、所産を創造するために実施する有期性のある業務」PMBOKとかより(買ったことないからわからない)
つまり
期限のある、何かしらの活動
という感じ。
期限に対して、どのように成果を出すか(納品をするか)を追求する活動な気がします。
プロダクト
「製品」「サービス」「商品」で生み出された価値・成果そのもののことかな？という感じ
中心となる言葉が変わることによる変化
プロジェクトでの考え方
計画に沿い期間内でサービス/商品/プロダクトを納品することに主眼が置かれます。
プロジェクトの意味に有期(期限が存在する)が含まれるかぎり、期限に向かってアウトプットを出すことが至上命題となります。
期限に対して着地をしなければいけないので、基本的に計画外のことはしたくありません。計画外の事が発生しても収束可能ということは、何かしらの余分な見積もりがされていることになります。(計画外の事が発生しない場合はぼったくりですね)
計画完了時点である程度計画が変更されない根拠がないと成り立たないので、計画駆動とは若干の矛盾というか達成不可能な部分は含んでるんでしょう・・・。
計画を完遂するために、フェーズを区切り、その作業に最適なコストとリソースを最適数割り当てます。フェーズを跨ぐときには得意分野の違うメンバーが稼働するので、引き継ぐ資料が必要となります。
決まった作業量と達成目標から分解して計画をしているので、変更を許容する概念は基本的にはありません。
計画にあるものを計画通りに納品することが求められるので、計画よりも(主観的に)良い/悪い状態を許容しません。
何よりも辛いのが、開発プロジェクトの完了がプロダクト開始の合図になってしまうことです。開発プロジェクトが終わったとて、そのプロダクトがどれだけ活きてくるかわかるのはそのプロジェクトには関係ないことかもしれません。
プロジェクトでの具体例
いわゆるウォーターフォールのような状態だという前提で例をあげます。
大規模と呼ばれるような(定義とかわからないので自由に想像してもらえると・・・)プロジェクトを例にします。
私たちは大規模なサービス開発をウォーターフォールで開発していると思ってください。
大規模なプロジェクトであれば、もちろん、大規模な人数で大規模な期間をかけてプロジェクトが実施されます。
上流工程で、設計担当の人たちがヒアリングや企画を行い、サービスを設計していきます。(概ね必要なコストも算出)
次は製造担当の人たちに作業は引き継がれます。
仕様書や設計書と呼ばれる資料を作り込むことで、円滑な引き継ぎを行います。
その設計書をもとに、次は製造が行われます。
実際に作っていく段階で、考慮されていない箇所も見つかる事があります。
その考慮漏れによっては大きな変更の可能性もあります。
しかし、計画をされている事柄から大きく変更があることは避けたいのです。
なぜならば、その計画ありきで予算などさらなる計画がされているからです。作業をする側も、最大限の利益を得るためにはより少ない期間と労力で作業をしたいのです。
そうして、計画に合わせ納期に間に合うためにリソースの効率を上げてプロダクトが完成します。
完成したら終わりではありません。
ここから、そのプロダクトが効果を発揮し始めるのです。機能的に使えることが担保されていても、そこに価値があるのかはプロジェクトが完了してからしか確認できません。
これが、プロジェクト中心に進むということです。
プロダクトでの考え方
プロダクトが顧客価値を生む事に主眼が置かれます。
プロダクトが価値を生むためには、1人の意見だけで成功を掴むことは難しくなります。なので、プロダクトチームに多様性を含ませ、違う意見を求めます。より忌憚のない意見を全員が出せるように、組織の構造を構築していきます。
プロダクトの直接価値の向上につなげるために、できる限りのムダを排除しようとします。それは、トヨタ生産方式やリーンなどで語られる、7つのムダだったりします。売れないものは作りたくない、余計な引き継ぎを発生させたくない・・・安定して価値を提供・拡大させていきたいのです。
プロダクト開発は基本的に無期です。なぜならば、プロダクトが求められる限り、継続・改良していきたいからです。
なので、できる限り持続可能な環境を整えます。
それは、作業者の作業ボリュームの話かもしれません。
それは、リスクの少ない開発方式かもしれません。
プロダクト開発において、計画通りに完成させる事に大きな意味はありません。価値提供をリスク少なく行いたいのです。
そのためには、作り込んでから市場に提供することをしません。
なぜならば、作り込むということは当たらない可能性を増やすことにつながるからです。投資をすればするほどリターンがあるというわけではないことを受け入れているのです。小さな投資で大きくリターンを得られる可能性に賭けます。その可能性がより高いと思われる想定価値を提供していきます。
プロダクト開発であれば、リリースした時点で投資に対する効果を得られます。効果を得られる単位で素早く市場投下していく考えになります。
プロダクトでの具体例
いわゆるアジャイルな開発をイメージしてください。
少人数で、スプリントという細かい連続した期間で開発をし続けます。
開発する機能に優先度をつけ優先度の高いものからリリースしていきます。
人数は、属人化しない程度です。
そして十分に多様な程度がいいかもしれません。
人数をかけすぎることも投資のリスクになります。意思統一やコミュニケーションが円滑にいかない原因になります。
スプリントという細かな連続した期間を採用します。それは、一定期間で市場価値のあるものを市場投下したいからです。できるだけ早く市場に投下することで、市場の反応が分かります。投資対効果のないものの反応がわかることはリスクを回避することに繋がります。
この期間中に、プロダクトの市場価値に対する実験と検証が行えます。
そして他にも、プロダクトチーム自体のプロセスの検証も行えます。
価値提供の観点と、自分達のプロセスの観点で検証を行えると、そこからムダを省くことができます。必要ない機能への投資、必要ない資料への作業コストの投下、必要のないプロセスによる市場提供遅延などがカイゼンされることになります。
まとめ
プロジェクト中心＝ウォーターフォール
プロダクト中心＝アジャイル
の概念はどこまで言い切っていいものなのかはちょっと不安です・・・。
ただ、中心に置くものが変わることで、その構造から文化が醸成されることは間違いないと思います。コンウェイの法則！(組織文化は組織構造からなる)
本質とすべきは、「計画と納期」ではなく「提供価値(プロダクト)」のはずです。そこに最適な進め方ができるといいですよね