アジャイルやマイクロサービスを阻む「今までのやり方」 - arclamp
デブサミ2023夏でスポンサー枠を取って「見えない壁を越えよう！アジャイルやマイクロサービスを阻む「今までのやり方」」という講演をしてきました。資料はこちら。 「アジャイルやマイクロサービス」という「これからのやり方」に取り組む時、苦労するのは「今までのやり方」とのギャップです。これは「ウォーターフォールやモノリス」との手法的な違いというよりも、その裏側にある組織やITの仕組み、さらには文化に起因するものです。 なぜなら、今までは「安定して効率的に対応し続ける」ことが正解であり、そのために仕組みを作り上げてきたからです。このような「今までの組織やITの仕組み」のままで、ただ単に「これからのやり方」に取り組んでも失敗してしまうのです。 「今まで」と「これから」のギャップ 失敗1：半島型 新しい手法を試すにあたり、これまでの仕組みとは意図的の距離を置く必要があります。そうしないと、これまでの仕
アジャイルで「偉い人」はどう振る舞うべきか - arclamp
アジャイルを展開していくうえで、現場の開発チームがどう振る舞えばいいかは具体的なテクニックがあるのですが、「偉い人」がどう振る舞うべきかについての情報が少ない気がしたので整理します。なお、僕の元ツイートはこちらからの一連です。 アジャイルを推進している偉い人の中にはスプリントレビューに出るなど、マイクロマネジメントになりがちな人がいる。理由を聞いたら「成果物が、普通に考えたらそうならないでしょ、みたいなものを作るから目を離せない」という。進言したのは「それはチームに考えさせてないからですよ」（続— 鈴木雄介/Yusuke SUZUKI (@yusuke_arclamp) 2023年2月4日 前提 偉い人、とは 偉い人は関わりすぎてはいけない なぜ、チームは普通に考えないのか 偉い人が関わらないのもダメ 偉い人は適切に関わる 追記 前提 この議論において「そもそも、偉い人やPOやエンジニアに
作業ではなく、仕事をせよ - arclamp
この記事はグロースエクスパートナーズ Advent Calendar 2022の11日目です。 （補足追記：この記事は、一緒に働いている／働くことになる若い後輩たちへのメッセージです） 毎年、メンバーからお題をもらっているのですが「一緒に仕事する相手がこうだったら教えがいがある・やりやすいなと思う言動について書いてほしい」ということなので、僕のキャリア（もうちょっとで四半世紀...）の中で学んできたことも含めて、整理してみます。 心構え：作業ではなく、仕事をせよ まず、一緒に仕事をする上でお願いしたいのは「作業ではなく、仕事をしてほしい」ということです。ここでいう仕事と作業の定義は以下の通りです。 仕事というのは「ある目的を達成するための行動」 作業というのは「ある計画や手順のもとにおこなう行動」 仕事は作業を含んでいます。目的を達成する行動全般が「仕事」であり、仕事の中で具体的な手順を実
日本企業にアジャイルを導入して考えたこと #easg - arclamp
2016年11月18日に行われたエンタープライズアジャイル勉強会11月セミナーにて「ユーザー企業へのアジャイル導入四苦八苦」という講演をさせてもらいました。資料は後段に。 エンタープライズアジャイルとは 「エンタープライズアジャイル」の定義は曖昧です。いわゆるエンタープライズ業界でもアジャイルをやっていこう、という方向性を合意しつつ、そのディテールは現場ごとに異なります。 弊社はSIerなので、別顧客で3つの事例を紹介しています。もちろん内容は異なりますが、いずれも以下のような条件になります。 顧客は日本企業で社歴が数十年以上 システムはいわゆるSoE領域（間接的にでも売上に寄与する） 10人ぐらいのチームが継続的に維持される規模 こうした案件を通じた学びはフィードバックサイクル、プロダクトオーナー、アーキテクチャの三点です。 フィードバックサイクル 企業システムではリリースサイクルを「3
アーキテクチャ設計に品質特性を使おう - arclamp
アーキテクチャ設計をするうえで重要なのは「利害関係者の合意を得る」ことです。利害関係者全員の要件が全て理解できても、それぞれの要件には必ずトレードオフが存在します。すべて完ぺきに満たすことは不可能なので、トレードオフをバランスよく判断して利害関係者に納得してもらうのがアーキテクトの腕の見せ所です。 このトレードオフを上手に行うために、そのシステムに求められる品質特性を明示し、コミュニケーションの基礎とする必要があります。ざっくりステップを説明すると、以下のようになるでしょうか。 利害関係者にインタビューをして重視しているポイントを聞き出す そのポイントからシステムに求められる品質特性を整理する 整理された品質特性を元に、実際のアーキテクチャの設計を行う 設計されたアーキテクチャを品質特性に照らし合わせて評価を行う 品質特性というのは色々なところで定義がありますが、経産省が公開している「情報
チケット駆動開発で作業管理はしないほうがいい - arclamp
先日、2013/3/23（土）に弊社でチケット駆動と開発環境に関するイベントを開催しました。リンク先には資料も上がっていますので参照ください（※アトラシアン製品関連のイベントです）。 基調講演にはチケット駆動開発を推進されている関西XPUGのあきぴーさんをお招きして「チケット駆動開発をパターン言語で読み解く」という話をしていただき、最終枠ではパネルディスカッションをしました。 チケット駆動開発とウォーターフォール パネルディスカッションでは、僕が「チケット駆動開発を作業計画に使うのは難しく、WBSとの併用が現実的」と話し、あきぴーさんが「作業計画をチケット駆動開発で回していくには」というノウハウを紹介されていました。 この違いは僕がウォーターフォール的な新規案件を、あきぴーさんがアジャイル的な開発/保守運用案件を前提にしているためです。 僕自身はBTS（Bug Tracking Syste
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
おじさんにも分かるITトレンド説明と日本のエンプラITの限界 - arclamp