• GIZMODO
  • DIGIDAY
  • gene
  • cafeglobe
  • MYLOHAS
  • Glitty
  • machi-ya
  • roomie
  • GIZMODO
  • DIGIDAY
  • gene
  • cafeglobe
  • MYLOHAS
  • Glitty
  • machi-ya
  • roomie

堀込泰三堀込泰三  - ,,  11:30 AM

リソースが足りない時にプロダクトマネージャーとして身に付けておきたい10の心構え

リソースが足りない時にプロダクトマネージャーとして身に付けておきたい10の心構え

130620ProductManagement1.jpg


あなたは、スタートアップまたは大きい組織の商品開発チームの一員です。すべてが緊急で、すぐに終わらせなければならないことばかり。リソースは足りないが、何とか帳尻を合わせなければ。不安が襲う。モチベーションは、悲観や皮肉に姿を変える。すべてが悪くなり始める。かつてないほどに悪く。

そんな経験はもうこりごり。そんなあなたのために、リソースがまったく足りない状況で、迫りくる困難をどうやって乗り越えていけばいいか、私が経験から学んだ10の教訓をお伝えします。



1. パニックにならない

言うは易しですが、パニックにならないことが何よりも大事。冷静でいなければならないときにイライラするのは、もっとも避けなければなりません。事態は、思ったよりも悪くないはず。そう、決して。

だから、お茶を飲みましょう。散歩に行きましょう。同僚と話しましょう。心をすっきりさせましょう。すっきりした心は、大切な資産です


130620ProductManagement2.jpg


2. 制約を受け入れる

誰もが、リソース不足に苦しんでいます。もう一度言います。誰もが。いつだって。素晴らしいアイデアを出すだけならお金はいりませんが、リソースはそういうわけにはいきません。

誰もがリソース不足なのですから、私はむしろ、その事実を受け入れて巧みに利用することを心がけています。


「アイデアを書き留めなければ、明日にはなくなってしまうだろう」という会社は、今までに聞いたこともない。

── Stephan Schimidt


制約は、想像力を育みます。制約があるからこそ、これまでの枠からはみ出して考えられるようになります。そうすれば、今までに考えたこともなかったようなことに気付くでしょう。陳腐な言い方をすれば、「必要は発明の母」なのです。制約は、素直に受け入れましょう


3. 進行中の作業に集中せよ

あなたの担当する商品に20の変更を同時に行ったらどうなるか、考えたことがありますか? ユーザーエンゲージメントは? 市場でのポジショニングは? コードのアーキテクチャは? ユーザーインターフェースは? 想定していた順序で変更が進まなかった場合はどうする?

どんなに優秀なメンバーがそろっていても、これを明確に把握することは難しいでしょう。むやみに手を広げることで、すでに困難な仕事をさらに困難にしてはならないのです。

マルチタスクは幻想です。特に、エンジニアリング、ユーザーエクスペリエンス、マーケティング、ポジショニングなどのクリエイティブな仕事においてはなおさらです。

進行中の作業に集中することで、商品の出荷を早めることができるばかりか、チームが最高の力を発揮できます。少ないことはいいことなのです。

文脈の切り替えを減らすことで、大事なことへの理解を深め、依存を軽減し、調整ごとが減り、不具合が減り、悪い判断が減るのです。

シンプルであること、集中すること、そして仕事の質を高めることが、あなたが同時にやろうとする作業の数と密接に関係しているのです。


4. 優先順位をつける

願ってもないチャンスのように思えるアイデアでも、必ずしも実行に移す価値があるわけではありません。アイデアにお金はかからないのです。素晴らしいアイデアはたくさんあるけれど、試している時間はあまりない。そんな時には、正しい物を正しい順序でやる必要があります。


やると決めたことをうまくやるには、あまり重要でない機会を切り捨てなければならない。

── Mike Markkula(Appleのマーケティング&エンジェル投資家)


これこそ、価値を高める手段です。全関係者を集めて、変更を遅らせることによるコストを算出しましょう。

例えば、ブラックフライデーまでに請求システムを統合しなければならないなど、明確な期日が決まっている場合、今やるか来週やるかは問題ではなく、期日を過ぎると一気に遅延のコストが急増します。

Ruby on Railsをヴァージョンアップするなど、その他のシナリオでは、もう少し曖昧になります。来月までにやらなくても倒産することはありませんが、あまり先延ばしにすると、いずれ高いツケが回ってきます。

とは言え、状況を100%理解して完ぺきな決断を下す必要はありません。考える時間を取ることが必要なのです。時計とにらめっこをしながらチェスをするようなものです。

遅延によるコストには、下図のようにいろいろなシナリオがあります。


130620ProductManagement3.jpg


5. いつでもドーナツを忘れずに

もしあなたがイライラしてきたら、チームや関係者など、ほかの人たちはもっとイライラしているかもしれません。プロダクトマネージャーであるあなたは、エンジニアリング、マーケティング、ユーザーエクスペリエンス、セールスなど、たくさんの部門の交差点にいるのです。

あなたはすべての部門に首を突っ込んでおきながら、いずれの専門家でもありません。あなたの責任は、総指揮を執ること。ある意味、誰も担当しておらず、誰も言葉にできないようなことをやるのがあなたの仕事なのです。


「人々をあるがままに扱えば、才能を台無しにしてしまう。人々をあるべき姿で扱えば、なれる人への成長を促すことができる」

── ヨハン・ヴォルフガング・フォン・ゲーテ


積極的かつ楽天的になりましょう。誰もが協力して素晴らしいことをやり遂げられるような雰囲気を作るのです。プロダクトマネージャーであるあなたは、人から頼まれなくても今やるべきことをやるという、特別なポジションにいるのですから。

謙虚であることや親身になることも大事です。もうひと頑張りするために、ドーナツを差し入れするのもいいでしょう。


130620ProductManagement4.jpg


6. 早期出荷で情報を買う

出荷までの期間を短縮できるなら、それに勝ることはありません。意図的に範囲を狭める、技術的負債を認める、機能をいくつかの部分に分けて個別に出荷するなどの方法が考えられます。

これは強力な考え方です。早期出荷によって、情報を買うことができるのです。

情報を買う別の手段としては、試作品や紙のモックアップを作る、基本的なUIコンセプトを試してみるなどの方法もあります。

副次的な効果として、機能の複雑性に対して、いいように考えられるようになります。出荷を早めることで、現在取り組んでいる内容について、劇的にリスクを下げることができるのです。


7. ゆっくり、確実に

急いては事をし損じます。特に、すべてを早く終わらせなければならないような状況では、急がずにしっかり時間を取る必要があります。いろいろな立場に立って考えてみましょう。ユーザーストーリーを書いてみましょう。readmeを書いてみましょう。ウサギではなく、カメのように働くのです


130620ProductManagement5.jpg


8. 手の届きやすい果実を

どんな商品にも、ちょっとした変更で大きな影響を与えられるものがあるはずです。多くの場合、それはあなたのマスタープランには書かれていないことであり、今後の予定にも入っておらず、関係者の誰一人として要求したこともないようなことでしょう。

手の届きやすい果実を見つけることは、RPGで宝箱に遭遇することに似ています。少ない努力で、即席の報酬を。手の届きやすい果実を収穫する文化を築きましょう。少ない努力で済むことなら、立ち止まって、その価値を切り開くのです。価値を高めることがあなたの仕事。過去の計画を遵守することではないのです。果実の育つ森を見逃さないようにしてください。


130620ProductManagement6.jpg


9. 技術的負債が価値に見合うなら投資を

ソフトウェアプロジェクトには、技術的負債が付き物です。それは、時間とともに累積していきます。開発期間が重要な状況ではその傾向が高まります。

技術的負債は、本来悪いものではありません。ツールであり、トレードオフなのです。とは言え、時が経つと、不具合対応に時間がかかるようになります。時には、新機能の開発よりも時間がかかる場合も。そんな時は、一歩戻ってみるチャンスなのかもしれません。

技術的負債が高い価値に見合うような領域を見つけてみましょう。大胆になるのです。時間をかけて、そのような部分を改善します。そうすれば、あなたの商品でいちばん大事な領域で、素早く動けるようになっているでしょう。

使用頻度の高い部分における技術的負債は、あっという間に膨れ上がります。サポートリクエスト件数、感性品質、本質的価値を提供する能力に影響を及ぼすでしょう。

「リーン&アジャイル」であることは、あなたのコードベースでの作業が窮地に陥っているような状況では、あまり役に立たないのです。


130620ProductManagement7.jpg


とは言え、たいていの場合、あらゆる部分における技術的負債はあっという間に収穫逓減をもたらし、機会費用の増大を招きます。技術的負債と金銭的負債は、性質が異なるのです。

誰も利用しないような部分では、技術的負債があっても大丈夫です。返済の必要もありませんし、時とともに大きくなることもないでしょう。少し待てば、技術的負債の多い部分を廃止したり、サードパーティのライブラリで置き換えられたりする場合もあります。

あなたのコードベースにおいて、技術的負債が価値に見合う領域を見つけ、状況改善につながる方法を考えてみましょう。


10. 「なぜ」を定義する

毎日同じことをやっていると、本来の目的を忘れてしまいがちです。でも、優れたソリューションの本質は、なぜそれが必要なのかを深く理解することにあります。エンジニアリング、マーケティング、ユーザーエクスペリエンスデザイン、営業などの業務内容にかかわらず、山を動かせるのは、目的を持った人なのです。

プロダクトマネージャーであるあなたの主な仕事は、背景を理解し、目的を定義し、それを皆に周知させること。皆とは、あなた自身、お客様、チームのメンバー、関係者全員、他のチームのことです。

コミュニケーションにやりすぎはありません。だから、ドーナツを忘れずに!


10 Product Management Hacks for Times when you're strapped for Resources | Medium

Thomas Schranz(訳:堀込泰三)
Photos by greggman, Karl Scotland, Max Braun, Herkie, toholio.

MORE FROM LIFEHACKER

powered by

Kotaku

© mediagene Inc.