Tag
プロダクト開発の営みを「ディスカバリー」と「デリバリー」の２つのサイクルに大きく分けたときに、「最近はディスカバリーがボトルネックだ」という声をよく聞く。 AIの力を使って、エンジニアリングの設計や実装、テスト、デプロイ（＝デリバリー）のスピードは格段に速くなった。結果として、その前工程である「なぜ」「何を作るべきか」のところ（＝ディスカバリー）にボトルネックが移動した形。 自分が今いるプロダクト開発チームも、同様にボトルネックが「ディスカバリー」に移ったようにぱっと見は見える。 でも、本当にそうなのか。 「開発コストはほぼゼロになった」「だからプロダクト開発のやり方は根本的に変わる」という声
たまたま見かけた、以下の DACI に関する記事を眺めていて、これまでの人生で何度か見てきた「チームの意思決定が進まない」光景を思い出した。 DACI：意思決定フレームワーク | Atlassian Team Playbookこの DACI テンプレートを使用して、チームの各メンバーに役割と責任を割り当て、意思決定をより効率的かつ効果的に行ってください。AtlassianAtlassian 経験上、チームの意思決定がなかなか進まない時には、以下のようなことが起きていることが多かった。 * 「チームワークを高めること＝合議制で進めること＝必ず良いこと」として扱ってしまう * リスクを重く捉えすぎ
今日、自分と@kantarockさんの二人でやっているポッドキャスト番組「人見知りプロダクト開発ラジオ」の第47回目の配信を収録した。 収録後にあらためて配信を聞き返してみて、これは大事な話だったなと思った。せっかくなので、自分のブログにもこの考えを言葉として残しておこうと思う。 素早く、リスクをとった意思決定には強い意志が必要 今回の配信のテーマは、プロダクト開発において迅速な意思決定に必要になる「強い意志の持ち方」について。 プロダクト開発では意思決定をする場面が多い。なぜ、誰のために、何を作るのか。逆に何を作らないか。そうした意思決定を、どうすれば素早くできるか。リスクを取ることを恐れず
仕事の割り振りで抜け落ちがちな観点 チームで仕事を進めるとき、誰に何を任せるかを考える場面がある。そのとき、つい「誰の手が空いているか」「負荷が偏っていないか」から考えてしまう。負荷分散は大事だし、特定の人に仕事が集中しすぎるのは避けたい。 ただ、負荷分散を優先するあまり、もう一つの大事な観点が抜け落ちることがある（特に自分の場合）。それは「その仕事に一番詳しいのは誰か」ということ。 自分にも覚えがある。ある仕事について、自分が一番知見を持っていたのに、負荷分散を意識しすぎて（自分がタスクをブラックホールのように抱え込んでしまう性質もあって）自分がやるという選択肢を外してしまったことがあった。
スタートアップにおけるプロダクト開発には、不確実性がつきもの。市場環境、プロダクト戦略、技術選定、採用、などなど。正解がわからない中で仮説を立て、意思決定を重ねていくことを日常的に行っていく。 一方で、コントロールできることもある。ロードマップの策定、目標の設定、意思決定の場の設計や、決まったことの透明化。いわゆる「プロダクトオペレーション」と呼ばれる領域で、不確実性が低く、自分たちの意志があれば確実にやれることではある。 最近、高い不確実性に挑むためには、後者を確実にやることの重要性に改めて気づいた。 きっかけ 先日、チームの目標を決めるプロセスの中で、コントロールできることを徹底できていな
仕事をしていると、「a or b」を選択する場面に直面することが多い。 * スピードを取るか、品質を取るか * 全体を見るか、個人に向き合うか * 責任を果たすか、やりたいことをやるか * など どちらかを選ぶと、何かを失う（＝トレードオフが発生する）ことも多い。こういう場面で、自分は「a or b」ではなく「a and b」を選択できないか、つまり両方を取れる方法がないか模索するように心がけている。 きっかけ 心がけるようになったきっかけがいくつかある。 一つは、pmconf 2019 に参加したときに、LINE二木さんの「LINEにおけるお金とユーザーのジレンマ」というセッションを聞いたと
「全部解決したい」という衝動 先日、開発チームの体制変更と開発プロセスのアップデートを行った。複数のチームがより同時並列で動ける状態を目指した変更だった。 その後の振り返りの場で、変更に伴うトレードオフについて、一緒に働く人たちからいろいろなフィードバックをいただいた。どれも共感できて納得感のあるフィードバック。 僕はこういう場でフィードバックをもらうと、全部なんとかしたいと思ってしまう。出てきた課題を全部解決したい。一つひとつに手を打ちたい。いただいたフィードバックになんとか応えたい。それが自分の性質だと思う。 でも、出てきた課題をすべて解決しようとすることが、本当に正しいアプローチなのか。
凡事徹底ができているからこそ、次の高い段階に進めることがある。基本をしっかりやる。当たり前のことを当たり前にやり続ける。それができて、その先にある大きな成果やアウトカムに手が届く。 頭ではそう理解しているけど、凡事徹底は大変。めんどくさい。継続するのが難しい。だから、つい楽をしたくなる。もっと短時間でいいものを作りたい。すぐにアウトカムに近いところに飛びたくなる。 これは自分の弱みでもあるし、他の人もそういう気持ちになったことはあるんじゃないだろうか。 凡事徹底とその難しさ ここでいう凡事徹底とは、例えばこういうもの。 * ミーティングの成果は、始まる前の準備で決まっているでも書いた、ミーティ
最近は仕事中のほとんど全ての時間をアーキテクチャを設計したり、コードを書くことに使わせてもらってます。すごく楽しいです。 そんな中、自分自身も含めたエンジニア組織のあり方について、個人的に考える機会があったので、備忘録的にメモ。 組織ではく、サービス・プロダクトが作りたい まず最初に頭に浮かぶのは、ユーザーの課題を解決し、価値を届け続けられる素晴らしい「サービス」と、それを支える「プロダクト」を作りたいということ。それを追い求める過程で、ひとりひとりが行動を積み重ね、その結果として必要な「組織」が自然と生まれていることが自分の理想。 「どんな組織を作りたいか」ではなく「どんな組織でありたいか」
最近、仕事で自分の周りにやれることが無限にあって、とても嬉しい状態になっている。自分が貢献できることと、それによって生み出せるポジティブな影響の両方がたくさんあるように思えてる。 ものすごく自由度が高く、やり込み要素も豊富なゲームの世界に突然放り込まれたような感覚。「あれも楽しそう」「これもやりがいがありそう」と、どれから遊んでみようかワクワクしながら考えている時のあの感じに似ている。 そういう楽しい状況なのだけれど、見方を変えれば難しい状況でもある。何から始めようか必要以上に考えすぎてしまって、動き出しが遅くなってはいけないと思う。また、いろんなことに手を出しすぎてしまって、物事が全部中途半
仕事では「自分が今見えているものが全てじゃない。知らないことや、気付いてないこと、理解できてないことが必ずあるはずだ」って強く意識するようにしている。自分はそれが不確実性の高いスタートアップで働く上ですごく重要なことだと考えているから。 たまに、すべてが見えているように自信を持っている（or そのように振る舞ってるように見える）人と接すると、自分と真逆だーって自分の癖とか性格によく気付かされる。 物事は、人が知る由もない理由によって成功・失敗したりする。自分で「成功したのはこれが要因だ」「失敗したのはこれが原因だ」とわかったつもりになっていても、実はそうじゃないことがある。 → 自分が観測でき
最近、チームや個人の成長について考える機会があった。自分自身の成長についても、もっと加速させたいという気持ちがあり、改めて大事だと思うことを書いておく。 昔、「チームが機能するとはどういうことか」という書籍を読んだ時に、以下のようなことが印象に残った。 * チームが目標を達成するためには、日々の活動やその結果から学習し、成長し続ける必要がある * 毎日、毎週、毎月、自分やチームの活動を振り返り、「何か学べたことはないか」「もっとうまくやる方法はないか」の2点について考えて、次のサイクルをより良いものにするサイクルを絶えず繰り返すことで、それが成長につながる * 個人の学びや成長がチームの成長の
2023年ももうすぐ終わりなので、この1年間を思い出しながら振り返ってみる。 振り返ってみると、ずっと頭の中が整理できないまま、散らかった状態で走り続けた一年間だった。でも、いろんな人たちの支えがあって、なんとか走り抜けられることができた。来年は今年の経験を活かして大きな挑戦もできそうなので、結果的にはよい一年を過ごすことができたと思う。 WE UP でスタートアップの CTO として一年を過ごした。プロダクトをリリースしたり、ピボットをするためにプロダクトをクローズしたり、受託開発をしたり、新しい事業やプロダクトの方向性の議論をたくさんしたり、プロトタイプやMVPを開発したり、本当にいろんな
会社でたてた事業、プロダクトの壮大な目標を達成するために必要なことについて、最近気づいたことを自戒もこめて書いてみる。 なにか目標をたてるときは、まず長い時間をかけて最終的に達成したい大きな目標をたてたあと、それを実現するために必要な、より細かい目標（マイルストン）を分割して立てることが多い。 そうやって、目標設定をやっていくと以下のような目標の階段（ステップ）ができあがる。 * 1週間の目標 * 今月の目標 * 3ヶ月後の目標 * 1年後の目標 * 3年後の目標 * 5年後の目標 まずは目の前にある目標を達成するために様々な取り組みをおこなう。その中で、常に変化する理想と現状、それらの差分を
めでたいニュースを自分自身に結びつけて考えると勇気づけられた話と、そこから得た気付きについて。 昨年末あたりから、僕は「歴史を面白く学ぶコテンラジオ（COTEN RADIO）」を熱心に聞き始め、たくさん学ばせてもらっています。そのコテンラジオが、日本最大級のクリエイティブアワード「2022 62nd ACC TOKYO CREATIVITY AWARDS」において、ブランデッド・コミュニケーション部門 B カテゴリーの総務大臣賞/ACC グランプリを受賞したとのニュースが流れてきた。 「歴史を面白く学ぶコテンラジオ（COTEN RADIO）」が ACC TOKYO CREATIVITY AWA
個人の頑張りだけじゃなくて、それを支える・促す環境を先に整えておくことが大事だという話。 昨日、4 年ほど前に自分が書いた以下のブログ記事をたまたま目にしました。自分で書いたものなのですが、読んでいてなんだかすごく勇気づけられました。 Issue のゴールを 20%くらいは超えていく 書いていることは、「目の前の Issue （課題）を解くときに、ゴール（完了条件）が 100%だとして、それを超える 120%くらいのアウトプットを常々出せるように心がけてくといいよ。着実に自分自身を成長させることができるよ。」という内容でした。 勇気づけられると同時に、この記事を書いてから 4 年経った現在、自
最近仕事をしてて大事だとと思ったのでメモ。 プロダクトの不具合、見つかるときは立て続けにどんどんたくさん見つかります。 不具合が見つかるきっかけは色々です。自分たちでプロダクトのドッグフーディングをしていて見つかったり、お客様からのフィードバックで見つかったり。 特にお客様からのフィードバックで見つかった不具合は、なんとかなるべく早く修正したくなるものです。問題のインパクトや影響の大きさにもよりますが、暫定対応はなるべく早く行い、事象の解消をしたあとで、落ち着いて恒久対応や Postmortem に取り組みたいもの。それはそれで大事です。 でも、不具合の件数が少ないならまだしも、何件も連続して
PLAID Advent Calendar 2019 の 19 日目の記事です。 こんにちは。kadoppe です。株式会社プレイドで Software Engineer をしています。 今日は、ぼくが、ぼく個人のパフォーマンス（生産性）をあげるためにやっているいくつかの工夫の中から、掲題の件に関するトピックについてピックアップして紹介してみようと思います。 では、はじめます。 結論 背景が長いので出オチになります。 記事タイトルにもある 「爆速で頭の中のアイデアを文章化する」 ために、ぼくが何をしたかというと、「めぐりズム 蒸気でホットアイマスク」（以降、ホットアイマスク）を装着してをつけ、
自分の年齢は自分で決めればいいという考え方。 ハーバード・ビジネス・レビュー 2019 年 8 月号の特集インタビュー「宇宙への夢を語ることで科学技術は進歩する — 宇宙飛行士 向井千秋」を読んで、グサっと刺さる勇気が出る言葉が書いてあったので、忘れないように書いておく。こういうインタービューが好きです。 DIAMOND ハーバード・ビジネス・レビュー 2019 年 8 月号 [雑誌] (MOONSHOT(ムーンショット) 大いなる挑戦が人を動かす) 宇宙飛行の最年長記録（77 歳）をもつジョン・グレンさんがよく “calendar year” という言葉を使っていたらしい。言葉の意図としては
北海道の東川町に出張する機会があり、現地の図書館で販売されていたので購入。 東川スタイル-人口 8000 人のまちが共創する未来の価値基準 人口減少時代に人口が増加傾向にある「東川町」という地域のなかで、住民のみなさんが大切にしているものや価値観を、生活や仕事の中で実際に体現されている様子について紹介している本。 仕事（ビジネス）をスケールさせるのではなく、価値観を維持し、磨き上げていくことを大切にする、現地の人の生き方・考え方に触れることができる。昔から東川町に住んでいた人も、途中から移住してきた人も関係なく、自分たちの価値観を体現することに価値をおく様々な人々の集大成が、東川町の「東川らし
NewsPicks の特集記事。 『kadoppe は「プロジェクトやプロダクトの価値を最大化させる」ための経験や知識を増やした方がいいよね』というアドバイスを、以前とある人にもらった。 その会話の中で「濱口秀司さん」というキーワードが出てきたので、少し探して目についたこの記事を読んでみることにした。 濱口秀司のつくり方 記事の内容は置いといて、読んで得られた気づきや学びをメモ。「プロジェクトやプロダクトの価値を最大化させるか」という観点で得られた気づきは主に以下の２点。 * スコープの縮小にあらがうこと * 全員が難しい問題に取り組んでいる状況を作ること スコープの縮小にあらがうこと 最初は
ゴールを勝手に 20％くらいは高く見積もった上で Issue に取り組むといいよ、という話。 みんなは当たり前にやっていることかもしれないけど、最近、意識して取り組んでいるのでメモ。できないときもありますが。 今の職場では GitHub の Issue 上で様々なタスクやそれにまつわるコミュニケーションを行なっている。自分をアサインした（あるいは誰かにアサインされた） Issue に取り組み、アウトプットを出して、最終的に Close することが、日々の基本的には仕事の流れになる。 日々の取り組んでいる Issue には達成したいゴールが設定されている。どうすればこの Issue が Clos
フィクションです。 チームで一緒に働いている「とある人」から「自分はチームのみんなにあまり信頼されてない感がある」という旨の発言があった。 どうして信頼されていないと感じるのか。「とある人」の行動にもいくらかは原因はあると思う。でも、普段の些細なコミュニケーションの中でそう感じさせてしまったのなら、それは周りの人間にも責任はあるんじゃないかと思った。 そんな中、昔読んだ「Team Geak」 という本のことを思い出した。 この本には、こんなことが書いてある。 あらゆる人間関係の衝突は、謙虚・尊敬・信頼の欠如によるものだ 謙虚（Humility）、尊敬（Respect）、信頼（Trust）の頭文
忘れないように、もう一度整理してみる。 書籍「リーン開発の本質」では、チームが行うすべて活動の中で、顧客に価値を届けることに貢献していないものすべてを「ムダ」として定義し、それらを以下の７つに分類している。 * 未完成な作業のムダ 99%完成していたとしても、それは意味を成さないし、放置することでさらなるムダを生み出す。 * 余分な機能のムダ 今必要とされていない機能を作っても、何の価値も生み出さないし、システムは複雑になる。 * 再学習のムダ 経験を伝えなければ、誰かがすでに踏んでいる地雷を、同じ人が二度踏む。 * 引き継ぎのムダ 情報が 100%欠落しない引き継ぎは存在しない。せっかくの知