プロダクトオーナーに必要なスキル
問題提起
プロダクトオーナー（ Product Owner : PO ）はアジャイルの方法論 の 1 つであるスクラムで定義されているロールです。
スクラムガイド では以下のように説明されています。
プロダクトオーナーは、スクラムチームから⽣み出されるプロダクトの価値を最⼤化することの結果に責任を持つ。組織・スクラムチーム・個⼈によって、その⽅法はさまざまである。
このような説明からか、企業におけるビジネス・サービス企画系部門の社員が担うケースが多いです。
そして昨今の日本企業はシステム開発の内製化途上であるため、多くの場合、開発者は IT 企業から SES 契約[1]などにより集められます。
この時何が起こるでしょうか？
開発が思うように進まない のです。
なぜ開発が進まないのか？
なぜ開発が思うように進まないのでしょうか。
社外から集められた開発者は基本的に業務委託元である企業のビジネスについて深く理解しているとは言えません。
そして、業務委託元企業のビジネス・サービス企画系部門に所属するプロダクトオーナーは、システム開発のことをよく知りません。
何が起こるでしょうか。
それは、このバックグラウンドの違いにより、コミュニケーションがうまくいかないのです。
仲が悪いという意味ではありません。
プロダクトオーナーは作って欲しいものを開発者に話します。
開発者はプロダクトオーナーに質問します。
プロダクトオーナーはうまく質問に答えられません。
例えば、次のような感じです。（やや極端な例ですが、ご容赦ください。）
プロダクトオーナー： Webサイトでログイン画面を作ってください。
開発者： Basic認証でいいですか？
プロダクトオーナー： べーしっく認証とは何ですか？
開発者： IDとパスワードで認証することです。
開発者： IDは何桁で許容する文字はどうしますか？
プロダクトオーナー： ちょっとわからないので、よくある感じで作ってください。
開発者： （ちゃんと要件決めてくれないと作れないな。。。）
こんな感じです。
プロダクトオーナーだけが悪いわけではなく、要件が明確である請負開発に慣れきった開発者もまた柔軟性に欠けるという見方もできるでしょう。
どちらの責と言及しないにせよ、これは「 サービス要件をシステム要件に落とし込めない 」ことが原因で発生しています。
これまではどうだったのか？
前節のような話を聞くと、今に始まったことではなく昔からあったことなのでは？と思われることでしょう。
そうです。ただし、今回のケースでは事情が異なります。
とある企業にビジネスあるいは会社経営上の課題がありました。
経営幹部はコンサルタントを雇い、課題解決するためのソリューションの提案をもらいます。
その中に IT システムの構築が必要なものがありました。
コンサルタントは顧客（企業の経営者や部門の責任者・メンバなど）にヒアリングを行いながらサービス・システム要件を盛り込んだ RFP[2] を作成します。
作成された RFP は顧客企業の IT 部門のレビュに通され、システム要件が精査・修正されます。
そしてこの RFP は複数の IT ベンダに送付され、システム開発を請け負うベンダを選定するコンペにかけられます。
企業は複数の IT ベンダからの提案を受け、総合的に判断をし、発注先の IT ベンダを選定します。
細かな差異はあれど、概ねこのような流れで企業はシステム開発を発注し、 IT ベンダはそれを請け負います。
この流れの中に サービス要件をシステム要件に落とし込むプロセスが含まれている のです。
前節までで挙げた、プロダクトオーナーと開発者との関係と比較してどうでしょうか？
どう対応するのか？
「 サービス要件をシステム要件に落とし込む 」にはどうすればよいでしょうか？が本節のテーマになります。
記事のタイトルからすると、プロダクトオーナーがそのスキルを身につければいい、という話になりますが、それではつまらないので他の方法も含めて考えてみます。
ツールを使う
何らかのツール・方法論などでプロダクトオーナーと開発者の間を繋げないでしょうか。
例えば ドメイン駆動設計 です。
ドメイン駆動設計は、イベントストーミングといった手法から UX を設計し、ビジネス側にも開発側にも理解できる「ドメインモデル」というものを中心に添えてコミュニケーションし、実装に落としていく方法論です。
ただし、ここでは詳細には触れませんが、このドメイン駆動設計というもの、なかなか難しいです。
開発者が幅出しする
筆者は技術者なので開発者よりの人間です。
本記事のタイトルがあんな感じになったのも、本節のテーマを嫌厭しているからです。
ただし、実装者ではなく、旧来からの業務機能開発チームリーダポジションの方はどうでしょうか。
実際に実装（コーディングやサーバ構築・設定）することは無いものの、要件から仕様・設計に落とす領域を担当してきたキャリアのイメージです。
上記のようなキャリアを積んできた方がもう少し上流へシフトするのが比較的近道なのではないでしょうか。
プロダクトオーナーが幅出しする
そもそも学校教育のプログラミング必須化やその他 IT 人材不足への対応など、日本の国家レベルで IT リテラシや人材数の底上げが行われています。
本記事の文脈に沿わなくとも、ある程度の幅出しは必要でしょう。
しかし、現実的なところではなかなか難しいでしょう。
例えば、プログラミングが出来たところでシステム設計まではまだ距離があります。経験が必要です。
（逆に、技術畑の筆者としてはビジネス側にシフトするのも難しいと思ってます。。。）
社員を採用する
人を雇う、といったタイトルでもよいのですが、コミットメントが必要な役割ですので敢えてこのタイトルにしています。
企業が新規に作る DX 系部門の組織長やメンバは社外からの中途入社の方が多いです。
そして、この中途入社の方々（特に組織長や管理職となる方々）は、 IT ベンダ出身ではなく IT に強い事業会社出身の方が多いです。
彼ら彼女らはビジネスにもシステムにも染み出し、間を取り持つことができます。
さいごに
これまでの記載でやや筆者の意見が見え隠れしましたが、結論は書きません。
どの方法にもメリデメがあり、筆者自身もどれが最適か判断できないからです。（もちろん他にも方法はあると思います。）
しかしながら、 サービス要件をシステム要件に落とし込む 能力を持ち、 プロダクトオーナーのアシスタント としてビジネスとシステムの間を取り持つ役割の ニーズは非常に多い と実感しています。
皆さんの周りはどのような状況でしょうか。
Discussion