アジャイルを展開していくうえで、現場の開発チームがどう振る舞えばいいかは具体的なテクニックがあるのですが、「偉い人」がどう振る舞うべきかについての情報が少ない気がしたので整理します。なお、僕の元ツイートはこちらからの一連です。 アジャイルを推進している偉い人の中にはスプリントレビューに出るなど、マイクロマネジメントになりがちな人がいる。理由を聞いたら「成果物が、普通に考えたらそうならないでしょ、みたいなものを作るから目を離せない」という。進言したのは「それはチームに考えさせてないからですよ」（続— 鈴木雄介/Yusuke SUZUKI (@yusuke_arclamp) 2023年2月4日 前提 偉い人、とは 偉い人は関わりすぎてはいけない なぜ、チームは普通に考えないのか 偉い人が関わらないのもダメ 偉い人は適切に関わる 追記 前提 この議論において「そもそも、偉い人やPOやエンジニアに

2021年9月18日に開催されたXP祭り2021で「マイクロサービスに至る歴史とこれから」という講演をしました。資料は次の通りです。本来は75分ぐらいかかるのを45分で話そうとして、余裕で時間オーバーしてすみませんでした。 テクノロジーとテクニックによる進化の流れ テクノロジーやテクニックは、ITの改善サイクルを向上させるために進化を続けています。「技術そのもの」であるところのテクノロジーに対して、テクニックというのは「人による技術の活かし方」を示します。なので、基本的にはテクノロジーが生まれ、それを使いこなしたテクニックが登場することになります。 テクノロジーとテクニックの進化の歴史現在、進化中のテクノロジーであるCloud NativeやServerlessを前提としたテクニックを示す用語、つまり、マイクロサービスに次に来るかもしれない言葉というのは、時間軸からすると再来年ぐらいに出て

2017/12/15のエンタープライズアジャイル勉強会 2017年12月セミナーの企画は僕がやらせてもらいました。 テーマは「アジャイルを機能させる外枠」とし、アジャイルチームがうまく機能するために、あえてチームの外側で解決した方がいいこと、を整理してみたいと思いました。 アジャイルチームというのは、実際にモノを作り、サービスを動かし、ユーザーからのフィードバックを付けて改善を行っていくことが目的です。その目的を達成するためにはアジャイルチームの外枠をちゃんとする必要性があると考えています。 アジャイルを機能させる2つの外枠 1つ目の外枠は「何を作るべきか」という観点。チームが何を作るべきか、という手前には「そのチームが実現すべき価値とは何か」をきちんと考える必要があります。この点はギルドワークスの市谷さん（@papanda）にお願いしました。市谷さんの講演は「アジャイル開発はWhyから

2018年7月23日におこなわれた要求開発アライアンス2018年7月定例会で「エンタープライズアジャイルにおける要求探索の勘所」という話をさせていただきました。資料は以下。 僕にとってのエンタープライズアジャイルの定義は ウォーターフォール開発の環境が整備されている中で取組むアジャイル のことです。で、こういう現場の支援、あるいは自社で開発していると以下のような段階で成長していっているなぁと感じています。 1.PO本人がスコープ管理をちゃんとできるようになる 2.企画組織内でPOがリードタイムの管理をちゃんとできるようになる 3.他部署ともルールをきめてプロセスの共有をちゃんとできるようになる というわけで、そういったところを資料にしてあります。 まだまだ、エンタープライズアジャイルには辛いところも多いですし、進化の過程だなと思うところもたくさんあります。しかし、こういった取組みを深めてい

昨年末、ブログをネタにTwitterで議論したことを akipii さんが「アジャイル開発にはモデリングや要件定義の工程はあるのか、という問題とその周辺: プログラマの思索」というエントリにまとめてくださいました。ありがとうございます！。 ブログで書かれたことに直接の返答にはならないのですが「アジャイルにおける事前合意はどうあるべきか？」ということを書きたいと思います。 アジャイルは最初に全てのCDSを決めない まず、狭義のアジャイル開発プロセスは優れたマネジメント手法です。システム開発を評価するQCDS（品質/コスト/期日/スコープ）ですが、Q（品質）というは「そのシステムにとって問題ないレベルにする」でしかないので、CDSの調整が論点になります。 ウォーターフォール型開発というのは、 「スコープは最初に確定」し、 「コストや期日はスコープを達成するために必要な分を最初に設定」し、 必要

2017/12/15（金）にエンタープライズアジャイル勉強会2017年12月セミナーで「アジャイル開発を支えるアーキテクチャ設計とは」という話をしました。資料は以下から。 アジャイル開発を支えるアーキテクチャ設計とは 僕の話したかったのは「アーキテクチャ設計といっても『大きなアーキテクチャ設計』と『小さなアーキテクチャ設計』というレベルがあり、後者はチーム内で解決すべきだが、前者はチーム外で解決すべきだ」ということです。 大きなアーキテクチャ設計：システム間連携のレベル→アジャイルチームの外で実施 小さなアーキテクチャ設計：システム内連携のレベル→アジャイルチームの中で実施 なぜ分けるのか、というと、それぞれのレベルで求められる性能も可用性も保守性も違うからです。 小さなアーキテクチャ設計は「チームが好きにすればいい」わけですが、大きなアーキテクチャ設計は「チームをまたがって企業内でそれな

がちがちのエンタープライズ系で既存システムのマイクロサービス化に取り組むときに注意したいこと。 儲かる機能をマイクロサービス化する マイクロサービスの最大の目標は「サービス化された機能のリリースサイクルを、その機能を管理するチームが独自に決定できるようにする」ことです。つまり、システム内の他の機能や他システムとの調整をしないで、いつでも好きなようにリリース可能であることが大事です。もちろん、日中に。 それは何のためかというと「機能をどんどん改善して儲けたい」からです。これまでは、儲かる機能を改善をしようとしても、その他の機能や他システムとの調整や影響範囲調査やリグレッションテストに時間がかかってリリーススピードをあげることができませんでした。この問題が解決できればウハウハできるはずです。 マイクロサービスのサービス分割点について聞かれることが多いですが、それは「ビジネス部門が『早くリリース

タイトルは煽りです。某勉強会向けに作成した資料ですが許可を得て掲載します。 2001年アジャイル、2006年クラウド、2009年DevOps、2014年マイクロサービスという一覧のトレンドを解説しつつ、最後は「日本のエンプラITはついて行けていないよ」という話。1時間ぐらいで話せますので、自社のことを考えて残念な気持ちになりたいというドM気質のエンプラ企業の方はご連絡をお待ちしております。 ハイライトは以下のページですかね。 合わせて読みたい：事業会社におけるマイクロサービス化について

「アジャイルがダメだと思う7つの理由」をエントリしてから一週間が経ちました。まさかPublickeyにまとめが載るとは思いませんでしたよ。 内幕を正直に書くと、あの日の昼に「アジャイルも普及してきて妙に執着する人が増えたよね」と茶飲み話していており、それを「受託開発に真面目に取り組むマネージャーが、知り合いでアジャイルにハマった人に久しぶりに出会って『時代はアジャイル』と熱くねちねちと語られているうちに、どうにも納得できなくてキレた」という設定で書いたものです。刺激的な表現もあってお騒がせしました。 反応していただいたBlogは「アジャイルがダメだと思う7つの理由」に追記してあります。その他の反応ははてブでも見てもらえればと思います。 職業アジャイラーの皆様からは同意と反論が混ざった反応をいただいております。ご意見がある方は引き続きBlogで書いて頂ければ幸いです。あのエントリは仮想人格が

1.全体スケジュールにコミットできない アジャイルはタイムボックス型（一定期間で棚卸しをして、それを繰り返す）のマネジメントをする。だから、全体としての計画は立てられない。「だって、最初に全ての機能を洗い出せないでしょ」というのは分かる、分かるけど全体の計画は立てないといけない。経営者は顧客やVCと全体の計画にコミットしなきゃいけないんだ。そのときに「やってみなきゃ分からない」なんて言えるわけでない。 てか「やってみなきゃ分からない」なんてことは誰でも知っているんだよ。でもさ、それを言わぬが花。大人なんだからコミットメントをしないといけないんだよ。そして、その達成ためには、あらゆる手段を尽くすのです。 2.アーキテクチャ上の無駄が生じる ソフトウェアの構造や構成は工程が進むほどに修正しにくくなり、ずっと残る。だから、アーキテクチャ設計は慎重に全体を考えながらやらなきゃいけない。でも、アジャ

昨年の12月からブログを書いていませんでしたね。こんにちは、JJUG会長の鈴木雄介です。2017/5/20（土）に20回目となるJJUG CCC 2017 Springを開催しました。 まずは、参加者、講演者、スポンサー各社、ボランティアスタッフ、そして幹事のみなさま、参加ありがとうございました、そして、お疲れ様でした。 参加者は1034名（申込1874名）となり、過去最高を記録しました。20回目で1000人越えという大きな区切りを向かえることができました。 ともかく混雑してましたね。満席で部屋に入れない、部屋間の移動が大変、懇親会が満員電車などなど。我々としても、あの会場で1000人越えは厳しいな、と感じています。 結果「会場が狭い」「混雑しすぎ」という意見はメールやSNSを問わずにいただいています。はい、おっしゃるとおり。 そして、それに対して私も含めて感情的な反応が出てしまったことを

日本Javaユーザーグループの会長 鈴木です。2016年12月3日（土）にJJUG CCC 2016 Fallを開催しました。事前申し込み1525名、当日参加905名と記録更新です。 ベルサール新宿グランドにも慣れてきたのと、今回は貸し切りだったので大きな混乱はなかったかな、と思います。ただ、トイレ待ちでセッションに間に合わない、といった声もあるみたいなので、休憩時間の延長なども考えたいと思います。「キャパの限界」という意見も承知していますが、様々な事情からもうちょっと同じ会場で頑張ろうと思います（たぶん）。 また、参加アンケートもありがとうございます。次回に活かしたいと思います。まだ書いていないよ、という方はアンケートフォームからお願いします（ページが多くてごめんなさい）。 JJUGを支える数字の話 当日は部屋担当などでのんびり過ごしていたのですが、懇親会LTで枠が空きそうだったので、あ

Sun MicrosystemsがOracleに買収されたのが2009年ですから、あれから7年が経ちました。 2013年、Javaは大人になったはずだった 僕は2013年に「イマドキのJavaとORACLEについて - arclamp」という記事をアップし、次のように書きました。 そんなわけで「ORACLEはJavaにコミットしているのか？」という質問が無意味なぐらい、ORACLEはJava技術だけではなく、Javaユーザーの方を向いているのです。 もちろん、ORACLEは（SUNに比べて）イノベーションが足りないとかスピード感がないとか批判もできるのですが、これだけエンタープライズのユーザーが増えた中では、Javaの後方互換性を保ちつつ、着実に進化していく、つまりは引き続き安心してJavaを使うことができるというのは大きな価値でしょう。 そう、Javaは本当の意味でオトナになったのかもし

初めて単独主催の勉強会をしました。ワークショップなので後半の1時間はディスカッションにしたのですが40人のわりには、それなりに面白い話ができた気がしています。資料とワークの結果、あとTogetterは以下から。 togetter.com 今回のプレゼンは純粋な「プロジェクトマネジメント論としてのウォーターフォールとアジャイルの違い」に絞った話をしたので、後半のワークが現実的な話になって面白かったです。話をしたのは以下のようなことです（資料の後半に細かいメモ書きがあります）。 そもそもウォータフォールは必要なのか？ とはいえ、ウォータフォールを採用しなくてはならない状況は？ なぜ、アジャイルを採用できないのか？ チームは重要だけど、どういうメンバーがいいのか？ アジャイルとはいえPM的な人が必要になることってあるよね？ アジャイルの立ち上げってどうするのがいいの？ 偶然、牛尾さんの 私は間違

2015/11/28（土）にJJUG CCC 2015 Fallをベルサール新宿グランドにて開催しました。 セッション30個、ハンズオン2個、ブース4社、スポンサー11社という規模になり、参加677名（登録1129名）という結果でした。ご参加いただいた皆様、セッションをしていただいたスピーカーの皆様、セッションならびにブーススポンサーの皆様、それからボランティアも含めて運営スタッフの皆様、本当にありがとうごさいました。 今回のCCCは幹事会メンバーが増えてから3回目、いろんなトライをして、上手くいったり、いかなかったり、大変に学びの多い会となりました。ご迷惑をお掛けした点があれば大変申し訳なく思います。KPTもたくさん出ていますので、次回に活かしたいと思います。良い点にせよ、悪い点にせよ、フィードバックをしたい!という方はお近くの幹事メンバーなり@JJUGまでご連絡ください。JJUGの健全