プログラムマネジメントとプロダクトマネジメントは双子の兄弟か

とある夜の会合で某氏が

「プロダクトマネジメントはプログラムマネジメントではないか」

と言い置いて席を離れた後、そうかねぇとツラツラとそれが成り立つかを頭の中で考えようとしたけれどなんだかよくわからない。

わからないときにはわからない頭の中でこねくり回しても時間の無駄なので言葉の意味合い、定義から調べなおすのが兎に角一歩進めるのでそうする。

「製品、製品ライン、あるいは製品ポートフォリオのレベルでのビジネスマネジメント」

引用　

プロダクトマネジメントとは / PMstyleコラム

うーん、わかったような、わかっていたような。つまりだ、モノコトのビジネス・ライフサイクルをマネジメントする、という意味であると理解することにした。

標準書全体の文脈を含めて読み取ると、米国ではプログラム＝「巨大なプロジェクト」というとらえ方が強いが、日欧では「事業を創出する諸活動」との文脈でとらえる傾向がある

引用　プログラム・マネジメントは本当にプロジェクト・マネジメントの上位概念なのか : タイム・コンサルタントの日誌から

なるほど。局によって意味合いが少し違うけれど、日欧では事業＝ビジネスの諸活動の意味合いで使われると。

いいとこ取りしている感じの日本の定義を見ると、欧米の両方を包含した定義になっているのでますます曖昧になる。

日本PM協会: 新版P2M標準ガイドブック (2007)
使命（ミッション）を実現するために、複数のプロジェクトが有機的に結合された事業。　- 「大規模システム型プログラム」と「戦略型プログラム」（創出・変革型）とに分類される（定常業務はサービスプロジェクトとして位置づけられている）。

 引用　同上

特に、有機的に結合された事業とは、ビジネスオーナが担当事業の範囲でマネジメントしていればリソースやビジネスの判断は配下のビジネスの事情を考慮してジャッジするのでとても有機的である。

プロダクトマネジメントはモノコトのライフサイクルマネジメントだとするとプログラムマネジメントの事業を創出する諸活動が当てはまらなくもない、というか当てはまると言い切っても間違いではなさそうだ。

ところで、これまでプロダクトマネジメントに関わるまでは、プログラムマネジメントとは、プロジェクトマネジメントを束ねたマネジメントスタイルがプログラムマネジメントだと思っていた口である。

古いPMBOKをベースの知識として、あとは実施に経験して補完した限り、それで間違いはないと思うし、実は今でもそうだと思いっている。

なぜかというと、ビジネスにおいてサービスの創出や世代更新からマーケティングやセリングに携わっているとモノコトのライフサイクルマネジメントを複数並行して見ていたからだ。

そのときはプロダクトマネジメントという呼び方はしていなかったけれど、実務的にそれをやっていたのである。経験はとても強い知識の関連性を産むものなので、今のプロダクトマネジメントについては経験の目線から入るから、ああ知っているよ、という反応になるのだ。

多分、プログラムマネジメントとプロダクトマネジメントは違うもので差分があると思う方のプログラムマネジメントが対象とするライフサイクルの範囲が違うのだ。それは、プロジェクトの実行段階である設計からテスト完了までか、その両サイドにある企画からモノコトのサンセットまでを視野にいれているかの差で、これ自体が正解や間違いという判断するものではなく、経験の差があるだけの話だ。

プロダクトマネジャーの教科書

世界で闘うプロダクトマネジャーになるための本 ~トップIT企業のPMとして就職する方法~

改訂3版 P2Mプログラム&プロジェクトマネジメント標準ガイドブック

OKRと目標管理に実装されていなければならないこと

組織によってはあとひと月ちょっとで年度末を迎えるところもあるだろうし、多くは来年3月が年度末のところが多いのでしょう。だいぶ、web系の会社も増えたり、再編があったりすると決算月がいわゆる年度末の3月ではない組織が増えているような気がしますが。

年度末といえば、業績評定です。まあまあ、そんな嫌な顔をしないで。この1年何をやってきたか、自分と向き合うには良いじゃないですか。

 業績評定をするには元となる目標設定が必要で、評定をするためには元の目標設定の大切さについてはこれまでなんどかエントリを書いています。

ここのところ、グーグルのOKR（Objective and Key Result　目標と主な結果）というキーワードを見かけるようになったのですが、それに当たる記事を読んでみてもよくわからないのですよ。

目標管理での目標設定

過去のエントリで書いてるのですが、目標をどう設定するかでその年の目標設定で達成したいコトがほぼ決まってしまうのです。

どういうことかというと、曖昧な目標設定をするとエンジニアに限らず人は自分に甘いので結果的に目標を達成しないというものです。

ですから、目標管理での目標は、

• 定量的な目標を
• 具体的に達成したイメージを持って

設定できるかどうかにかかっていると言い切っても問題はありません。ただ、ほぼ8割方のエンジニアは定量的で達成したときのイメージを目標設定することができないのが実態です。

目標管理でのKPI

 一般的に目標管理のエンジニアレベルの目標を上に辿っていけば、組織の年度の事業計画のKPIに遡れるはずです。いや、遡れなければおかしいです。

なぜなら、組織の事業計画を達成するのが組織に属するエンジニアだからです。そのエンジニアの1年の活動が組織のKPIに結びついていないならエンジニアの活動は評価されないというのと同じです。組織の評価をKPIでするのですから。

そうした考え方を踏まえるなら、エンジニアの目標設定はKPIの一部分を担う定量的な目標になっていなければ辻褄が合いません。

そうした背景もあって、エンジニアの目標管理の目標は、定量的である必要があるし、目標達成時のイメージが具体的である必要がるのです。まあ、後者については、エンジニアが年度の初めで1年後に実際にどうなっているかは別にして、到達したいイメージを作っておかないと最初の一歩が踏み出せないという事情もあるのですが。

OKR

ところでOKRですが、

企業のチームメンバーそれぞれの目標と期待されている結果を明確にし、組織のオペレーションとコミュニケーションを効率化するためのシステム

引用　

KPIはもう古い！ Googleも採用する『OKR』が目標達成に効く理由。 | コラム

だそうです。考え方は良いですよね。期待を明確にして、オペとコミュを効率化しよう、ですから。

目標自体は、エンジニア一人ひとりに設定するものです。一人ひとりのエンジニアの活動結果が集約して組織の事業計画の達成につながるので。

さて、目標を設定するときに、目標は組織の期待だけなのか。いいえ、違いますよね。これも過去のエントリに何度か書いてきましたが、組織の期待とエンジニアの希望のすり合わせの結果の合意がエンジニア一個人の目標にならなければおかしいです。

一方的な期待では、主体性が欠如するので。

引用の中で、

ひとつの目標を階層ごとに細分化、数値化し続けていくことで、チーム内で「何をすべきか、目標は何のためにあるのか」がわかりやすくなります。

とあります。あれ、上述してきた目標管理の目標設定と同じですね。わざわざOKRと言い換える必要があるのかしら。

ただ、こういう言い方は良いなと思います。

しかしたいていの場合、このような目標設定の仕方ではうまく行かない場合が多いもの。なぜならば「結局どうしたいのか」というビジョンをつい忘れがちになってしまうからです。

達成したい目標の達成時のイメージを持っていないと目の前の数字を達成することが目的となってしまうのというところ。よく言われる、目的と手段が擦り変わるというやつですね。

目標を個人に活かす

 結局、組織としてはリソースたるエンジニアに事業計画の達成を担って欲しいのです。それだけ。指揮命令して間違いないくオペレーションする必要のある業務もあるのでしょうが、エンジニア個人の属人的な知識に頼っているシステム開発では、それでうまくいくなら良いけれど、実際はそうならないのは考え、行動するエンジニアに依存しているからです。

だから建前上は、主体的に活動して欲しいわけです。でも強制しても期待する結果は得られないから、エンジニアが気持ちよく働けるように落とし所を模索しているのです。

エンジニアも、組織がそうしようとしていることは見え見えなので、上手に乗ったふりをして、やりたいこと、試してみたいことがあるなら事業計画を担っているように見せかけて目標を設定すれば良いのです。

大体は、儲かる目標になっていれば文句はつきませんから。

そこで必要になるのは、エンジニア自身がこれから1年何をしたいか、どうなっていたいかと事業計画のKPIが落ちてきたときの紐付けと貢献の表現力です。

でもね、儲かるなら（コンプラは当然として）嘘はないわけです。単に、手段まで言っていなかっただけの話です。

だって、目標を達成できれば評価されるのであって、手段を評価するのはお門違いです。それこそ、目的と手段が入れ替わってしまうのですから。

HIGH OUTPUT MANAGEMENT(ハイアウトプット マネジメント) 人を育て、成果を最大にするマネジメント

ワーク・ルールズ！―君の生き方とリーダーシップを変える

How Google Works (ハウ・グーグル・ワークス) ―私たちの働き方とマネジメント

勝つKPI管理導入９つのステップ: 何故この不況下にあの会社は勝ち続けるのか (KPI Trust)

エンジニアが得意でない考え方を共有することのメリット

TLに流れてきたモノゴトの候補群から採用する際のロジックを作る（＝ルールと表現しても良い）という考え方がとてもしっくりしてというか、わたし自身の考え方と似ていて好感を持ったことがありまして。

エンジニアのお仕事って最終的に判断するのは顧客だったり、チームの中ではプロジェクトマネージャだったり、アーキテクトとロールとして権限＝最終責任を負える役割の人がするのだけれど、そこに行く過程で多くの判断の積み重ねを繰り返していて、そのほとんどがチームの一人ひとりのエンジニアが担っているという事実をエンジニアはもう一度、理解し直すべきだと思うのです。

ときどきどうしたものかなーと思うのは、ただただリーダ役や顧客に判断を仰ぐエンジニアを見かけるときなんですよ。あれ、本人は仕事を進めたいからというか、仕事が進捗しないと責められると思っているので必死なのかもしれないですけれど、システムの専門家としてはどうかなぁ、と。

例えば、システムの仕様について判断を得たいとすると、その仕様には様々な解決手段があるわけです。適用する技術が存在するだけ。実際には、想定している前提事項や外部からの制約条件で絞り込みされて、それでもまだいくつかの選択しか残る。

じゃあ、それを選べと言われた顧客が選べるかといえば、それは専門家でないのだから、技術的な観点での判断を要求するのは無理強いなことをしているだけなのです。そりゃ決められなくてずるずると進捗がスリップするわね。

エンジニアも仕様などを考えるときに、多くの情報を揃えて色々と考えて仮説を立てて仕様の合意に至ると思っているのですが、－さすがに思いついたポッと出のアイデアをそのまま仕様にしたりしていないですよね－、その過程では、それを考えるタイミングで確保できる情報をベースに制約条件と前提条件などや機能の振る舞いとしての事前事後条件を含めて仕様のあり方を図式化と言語化していると思うんですよね。

で、このケースは良いだとかこっちのケースは要件が実現できなくてダメだから、と判断のステップを踏んでいるのだと思うわけです。

それを明示化して共有したらどうなんでしょうか。

所詮、隠すことは何一つないのですよ。お金は顧客にもらっているのだし。まあ、1から10まで洗いざらい晒されても顧客はどうして良いか困りますけどね。

でも、仕様の考え方、ロジック（と言っても仕様の中身ではなくモノゴトの決め方）を説明してその上で、相談相手に期待する役割をしてもらえば良いのですよ。

そのロジックは日頃ブログで書いているトップダウンで考えようというのに結びつきます。概念から説明して行くとそれの判断を求められる方も情報が大局から掴めるので追いついていけるんですよね。それがボトムアップでしたら積み上げようとすると仔細な仕様だと詰めきれていないことが多くてそこにアラが出てあら探しになってしまうので。

調達 iPhoneX bluetoothレシーバー

イヤフォンをiPhoneXに繋ぐケーブルがとっても貧弱で、実際、朝夕の通勤で使うにはすぐに断線しそうで不安になるくらい。

buletoothのカナル型イヤフォンでも買おうかと思ってネットで探していたら、buletoothレシーバーで繋いでいる人がいてソニーの最新型のそれを見つけたので買いに。

SONY ソニー ワイヤレスステレオヘッドセット SBH24 : カナル型 Bluetooth対応リモコン・マイク付き 2017年モデル ブラック Black [並行輸入品]

ヨドバシに行って現物のありかを教えてもらったときに、音質を聞いて見たら「値段なりですよ」と言われたので、じゃあ、いい感じのはどれと聞いたらこれをオススメされたので勢いで買ってきた。

オーディオテクニカ Bluetooth対応ポータブル・ヘッドホンアンプaudio-technica AT-PHA55BT

出たばかりで、店頭在庫はないよと張り紙があったけど、店員さんにあったら買うのにと言ったらその場で在庫を調べてくれて、在庫補充完了してましたと。

何事もダメ元で聞いて見ることは大事だなー。

システム開発手法は変えていくものであることを中堅エンジニアは知っているのだろうか

新人で配属されたエンジニアは最初にアサイメントされたプロジェクトチームのやり方で、システム開発の方法を刷り込まれてしまうんですよ。これ自体は誰もが当たり前だと思ってしまうのだけれど、これ、ほんと怖いので。

何が怖いかというと、アジャイ開発のスクラムでも、まだほとんどのプロジェクトで採用しているウォーターフォールでも同じなのだけれど、最初に刷り込まれたシステム開発手法が、－いや、システム開発手法と呼べるものならいいのだけれど－、新人エンジニアの標準になってしまうのです。

基本的な考え方として、システム開発におけるシステム開発手法はその対象のプロジェクトに最適化しているので、テーラリングされているのです。つまり、局所最適化されているので他のプロジェクトに合わせようとすると無理無駄が生じるのです。

理想というか、あるべき姿は、基本的なシステム開発手法の雛形があって、それをプロジェクトの特性でテーラリング、個別最適化するものです。

でも、新人エンジニアが最初に出会うプロジェクトでのやり方以外を学ぶ機会がないので、現場で覚えたシステム開発手法が正だと思って覚えてしまう。

問題なのは、それは変えてはいけないものだ、そうあるべきだと位置付けてしまうことです。本来は、雛形からテーラリングで変えるのが当たり前なのですから、真逆に理解されてしまうとよりよくするために変えていくという考え方がなかったことになってしまうのです。

さらに拍車をかけるのは、チームのルールを守れと徹底すること。これはこれで必要なことなのですが、それはチームの合意を持って変えていくという方針も合わせて示さないとこれが起きるです。

今、あなたが現場でやっているシステム開発はその現場の方言でしかないのです。それもプロジェクトに最適化されているかどうかもわからない。

そうしたことを考えたことがないなら、それは多分、プロジェクトの中で無理無駄を多くやっているのです。どうしてかはすでに上述してきたとおり、テーラリングを継続的に行なっていないから。

新人エンジニアはもちろん、中堅エンジニアも今のプロジェクトで採用されているシステム開発手法がそのプロジェクトで最適、つまり、開発の無理無駄がないかを毎日疑ってかかってみなければならないのです。そして無理無駄を見つけて少しでも開発が楽に楽しく、期待する品質を確保できるやり方を探求しなければ。

ベテランエンジニアはいいのかって。ええ、言われたままやるエンジニアが多いですよね。そうならないようになって欲しいのですよ。

辛いレビューをハックする3つの方法

プロジェクトメンバが文書レビューを受けているのを見ると、レビューを受けること自体が嫌そうだし、受けている最中も苦痛のようだし、終わった後の憔悴感といったら不憫でなりません。

じゃあ、お前はと言われれば、

「はいはい、どうぞどうぞ。一番目でも辛辣なご指摘でも言ってください」

など口には出して言いませんが、内心もそれほど差はないくらいの軽やかにレビューを受けております。

何せ、レビューをしてくれる方が偉い人が多いので、このくらいの心持ちでないとやっていられません。

レビューのハックの記事やテクニックを読む限り、「○○すること」「△△禁止」的な書きっぷりが多いです。もしからしたら、過去記事にそんなのがあるかも。

＃あるとすれば、フォーマルなレビューのやり方があったかもしれない…。

実際のレビューを受けている際には、あれこれしなければならない系は身につくまでは全く役に立たないです。振る舞いが自然と身につくまではレビューでの説明で目一杯だし、目一杯なところに質問や指摘やマサカリが飛んでくるのでそれを避けるのだけで精一杯なんですから。

なので、今日の文書レビューでつらいなーと思っているエンジニアや普通の会社員の方は、この方法でお試ししてみてはどうでしょうか。

【その１】レビューは気がつかなかったことを教えてくれる場

 レビューの出席人数が多ければ多いほど、組織としてはコストをかけていることになります。

つまり、大事なレビューであるということです。

＃実際はそうじゃなくて暇…

なので、指摘してくれてありがとうという気持ちで行きましょう。

【その２】自分の手間を忘れる

 よく見かけるのが、手間を惜しまず完成度を高めて期限ギリギリに持ってきてレビューを受けて玉砕するエンジニアです。

間抜けとしか言いようがありません。学習機能はないのでしょうか。

 完成イメージ、レビューをパスするイメージさえ持っていないのに、そんなに手間を掛けてどうするの。レビューで最初からやり直しになったらただのゴミですよ。昭和なら、印刷して持って行った資料がそのままゴミ箱行きですよ。

資料をどう作っても期限までにレビューを通さないといけないのですから、サクッと作って、サクッとパスするのが目指す姿です。

なので手間を掛けないというより、自分　“が”　やった手間を頭の中から無くすことです。

これだけ時間をかけたのに、と思うから指摘されて頭に来るのですから。

実は、この２番目が一番大事です。

【その３】レビューアはレビューが終わったら共犯

レビューアは、レビューが終わって例え条件付きでも合意したら、文書を書いたあなたの共犯です。

さらに上のレビューや他から指摘されたとしても、その前でレビューアだった人たちは共犯なのです。

＃だって合意したのだから。

だからそれ以降の場でコメントし始めたら、

「お前、合意したよな」

とねじ込んで構いません。 

ということでこの3点は、しなければならない系とは違って、心軽やかにレビューにのぞためのハックです。

ご活用ください。

なぜ重大な問題を見逃すのか? 間違いだら けの設計レビュー 改訂版

ソフトウェア品質知識体系ガイド -SQuBOK Guide-(第2版)

「設計力」を支えるデザインレビューの実際

【2017年改良版】ベルギーワッフル作るよ！

ワッフルはときどき食べたくなるよね。ということで、週末の朝はワッフルを作りませう。
材料は、つぎのとおり。作り方の写真は、倍の量で作っていまので。

材料

1.薄力粉　　　　　100g
2.強力粉　　　　　100g
3.たまご　　　　　 1個
4.牛乳　　　　　　 150ml　＃柔らかめがおすすすめ
5.ドライイースト　　5g
6.バター　　　　　 25g　　＃バターはレンチンで溶かしバターにします！
7.ザラメ　　　　　100g　100gだと硬めの歯触りと重めの味に。最初は50gで混ぜて、半分焼いたらザラメを足して2種類作るのもおすすめ。我が家はザラメましましが好み。

ベルギーワッフルのつくり方
薄力粉と強力粉を量ります。牛乳、バター、ドライイーストなども先に量っておきましょう。
※料理を作るときは、作りながら量るのは止めよう。
※右の写真の分量は、倍なので注意〜！！！
　

材料の1.薄力粉から5.ドライイーストまでをボウルに入れて混ぜます。
※シリコーンのヘラで混ぜるのがおすすめ。
※泡立て器の方が楽だけどリングの中に粉の塊が入ってしまい、混ぜ終わったときに取り出すのが飛び散って大変なので。
ひととおり混ぜ合わせたら室温でやわらかくしたバターを投入します。

【2017年改良のポイント！】
バターは溶かしバターにして、最後に混ぜます。

　

少し硬いなと思ったら牛乳(分量外)を足しても大丈夫。
※スポンジを焼くわけではないので、1グラム単位で分量を気にする必要ないので。
バターを混ぜると生地に艶が出てくる。
　

艶が出てきたら、ザラメを投入。

【2017年改良！】

ここで溶かしバターを投入します。最後に溶かしバターを入れて混ぜ合わせると、生地がツルツルとなって、ワッフルメーカの型にくっつかなくなります。これを思いついてやってみてたら、型からの取り外しがめちゃ簡単になって感動しましたよ。

もう何年使っているだろう？10年選手くらい？コストコで買ったワッフルメーカー。
コンセントにプラグを差して温めます。
型に手を近づけて温度を確かめて温まったら生地を投入。
※我が家は小さ目に焼くのが主流。
※大きいと持て余すし、小さいとちょっとおやつにつまむのにちょうどいいから。
　

焼けはじめると右端から水蒸気が。
そして湯気が端端から上がってくる。
部屋中に良い香りが...。
※焼き始めたら家族を起こしてあげよう。
※サプライズにぴったり。
　

ちょっと覗いてみましょう(早すぎると裂けてしまうので、本当は我慢して)。
良い感じですね。
蓋を閉じて、もう少し我慢。

どうです？
美味しそうでしょう？
たくさん作りすぎたら、ジプロックに入れて冷凍して保存しても。
※って考えるとたくさん作りたくなるでしょ？
　

Vitantonio ワッフル＆ホットサンドベーカー [ 焼き型2種付き / ブラック ] VWH-200-K

Vitantonio ワッフル＆ホットサンドベーカー プレミアムセット 《 アイボリー / VWH-32 》[焼き型3種付き]

ビタントニオ ワッフル & ホットサンドベーカー プレミアムセット ピンク VWH-31-P

Vitantonio ワッフル＆ホットサンドベーカー [ 焼き型2種付き / レッド ] VWH-30-R