駆け出しSM Stage1：ファシリテーション
これは豆蔵デベロッパーサイトアドベントカレンダー2023第15日目の記事です。 はじめに # ご無沙汰しております。駆け出しスクラムマスター(以下、SM) 亀井です。 夏のリレー連載2023でも書きましたが、5月にSMデビューしてあるプロジェクトに参画し早7カ月が経ちました。 今回もありがたく執筆の機会を賜りましたので、初めてSMとして参画したプロジェクトで私がぶち当たった壁「ファシリテーション」でのつまずきと打開策をご紹介したいと思います...
記事を読む業務システムにおけるアジャイル その4：「知」のオープン化
はじめに # 中佐藤です。 前回の締めの言葉として「次回は『目利き』の話」と書きました。 今回は厳密に言うとアジャイル開発の話ではありません。しかし私がアジャイルのコンサルやコーチをしている過程で、根幹の問題はこれだよなと思うことがあり、この連載の一環として書いてみます。 時には昔の話を # しばらく昔話にお付き合いください。 私は学生時代は言語学が専門で、つまり完全な文系です。それなのになぜか、新卒で入社した機械メーカーでいきなり情報システム部に配属されました...
記事を読む業務システムにおけるアジャイル その3：SaaSとの相性
はじめに # 中佐藤です。 今回は、いろんなベンダーさんから石を投げられそうな話で、ちょっとビクビクしながら投稿します。 とはいえ、同様の話を最近あちこちで聞くので、心を鬼にして(?)解説します。 SaaSはアジャイル開発向きか # 業務システムを刷新する際に、スクラッチ開発ではなく、SaaSベースで開発する、という状況もよく聞くようになりました...
記事を読む業務システムにおけるアジャイル その2：業務フローを元に考える
はじめに # 中佐藤です。なんだかんだで1回目から間が空いてしまいました。 本連載2回目で、「業務フロー」を取り上げます。業務フローがどのようなものかは前提知識として説明を省きます。 そしてこれが前回予告した「イケてるプロダクトオーナー」vs「イケてないプロダクトオーナー」の話につながります。 （プロダクトオーナーは以下、POと略します） POが見るべき範囲 # 前回、業務システムの範囲は「人の動きも含めてシステムである」というお話をしました...
記事を読む業務システムにおけるアジャイル その1：「システム」の範囲
はじめに # 中佐藤です。アジャイルの中でもマイナー領域を攻めることにかけては割と自信があります。 そもそも私がアジャイル関連の仕事を始めた2008年頃には、アジャイルそのものがマイナーだったのです。いつの間にかすっかりメジャーになってしまいましたが。というわけで、アジャイル開発の話の中でも範囲をぐっと狭めて「業務システムにおけるアジャイル」について、連載を始めようかなと思います。 業務システムとは # 上の文章で、ん？と思われた方はいると思います...
記事を読むアジャイル実践者に捧ぐちょっぴり(?)ダークなステークホルダーマネジメント
この記事は夏のリレー連載2023の5日目の記事です。 はじめに # 中佐藤です。 夏といえば「怪談」ですね。この記事は夏のリレー企画の怪談枠です。みなさま、背筋がヒヤッとする内容をお楽しみください。ここに書かれている内容はフィクションです（いいですか、フィクションですよ）。 ちなみに、後になればなるほど、ダーク度合が増します。 なぜこんな内容を？ # アジャイル開発もごく当たり前になり、キラキラした事例はたくさん聞きます...
記事を読む駆け出しスクラムマスターのあれこれ相談室
この記事は夏のリレー連載2023第4日目の記事です。 はじめに # はじめまして。 ２つのウォーターフォール型プロジェクトとアジャイルのスクラムによる開発を3カ月経験した後、 縁あって今年5月からあるプロジェクトでスクラムマスターデビューを果たしました亀井と申します...
記事を読むプロダクトオーナーの煩悩： スクラムの価値基準
はじめに # 中村です。社内開発でプロダクトオーナーやってます。 開発現場での悩みや気づきなど、わりと赤裸々に書いていきます。 まず前提として宣言します。当案件、あまりスクラムとして円滑に回っていません。故にナレッジ、事例としての公開に二の足を踏んでいた（だってカッコつけたいじゃん）のですが、それも含めて透明性かな？と腹をくくり公開に踏み切りました。同様の悩みを抱えるチームの人体実験先例になれば幸いです。 ちなみにチームの現状です...
記事を読むアジャイル開発におけるアーキテクチャの創発
庄司です。 Gartner によれば「創発的アーキテクチャ (Emergent Architecture)」の特質は、次のようにまとめられています。 非決定的 - これまでエンタープライズアーキテクトは成果を計画するために中央集権的な意志決定法を用いてきました。創発的アーキテクチャを使うと、イノベーションを実現するために分散型の意志決定をおこなうように変わります...
記事を読むスクラム『で』教育する～メンバーを育てながら開発を進める～
はじめに # この記事は、「新米スクラムマスターの思考メモ」シリーズの番外編です。最終回の記事でも述べていたように、スクラムで教育するということについて執筆します。今回の記事も主観多めでお送りいたします。 今回の記事は、「スクラム『で』教育する」という話で、スクラムの場でどのように社員教育をすべきなのかという点にフォーカスしています。「スクラム『を』教育する」いう話ではありませんのでご注意ください。 スクラムと教育の相性は？ # 個人的には、スクラムと教育の相性は決して良くはないと思います...
記事を読む
