デブサミ2023夏でスポンサー枠を取って「見えない壁を越えよう！アジャイルやマイクロサービスを阻む「今までのやり方」」という講演をしてきました。資料はこちら。 「アジャイルやマイクロサービス」という「これからのやり方」に取り組む時、苦労するのは「今までのやり方」とのギャップです。これは「ウォーターフォールやモノリス」との手法的な違いというよりも、その裏側にある組織やITの仕組み、さらには文化に起因するものです。 なぜなら、今までは「安定して効率的に対応し続ける」ことが正解であり、そのために仕組みを作り上げてきたからです。このような「今までの組織やITの仕組み」のままで、ただ単に「これからのやり方」に取り組んでも失敗してしまうのです。 「今まで」と「これから」のギャップ 失敗1：半島型 新しい手法を試すにあたり、これまでの仕組みとは意図的の距離を置く必要があります。そうしないと、これまでの仕

近年、DXの流れでアジャイルが注目されていますが、JTC（日本の伝統的な大企業）では、組織の問題でアジャイルチームがうまく機能しないことがあります。この問題を解決するために必要なことについて整理してみました。なお、 JTCとは「ウォーターフォール型のシステム開発が中心で、そのために部署の分割とルールが整備されており、文化にまでなっている会社」のことです。 はじめに なぜ、DXにアジャイルか？ アジャイルはタクシーか、電車か 素早さは優先順位の決定回数で決まる JTCでアジャイルをするときの課題 いかに優先順位を調整するか いかに決定するか JTCでアジャイルをするための取り組み いかに優先順位を調整するか いかに決定するか まとめ はじめに このエントリは、2023/1/27に開催されたアジャイル経営カンファレンスでの講演「ビジネスとITをリンクさせるアジャイルな組織のつくり方」の内容に補

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

この記事はグロースエクスパートナーズ Advent Calendar 2022の11日目です。 （補足追記：この記事は、一緒に働いている／働くことになる若い後輩たちへのメッセージです） 毎年、メンバーからお題をもらっているのですが「一緒に仕事する相手がこうだったら教えがいがある・やりやすいなと思う言動について書いてほしい」ということなので、僕のキャリア（もうちょっとで四半世紀...）の中で学んできたことも含めて、整理してみます。 心構え：作業ではなく、仕事をせよ まず、一緒に仕事をする上でお願いしたいのは「作業ではなく、仕事をしてほしい」ということです。ここでいう仕事と作業の定義は以下の通りです。 仕事というのは「ある目的を達成するための行動」 作業というのは「ある計画や手順のもとにおこなう行動」 仕事は作業を含んでいます。目的を達成する行動全般が「仕事」であり、仕事の中で具体的な手順を実

いまさらですが、DevOpsとは何か、具体的には何に取り組むべきなのかについて整理しました。DevOpsとは、サービスの継続的な改善を実現するために、Dev自身がサービスの運用ができるよう、Opsは運用作業のツール化を進めていく取り組みです。そして、DevOpsエンジニアやSREなど、新たな役割への転換が求められます。 DevOps = 開発と運用の協業？ Velocity 2009というイベントで、写真共有サイトFlickrのエンジニアJohn Allspaw氏とPaul Hammon氏が「10+ Deploys Per Day: Dev and Ops Cooperation at Flickr」（ ビデオ / スライド ）という講演を行います。この講演ではWebサービスの運用における開発チームと運用チームの協業が語られています。両者が同じ目線に立つためにツールを活用するとともに、カル

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

ようやく裁判の結果が出ました。結果としてフェアユースが認められたのはよかったのですが、Googleが勝訴したということは素直に喜べないので、その理由を書いておきます。 関連ニュースは、こういったところから。 約1兆円の賠償金を巡るGoogleとOracleの10年にわたる訴訟が決着、「APIのコピー」は結局違法なのか？ - GIGAZINE Google、オラクルの著作権侵害せず 米最高裁判決: 日本経済新聞 グーグル、米最高裁でオラクルに勝訴--「Android」Javaコード訴訟で - CNET Japan 経緯 では、経緯について時系列に沿って整理していきます。推定可能な事実に基づきますが、一部、妄想も含まれています。 2005年 Google（広告収入増やすには無償で改変自由なスマホOSが重要になるはず。普及させるなら開発者の多いJavaベースだよな。でも、クラスライブラリ改変しな

エモいことで有名なDevLOVEの10周年記念イベントDevLOVE X 〜 それぞれの10年、これからの10年 〜で「エンタープライズ、アーキテクチャ、アジャイルのこれから」という講演をしてきました。資料は以下。 Togetter - #DevLOVEX 鈴木 雄介「エンタープライズ、アーキテクチャ、アジャイルのこれから」 #DevLOVEXC Day2-7C 10年間の振り返り 10年間の振り返りとして10年前に書いた記事や講演資料をみたのですが、わりと一貫していて安心しました。たとえばクラウドを超えた先の企業システム像 20091008 JJUG CCC では、 ・インターフェースによる分業 ーマルチパラダイム ・個々のシチュエーションでは1つの最適な道具（パラダイム） って、まさにマイクロサービスのことだし。日経SYSTEMS 2009年2月号の特集１「10年後も通用するスキル」で

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

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

2016/11/26（土）に行われたプロダクトオーナー祭り 2016で、プラチナスポンサーとして「プロダクトオーナーは育成できるのか？」という話をさせていただきました。資料は後段に。 なぜSIerがPOを語るのか 弊社は受託開発を中心とするシステム開発企業、いわゆるSIerです。資料も「SIerとして」という立場から書いています。なので、最初に「なぜSIerがプロダクトオーナーを語るのか」というのを説明したいと思います。 そもそも弊社は優先的に「大企業においてプロダクト開発的なプライム案件」を中心に獲得をしています。顧客企業はヘルスケア、通信、クレジットカード、データサービス、出版などの大手企業で、案件チームごとに10～15名ぐらいのメンバーが稼働し続けているような形態です。いわゆる保守というよりは、もっと新機能開発や改善を中心にしています。 弊社が、こうした案件にこだわる理由は、 継続前

思ってたより衝撃的だったのでブログを書きます。 顧客ＤＢ開発に関与＝知識悪用し防止措置解除—派遣ＳＥ、逮捕状請求へ・警視庁 - WSJ 外部業者から派遣されているシステムエンジニア（ＳＥ）の男が、情報が流出したデータベース（ＤＢ）のシステム開発に関与していたことが１７日、捜査関係者への取材で分かった。 警視庁は男が専門知識を悪用し、ＤＢの流出防止プログラムを解除して顧客情報を記憶媒体に複製したことを確認。 これが本当だとすると各所が大騒ぎにならないといけません。ただ、「すわ、セキュリティコンサルに依頼だ！」では、まったく解決になりません。むしろ、振り返って「自社のITマネジメントってどうなっている」を正しく理解した上で「で、これからどうしていく？」ということを考えないといけません。 この事件はセキュリティの問題ではなく、ITマネジメントの問題なのです。 まず「流出防止プログラムがあった」こ