こんにちは、食べログシステム本部長の京和です。 本エントリでは Shopify の Engineering Blog から、Kirsten Westeinde による「Deconstructing the Monolith: Designing Software that Maximizes Developer Productivity」を翻訳して掲載します。 食べログではユーザーや飲食店に価値を届けるスピードを最大化するべく、マイクロサービス化などをはじめとしたこれまでの組織やアーキテクチャを刷新するための取り組みを始めています。しかし、マイクロサービスはアプリケーションアーキテクチャとインフラアーキテクチャが複雑に絡み合ったシステムで技術的難易度が非常に高く、適切に構築できなければ「分散されたモノリス」と呼ばれるアンチパターンに陥ります。1 Shopifyではマイクロサービスではなく、
![[翻訳] Shopifyにおけるモジュラモノリスへの移行 - Qiita](https://cdn-ak-scissors.b.st-hatena.com/image/square/dfb840670b1246203f99547145b4b7b27db28e26/height=288;version=1;width=512/https%3A%2F%2Fqiita-user-contents.imgix.net%2Fhttps%253A%252F%252Fcdn.qiita.com%252Fassets%252Fpublic%252Fadvent-calendar-ogp-background-7940cd1c8db80a7ec40711d90f43539e.jpg%3Fixlib%3Drb-4.0.0%26w%3D1200%26mark64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZ3PTk3MiZoPTM3OCZ0eHQ9JTVCJUU3JUJGJUJCJUU4JUE4JUIzJTVEJTIwU2hvcGlmeSVFMyU4MSVBQiVFMyU4MSU4QSVFMyU4MSU5MSVFMyU4MiU4QiVFMyU4MyVBMiVFMyU4MiVCOCVFMyU4MyVBNSVFMyU4MyVBOSVFMyU4MyVBMiVFMyU4MyU4RSVFMyU4MyVBQSVFMyU4MiVCOSVFMyU4MSVCOCVFMyU4MSVBRSVFNyVBNyVCQiVFOCVBMSU4QyZ0eHQtY29sb3I9JTIzM0EzQzNDJnR4dC1mb250PUhpcmFnaW5vJTIwU2FucyUyMFc2JnR4dC1zaXplPTU2JnR4dC1hbGlnbj1sZWZ0JTJDdG9wJnM9NDUxODQ2MjU3YTEzNDMwMjQ4MDU3ODNmYzM3MjM3NGI%26mark-x%3D142%26mark-y%3D100%26blend64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZoPTc2Jnc9OTcyJnR4dD0lNDB0a3lvd2EmdHh0LWNvbG9yPSUyMzNBM0MzQyZ0eHQtZm9udD1IaXJhZ2lubyUyMFNhbnMlMjBXNiZ0eHQtc2l6ZT0zNiZ0eHQtYWxpZ249bGVmdCUyQ3RvcCZzPWZiZDJlOGIzYmQzMjk3ZDIxOTA4MjFhZDlkMGI0NTE2%26blend-x%3D142%26blend-y%3D455%26blend-mode%3Dnormal%26txt64%3DaW4g6aOf44G544Ot44Kw%26txt-width%3D972%26txt-clip%3Dend%252Cellipsis%26txt-color%3D%25233A3C3C%26txt-font%3DHiragino%2520Sans%2520W6%26txt-size%3D36%26txt-x%3D156%26txt-y%3D550%26s%3Dfb3a6bbe6d17db94858fcbdae8bc1b62)
今般、市毛由美子弁護士が参加している一般社団法人情報処理学会内の情報処理に関する法的問題研究グループ（LIP）が、実務家、法律家及び研究者の２年間にわたる研究成果として「アジャイル開発向けソフトウェア開発委託契約書（準委任型）」を公開しました。昨今は特に、新型コロナウイルスの影響により先の⾒えない社会環境において、持続的に変⾰を求めていくことを許容するアジ ャイル開発の⼿法が、経営課題を解決する重要なツールとして期待されています。LIPは、アジャイル開発にかかわる紛争を契約面で予防することで、アジャイル開発が広く普及することを願い活動してきました。 今回の契約例は、「スクラム」の⼿法により、⾃社開発でなく社外ベンダ（受注者）を活⽤することを前提としています。アジャイル開発にかかわられる皆様の一助になれば幸いです。
2023-11-02 JaSST'23 Kyushu 招待講演 https://www.jasst.jp/symposium/jasst23kyushu.html 実装完了後の手動テストに依存した開発サイクルに継続的テストのアプローチを適用し、段階的に品質を向上する方法について説明しています。
「プロダクトマネージャーがプロダクトマネジメントを失敗させる!?」大企業病の罠を乗り越え若々しいチームを実現する/Traps of Optimization in Product Management 2024
「プロダクトマネージャーがプロダクトマネジメントを失敗させる!?」カオスなプロダクト開発を効率化したら硬くて息苦しい官僚組織になっちゃった! 大企業病の罠を乗り越え若々しいチームを実現するぞ 効率化を進めていったら息苦しい組織になってきたと悩む方に向けたセッションです。 概要 https://confengine.com/conferences/regional-scrum-gathering-tokyo-2024/proposal/19268 発表者 https://twitter.com/_N_A_ https://note.com/mryy 関連スライド 「私考える人、あなた作業する人」を越えて、プロダクトマネジメントがあたりまえになるチームを明日から実現していく方法 https://speakerdeck.com/moriyuya/product-management-rsgt20
スペシャリストになれなくても成長する方法 #scrumsendai / How to grow even if you can't become a specialist
2022/08 スクラムフェス仙台でプレゼンテーションしたスライドです。 https://confengine.com/conferences/scrum-fest-sendai-2022/proposal/17013/5000dai ソフトウェア開発者としてのキャリアやスキルをどのように広げていくかについて悩むことは多いと思います。日々技術は変化していっているのに自分の勉強がおいつかなくて、まわりのすごい人たちに焦り、何もできていない自分にがっかりする。自分はそんな日々を過ごしてきました。 ですが、そこからほんの少しずつでも視点をずらしてジェネラリストという道を選び、ソフトウェア開発に徐々に貢献できるようになり、自信をもてるようになったことも事実です。 ソフトウェア開発者として、アジャイルコーチとしてジェネラリストを選択した理由、ジェネラリストとしてやっていることなど、具体的な経験を交え
はじめに すまんタイトルは釣りだ。めっちゃ煽った 前提 SaaS企業の内製開発 数十億円調達済みの大きめな会社 スクラム開発をしている 相談者は社内受託感が強まっているのがご不満 ある日相談された 「壁の向こうから締切とプロジェクトが降ってくる」 「プロジェクトが降ってくるのはいいとして、着手前に密室でマネージャーだけで 勘と経験と度胸 ベースで完了目標の日付を決めるのはやめてほしい」 「ほぼ間違いなく、完了目標の日付をオーバーしてしまう。守れない日付をほぼ「締切」として指定しないで欲しい」 「期間とスコープを指定されるのは社内受託感が強い」 という相談を受けました。 前提として SaaSの内製開発をしているWeb企業である スクラム開発をしている 中期的な完了予定の予測を出すことはできない。まだスクラムチームはそのレベルにない 結論から言おう さて僕からの答えはこれです 正確にいうとマネ
プロダクトマネジメントプロセス概要
より価値を届けていくためにどのようにプロダクトマネジメントをすればよいのか？をまとめてみました。
エンジニアが仕様案を手戻りさせるアンチパターンはもう終わりにしよう - yigarashiのブログ
プロダクト開発のアンチパターン プロダクトオーナー（PO）が仕様案を持ってリファインメントや計画に臨み、エンジニアが実現可能性や曖昧さの観点からダメ出しをして手戻りが起こる……スクラムやデュアルトラックアジャイルを志向する組織においては、一度は目にする光景だろうと思います。しかしこれは、以下のふたつの理由からひどいアンチパターンであると言えます。 ひとつには、仕様案を持って臨むPO側の精神的な負担があまりにも大きいやり方だからです。ちゃんとした仕事をしているPOならば、そもそも仕様案なんていう細かいところにたどり着くまでに、とてつもない量の不確実性を捌いてボロボロになっているのです。プロダクトのミッション、戦略、プロダクトゴール、ユーザーの課題、仮説検証の設計、MVPの特定、そういった大上段からのヘビーな分解を繰り返して、ようやくたどり着くのが具体的な仕様案なわけで、それを実装が難しいとか
コロナ禍に「サウナの混雑表示システム」を一晩で 元エンジニアの番頭が手掛ける「アジャイル銭湯」 | i:Engineer(アイエンジニア)｜パーソルクロステクノロジー
「世の中のITエンジニアはエンジニアだらけのコミュニティにいることで、自分の技術がどれだけ他業界ではハイスペックなのか気づけていないと思うんです。もったいない」 そう話すのは、東京・大崎の銭湯「金春湯（こんぱるゆ）」の経営者、角屋文隆さん。9年間務めた大手メーカーのエンジニア職を辞め、1年前に実家の銭湯の経営者となった、業界には珍しい“エンジニアの番頭”さんです。 金春湯はもともと利用者のデータをまったくとっていませんでしたが、角屋さんは“金春湯専用システム”をイチから開発し、客層や混雑の時間帯を数値化。ほかにも公式サイトを改修したりWebショップを展開したりと、創業70年となる老舗の実家にIT革命をもたらしています。斜陽産業から抜け出しきれない業界のなかで、売上は１年で7割増える結果となりました。 「でも、自分が使った技術は新人研修で学べるレベルなんです」という角屋さん。エンジニア時代に
OKRと「測りすぎ」 〜なりたい姿を、「測りすぎ」ないようにしながらどう追いかけるか〜/OKR and the tyranny of metrics
OKRと「測りすぎ」 〜なりたい姿を、「測りすぎ」ないようにしながらどう追いかけるか〜/OKR and the tyranny of metrics
アジャイルな見積もりを理解する「コース定数」という概念 - だいくしー(@daiksy)のはてなブログ
アジャイル開発をはじめて体験すると、いろいろな考え方を身につけるために苦労をすることがあります。 特に、相対見積もりや、ベロシティによる経験主義的な見通しの取り方について、実際に経験せずに理解するのは難しいようです。 そこで今日は、日常生活の中で馴染みの深い考え方を使って、説明を試みてみたいと思います。 「コース定数」でアジャイルな見積もりを考えてみる 国民的な娯楽である登山をやられる人なら誰もが知っている「コース定数」という考え方があります。みなさんもご存知かと思いますが、簡単に解説します。 山は、事前の計画がとても重要でありつつも、実際に登ってみないとコースの状態や、自分の体力がその山に適しているのかがわかりづらい遊びです。そういう意味では、経験主義的なアプローチが必要なソフトウェア開発に似ているとも言えます。 交通機関やレスキューの体制が整備されている街中と違い、山は自分の体がすべて
プログラマーに贈る、わかりやすい文章を書くための技法 - LIVESENSE ENGINEER BLOG
これは Livesense Advent Calendar 2022 DAY 8 の記事です。 転職ドラフトでエンジニアをしている verdy_266 です。 僕の2022年を振り返ると、採用広報チームでの活動を無視することはできません。転職ドラフトの開発を行う傍ら、昨年末に採用広報チームにジョインし、記事の執筆や校正に多くの時間を割いてきました。 今まで記事を投稿したことがなかったこちらのブログにも共作含め5記事を投稿し、11月には Software Design への寄稿の機会をいただくこともできました。文章を書くことが思った以上に好きなんだなと発見があった年でもありました。 made.livesense.co.jp made.livesense.co.jp made.livesense.co.jp made.livesense.co.jp made.livesense.co.jp 弊
SRE実践の手引 ─ 信頼性をどう制御するか？ から始める、現実的な指標と目標の設計と計測 - エンジニアHub｜Webエンジニアのキャリアを考える！
SRE実践の手引 ─ 信頼性をどう制御するか？ から始める、現実的な指標と目標の設計と計測 SREの役割には、信頼性、SLIとSLO、エラーバジェット、トイル、ソフトウェアエンジニアリングといった複数のキーワードが存在するがゆえ、なかなかうまく実践できない、という声もあります。本稿では、難しく見られがちなSREの内実を、「信頼性の制御」というコンセプトを軸に整理し、小さく始める一歩を坪内佑樹（ゆううき）さんが解説します。 こんにちは。SREの研究者をやっているゆううき（@yuuk1t）です。 SRE（Site Reliability Engineering）は、従来のオペレーションエンジニア、システム管理者（sysadmin）と呼ばれる人々が担っていた技術領域の新しい形です。Googleによって提唱され、日本国内でも2015年ごろからWebコンテンツ事業者のコミュニティを中心に広く知られる
これは Livesense Advent Calendar 2022 DAY 2 の記事です。 はじめに 身を以て学んだアンチパターン スクラムガイドを理解したつもりになっていた スクラムによってリリースが早くできるわけではない 見積もりを約束にしてはいけない プロダクトオーナーはスクラムチームメンバーでありお客様ではない ロール（プロダクトオーナー、スクラムマスター、開発者）の兼任は出来るだけやめた方が良い プロダクトバックログは会話ツール まとめ はじめに 転職会議事業部でエンジニアをしている、前山です。 アドベントカレンダー2日目の記事です。 今回は、スクラムマスターとして苦しんだ経験について、アンチパターン的に書いてみたいと思います。 スクラムマスターは2年ほど前からやらせてもらっており、今年に入ってから発足したチームで、もっとちゃんとスクラムマスターをやろうと本気で勉強をやり始め
『LeanとDevOpsの科学』をきちんと解読する 〜Four Keys だけじゃ絶対もったいなくなる話〜
スクラムフェス福岡2024での講演資料です。 --- 皆さん、職場でFour Keysを導入していますか？ Yesと答えた皆さん、『LeanとDevOpsの科学』は読みましたか？ あくまで僕の周囲のみの観測で語るのですが、Four Keysを職場で導入しているという人はとても多いのですが、そのうち、出典である『LeanとDevOpsの科学』をきちんと読んだ人はかなり少ないようです。 そして、ここで敢えて強めの主張をするのですが 『LeanとDevOpsの科学』を読まずにFour Keysをきちんと利用することはほぼ不可能です。 Forsgrenらは徹底した研究の結果として4つのメトリクス（指標）を見出すのですが、その裏には彼女らの沢山の思いが詰まっています。その思いや彼女らの思考を理解し、彼女らの考えをきちんとトレースして始めて、Four Keysは意味を持ちます。 そして『LeanとDe
はじめに 今日は、ニコニコのプレミアム会員サービスを支える「プレミアム課金システム」を動画システムのモノリスから切り出し、変更可能にしていった過程について書きます。プレミアム課金システムは金銭を扱うシステムですので、「（特に、失敗した）話を聞くのは面白いけど、自分で触りたくない」と思われる方も多いのではないでしょうか。 この記事では、決済にかかわるシステムでも一般的なシステム改善の方法が適用できることをお伝えしたいと思います。また、コストを抑えつつ着実なシステム改善を行う方法論としてもご理解していただけると嬉しく思います。 背景 プレミアム会員サービスについて 月額500円（税別）のプレミアム会員制度には159万人（2020年9月末現在）の方が加入してくださっており、ニコニコ事業を支える主要な有料サービスです。 ニコニコ動画は2006年にサービスを開始し、2007年にプレミアム会員サービス
新型コロナウィルスの影響も長引いてますが、皆さま無事お過ごしでしょうか。私は幸い無事です。 日ごろチームでソフトウェア開発をしているのですが、近年社内ではペアプログラミングやモブプログラミングが流行しています。 私のいるチームでもここ二年ほどモブプログラミング（ないし類似のプラクティス）に取り組んできました。 モブプログラミングについて正確にどのようなものかは以下の記事などをご参照いただければと思います。 簡単にまとめると、要求分析やコーディング等幅広い開発作業を、同じ場所に集まったチームの共同作業でこなしていくというものです。 このご時世ですので、最近はオンラインのミーティングルームに集合する形式でしたけど。 www.agilealliance.org ここから先は、非常にパーソナルな、私に限定された体験になります。 どの人・チームにも適用できる話ではありません。ではありますが、どの人・
【追記 2023/06/26】 テックリードに求める役割と適切なチームサイズについて - pospomeのプログラミング日記
自分はDMMプラットフォーム内のマイクロサービスアーキテクトグループという組織の責任者をしているが、 最初に比べると組織がそれっぽく拡大したこともあり、 ここ最近テックリードを立てる機会が増えてきた。 一度自分がテックリードに求める役割と適切なチームサイズについてアウトプットしてみようと思う。 DMMプラットフォームのマイクロサービスアーキテクトグループとは? pospomeがテックリードに求める役割 技術領域をリードする プロジェクトマネージメント 他チームとのコミュニケーション チームメンバーの評価 なんだかんだで総合力 pospomeがテックリードに求めない役割 ピープルマネージメント よく分からない政治的なコミュニケーション 適切なチームサイズについて 新規チーム設立を考慮する場合 おまけ：テックリードに求める役割と適切なチームサイズ以外のあれこれ No.2 の重要性 立場が人を作
不確実さが増す世界のプロジェクトマネジメントとはとういうものか 倉貫義人氏：そんな不確実さが増す世界のプロジェクトマネジメントはどういうものなのか。（スライドを示して）プロジェクトがうまくいかない（理由）というのは、このあたりを見てもらうと胃が痛くなりそうな言葉がいっぱい書いてあると思います。想定よりコストがかかるとか、作ったものを直せないとか。 （スライドを示して）これに対してどうすればいいかというと、「こうすればうまくいくのかな？」と考えがちですよね。「遅いからプレッシャーをかけようか」とか「少し遅れているので人を増やそうかな」とか「一気に作ったほうがいいんじゃないの？」とか「属人性を排除しましょう」とかと言いがちですよね。 これらはけっこう言いがちですが、全部失敗するやつです。これを全部やってみたら困ったことにプロジェクトが大変なことになるので、ぜひやってみたらいいと思います。 （会
ピナクルズの CTO をしている渋谷です。「現場向け動画 DX」を実現するための SaaS『tebiki』を開発しています。 今回は、「プロダクトの開発スピードを落とさずに、かつユーザーの芯を食ったソリューションを提供するためには、すべてのスコープをいかに小さくできるかが重要」だということについて書いてみたいと思います。 ちなみに弊社はこれを実践することで開発がものすごくスムーズになり、リリース頻度が体感で 50% くらい向上しました！ スピードは失われていく前提として、プロダクトの開発スピードは意識的に改善し続けなければ、機能の追加とともに失われていきます。 提供する機能の増加に伴い、仕様の辻褄合わせだとか実装の順番だとかの複雑に関連するパラメータも同時に増えてしまうので、結果として人や時間といった必要なリソースが指数的に増えていくという話ですね。 （技術的な負債もこのパラメータに含まれ
The Patternsハイパープロダクティブチームを体系的に生み出すため9つのパタンはこちらになります。 1. Stable Teams 2. Yesterday's Weather 3. Swarming: One Piece Continuous Flow 4. Interrupt Pattern: Illigitimus Non Interruptus 5. Daily Clean Code 6. Emergency Procedure 7. Scrumming the Scrum 8. Happiness Metric 9. Teams that Finish Early Accelerate Faster https://www.scruminc.com/wp-content/uploads/2014/05/teamsthatfinishearlyacceleratefaste
新規事業とアジャイル
みなさんこんにちは。@ryuzeeです。 新刊『プロダクトマネジメント - ビルドトラップを避け顧客に価値を届ける』が10月26日に発売になりますので、よろしくお願いします。 先日、プライベートで新規事業とアジャイルに関する短いセッションをしましたので、そのときの資料を共有します （本当は1時間かかるものをかなり縮めたダイジェスト版です）。 以下、資料だけ見てもわからない方向けの解説です。 TL;DR（結論）何が分からないのかすら分からないこともある。過度に詳細な計画にしない適切な問題を扱っているか、顧客はいるかが重要顧客が関心を持つのは、自分の課題の解決であり、ソリューションそのものではない仮説と検証の繰り返し急いでたくさん作らない。機能の多さは成功につながらない投資モデルを変える(100打数10安打1ホームランなら上等)アジャイルとはフィードバックサイクルの集合体最初から人が多すぎると
はじめに 今の会社に転職してきて２ヶ月が経ち、まだまだ分からないことも多いですが少しずつ環境にも慣れてきたので頭の中を整理するためにも今感じていることをアウトプットしたいなと思い書きました！ 現在、私が参画しているチームはスクラムをベースとして開発を行なっており、前職もスクラムでの開発を経験していたので、その違いを整理していきます。 前職 スクラムを導入するまでの背景 前職では、美容医療・精神科クリニックを運営している会社で、クリニックスタッフが使用する社内システムの開発に携わっていました。働き方としてはフル出社になります。 チーム構成は以下で、私はメンバーでした。 チーム構成（7名） ディレクター(PM) 1名 リーダー 1名 アーキテクト 1名 メンバー 4名 はじめからスクラムを導入していた訳ではありませんでした。 開発の流れとしては、クリニックスタッフまたは関係者からディレクター（
こうしてふりかえりは終わってしまった / A Demise of a retrospective
2023.04.08 ふりかえりカンファレンス2023 https://retrospective.connpass.com/event/266892/
SI案件でアジャイル開発を進めるときの勘所
みなさんこんにちは。@ryuzeeです。 10月に発売となった『プロダクトマネジメント - ビルドトラップを避け顧客に価値を届ける』ですが、まだお読みになっていない方是非よろしくお願いします。 また、ここ数か月新しい書籍の翻訳に取り組んでいて、来年の春くらいには発売になるかと思います。この本も楽しい本だと思うので是非楽しみにお待ち下さい。 さて、先日、プライベート講演で、SIのコンテキストでアジャイル開発を進める場合に、どのような点に気をつけておくとよいかを話して来ました。 汎用的な内容で読者の方の参考になるかと思いますので、資料を公開しておきます。 以下、資料だけ見てもわからない方向けの解説です。 TL;DR（結論）SI案件でアジャイル開発を適用する場合、顧客側がアジャイルを正しく理解していない可能性があるので、案件開始前に教育すべしステークホルダーマネジメントは重要。これはウォーターフ
『リーダーのための「スクラムガイド」手引き』を翻訳・提供、Scrum.orgに公開されました | サーバントワークス株式会社
各位 Scrum.orgにて公開されている「Scrum Guide Companion for Leaders」を代表の長沢智治が共訳にて日本語翻訳し、日本語翻訳版『リーダーのための「スクラムガイド」手引き』として、Scrum.orgに提供し、公開されましたので、お知らせいたします。 また、同タイミングにて、「ビジネスアジリティのための投資戦略」も同様に日本語翻訳版が公開されました。 リーダーのための「スクラムガイド」手引き スクラムガイドは、複雑な問題に対応するフレームワークのルールとして浸透していますが、リーダーシップの役目を担うステークホルダーの一人としてどのように支援し、役目を果たすのかは、キャッチアップが難しい面があります。そこで、「Scrum Guide Companion for Leaders」では、文字通りスクラムガイドをリーダー層の理解促進と、スクラムチームの支援を的確
新規開発を始めるときにやるべきこと
自動テスト実行結果の目的を整理する / Organizing objectives of automated test results
スクラムの原則を、いかにして実践するか - 現場にありがちな悩みを吉羽龍太郎に相談してみた - エンジニアHub｜Webエンジニアのキャリアを考える！
スクラムの原則を、いかにして実践するか - 現場にありがちな悩みを吉羽龍太郎に相談してみた スクラムは多くの開発現場で取り入れられており、その原則を学ぶのは簡単です。しかし原則を現実に実行しようとすると、さまざまな課題が……。アジャイルコーチの吉羽龍太郎さんにスクラムの基礎から、ありがちな課題への対処法をたっぷり聞きました。 スクラムは軽量で理解が容易、だけど実際にやるのが難しい 【スクラムの基礎知識】3つの役割を理解する 【スクラムの基礎知識】5つのイベントを理解する 【スクラムの基礎知識】3つの作成物を理解する スクラムを“現実的に”実践する手法 見積もりは誰のもので、誰が作るのか フィボナッチ数列よりも「Tシャツ見積もり」。素早く見積もりを作る手法 スプリントの期間は1週間が計画しやすくておすすめ スプリントプランニングの極意。タスクの粒度は小さければ小さいほど扱いやすい タスク管理
C#によるクライアント/サーバーの開発言語統一がもたらす高効率な開発体制 ～プリコネ！グランドマスターズ開発事例～
2022/08/25 CEDEC2022
こんにちは！estieでビジネス部門の責任者をしている束原です。 2024年になりましたね。estieは決算月が12月なのですが、毎年期初に「今年こそが勝負の年だ」と言っている気がしており、それに対して「ガハハ」と笑い合えるメンバーで仕事ができているのが最高に楽しいなと日々痛感しております。 さて、こちらは事業の立ち上げ（事業開発）に関する記事です。 この記事に書いてあること estieでは「仮説検証」をやめようと思っている話 事業開発の成分の8割は営業だという話 かなり極論が並んでいますが(笑)、事業開発を進める上でとても重要だと考えているので、ご興味のある方は少しお付き合いください。 to Bスタートアップは仮説検証をやめようという話 「仮説検証って言葉が嫌いなんすよねー」と、確か弊社の事業責任者の齋藤だったか代表の平井だったかが以前社内で言ってました。 1年前くらいまで私は、その発言
DXの本質と、「開発しないエンジニア」のキャリアパス / What is Product Specialist?
「Developers Summit 2021 Summer」での登壇資料です。 https://event.shoeisha.jp/devsumi/20210730/session/3243/
本記事はドメイン駆動設計(DDD) Advent Calendar 2021 25日目の記事です。 「もっとビジネス変化に耐えられる設計を目指したい」「ただデータをやりとりするだけなのに複雑化してしまうのを防ぎたい」 様々な動機からドメイン駆動設計に入門しようとする方がいると思います。 自分もエンジニアとして働きはじめて、「どうしてすぐに変更しにくくなってしまうのか」「より柔軟な設計にするにはどうすればよいか」と悩むことが多くなり、良い設計手法を探って出会ったのがドメイン駆動設計でした。 最初はドメイン駆動設計関連の本ばかりを読んでいたのですが、途中から「これってドメイン駆動設計というよりはオブジェクト指向の話では？」とオブジェクト指向に興味を移し、さらに「より変化に強いプロダクト開発するにはチームから変化させないとまずいのでは？」とアジャイル開発に興味が移りました。 本記事では、ドメイン
スクラムガイドに新たに追加された「プロダクトゴール」とは？ あるいはプロダクトゴールの設定には何が必要か？（前編） Regional Scrum Gathering Tokyo 2022
スクラムガイドに新たに追加された「プロダクトゴール」とは？ あるいはプロダクトゴールの設定には何が必要か？（前編） Regional Scrum Gathering Tokyo 2022 代表的なソフトウェア開発手法として知られる「スクラム」を開発したケン・シュウェイバー氏とジェフ・サザーランド氏によるスクラムの公式ガイド「スクラムガイド」。2020年11月付けの最新版には新たに「プロダクトゴール」と呼ばれる概念が導入されました。 スクラムガイドによると、プロダクトゴールはプロダクトの将来の状態を表しており、スクラムチームの⻑期的な⽬標である、と説明されています。スクラムチームにとって非常に重要なものだと位置付けられているのです。 この重要なプロダクトゴールをどのように考え、どう設定すべきなのでしょうか。 1月5日から7日までの3日間、都内およびオンラインのハイブリッドで開催されたイベント
アジャイルの反対はウォータフォールでは無いんじゃない？という話 - メソッド屋のブログ
先日ふとSNSを眺めていると、「アジャイル」と「ウォータフォール」はあうあわないがあるので、使い分けるのが吉的な意見を見てなんだかもやっとした気分になった。 正直アメリカに来てから「ウォータフォール」を見たことが無い。確かに日本にいたときは使われていた。最近はさすがに「アジャイル」がだんだん主流になっていく流れも見える気がするが、 アジャイルが「主流」という感じすらしっくりこない。なんでだろう？アメリカでもアジャイルは「主流」ではない。 日本にいたときの個人的な開発方法論のイメージ 日本に居たときは、実際にウォータフォールが沢山あった。ただし、自分はソフトウェア開発には「ウォータフォール」が効率が良いとは一切感じられなかったので、そのことを書いたら結構炎上した。 simplearchitect.hatenablog.com 日本に居る時のイメージは、自分的にはこんなイメージだった。ウォータ
必要にかられていて、社内でも読書会がはじまった。読書会はまだやってるけど、先行して読み終わった。愛称は「ちいとぽ」らしい。 チームトポロジー 価値あるソフトウェアをすばやく届ける適応型組織設計 作者:マシュー・スケルトン,マニュエル・パイス日本能率協会マネジメントセンターAmazon どういう本なのかは、訳者の方が用意してくれた以下の資料が良いのではないか。 自分が読み始めたモチベーションとしては、チームの分け方について知見を得たいというものだった。 shimobayashi.hatenablog.com 本を読んでみた感想としては、元々の自分の考え方もそんなに外してないことが分かって安心感があった。もちろん考慮の幅・深さ・質は違うので、この本を読んで良かった。 どれくらい根拠のある内容なのかはよく分からなかったけど、個人的にはこれまで勉強してきたことと整合的だった気がするので全体的にはす
アジャイルを展開していくうえで、現場の開発チームがどう振る舞えばいいかは具体的なテクニックがあるのですが、「偉い人」がどう振る舞うべきかについての情報が少ない気がしたので整理します。なお、僕の元ツイートはこちらからの一連です。 アジャイルを推進している偉い人の中にはスプリントレビューに出るなど、マイクロマネジメントになりがちな人がいる。理由を聞いたら「成果物が、普通に考えたらそうならないでしょ、みたいなものを作るから目を離せない」という。進言したのは「それはチームに考えさせてないからですよ」（続— 鈴木雄介/Yusuke SUZUKI (@yusuke_arclamp) 2023年2月4日 前提 偉い人、とは 偉い人は関わりすぎてはいけない なぜ、チームは普通に考えないのか 偉い人が関わらないのもダメ 偉い人は適切に関わる 追記 前提 この議論において「そもそも、偉い人やPOやエンジニアに
私がもはやベロシティについてほとんど話さない理由
ベロシティは、スクラムの要素だったことはありません。 ソフトウェア開発に「ベロシティ」を適用することは、エクストリーム・プログラミング（XP）の先駆者たちによって考案されましたが、今ではそれが良くないアイデアだと考える人たちもいます。 残念ながら、スクラムの世界では、いまだに 「4倍のベロシティ向上 」や 「超生産性」などの言葉を押し付けている人がいます。私はこれを恥ずかしく思っています。これは、私が ケン・シュエイバーから学んだ スクラムではありません。ケン・シュエイバーは代わりに、 厳格な完成の定義 と、守れない約束を避けるということを強調していました。 もし私たちが、 実験から学び、適応する能力 を促進するのであれば、特に私たちの近視眼性（木を見て森を見ない傾向）と短絡的な認知バイアスを考えると、従来の生産性重視の姿勢は（それがどのような理由であれ）有害となりえます。あなたが昔に書い
最初に タイトルは煽りで釣りです。ごめんね。 この記事の結論を先に書くと タイトルは釣り スクラムチームは導入当初はスムーズに成功できるように感じる。しかし途中でどこに進むべきかの方角を見失い、迷走してスクラムバットに陥る スクラムに求める効能はベロシティの安定が必須なものが多いのに、ベロシティの安定を意識すらしないままスクラムをやるので、迷走に陥る じゃあどうしてそうなってしまう？という話を個人の経験をもとに書いていこうと思います。 前提として この記事を書いた人はWebサービスの内製開発をしているアプリケーションエンジニアだったので、基本的に内製開発のWebサービスでのスクラム導入について語ります なぜこの記事を書いたか やっとむさんのツイートを見て思いつきました。 スクラムの導入をしたいというチームは数多く見ますが、かなり中途半端なところでスクラムのレベルアップをやめて、小手先の「改
2021年3月に劇場公開され、興業成績100億円を達成した、ヱヴァンゲリヲン新劇場版シリーズ完結編「シン・エヴァンゲリオン劇場版」。その制作は、プリプロジェクトを含めると足かけ11年にわたっていた。 中心人物は言うまでもなく庵野秀明氏（カラー代表）だ。総監督に加え、原作、脚本、画コンテ、原画、宣伝、エグゼクティブプロデューサーを兼任。全体を統括するマネジャーでありながら、脚本や原画などプレイヤーを兼ねていたことが、肩書きだけでも分かる。 シン・エヴァのスタッフが見た「ドキュメンタリーとは違う」庵野氏 公開当時に放送されたNHKのドキュメンタリー番組では、庵野氏が一度現場に任せようとしながらも、結局本人が直接カメラを手に取ったり、制作が進んでいたシーンを破棄して脚本から作り直したりするシーンも放送された。 視聴者からは「庵野秀明の“ちゃぶ台返し”」「ワガママに振り回されるスタッフがかわいそう
エンジニアの組織づくりについて、さまざまなテーマでパネルディスカッションを行う「【CADDi x Retty】エンジニアリング組織の悩み相談」。ここでRetty株式会社の常松氏、キャディ株式会社の猿田氏が登壇。最後に、1on1についてと、視聴者からの質問について話します。前回はこちらから。 1on1の頻度 猿田貴之氏（以下、猿田）：「1on1を毎週全員やるとメチャクチャ大変なんですが、効率化の工夫などありますか？」なるほど。常松さん、1on1はメンバーというか、どれぐらいやっていますか？ 常松祐一氏（以下、常松）：1週間に1回、30分。今はVPoEになったので少し減ったんですけれども、9月までは社員のメンバーが16人ぐらいいたのかな。 猿田：16人を1週間に1回だと、週8時間ぐらいやっていたということ？ 常松：1日に4回とか5回とか、1on1でずっと話していて。1日の半分というか、週の半分
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
[翻訳] Shopifyにおけるモジュラモノリスへの移行 - Qiita
LIP版「アジャイル開発向けソフトウェア開発委託契約書（準委任型）」 公開 - のぞみ総合法律事務所
テスト自動化から、 開発を支える継続的テストへ
完了予定も出せないから、いつまで経ってもお前のチームは社内受託なんだよ
私はスクラムを解っていなかった - LIVESENSE ENGINEER BLOG
ニコニコで12年運用した決済システムを移行する上で必要だったこと - Qiita
モブプログラミングに向いてない私の話 - 誰かの役に立てばいいブログ
これからのプロジェクトマネジメントに大事なのは「結果にコミットしない」こと クリエイティブな仕事に求められる“アジャイル思考”
開発のスピードを上げたいならすべてのスコープを小さくしよう
スクラムチームを超生産的にするためのパタン・ランゲージ｜天野 祐介 (ama_ch)
現職と前職で感じたスクラムの違い - Qiita
to Bスタートアップは「仮説検証」をやめようという話 - estie inside blog
ドメイン駆動設計からオブジェクト指向、そしてアジャイル開発まで。関連書籍練り歩きのススメ
チームトポロジー を読んだ - 下林明正のブログ
アジャイルで「偉い人」はどう振る舞うべきか - arclamp
だからお前のチームはスクラム導入で満足して、いつまでたっても生産性が上がらないんだよ
「ちゃぶ台返しはしない」 シン・エヴァ制作進行が見た“マネジャー庵野秀明”の姿（後編）
「1on1でクリアに不満を言ってくれる人は、ほぼいない」 「言っても意味ないな」で終わらないための信頼関係の築き方