アジャイルにすると開発者が好き放題開発するんでしょ?よく聞くフレーズが並んでいたので、今度何かで使うことにします。学習するチームと不確実性マネジメント基本的なアジャイルの進め方はこの辺で一応書いています。Agileの観点でアジャイルの進め方を見直してみます。不確実性ざっくり3分割こんな感じに3つに大別されます。エンジニアリングは「曖昧さ」を減らし、「具体性・明確さ」を増やす行為です。上の不確実性をすべて継続的に削減していくことが、エンジニアリングの本質となります。方法不確実性この不確実性を一言で表現すれば、いつ終わるかわからない不安です。その原因は、システムに使用する技術に関する理解の浅さだったり、コミュニケーションうまくいかないことであったり、様々です。いつ終わるかわかりませんが、それでもスケジュール・見積もりは建てなければなりません。この不確実性を解消していくには、スケジュールとその不確実性を可視化していくことです。詳しいやり方は本書に譲りますが、こんなものが紹介されていました。CCPMアプローチ多点見積もり相対見積もり(Tシャツ、プランニングポーカー)どれも、スケジュールの不確実性をなるべく考慮して、プロジェクトが不確実なものだという考えに基づいているように感じます。スケジュールをノルマではなく、見積もりと考え直す必要性があるように感じます。作っているもの、やっていることが本当にあっているかという不安です。これに立ち向かうには、すばやくリリースを行い、テンポよくフィードバックをもらい、方向性を修正し続けることです。本の中ではユーザーストーリーが紹介されていますが、機能単位で小さく作っていきます。ときに非効率な作り方に見えるかもしれません。開発の効率よりも、目的不確実性に立ち向かう手段だと考えれば、納得してやれるはずです。一つ面白かったのは、リーンキャンバスです。普段からプロダクトの価値を語るときにはエレベーターピッチを作れと言われていますが、その他にもリーンキャンバスというフレームワークがあるのですね。リーンキャンバステンプレートこれはなんかサマになるので、今後意識して作ってみたいと思います。通信不確実性この手の話をしていると、だいたいレトロスペクティブの話になります。現状整理:今どうなっているか、事実を並べる良かった探し:無理やり良かったことを言い合う問題の洗い出し:問題と思われる点を言い合う。さまざまな観点で問題の深掘り:重要な問題について、原因を探る。対策の決定:実行可能な対策を決定。全員で実行できることがポイントやっぱりインセプションデッキって大事なんですね。わからないことは不安です。わかるように状況を整理して、どうしたら解決できるのかに目を向けることができるように、振り返りを行っていきます。技術組織の力学とアーキテクチャさて、この本で一番気になっていた技術組織に関する話です。組織が健全かどうかは生産性で語られることが多いです。一般的には生産性は、投下した労働に対する収益ですが、エンジニアの組織ではガルブレイスの情報処理モデルである程度説明することができます。不確実性は下記のように当てはめることができるかもしれません。組織の情報処理能力を低下させる要因になっており、これはコミュニケーションコストとみることができます。(少なくともこのモデルでは)コミュニケーションコストがエンジニア組織の生産性を低下させる要因ということです。実際には、コミュニケーションだけが原因ではないとは思いますが、生産性改善していく具体策としては大体こんな感じです。エンジニアとしては、そもそも無駄なコミュニケーションはしたくないので、なるべくコミュニケーションを減らす方向に考えているところは、納得です。権限移譲に関しては、飴と鞭、義務と権利、で権利の明文化と報告責任の付帯が重要です。ルールのない自由なんて、お互い怖くてなんもできないですよ。その他、組織内の情報の見える化は大事ですねって話です。いらないコミュニケーションは、こっちからオープンにふるまうことで解決していきましょ。技術的負債にについては、これはなかなか根が深い問題で、一般的にはなかなか理解されない問題です。技術的負債を見えるようにすることが第一歩、その先に負債による開発速度の低下を定量評価することしか進む道はないのかなと、個人的には思っています。説明できないっすもん。その他、マイクロサービスとかはそのうちちゃんと勉強するんで、そこで改めて具体的に見ていきたいと思います。感想おそらく、現代の多くのビジネスマンが抱える不安の根源とその対策について、エンジニアリングという切り口で解説した本です。世の中の仕事の大半はよくわからない不確実なものの塊です。その不確実性を削減して問題解決まで持っていくにはどうすればよいか、そのための組織はどうあるべきか、といったことが細かく書かれていた印象です。論理は難しいですが、納得感もあり、非常に共感する内容になっていました。エンジニアリングと言う切り口で組織づくり、マネジメントは確立した答えがない分、どこの組織でも苦手な人が多い印象です。(あるいは当事者はできてるつもりで、現場からは悲鳴が上がっているかも?)アジャイルという文脈では、正しいアジャイルの考え方を理解した上で、アジャイルを実践していくことは、開発だけでなく組織の成長に繋がります。マネジメントを行う立場の方は、騙されたと思ってぜひ本書を読んでほしいです。組織の中で各役職でどうふるまうべきかについては、こちらの本も是非ご参考ください。不確実性に向き合う思考と組織のリファクタリングTweet関連記事2020-01-25できることとできないことを整理したメモ最近なにかと自分のキャリアを振り返ったりすることが多いんで...2019-10-18ソフトウェア開発の今を学ぶ一応エンジニアの端くれなので、読んでおこうかという気持ちで...2019-09-26Jenkinsを使ってCI・CD入門してみるCI・CDしない奴は人間じゃないみたいな雰囲気がにじみ出ている...2019-08-30仮説検証型アジャイル開発とはなにかちょっと前にこちらの記事が話題になっていました。(1)ほしい物リスト買ってあげると中の人が喜びますはてなブログをはじめよう!nogawanogawaさんは、はてなブログを使っています。ブログを報告するスターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。