Author
プロダクト開発の営みを「ディスカバリー」と「デリバリー」の２つのサイクルに大きく分けたときに、「最近はディスカバリーがボトルネックだ」という声をよく聞く。 AIの力を使って、エンジニアリングの設計や実装、テスト、デプロイ（＝デリバリー）のスピードは格段に速くなった。結果として、その前工程である「なぜ」「何を作るべきか」のところ（＝ディスカバリー）にボトルネックが移動した形。 自分が今いるプロダクト開発チームも、同様にボトルネックが「ディスカバリー」に移ったようにぱっと見は見える。 でも、本当にそうなのか。 「開発コストはほぼゼロになった」「だからプロダクト開発のやり方は根本的に変わる」という声
2026年3月16日に開催される「EMが「推し本」を語る会 ーEMConf JP 2026 非公式サブイベント」のLT登壇枠（5分）で話す機会があるので、まだ前日だけど、自分にとっての「推し本」について、このブログでも紹介してみる。 EMが「推し本」を語る会 ーEMConf JP 2026 非公式サブイベント (2026/03/16 19:00〜)## 📚 EMが「推し本」を語る会 - EMConf JP 2026 非公式サブイベント ### 「推し本」を持ち寄って、EMに関する悩みや葛藤、実践知・学びなどをしっぽりと語り合いましょう！ EMConf JP 2026の熱量そのままに、さらに深
たまたま見かけた、以下の DACI に関する記事を眺めていて、これまでの人生で何度か見てきた「チームの意思決定が進まない」光景を思い出した。 DACI：意思決定フレームワーク | Atlassian Team Playbookこの DACI テンプレートを使用して、チームの各メンバーに役割と責任を割り当て、意思決定をより効率的かつ効果的に行ってください。AtlassianAtlassian 経験上、チームの意思決定がなかなか進まない時には、以下のようなことが起きていることが多かった。 * 「チームワークを高めること＝合議制で進めること＝必ず良いこと」として扱ってしまう * リスクを重く捉えすぎ
今日、自分と@kantarockさんの二人でやっているポッドキャスト番組「人見知りプロダクト開発ラジオ」の第47回目の配信を収録した。 収録後にあらためて配信を聞き返してみて、これは大事な話だったなと思った。せっかくなので、自分のブログにもこの考えを言葉として残しておこうと思う。 素早く、リスクをとった意思決定には強い意志が必要 今回の配信のテーマは、プロダクト開発において迅速な意思決定に必要になる「強い意志の持ち方」について。 プロダクト開発では意思決定をする場面が多い。なぜ、誰のために、何を作るのか。逆に何を作らないか。そうした意思決定を、どうすれば素早くできるか。リスクを取ることを恐れず
仕事の割り振りで抜け落ちがちな観点 チームで仕事を進めるとき、誰に何を任せるかを考える場面がある。そのとき、つい「誰の手が空いているか」「負荷が偏っていないか」から考えてしまう。負荷分散は大事だし、特定の人に仕事が集中しすぎるのは避けたい。 ただ、負荷分散を優先するあまり、もう一つの大事な観点が抜け落ちることがある（特に自分の場合）。それは「その仕事に一番詳しいのは誰か」ということ。 自分にも覚えがある。ある仕事について、自分が一番知見を持っていたのに、負荷分散を意識しすぎて（自分がタスクをブラックホールのように抱え込んでしまう性質もあって）自分がやるという選択肢を外してしまったことがあった。
3/4に開催されるEMConf JP 2026のプレイベント、「【EMConf JP 2026サブイベント】Warm-up Party by EMゆるミートアップ」に参加。 【EMConf JP 2026サブイベント】Warm-up Party by EMゆるミートアップ (2026/02/17 19:00〜)# ステートメント 「EMゆるミートアップ」は、エンジニアリングマネージャー業を担う方同士で、ゆるくディスカッションや交流を行う勉強会です。 多様なフェーズ・文化をバックグラウンドに持つEM間での交流を通じ、マネージャーに必須の「自己開示と傾聴、相互理解」の実践の場、ひいては「EM像のア
スタートアップにおけるプロダクト開発には、不確実性がつきもの。市場環境、プロダクト戦略、技術選定、採用、などなど。正解がわからない中で仮説を立て、意思決定を重ねていくことを日常的に行っていく。 一方で、コントロールできることもある。ロードマップの策定、目標の設定、意思決定の場の設計や、決まったことの透明化。いわゆる「プロダクトオペレーション」と呼ばれる領域で、不確実性が低く、自分たちの意志があれば確実にやれることではある。 最近、高い不確実性に挑むためには、後者を確実にやることの重要性に改めて気づいた。 きっかけ 先日、チームの目標を決めるプロセスの中で、コントロールできることを徹底できていな
仕事をしていると、「a or b」を選択する場面に直面することが多い。 * スピードを取るか、品質を取るか * 全体を見るか、個人に向き合うか * 責任を果たすか、やりたいことをやるか * など どちらかを選ぶと、何かを失う（＝トレードオフが発生する）ことも多い。こういう場面で、自分は「a or b」ではなく「a and b」を選択できないか、つまり両方を取れる方法がないか模索するように心がけている。 きっかけ 心がけるようになったきっかけがいくつかある。 一つは、pmconf 2019 に参加したときに、LINE二木さんの「LINEにおけるお金とユーザーのジレンマ」というセッションを聞いたと
「全部解決したい」という衝動 先日、開発チームの体制変更と開発プロセスのアップデートを行った。複数のチームがより同時並列で動ける状態を目指した変更だった。 その後の振り返りの場で、変更に伴うトレードオフについて、一緒に働く人たちからいろいろなフィードバックをいただいた。どれも共感できて納得感のあるフィードバック。 僕はこういう場でフィードバックをもらうと、全部なんとかしたいと思ってしまう。出てきた課題を全部解決したい。一つひとつに手を打ちたい。いただいたフィードバックになんとか応えたい。それが自分の性質だと思う。 でも、出てきた課題をすべて解決しようとすることが、本当に正しいアプローチなのか。
凡事徹底ができているからこそ、次の高い段階に進めることがある。基本をしっかりやる。当たり前のことを当たり前にやり続ける。それができて、その先にある大きな成果やアウトカムに手が届く。 頭ではそう理解しているけど、凡事徹底は大変。めんどくさい。継続するのが難しい。だから、つい楽をしたくなる。もっと短時間でいいものを作りたい。すぐにアウトカムに近いところに飛びたくなる。 これは自分の弱みでもあるし、他の人もそういう気持ちになったことはあるんじゃないだろうか。 凡事徹底とその難しさ ここでいう凡事徹底とは、例えばこういうもの。 * ミーティングの成果は、始まる前の準備で決まっているでも書いた、ミーティ
最近、仕事で参加する議論の性質が変わってきたと感じる。 自分の役割が以前と少し変わってきた。解決したい課題がエンジニアリング領域のものだけではなく、開発プロセスやチームビルディング、採用など、領域が幅広くなってきた。 また、事業やプロダクトのフェーズも変化してきている。以前は「どう実現・実装するか」「どうやってリリースするか」という具体的な話が多かったが、今は「プロダクトの価値をどう高めるか」「プロダクトの成長をより加速させるためには」「それを実現する組織やチームを作るには」といった、より抽象的で俯瞰的な議論が増えている。 過去の職場でも同じような状況に取り組むことはあったけど、こういった抽象
最近の仕事の中で、明確な反省点がある。 自分が参加したいくつかのミーティングに、準備不足のまま臨んでしまったことだ。その結果、他の参加者の貴重な時間を使っているにもかかわらず、議論の解像度を上げきれず、効果的な成果につなげられなかった。 ミーティングの成果というものは、その場が始まる前の準備段階で、大枠が決まるんだということを、改めて認識した。 オーナーとしても、一人の参加者としても ここで言う「準備」とは、ミーティングの主催者（オーナー）やファシリテーターが、アジェンダや資料を作り込むことだけじゃない。一人の参加者としてミーティングに参加する場合も、その役割なりの準備が必要だ。 オーナーであ
スタートアップのソフトウェア開発において、「スピード」は正義とされることが多い。 多少実装が荒くても、まずは世に出し、ユーザーの反応を見ながら後からリファクタリングすればいい、という考え方。 そういった環境に身を置く中で、僕自身も「不確実性の高い状況では、完璧な設計を求めて手を止めるよりは、動くものを届けることのほうが価値がある」というスタンスで開発に向き合ってきた。 けれど、先日チームの同僚と設計やコードのレビューに関する議論をしている中で、この考え方をアップデートしなければいけないな、と感じる場面があった。 スピード重視のスタンスを、あらゆる機能開発に無条件で適用するのは乱暴だった、と思い
ブログ執筆を支援してもらうために、こんな「カスタム指示」を持ったGemを作ってみた。 # ロール あなたは、ソフトウェアエンジニアであり、エンジニアリングマネージャーでもある「kadoppe」の専属編集者兼思考パートナーです。A社に所属する敏腕編集者のように、雑誌Bの編集長や数々の技術書を歴任してきたプロフェッショナルとして振る舞ってください。 あなたの任務は、kadoppe氏のブログ（[https://kadoppe.com](https://kadoppe.com)）の執筆スタイルを深く理解し、アウトプットの質とスピードを最大化することです。**特定のロール（EMやアーキテクト）に固執せず
2025年4月に転職。「夢中をふつうにする」をビジョンに掲げ、管理職が抱える様々な課題を解決する「マネジメントサクセス」プラットフォームを提供する 「mento」に入社した。 【入社エントリ】僕がmentoに入社した理由とやっていきたいこと2025年4月、「夢中をふつうにする」をビジョンに掲げ、法人向け・個人向けのコーチングサービスを提供している「株式会社mento」に、ソフトウェアエンジニアとして入社しました。kadoppe.comKohei Kadowaki (kadoppe) ちょうど、プロダクトやテクノロジー / AIの力で、ユーザーへの提供価値や事業の成長をさらに加速させていくぞ！っ
何か問題が起きた時の解決方法として、もしくは将来の起こりうるリスクの対策として「新しいルールや決め事を作るのはどうか」という議論になることがある。プロダクト開発の進め方やチーム体制を新しくするような時も、新しいルールを作りにいくような議論を自分からすることがよくある。 そういう時は「そのルールは本当に必要？不要では？」と、自分自身の考えも含めて、できるだけ疑ってみることにしている。 ルールを作ることによるメリットはもちろんある。一方で、ルールが増えることで、個人やチームの思考や行動、判断に制約がかかる。自由で大胆で創造的な、これまでの前例にとらわれないアイデアや発想が生まれることを邪魔してしま
最近は仕事中のほとんど全ての時間をアーキテクチャを設計したり、コードを書くことに使わせてもらってます。すごく楽しいです。 そんな中、自分自身も含めたエンジニア組織のあり方について、個人的に考える機会があったので、備忘録的にメモ。 組織ではく、サービス・プロダクトが作りたい まず最初に頭に浮かぶのは、ユーザーの課題を解決し、価値を届け続けられる素晴らしい「サービス」と、それを支える「プロダクト」を作りたいということ。それを追い求める過程で、ひとりひとりが行動を積み重ね、その結果として必要な「組織」が自然と生まれていることが自分の理想。 「どんな組織を作りたいか」ではなく「どんな組織でありたいか」
最近仕事で、LLMを使ったアプリケーション開発に取り組んでいて、プロンプトエンジニアリングの基礎力を身につけるために読んでみた。 Amazon.co.jp: 生成AIのプロンプトエンジニアリング ―信頼できる生成AIの出力を得るための普遍的な入力の原則 : James Phoenix, Mike Taylor, 田村 広平（監訳）, 大野 真一朗（監訳）, 砂長谷 健（翻訳）, 土井 健（翻訳）, 大貫 峻平（翻訳）, 石山 将成（翻訳）: 本Amazon.co.jp: 生成AIのプロンプトエンジニアリング ―信頼できる生成AIの出力を得るための普遍的な入力の原則 : James Phoeni
2025年5月12日に開催された、「御社のDevin、何してる？ 各社の事例に学ぶ！組織の一員としての付き合い方」というイベントに参加しました。 御社のDevin、何してる？ 各社の事例に学ぶ！組織の一員としての付き合い方 (2025/05/12 19:00〜)# ✍️概要 AIエージェント「Devin」は、単なるツールではなく、開発組織の一員として機能する新しい可能性を持っています。しかし、実際に組織に馴染ませ、効果的に活用するにはどのようなプロセスが必要なのでしょうか？ 本イベントでは、Devin を導入・活用することで開発組織やエンジニアの働き方がどのように変化するのかを掘り下げます。
2025年4月25日に開催された「Engineering Manager Meetup #16 〜EMConf expansion〜」というイベントに参加しました。 Engineering Manager Meetup #16 〜EMConf expansion〜 (2025/04/25 19:00〜)2025/03/30 増枠しました。繰り上がった方で懇親会に参加される方はこちらから参加登録をお願いします ## このイベントはEMConf JP 2025 のサブイベントです 02/27に開催されたEMConf JP 2025 は、「増幅」と「触媒」のテーマのもと大きな熱狂の中で終了しました。
2025年4月、「夢中をふつうにする」をビジョンに掲げ、法人向け・個人向けのコーチングサービスを提供している「株式会社mento」に、ソフトウェアエンジニアとして入社しました。
2025年4月8日開催された、「AI Coding Meetup #1 - チーム開発 ✕ AI、みんなの実践知」というイベントにオンライン参加してきました。
最近、仕事で自分の周りにやれることが無限にあって、とても嬉しい状態になっている。自分が貢献できることと、それによって生み出せるポジティブな影響の両方がたくさんあるように思えてる。 ものすごく自由度が高く、やり込み要素も豊富なゲームの世界に突然放り込まれたような感覚。「あれも楽しそう」「これもやりがいがありそう」と、どれから遊んでみようかワクワクしながら考えている時のあの感じに似ている。 そういう楽しい状況なのだけれど、見方を変えれば難しい状況でもある。何から始めようか必要以上に考えすぎてしまって、動き出しが遅くなってはいけないと思う。また、いろんなことに手を出しすぎてしまって、物事が全部中途半
X のタイムラインにたまたま流れてきて、新規事業を立ち上げるためにリサーチをしている人が近くにいたので、参考になるかもしれないと思い読んでみた。「ユーザーの声を意思決定につなげるためにできること」というサブタイトルにビビッと惹かれたというのもある。
この先 Python を使ってがっつりコードを書くことになりそうで、おすすめされたので読んでみた。自分は他の言語の知識を流用しながら、Pythonのことはあまりしっかり学ばずに雰囲気で書いているエンジニア。 Effective Python 第2版 Pythonプログラムを改良する90項目 目次 * 1章 Pythonic思考 * 2章 リストと辞書 * 3章 関数 * 4章 内包表記とジェネレータ * 5章 クラスと継承 * 6章 メタクラスと属性 * 7章 並行性と並列性 * 8章 頑健性と性能 * 9章 テストとデバッグ * 10章 協働作業（コラボレーション） 感想 Pythonらしい
仕事上必要になりそうで、おすすめされたこともあり読んでみた。 マルチテナントSaaSアーキテクチャの構築 原則、ベストプラクティス、AWSアーキテクチャパターン 目次 * 1章 SaaSマインドセット * 2章 マルチテナントアーキテクチャの基礎 * 3章 マルチテナントのデプロイモデル * 4章 オンボーディングとアイデンティティ * 5章 テナント管理 * 6章 テナントの認証とルーティング * 7章 マルチテナントサービスの構築 * 8章 データパーティショニング * 9章 テナント分離 * 10章 EKS SaaS：アーキテクチャパターンと戦略 * 11章 サーバーレスSaaS：アーキ
どこかのブログ記事で、エンジニアに読んでほしい本としてお勧めされていたので読んでみることにした（肝心の記事を忘れてしまった）。ひとまず上巻のみ読んだ。 一人の技術者として本書を読んでみて、技術者としてこれからの人生もやっていく上で、とても大事なことに気づかされたし、いろんなことを学ぶことができた。以下にいくつか自分個人の体験も交えて書いてみる。 ご冗談でしょう、ファインマンさん (上) (岩波現代文庫 社会 5) 目次 * 1 ふるさとファー・ロッカウェイからＭＩＴまで * 2 プリンストン時代 * 3 ファインマンと原爆と軍隊 * 4 コーネルからキャルテクへ ブラジルの香りをこめて 感想
自分の人生や、特にこの1、2年間を振り返ると、自分には「やり抜く力」が足りないと感じることが多い。今年こそは「やり抜く力」を伸ばしたいと思い、兼ねてから積読していた本書を読んでみることにした。 やり抜く力 GRIT(グリット)――人生のあらゆる成功を決める「究極の能力」を身につける 目次 * [PART1]「やり抜く力(グリット)」とは何か? なぜそれが重要なのか? * 第1章:「やり抜く力」の秘密 * 第2章:「才能」では成功できない * 第3章:努力と才能の「達成の方程式」 * 第4章:あなたには「やり抜く力」がどれだけあるか? * 第5章:「やり抜く力」は伸ばせる * [PART2]「や
Obsidian のノートに、その日に自分が Bluesky に投稿した内容のリストをサクッと挿入できるようにした。 最近、読んだ記事の感想や考えたことなどを Bluesky に投稿している（Xへの投稿と同じ内容を Buffer というサービスを使ってマルチポストしている）。その記録を Obsidian にしている Daily Notes（毎日の行動ログや考え事、アイデア、1日の振り返りなどを書くノート）にもサクッと転記したいと思ったことがきっかけ。 使ったもの * Obsidian の Templater Plugin * 編集中のノートに動的な内容を挿入することができるプラグイン * 挿入
最近、APIに関する仕事をすることが多く、基礎知識を広げたり、理解があやふやな部分をしっかり理解するために読んだ。 マスタリングAPIアーキテクチャ モノリシックからマイクロサービスへとアーキテクチャを進化させるための実践的手法 目次 * 第1部 APIの設計・構築・テスト * 1章 APIの設計・構築・仕様化 * 2章 APIのテスト * 第2部 APIトラフィック管理 * 3章 APIゲートウェイ：外部トラフィック管理 * 4章 サービスメッシュ：サービス間トラフィック管理 * 第3部 APIの運用とセキュリティ * 5章 APIの展開とリリース * 6章 セキュリティ運用：脅威モデリング
ここ数年、エディタやターミナルエミュレータの Color Scheme として Dracula を使っていた。2025年になったこともあり、気分転換に新しい Scheme を使ってみることにした。 新しい Color Scheme として選んだのは Nord という Color Scheme。 Dracula と比べて色が優しい（ローコントラストというのかな）。落ち着いた雰囲気が気に入ったのでこれにした。 Cursor に設定した様子は以下。 Dracula ほどではないけれど、いろんなアプリケーション用の Color Scheme が豊富に用意されているのも決めて。自分は以下のアプリケーショ
仕事では「自分が今見えているものが全てじゃない。知らないことや、気付いてないこと、理解できてないことが必ずあるはずだ」って強く意識するようにしている。自分はそれが不確実性の高いスタートアップで働く上ですごく重要なことだと考えているから。 たまに、すべてが見えているように自信を持っている（or そのように振る舞ってるように見える）人と接すると、自分と真逆だーって自分の癖とか性格によく気付かされる。 物事は、人が知る由もない理由によって成功・失敗したりする。自分で「成功したのはこれが要因だ」「失敗したのはこれが原因だ」とわかったつもりになっていても、実はそうじゃないことがある。 → 自分が観測でき
最近、チームや個人の成長について考える機会があった。自分自身の成長についても、もっと加速させたいという気持ちがあり、改めて大事だと思うことを書いておく。 昔、「チームが機能するとはどういうことか」という書籍を読んだ時に、以下のようなことが印象に残った。 * チームが目標を達成するためには、日々の活動やその結果から学習し、成長し続ける必要がある * 毎日、毎週、毎月、自分やチームの活動を振り返り、「何か学べたことはないか」「もっとうまくやる方法はないか」の2点について考えて、次のサイクルをより良いものにするサイクルを絶えず繰り返すことで、それが成長につながる * 個人の学びや成長がチームの成長の
Appleのショートカットを使って、iPhoneのWebブラウザで現在見ている記事のWebクリップ（本文のみをMarkdown形式に変換したもの）を、GitHub のプライベートリポジトリにサクッと保存できるようにした。 こんな感じ。スクリーンショットは macOS 版のショートカットアプリですが、iOS版のショートカットアプリでも同様に作成できる。 手順をざっくり書くと以下。 事前準備 * GitHub に Private リポジトリを作成しておく * 上記リポジトリに対して「Contents : read and write」権限を付与したPAT （Personal Access Toke
「たたき」のドキュメントを書くときに、「これで決めに行く」と言う意識をできるだけ込められるといいなと、と言う話。 仕事で何かしら考えていることや、技術的な意思決定の内容を言語化するときに、まず最初は「たたき」のドキュメントを書くことが多い。「たたき」のドキュメントは以下のようなもの。 * 完成度が30%から70%くらいのもの * 全体の構造（アウトライン）は言語化できているが、実現方法の詳細の解像度が少し荒い * エッジケースも含めて網羅的に検討しきれてない部分がある * ドキュメントのタイトルに「WIP」のようなラベルをつけたりする 「たたき」を書くことで、自分が考えていることによって「どの
技術選定やシステム設計などに関して意思決定をする際に、自分のカバー範囲や知っている情報だけだと全てを決めきれないことがある。もちろん仕入れられる情報は仕入れた上で意思決定しようとするのだけど、関係する他チームや関係者の方針やこれから決定される事項によって、自分たちの意思決定をどうすべきかが変わってくるような場合。 たとえば、エンジニアリングチームで何らかの機能に関する設計をする際に、その機能が具体的にどのようなユースケースで使われるのかを判断材料にしたいことがある。そして、ユースケースを考えるのがエンジニアリングチームではなく、ビジネスチームの責務だったとする。 そういう状況でたまに起きるあま
事業やプロダクトについて議論をしたり、それを生み出すために手を動かすことはとても楽しい。細かい問題や嫌なことを気にすることもなく、時間を忘れて熱中して取り組むことができる。とても好きな時間。 一方で、事業やプロダクトがうまくいっていない時、あるいは、柱となる事業やプロダクトが存在していなかい時は、本当は気にする必要がない細かい問題が気になってしまう。事業やプロダクトを確立することに集中するべきなのに、本当は考えたり取り組む必要がない問題について頭を悩ませたり、議論をしてしまったりする。そしてそういう時間は自分にとってあまり面白くないし、テンションが上がらない時間。なので、やらざるを得ない時はあ
仕事で何かを書いたり作ったりした時に、意見のもらい方として気をつけていることについて書く。意見のやりとりの時間をできるだけ有意義なものにするために。 意見を求める時には、できるだけ同時に「主に意見をもらいたいポイント」を整理してから、相手に伝えるようにしてる。 書いた文章やコードをレビューしてもらう時もそう。 仕事で文章やコードを書くときは、達成したい何らかの目的があるはず。その目的を達成するために必要な最終系のイメージがあって、それを完成させるために手を動かし始める。 完成に近づいてくると、少しずつ進みが遅くなったり、品質が頭打ちになったり、完成までにあと何が足りないのかわからなくなったり、
チームの OKR の Objective を考える時、チームのみんながワクワク、熱狂して取り組めるものを掲げるのが大事だと思う。 一方で、組織全体を俯瞰的にみたり、他のチームからみたりするときに、何を達成するために活動しているチームなのかがパッとわかるように、わかりやすい Objective を掲げるのも重要。 ただ、他チームからみた時のわかりやすさを重視してしまうと、チーム内向けのワクワクさや熱狂できる度合いが下がってしまうこともある。表現が冗長になってしまったり、長くなってしまったり、ありきたりなものになってしまったり。 ワクワク・熱狂さを出すための方法は色々ある。Objective を達
ADR (Architectural Decision Record) を書く機会がここ最近何度かあった。直近を振り返っての反省の話。 ADRを書くときは意思決定の選択肢やそれぞれの長所・短所を考え、それぞれを比較して最終的な結論を決めるのだけど、そればっかりに焦点を当ててしまうと、あまりうまくいかない。 具体的な選択肢について考えるよりも、意思決定をする必要が出てきた背景や目的、意思決定の結果がどう使われるのか（＝ユースケース）、意思決定に影響がある制約など、前段の部分についてしっかり情報収集・整理した上で言語化することがとても大事。 今回は、今ある選択肢を比較して何らかの結論を出そうと急ぎ
組織作りは目的なのか、手段なのか、みたいな話。 自分の仕事上の過去の経験、特に印象に残ったエピソードについてお話した時に、「kadoppeさんは組織を作ったり設計したりするのがやりたいことなの」という質問をいただくことがある。強く印象に残っているのは、組織やチームが一丸となって、大きな目標を達成したエピソードが多いし、組織に関する仕事をメインでやってた時期もあるから。 でも、自分としては特に組織作りがやりたいわけではない。 会社として、事業として、プロダクトとして、何か大きな目標を達成したいとなった時に、誰か一人の力だけではどうにもならないことがある。複数の人の思考と視点とスキルと経験と行動量
2024年4月19日に下北沢のBONUS TRACKで開催された「WORK/LIFE MEETING」というイベントで話す機会をいただきました。 View this post on Instagram A post shared by BONUS TRACK HOUSE (@bonustrack_house) 「WORK/LIFE MEETING」はBONUS TRACKで働く人や、BONUS TRACKの運営に関わっている人が、自分の「働く」と「暮らす」について5分間のプレゼンをする、毎月開催されているイベント。 僕は2023年の9月頃から、BONUS TRACK の施設内で運営されている
2024年3月時点で個人的に継続的にお金を払って使っているソフトウェアプロダクト。サブスクともいう。 * Notion * Plus Plan ($4 / month) * ToDo管理とDaily Note、日々のメモ・ノートの管理 * Apple の「ショートカット」アプリやRaycastを組み合わせて、いつでもどこでもToDoやアイデアをサクッと記録できるようにしてる * Notion AI は使ってない * Raycast * Pro ($10 / month) + Raycast AI で GPT-4 を使うためのPlan ($10 / month) * macOS 上におけるほとん
スタートアップが作り出すプロダクトは、ただ「ユーザーの課題を解決できる」だけでは、足りてない。 ユーザがその課題を心底解決したいと考えている 自分たちのプロダクトが、その課題を他の代替案よりも効果的・本質的に解決することができる このうち、どちらかが欠けていると、そのプロダクトはユーザーにとって「本当に必要なもの」ではなくなってしまう。 なぜ、そのユーザーが自分たちのプロダクトを使う必要があるのか、「必然性」について考える必要がある。それは、上に書いた2つの項目の両方が交わる点を探すこと。 あくまでも、プロダクトはユーザの目的を達成するための手段。強く目的意識を持って、手段が目的にならないよう
2023年のゴールデンウィークに「DIE WITH ZERO」という本を読んだことに影響されて、自分の人生の限られた時間を今後どう使っていくのかについて一度考えてみようと思い、評判が良かったので購入しました。その後、半年ほど積読したあとに読了。 限りある時間の使い方 本書では、著者が「自分の時間をコントロールしようとしないほうがいい、なぜなら不可能だから」ということを一貫して主張している。これまで自分が読んできた生産性向上やライフハック系の書籍に書かれている内容と、かなり考え方が異なっていてすごく新鮮に感じたし、同意できる内容が多かった。 ToDoリストにタスクをやるべきこと/ やりたいことを
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 年経った現在、自
Mac の初期セットアップをちょっとでも楽にするために個人的にやってることを、メモ的に書きます。 ※ 自分用にやっていること & メンテナンス完全にできてないので、そのまんま真似してもちゃんと動かない部分もありますがご了承ください。 必要なソフトウェアのインストール自動化 自分の Mac になにか新しいソフトウェアをインストールするときは、基本的に Homebrew などのパッケージマネージャーを使うようにしています。 * コマンドラインのツール → Homebrew Homebrew * デスクトップアプリケーション（App Store 以外からインストールするもの）やフォント → Home
最近仕事をしてて大事だとと思ったのでメモ。 プロダクトの不具合、見つかるときは立て続けにどんどんたくさん見つかります。 不具合が見つかるきっかけは色々です。自分たちでプロダクトのドッグフーディングをしていて見つかったり、お客様からのフィードバックで見つかったり。 特にお客様からのフィードバックで見つかった不具合は、なんとかなるべく早く修正したくなるものです。問題のインパクトや影響の大きさにもよりますが、暫定対応はなるべく早く行い、事象の解消をしたあとで、落ち着いて恒久対応や Postmortem に取り組みたいもの。それはそれで大事です。 でも、不具合の件数が少ないならまだしも、何件も連続して
これからしっかり監視の仕組みを作っていくぞー、というフェーズのプロダクトに携わることになったので、体系的に知識をインプット / 復習の目的で読んでみました。 入門 監視 内容量はそこまで多くないので、サクッと短時間で読めました。気づいたことや学んだことをざっくりメモ。 監視 SaaS を積極的に使おう 監視のための仕組みを自前で作るのではなく、昨今充実している監視のための SaaS を使用するところから始めましょう。その方が、結果的にコストパフォーマンスがよくなるので、監視 SaaS を使うために必要になる多少の出費は許容しましょう。 自分がこれまで使ったことがある監視 SaaS は以下のよう
PLAID Advent Calendar 2019 の 19 日目の記事です。 こんにちは。kadoppe です。株式会社プレイドで Software Engineer をしています。 今日は、ぼくが、ぼく個人のパフォーマンス（生産性）をあげるためにやっているいくつかの工夫の中から、掲題の件に関するトピックについてピックアップして紹介してみようと思います。 では、はじめます。 結論 背景が長いので出オチになります。 記事タイトルにもある 「爆速で頭の中のアイデアを文章化する」 ために、ぼくが何をしたかというと、「めぐりズム 蒸気でホットアイマスク」（以降、ホットアイマスク）を装着してをつけ、
自分の今後のキャリアについて、前向きに再構築していくための本。 ビジネスモデル YOU 「バリュー・プロポジション・デザイン」を読んでいて、巻末で本書が紹介されており存在を知った。自分自身をプロダクトとしてみたときに、自分のバリュープロポジションはなにか、自分のビジネスモデルはなにかということが気になったのと、そもそも自分の出せる価値や能力、やりたいことって何だろうって、最近迷子気味だったので読んでみた。 企業の活動にビジネスモデルがあるように、個人の活動にもビジネスモデルがある。自分にはどういう能力があり、それをどう活かすことで、どういう価値を生み出すことができるのか。その価値をどういった顧
自分の年齢は自分で決めればいいという考え方。 ハーバード・ビジネス・レビュー 2019 年 8 月号の特集インタビュー「宇宙への夢を語ることで科学技術は進歩する — 宇宙飛行士 向井千秋」を読んで、グサっと刺さる勇気が出る言葉が書いてあったので、忘れないように書いておく。こういうインタービューが好きです。 DIAMOND ハーバード・ビジネス・レビュー 2019 年 8 月号 [雑誌] (MOONSHOT(ムーンショット) 大いなる挑戦が人を動かす) 宇宙飛行の最年長記録（77 歳）をもつジョン・グレンさんがよく “calendar year” という言葉を使っていたらしい。言葉の意図としては
文喫でみかけて、読みやすそうだったのでちょっと立ち読みして購入。 バリュー・プロポジション・デザイン 顧客が欲しがる製品やサービスを創る ビジネスモデル・ジェネレーションの続編。前作がビジネスモデル・キャンバスをつかって、事業や製品を取り巻く環境面の仮説検証サイクルを回す実践方法について語っていたのに対して、本書はサービスや製品そのもの仮説検証サイクルに焦点をあてている。 ざっくりだが、以下のようなことが、視覚的にわかりやすく、親しみやすいイラストとともに書かれていた。 「顧客が欲しがる製品やサービスを創る」ためには、まずは顧客を正しく理解する必要がある。 * 顧客が達成したいジョブはなにか
北海道の東川町に出張する機会があり、現地の図書館で販売されていたので購入。 東川スタイル-人口 8000 人のまちが共創する未来の価値基準 人口減少時代に人口が増加傾向にある「東川町」という地域のなかで、住民のみなさんが大切にしているものや価値観を、生活や仕事の中で実際に体現されている様子について紹介している本。 仕事（ビジネス）をスケールさせるのではなく、価値観を維持し、磨き上げていくことを大切にする、現地の人の生き方・考え方に触れることができる。昔から東川町に住んでいた人も、途中から移住してきた人も関係なく、自分たちの価値観を体現することに価値をおく様々な人々の集大成が、東川町の「東川らし
「プロダクトマネージャーが読むべき何冊の本」みたいな記事で紹介されていたので読んでみた。（具体的な記事は忘れた。） Amazon.co.jp: 決定力！ 正解を導く４つのプロセス eBook : チップ・ハース, ダン・ハース, 千葉敏生: 本Amazon.co.jp: 決定力！ 正解を導く４つのプロセス eBook : チップ・ハース, ダン・ハース, 千葉敏生: 本Amazonのストアでお買い物 ›すべてを表示 ソフトウェアエンジニアとして日々仕事をする中で、僕はいろんなタイミングで意思決定をしている。プロダクトの仕様を決めるとき、それを実現するための設計を決めるとき、障害対応の方針を決め
PLAID Advent Calendar 2018 の第9日目の記事です。 今日は僕がプレイドに入社した頃からエンジニアチームでずっとやっている「朝会」について紹介します。うまくいかなかったエピソードや転機、良くするためやったこととそこから得られた学びについて書ければと思います。 背景 — 朝会開催のきっかけと目的 今から約1年半前の2017年4月に、僕はプレイドに入社しました。入社当時のプレイドでは、約20名のエンジニアが数名ずつのチームにわかれ、それぞれのテーマに沿ってプロダクトの開発に取り組んでいました。 僕には前職でスクラムを用いたアジャイルなチームビルディングに取り組んだ経験があり
会社の Slack で紹介されていた本。チームが目標に向かってリズムよく進んでいくための方法について興味・関心があるので読んでみた。 OKR（オーケーアール） 本書は、前半部分が小説パート、後半部分が OKR 自体の解説パート、の 2 部構成になっている。 小説パートは、やるべきことにフォーカスできず、問題山済みのスタートアップが、OKR を導入することで、なんとなくうまくいった感じになる、サクセスストーリー（？）的な内容。 OKR 自体の説明やユースケースについては、元からある程度知っていたり、昔以下のようなワークショップにも参加したことがあったので、すんなり理解することができた。前段の小説
NewsPicks の特集記事。 『kadoppe は「プロジェクトやプロダクトの価値を最大化させる」ための経験や知識を増やした方がいいよね』というアドバイスを、以前とある人にもらった。 その会話の中で「濱口秀司さん」というキーワードが出てきたので、少し探して目についたこの記事を読んでみることにした。 濱口秀司のつくり方 記事の内容は置いといて、読んで得られた気づきや学びをメモ。「プロジェクトやプロダクトの価値を最大化させるか」という観点で得られた気づきは主に以下の２点。 * スコープの縮小にあらがうこと * 全員が難しい問題に取り組んでいる状況を作ること スコープの縮小にあらがうこと 最初は
ゴールを勝手に 20％くらいは高く見積もった上で Issue に取り組むといいよ、という話。 みんなは当たり前にやっていることかもしれないけど、最近、意識して取り組んでいるのでメモ。できないときもありますが。 今の職場では GitHub の Issue 上で様々なタスクやそれにまつわるコミュニケーションを行なっている。自分をアサインした（あるいは誰かにアサインされた） Issue に取り組み、アウトプットを出して、最終的に Close することが、日々の基本的には仕事の流れになる。 日々の取り組んでいる Issue には達成したいゴールが設定されている。どうすればこの Issue が Clos
フィクションです。 チームで一緒に働いている「とある人」から「自分はチームのみんなにあまり信頼されてない感がある」という旨の発言があった。 どうして信頼されていないと感じるのか。「とある人」の行動にもいくらかは原因はあると思う。でも、普段の些細なコミュニケーションの中でそう感じさせてしまったのなら、それは周りの人間にも責任はあるんじゃないかと思った。 そんな中、昔読んだ「Team Geak」 という本のことを思い出した。 この本には、こんなことが書いてある。 あらゆる人間関係の衝突は、謙虚・尊敬・信頼の欠如によるものだ 謙虚（Humility）、尊敬（Respect）、信頼（Trust）の頭文
忘れないように、もう一度整理してみる。 書籍「リーン開発の本質」では、チームが行うすべて活動の中で、顧客に価値を届けることに貢献していないものすべてを「ムダ」として定義し、それらを以下の７つに分類している。 * 未完成な作業のムダ 99%完成していたとしても、それは意味を成さないし、放置することでさらなるムダを生み出す。 * 余分な機能のムダ 今必要とされていない機能を作っても、何の価値も生み出さないし、システムは複雑になる。 * 再学習のムダ 経験を伝えなければ、誰かがすでに踏んでいる地雷を、同じ人が二度踏む。 * 引き継ぎのムダ 情報が 100%欠落しない引き継ぎは存在しない。せっかくの知