サクサク読めて、
アプリ限定の機能も多数！
アプリで開く
はじめにアジャイルという言葉は広く普及していますが、その本質を正確に理解している人は多くありません。表面的には「変化に強い開発手法」「小さく作って早く回す」という説明が一般的ですが、実際のアジャイルははるかに本質的で、人間の認知能力と組織構造に強く依存した哲学的な方式です。本レポートでは、アジャイルの本質を掘り下げ、なぜ特定の条件を満たすチームでのみ成立するのかを論理的に整理します。そのうえで、アジャイルが成功するために必要な“人の条件”と組織の前提について考察します。アジャイルとは「真実 × 目的 × 推論」が揃う方式であるアジャイルが他の開発方式と決定的に異なるのは、根幹に「真実を操作しない」という前提が置かれている点です。嘘や政治的配慮を最小化し、現実をありのまま扱います。これにより、チーム内の各メンバーが事実を基点として矛盾なく行動できます。しかし、事実の共有だけでは組織は前
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? はじめに 不確実性の多いソフトウェアプロジェクトでは、単純な「いつ終わる？」ではなく、「どの確率でいつ終わる？」という問いが鍵になります。この記事では、確率分布を用いて納期予測の難しさや不確実性を捉え直し、スコープクリープやベロシティ安定化の重要性を考察します。 また、スクラムのようなフレームワークを採用したチームにおいて、モンテカルロシミュレーションを用いて終了確率を予想するWeb上で使えるツールを開発し、誰もが使える形で公開しました。 これらを用いて、単なる点の見積もりから一歩進んだ、現実的かつリスクを見据えたビジネス上のコミュニケ
ペアプログラミング（ペアプロ）は、効果的だと分かっていても、開発組織のカルチャーとして根付かせるのは簡単ではありません。 では、ペアプロがほとんど行われていなかった組織で、それが自然に広がり、カルチャーとして息づくまでにはどんな工夫があったのでしょうか。 適切な休憩の取り方、ペアとの事前合意、ふりかえりのタイミング……現場での試行錯誤から生まれた「実践知」を、ネットショップ作成サービス「BASE」のプログラミングをするパンダさんに寄稿いただきました。 自身もベテランエンジニアとのペアプロでCSSへの苦手意識を克服したパンダさん。そのリアルな体験と知見は、ペアプロ文化を組織に根付かせたい全ての人に響くはずです。 はじめに｜ペアプロは心理的安全性を築く ペアプロは、価値を体験すれば自然に広がる チームの状況に合わせた柔軟なペアプロ運用 信頼関係構築、知識共有の促進――ペアプロの効果 【効果1】
WACATE 2024 冬での発表資料です。
野中郁次郎氏が死去、89歳。スクラムの基盤となった論文「The New New Product Development Game」や書籍「失敗の本質」など 一橋大学名誉教授の野中郁次郎（のなか いくじろう）氏が2025年1月25日土曜日、肺炎のため東京都内の自宅で死去しました。89歳でした。 ナレッジマネジメント（知識経営）の世界的権威として知られる一橋大学名誉教授の野中郁次郎（のなか・いくじろう）氏が1月25日、肺炎のため東京都内の自宅で死去しました。89歳でした。旧日本軍が判断を誤り続けた要因を分析した著書「失敗の本質」などが知られています。https://t.co/qYefEehCfn — 日経 社会ニュース (@nikkeishakai) January 26, 2025 野中氏は上記のポストにあるように、旧日本軍が判断を誤り続けた要因を分析した書籍「失敗の本質」の著者の一人として
2025年3月28日 JaSST’25 Tokyo Day2 で発表した資料です！
ウォーターフォールとアジャイルは、それぞれ異なる前提と目的を持つマネジメント手法です。ウォーターフォールは全体計画の精度を前提に効率的な開発を目指し、アジャイルは変化に適応しながら試行錯誤を重ねることに重点を置きます。しかし、世の中ではマネジメント手法としてフェアな評価ができていないようにも感じます。 その要因は、アジャイルの説明が精神論や感情論に寄りすぎている点にあると思っています。そこで、そういった要素を排除し、双方をマネジメント手法として整理してみました。 前提条件 僕は、いわゆるエンタープライズ業界の人なので、SIerがいるような規模の組織を前提にしていますが、マネジメント手法としての考え方は、どの業界でも利用できると思います。 「ウォーターフォール」とは、大手SIerなどで定義されているウォーターフォール的なマネジメント手法のこと。V字と呼ばれる要件定義、基本設計、詳細設計、実装
技術ブログやエンジニアセミナーなど、ソフトウェア開発に必要な情報を得る機会はたくさんありますが、系統だった知識をまとめて学ぶなら「本」は依然として便利ですし、繰り返し参照するにも適しています。 また本には人生を変える力があり、多くのエンジニアが書籍から知識を得るだけでなく、本と向き合うことでやり方や考え方を見つめ直しています。今回はAgile Journeyと関係のある8人の開発者に、エンジニアとして壁を乗り越え、アジャイルに取り組む契機になるような自分にとって大切な本を推薦してもらいました。 紹介する中には現在では入手の難しい本もありますが、機会があればぜひ手に取ってみてください。アジャイルやXP・スクラムをどう実践すればいいのだろう？アジャイルプラクティス 達人プログラマに学ぶ現場開発者の習慣アジャイルな見積もりと計画づくり 価値あるソフトウェアを育てる概念と技法 塹壕よりScr
お弁当の定番『イシイのおべんとクン ミートボール』などの商品作りを無添加調理で進める石井食品株式会社*1では、まだ40代の石井智康さんが代表取締役を務めています。石井さんは創業家の出身ながら、大学卒業後はIT業界に入り、フリーのスクラムマスターとして活躍するなど、石井食品とは距離を置いていました。 しかし、フリーランスとして働くなかで、改めて社会にどのような貢献ができるかを考えた結果、食の課題に取り組むため家業を継ぐことを決意。2018年に代表取締役社長に就任すると、それまで培ったソフトウェア開発やアジャイルの知見を生かして、さまざまな業務プロセスやコミュニケーションの改革に取り組んでいます。 企業を取り巻く環境が変化するなか、アジャイルに対する理解と知見を持つソフトウェアエンジニアが企業経営に取り組むことで、どのような変革をもたらすことができるのでしょうか。アジャイルとの出会いや石井食品
アジャイル開発に取り組むチーム向けのコーチングや、技術顧問、認定スクラムマスター研修などの各種トレーニングを提供しています。ぜひお気軽にご相談ください（初回相談無料） みなさんこんにちは。@ryuzeeです。 KPT（Keep, Problem, Try）はシンプルで使いやすいフレームワークとして知られていますが、スクラムのスプリントレトロスペクティブで繰り返し（毎回のように）利用することはお勧めしません。 なお、KPT自体が有効でないと言っているわけではありません。スプリントレトロスペクティブで繰り返し利用することに対する問題提起です。 たとえば何らかの大きな取り組みの最後に行ったり、プロダクトゴールを達成したあとや四半期ごとに長めの時間をとって全体を見たりするときには有効なこともあります。 また、ずっと改善を繰り返してきて非常に練度や能力が高くなっているチームの場合も有効かもしれません
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? この記事は株式会社カオナビ Advent Calendar 2024の5日目の記事です。 はじめに ソフトウェア開発は、不確実性がとても高いです。 問題を解決するために提案されたプロダクトが、実際にその課題を適切に解決できるかどうかは分からない 実際に問題解決がされたところで、利益となるかは分からない プロダクトを開発するにあたり、期間などのリソースが正確に予測できない こうした問題に対処するため、私たちは短期間での仮説検証を繰り返しながら、常にプロダクトを改善し続ける姿勢が必要になります。 この記事では、開発チームの立場から貢献するた
モブプログラミングは、なぜ5人が1台のPCで仕事をしているのに生産的になれるのか（前編）。モブプログラミングの生みの親が解説するその理由と効果とは？ 2人のプログラマが協力して同じコードに対してプログラミングを行う「ペアプログラミング」に対して、モブプログラミングは3人以上のチームメンバーが協力してプログラミングを行う方法です。 このモブプログラミングの生みの親であるWoody Zuill氏が、今年（2024年）1月に東京都内で行われたイベント「Regional Scrum Gathering Tokyo 2024」の招待講演「Software Teaming (MobProgramming) and the Power of Flow.」（ソフトウェアチーミングと「フロー」のチカラ）を行いました。 講演のなかでZuill氏は、なぜ一見すると手分けをして作業するよりも効率の悪そうなモブプ
アジャイル開発において”個人と対話”は重要な要素ですが、必要に応じて設計書も作成すべきです。しかし、アジャイルではスピード感ある開発を意識するところもあり、設計書の作成をしないことがしばしばあります。 「設計書が大事なのは分かるけど、そんな時間ないよ」 「時間があるなら設計書つくるけど、動くものをつくるのが優先でしょ」 確かに正しい意見ではあるのですが、各機能が相互に影響する複雑な実装だったり、長期的に改変を繰り返していくようなシステム(1年以上運用するなど)であれば、設計書を書くことで助けられる場面が結構あると思います。 そこで、アジャイル開発において「あまり設計書に時間をかけたくない人」のために、私が現場でやっていたことをご紹介できればと思います。 はじめに こんにちは。アジャイルScrum開発をメインとして日々精進しているkikuchi.sです。 この記事は アイソルート Adven
024年6月28日に開催された 開発生産性Conference 2024 の講演資料です。 講演詳細についてはこちらをご覧ください。 https://dev-productivity-con.findy-code.io/2024
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
