はてなブックマーク

以前「プロダクト企画にエンジニアを早めに巻き込む（嫌がられずに協力を得る方法）」という記事を書きました。 ykmc09.hateblo.jp 「TL;DR : ひとことでいうと」を抜粋すると以下のような感じです。 決定事項になる前に早めに巻き込もう 巻き込むときは、 その意図や相手に期待することを伝えよう 特性を理解して、ちょっとした工夫（最初の一声はチャットなどの非同期コミュニケーションを使う、etc）をしよう この記事では、「はやめに巻き込もう」ということを中心に書きましたが、最低限こういったことを考えて書いておくと、話がよりスムーズになるよ、というものを挙げてみようと思います。 プロダクトマネージャーが用意するリスト 目的の概要（なぜそれをやる？）※もっともだいじ。これが無いとかなりキツイ。 誰のための企画？（基本はエンドユーザーになる。） その人のどういう課題を解決したい？ その課

TL;DR : ひとことでいうと 決定事項になる前に早めに巻き込もう 巻き込むときは、 その意図や相手に期待することを伝えよう 特性を理解して、ちょっとした工夫（最初の一声はチャットなどの非同期コミュニケーションを使う、etc）をしよう たまに遭遇するシーン ソフトウェアプロダクトの企画（プロダクトデザイン、プロダクト設計）を行う人や組織が、 企画の要件や仕様をかっちりと固めてから、エンジニアに渡したほうがいい 、と思っているシーンを見聞きすることがあります。 「重厚なウォーターフォールプロセスを採用しているから」という場合もあると思いますが、 軽量なプロセス下にある Web サービス企業でも、企画と開発で役割分担をしている場合は（程度の大小はあれど）起こってしまう と思っていて、今回はそういったケースを想定しています。 特に、以下のような思いがあるからそうしている、というケースを話題に上

DevLOVE X で 「嫌われない」を諦めない というタイトルで登壇してきました。 伝えたかったこと 伝えたかったことの中で、今回メインに据えたのは ものごとを推し進めるために、「嫌われる要素」を取り除く努力もしよう ということでした。 このテーマの動機（個人的な部分をメインに） 「嫌われるのを怖がる」という弱み 僕は「嫌われるのを怖がる」タイプです。 「全員に好かれるなんて無理なんだから、嫌われちゃってもいいじゃん」という励ましを受けるやつです。HSP (Highly Sensitive Person) の数値も高めの人間です。 なので、「相手を伺いながら、大きな衝突が起きないように進める」というアプローチを取りがちで、「嫌われることをいとわずに物事を大きく進める」というのはかなり意識しないとできません。克服しようと努めている弱みのひとつです。 前職でメンターをしていただいていた方に「

2019年7月8日(月) に、Agile Leadership Summit 2019 というイベントを開催します。 「基調講演 + Open Space Technology*1」という構成で、企業内でアジャイルを推進、実践している方を対象したイベントになります。 基調講演は、日本紛争予防センター（JCCP）理事長の瀬谷ルミ子さんという方で、世界の紛争地の復興、治安改善、兵士の武装解除・動員解除・社会復帰（DDR）を行われている方です。 www.jccp.gr.jp 「武装解除・動員解除・社会復帰（DDR）」。 究極のコンフリクト・マネジメントですね。 アジャイル導入・推進や、もちろんプロダクトを作る過程においても、さまざまな利害関係者のコンフリクトを解消することが大きな仕事の一つになっていると思います。 今日、瀬谷さんご本人と打ち合わせを、アギレルゴコンサルティングの川口さんとしてきた

明確なスクラムマスターがいないチームで PO 兼エンジニアリングマネージャーとして働いてたときに、割と惰性のふりかえり（週次）をしてしまっていた頃があって（チームメンバーが優秀だったのでふりかえりの効果はあったけど、もっとうまくやれたよなーっと）、その頃を反省してました。過去の自分へのメッセージ。 いろんなところで見たわけじゃないけど、他でも聞いたりみたりするものもあるので、アンチパターン的なものであったりするかもしれない。 いつも大人数（7人以上）でやる 関与度、参加者の自己効力感減る。発言にムラもでる。同じ時間に集まるけど、グループ分けて議論→グループ間同期とかできるかな。 あげられた問題点をムリに全部議論しようとする 結局広く浅い議論になる。ざっとみて投票するなり、「コスト×効果」のマトリクスにざっくりまずプロットしてみるなり。深く時間かけてひとつだけ話す、でもいいじゃん。模造紙に出