kakudo.suzuki
はじめにソフトウェア開発・プロダクト開発で見積もりというのは常に議題となるものです。 工数見積もりというテーマだけで一冊の本になるほどある意味で技術を要するものであり連綿と試行錯誤を繰り返されているものです。 そうはいっても、 「自分がやりたいことがどれくらい大変なのか？を知りたい！」 という方はいますし、そのような事情があることもわかります。 ここでは、そんな方にむけたTIPSをすこしご紹介させてください 工数と工期、そしてスケジュールを区別して考えるまず、前提と
はじめにこんにちは 連休中にこちらの記事を拝読させていただきました。 ソフトウェア開発を行う企業の殆どが抱える構造的問題についてとてもわかりやすくまとまっていて、大変参考になりました。 ぜひ読んでみてください。 わたしたちのプロダクトも他のすべてのサービスと同じく、ユーザに受け入れられる価値を生み出していかなければ存続することはできません。 組織の拡大に従い、影響を受ける人や影響与えたい人が多くなるほど、この要求は積みあがるものです。他方、実行に移すためのヒトと時間は
こんにちは さて、本日は議論について。 私たちはしょっちゅう”議論”をしています。 プロダクト開発がお互いに頼り、頼られるチームワークである以上、そして自分たちが全知全能でない限り私たちは議論を避けることはできません。 「俺に従え！」 と議論の余地を許さないパワーを振りかざせるひともいますがよほど強いカリスマ性や実績がなければ興醒めされて誰もついてはきません。 「ダイバーシティでインクルージョンでみんなで議論してONE TEAMでフェアネスに建設的な議論をしましょう」
プロダクトマネジメントは意思決定の連続です。 予測がむずかしくリスクが高いことに向き合いながら、意思決定する上では適切に情報を集め解釈し気づきを得ることが必要です。 私たちは技術の進化によって多種多量なデータを蓄積しアクセスできるようになりましたが、それに圧倒されず活かすことが求められています これは私が情報に向き合い取り扱う上で、気をつけていること、気づきを与えてくれたことをまとめたものです。 誰もが求める「情報」報連相、情報の透明化 「もっと早く言って欲しかった
プロダクトマネジメントの仕事をしているとよくこんな声を聞きます 「私決める人、あなた作る人」から抜け出したい 自分には決定権がない。だれかのアイディアを実行するプロジェクトマネジメントばかりやっている Howを指示されるばかり、問題を解くために何を作るのかは自分たちで決めたい これは大きな組織でたくさんのステークホルダーがいるなかでプロダクト開発を行うチームや自分でよいプロダクトを創りたいという熱意がある人なら誰もがぶつかる壁です 私もこれまでこのように感じたことは
こんにちは、 今日はMVP（Minimum Variable Product)についての内容です。 クイックにリリースしたい 無駄を省きたい 細かいことは走りながら決めたい とみんな言うけれど、実際にはなかなかスコープは分割されずにリスクの大きなプロジェクトになりがちです MVP、PoC、アジャイルだとかそんな言葉はよく飛び交っているのに実際には小さく試すということになりにくい こんな悶々とした声を聞くことも多いのでいくつか思いつく理由をかんがえてみます 理由1:
これはなにグローバルな調査機関The Standish Groupによるソフトウェア開発に関する調査レポートCHAOS Report2022 Editionの要約とその内容の考察をまとめます。 こんなひとにおすすめソフトウェア開発/プロダクト開発のプロジェクトに従事するひと プロジェクトを成功に導き、よりよいプロダクトを生み出したいとおもっているひと CHAOS Reportに興味はあるけれど、長大な英語レポートを読解する暇がない CHAOS Reportとはなにか調
こんにちは さて、今回はよく耳にする「協働」について縷々書き留めたいと思います。 これは、私の雑多の思考を整理し、文章力と表現力を培うための鍛錬でもあります 先には組織で協働を育むためになにかアクションにつなげたいと思っていますが、現状の乱筆は何卒ご容赦ください。 協働されていない状態とはなにか「協働」、「一致団結」、「One Team」・・ こういった否定の入り込む余地のない大きく美しい言葉は、結局曖昧なものになって何も言っていないのと同じ状態になりがち こういう時は
こんにちは 前回の記事 に引き続き、後編として11章〜15章までを簡単なサマリと私自身の考察も踏まえて共有させていただきます。 第11章 「データ、舵を取れ！」要約価値を証明するな価値を創れ ユーザーに対して価値を作るという動機ではなく、ユーザに対して理論的に価値を提供できることを同僚に証明する目的で実験が行われている場合、実験はうまくいかずインパクトを生み出しにくいものになる。 成功した実験の背景にある動機は、「小さなものをリリースし、ユーザの価値になっているかど
こんにちは 前回の記事 に引き続き、こちらの書籍の6章〜10章までを簡単なサマリと私自身の考察も踏まえて共有させていただきます。 第6章 ユーザーに話しかける（あるいは「ポーカーって何？」）要約必読のポイントと考察ユーザーにあなたの仕事を依頼してはいけない OXOのリサーチャーが「計量カップに求めることは何ですか？」と顧客に質問すると、一見筋のよさそうな特徴がスラスラとリストアップされた。 一方で実際に計量カップをつかってもらうようにお願いすると、みな一貫して目盛り
こんにちは。 本日はこちらの一冊をご紹介させてください。 最近読んだプロダクトマネジメント関連の書籍では一番のお気にいりです。 よくあるフレームワークやベストプラクティス集ということではなく、まさに組織のプロダクトマネジメントで直面する「厄介な」現実を表現しつつ、それに奔走するプロダクトマネージャを鼓舞するような内容で、みなさまにも強くおすすめしたい一冊です。 ここでは、全16章からなる本誌のうち、前編1章〜5章までの簡単なサマリと私自身の考察も踏まえて共有させていただき
こんにちは 本日は最近読んだ書籍の中から、みなさまにおすすめしたい一冊 「人が増えても速くならない 〜変化を抱擁せよ〜/倉貫義人」 について一部要約しご紹介したいと思い ます。 この書籍で語られている内容は、私がこの業界に従事した当初、いえそれ以前から何度となく言及されつづけていた課題について、非常にわかりやすく言語化されています ビジネス・テックいずれの職種を問わず、プロダクト開発のプランニングに関わる方には是非おすすめしたい内容です もし、この記事で興味を持た
一般的に大規模で不確実性が高い場合にプロジェクトは難易度をますものです これはなぜか。これをうまく制御するにはどうすれば良いのか、分解して考察をしてみます 大きな組織に働く慣性を知る大きな組織やプロジェクトには、慣性がはたらくものです。 みんなも覚えているでしょう 「車は急にとまれない」 これと同じように大きな組織は急にとまれない。進路変更でさえも慎重さと規律が求められます。 一方で物事の不確実性が高い状態では、変更が頻繁に起こります。変更に機敏に柔軟に対応できない
はじめにあらゆる業務や組織の中で、仲間と仕事をする際にはなんらかの「仕組み」と呼ばれるものが存在しています。 それは、制度、プロセス、ガイドライン、ルール、メソッドなどと呼ばれたりします。 また、私たちが向き合っている「プロダクト」や「サービス」も顧客の課題を解決しながら、価値を創出する仕組みだといえます。 これらは常に新しいものが生まれ、改変され、さらにそれは設計者の意図を超えて変質したり忘れ去られたりするものです。 組織、集団がなんらかの問題に直面したときや、環境や
はじめにあなたの目標はなんですか、そのために今日何をしますか 組織戦略レベルからチームの日々のタスク、ひいては個人のToDoまで 時間、リソース、資金などに限りがある以上、すべてにおいて優先順位付けが必要です なにをして、なにをやらないか この判断を素早く妥当に行うことが命運を分けます あんなこといいな こんなこといいな 夢を叶えてくれる猫型ロボットはまだいない I am NOT User 私たちはユーザーではないのだから 「なにをしたい」より先の世界を目指しましょう
サイロをつくるニンゲン サイロ化を防ごう これはあらゆる組織において、何年も前から警鐘が鳴らされ続けていたことです。 セクショナリズムが蔓延し、情報連携が滞り、硬直していて柔軟性がない組織 誰しもが大企業病と言って嫌い、さまざまなプロセスやツールがこの課題に立ち向かってきました。 「情報の流れを見える化して、組織間のコラボレーションを促進して、サイロ化を防ぐ・・・」 というような常套句は何年も前から、コンサルタントやITベンターが繰り返し使い続けています。 では、
