原田騎郎のレビュー一覧
-
-
-
Posted by ブクログ
近年のソフトウェア開発における組織のあるべき姿をシンプルに解説した良書。
4つのチームと3つのインタラクションモードという切り分け方は、実際の業務においても納得感があった。
一方で、このプラクティスを適用できる段階・できない段階の組織というものはそれぞれありそう。
本書に登場する単語は独特なものばかりで、概念を知らない人には伝わりづらい部分がある。
とはいえ、難解な概念は少なく、昨今の組織戦略の文脈では多く登場するのもあって、理解と咀嚼に時間を割く価値はあるなと感じた。
コミュニケーションパスの制限による開発速度の向上は実感としても感じるものがあるが、チーム間のコミュニケーションによって生まれていた何らかが生まれづらくなる懸念があるのではないかと感じた。
そういった部分を俯瞰的に見る役目はイネイブリングチームか、あるいはEM的な立場の人になるんだろうか。 -
-
-
-
-
-
Posted by ブクログ
エクストリームプログラミングのラクティスをうまく活用し、顧客と開発者に喜びを実現できている。
人の成長スキルアップ(=スケールアップ)は容易ではない。
ペアプロをすることでスキルアップを助けるとともに、チームの人数拡大(=スケールアウト)ができる。
開発者はテーマから離れること(=スケールイン)でドメイン知識を忘れてしまう(スケールダウン)が、
自動テストを整備しておくことで、専任者がいなくなってもフォロー可能になる。
これによって変化の激しいビジネス環境に柔軟に対応できる。
エクストリームプログラミングの重要性を改めて認識した。
見積もりをコミットにして、見積もった人にやりきるのがプロの仕事だと迫っているようじゃ、見積もりの水増しが横行するだけだし、いつまでたっても開発に必要なデータが得られず、正確な計画が立てられない。
だから、開発者は懸命に取り組んだがうまくいかなかったことを報告し、その結果に応じて次の計画をどうするか顧客と一緒に考える。
すべてがおとぎ話のようにうまくいったように描かれているが、実際の取り組みは苦難の連続だったようだ。そしていまだに、多くの組織に共通の問題に対して明確な答えを出せずにいる部分もある。そんな中でもなんとか成果を果たし、喜びに支えられているようだ。
筆者のような高みにはたどり着けないかもしれないが、こんな経験を読み返し、なんども聞かせてもらいながら、同じような高みを目指して喜びに変えていきたい。
そんな清々しいモチベーションを感じさせる、まとめ、エピローグが素晴らしかった。 -
Posted by ブクログ
従業員、顧客、そして自分自身の全て人が日々の仕事に喜びを感じる会社を作った人が自分の会社の活動・設備・運営について教えてくれる本です。
なのですが、見る人からみたら全力でAgileをやっている会社が自分たちのプラクティスを割と詳細に教えてくれる本です。
Agile関連の本を色々読んでみたけど具体的にどうしたらいいんだろう、ってモヤモヤしている人には物凄くおすすめです。
「これってXPのことだよね」とか「これってリーンの話だ」など思い当たる箇所が随所に出てきます。
「Agileって何？」という人には、1つの会社の中で文化がどのように醸成されていくのか、それを守るにはどういったことが必要なのかなどの学びが得られるのではないでしょうか。
俺もメンローツアー行きたい。 -
-
-
-
Posted by ブクログ
ネタバレアメリカのソフトウェア開発会社「メンロー・イノベーション社」、そのＣＥＯであり共同創業者である著者が語る、喜びが感じられる職場たる同社の働き方。
個室やパーテーションがなく、レイアウト変更が自由、ペアを入れ替えながらの作業、一週の５日間の日別の作業承認ボードに貼られた計画おりがみとドットシールによる全体の作業内容と進捗状況の見える化、毎朝10時の全員によるデイリースタンドアップ、おーいメンロー！ですぐできる全体会議、顧客を巻き込んだショウ＆テル。
本書では強調されていないが、アジャイルソフトウェア開発手法の適用ということで、訳者にはアジャイルコーチなどの肩書の方が並んでいるのだろう。ただし、単にソフトウェア開発企業にとどまることなく、その他業種の働き方に対しても十分に刺激になる。
働き手として顧客リクエストに必要なスキルを学ぶことが尊重され、助けたり教えたりしながらプライベートの問題もサポートしあえる仲間がいて、時間・コスト・機能に見合った無理のない仕事があり、仕事の成果を喜んでくれる顧客やユーザーがいる。確かに魅力的な職場だと驚かされるし、それを実現している会社が現実にあることが嬉しくなる。
17-39 -
-
-
Posted by ブクログ
# 多方面からプロダクトに立ち向かうための、戦略的組織論
## 面白かったところ
- 組織とソフトウェアアーキテクチャは密接に関わり合っており、人こそがソフトウェアであり組織を良くも悪くもすることがわかった
- 自分が管轄外のプロダクトには適切な境界線（interface）を切って、異なる概念を持ち込まない・持ち込ませない制約があるとイイことを改めて学べた点
## 微妙だったところ
- 引用がとても多く、著者自身の熱い思いがあまりなかった点。チームトポロジーのフレームワークはすごいしやってみる価値はあるんだけど、イマイチ引き込まれれる何かがなかった。
## 感想
現場での課題図書として上がっていた一冊。なにもないところから著者の真意を汲み取ることは難しいだろうなとは思いつつ、現場での組織構成を擬えて見るとかなりイメージが進んだ。
人間一人の認知負荷にも限界があり、チームのそれにも限界がある。この前提を踏まえたうえで、自チームで担当すること・しないことのドメイン境界を切ってinterfaceでハーネスをかける。
「〇〇チームは▲▲機能の担当」という境界を Package by Featureで区切る。多機能とやり取りするときは必ずInterfaceを切って、他チームとコミュニケーションを図る。
なるほど。今やっている僕らの軌跡はこの本からやってきたんだと腑に落ちた。 -
-
Posted by ブクログ
チームトポロジー 価値あるソフトウェアをすばやく届ける適応型組織設計
エンジニア、コンサルタントのマシュー・スケルトン氏、マニュエル・パイス氏の著書です。ソフトウェアの開発、運用組織に関する書籍になります。
【本書で学べること・考えること】
- コンウェイの法則
- 一般的な組織構造がソフトウェアに与える影響
- 組織図とコミュニケーションギャップ
- 認知負荷
- 逆コンウェイ戦略
- チームファースト思考
- チームのアンチパターン
- 4つの基本的なチームタイプ
- 3つのチームインタラクションモード
- 組織構造のプラクティス
読んでみての感想です。
この本のベースは、「システムを設計する組織は、その構造をそっくりまねた構造の設計を生み出してしまう」というコンウェイの法則をベースにしています。
組織構造をあるべきアーキテクチャに合わせて変化させることで、ソフトウェアのアーキテクチャを最適化するという思想です。
コンウェイの法則、言われてみればですが目から鱗です。
基本となるストリームアラインドチーム（DevOps）を中心に基盤を支えるプラットフォームチーム、補助するイネイブリングチーム、専門的なサブシステムを提供するコンプリケイテッド・サブシステムチームという4つの基本的なチームが、コラボレーション、X-as-a-Service、ファシリテーションの3つのインタラクションので関わり合う構造のプラクティスを紹介しています。
自社サービスの会社ではない場合、完全に適用することはできないですが、組織の構造、認知負荷、チームの定義、タックマンモデルなど、チームに関する知見は大いに参考になると思います。
マネージャーやマネージメントを目指す方には、是非、一読してほしい良書です。 -
