勘と経験と読経

略すとKKD。ソフトウェア開発やITプロジェクトマネジメントに関するあれこれ。

More Effective Agileの前半部分を読んだ #デッドライン読書会

読むのが骨な(積みがちな)技術書やビジネス書を取り上げて2週間の読書期限を課して読んでアウトプットする仮想読書会「デッドライン読書会」の第16回。今回はSteve McConnell氏の「More Effective Agile」前半部分(12章まで)がノルマである。予測にたがわず、有用な本であることに疑いはない。

ソフトウェア開発を「うまくやる」ための本

のっけから、有用な匂いがビシバシ伝わってくる。俺たちのMcConnell氏が帰ってきた!

アジャイル開発に関するほとんどの書籍はエバンジェリストによって書かれている。エバンジェリストは特定のアジャイルラクティスを提唱しているか、アジャイル全体を奨励している。筆者はアジャイルエバンジェリストではない。筆者は「うまくいくもの」の提唱者であり、「なんの根拠もなく大袈裟な約束をするもの」への反対者である。本書では、意識高い活動としてアジャイルを扱うのではなく、管理的なプラクティスと技術的なプラクティスの集まりとして扱う。ここで扱うプラクティスは、その効果や相互作用をビジネス用語や技術用語で理解できるものである。
More Effective Agile “ソフトウェアリーダー”になるための28の道標 「第1章 はじめに」

ちなみにこの後、「第3章 複雑さと不確実さという課題に対処する」にて、なぜアジャイルなのかについても明快に説明される。流行っているからでも、VUCAの時代だからでもなく、明確にアジャイルラクティスに組織が投資したほうが良いという説明がされているのだ。というわけで、それ以降本書は批判的な立場を崩すことなく、アジャイルラクティスの良い使い方についてアドバイスするという体裁となっている。

35年かそれ以上にわたってソフトウェア業界に携わってきた中で、一番の難題は、「コード&フィックス開発」を避けることだった。コード&フィックス開発とは、事前の見直しや計画を立てずにコードを書き、そのコードが動くまでデバッグする手法のことである(中略)。アジャイル開発には、見るからに短期集中型でコード中心であるために、チームがアジャイル開発のプラクティスを実践しているのか、それともコード&フィックスを行っているのかますます見分けがつかなくなる、という課題がある(中略)。より効果的なアジャイルのミッションの1つは、アジャイル劇場を防ぐことである。アジャイル劇場とは、チームがアジャイルという化粧でコード&フィックスを覆い隠すことを指す。
More Effective Agile “ソフトウェアリーダー”になるための28の道標「第4章 より効果的なアジャイルの始まり:スクラム

あと、10章で既存の大規模アジャイル開発のフレームワークをバッサリ批判しているあたり、非常に痛快。

まだ完読していないけれども、おすすめの読み方は次の通り

  • まず監訳者あとがきを読んで、本書の業界的な位置付けや、ねらいについて俯瞰する
  • 1章と2章を読む
  • 巻末の「28の基本原則のまとめ」を読む
  • 残りを読む

マコネルと言えば……

有名なのは次の2冊だと思う。ソフトウェア開発における見積もりという行為には様々な批判があると思うけれども「ソフトウェア見積り」はいまだに有用度は高いと思うので、未読であれば強くおすすめする。「Code Complete」は好きな本だけれども、かなり古さを感じるので今から読むのであればよく注意したほうが良い(古書を買うか、Kindleでセールになっている時に買い、古いと感じたところは飛ばし読みするのが良いだろう)。

なお、本書を読んで知ったのだけれども、Construxのホワイトペーパーその他で本書以外の様々なマコネルの文書が読めるようだ。これらについても少しずつ読んでいきたいなぁ。
www.construx.com

リモートファシリテーターのポケットガイド読んだ

The Remote Facilitator's Pocket Guideという本が発売されてて読んだら面白かったので紹介する記事。本自体は短いのでさらっと読めます(個人的なな感想)。私はオライリーのサブスクをGoogle翻訳して読んだ。

本書について

ざっくり感想

ある程度は、この数か月の在宅勤務シフトなどで学習済の事柄であったが改めて俯瞰して見ると学びが多かった。あと、本記事では紹介していないが、セッションで利用するプレゼンテーション(筆者たちはGoogleスライドをよく活用しているようだ)のイメージが提示されていて、いくつかはさっそく取り込んで活用している。というわけで、なかなか現代にとっては良い本だと思う。きっと似たような本はこれからいっぱい出版されるんだろうな~

リモートファシリテーターとは

  • 本質的には通常のファシリテーターと変わりない。参加者が貢献して協力できるようにする条件を作成することに責任を負う役割である。

リモートファシリテーターのための6つの原則

原則1:平等な機会の創出(Create Equal Opportunity)

  • できれば全員がリモートで参加する
  • フルリモートセッションが出来ない場合は、会議室で誰かがリモートメンバーの仲介人になる
  • 会議の初めに技術的なチェックを行う
  • 仮想ホワイトボード/仮想付箋として機能する補助ツールを準備しておく
  • グループで意思決定を行うための準備(投票など)を準備しておく
  • 資料を読む時間を作る(セッション開始時の冒頭5分など)
  • 観察し、セッションに参加できていない人をフォローする

原則2:フローを有効にする(Enable Flow)

  • 会議の流れに介入して、円滑に目的地に到達できるように促す
  • アジェンダとセッションルールを最初に示す
  • 共有編集できるビジュアルドキュメントを活用する
  • 参加者が自分の感情等を表現できるツールを用意する(休憩したい、離席する、次のテーマに移りたい)
  • 現在地を共有する(スライド5を見てください/質問がある場合はスライド10に追加してください)

原則3: ビジュアルによるガイド(Guide With Visuals)

  • ビジュアルドキュメントを活用する(ホワイトボードの代替として)
  • 明確な指示をして認知負荷を下げる(会議の手順などを図示する)
  • 会議の約束事を明示する
  • 結論を視覚的に記録する(全ての会話を覚え続けなくてよくする)

原則4:つながりを育む(Nurture Connection)

  • チェックインの質問で会議を始める
  • 小グループに分割する
  • お手本になる(ファシリテーターの所作は皆に影響を与えやすい)
  • 状況についてよく観察する(食事はした?休憩はできている?タイムゾーンの差は考慮できてる?)
  • セッションを観察して、質問する(Aさん、喋っているようですが、ミュートになってますよー)
  • 退去を許可する(このテーマに意見の無い方はここで離脱してかまいません)

原則5:遊び心のある学習を可能にする(Enable Playful Learning)

  • 遊び心のあるマインドセットで参加できるアジェンダを作る
  • 賢い問いを発する
  • 楽しくて意味のあるビジュアルを使う
  • 音楽を活用する
  • 笑いを誘う

原則6:道具を使いこなす(Master Your Tools)

  • セッションも目的から始める(ツールに対して最適化してはいけない)
  • 事前準備重要
  • 必要であればピポットする
  • バックアップを準備する
  • セッションと成果物を分離する(セッション中に資料を美化したくなる衝動から離れるため)

2020年上半期に読んだ本まとめ

2020年1月~6月に読んだ本のまとめ。カウント対象は期間中に読み終わったものに限り、読みかけの本は対象外としている。あとコミック、漫画雑誌類もけっこう読んでいるのだけれども、これは除外。コミックDAYS利用中。

2020年上半期に読んだ本

  1. ビット・プレイヤー (ハヤカワ文庫SF)
  2. ホモ・デウス 上下合本版 テクノロジーとサピエンスの未来
  3. Genesis 一万年の午後 創元日本SFアンソロジー
  4. 笙野頼子三冠小説集 (河出文庫)
  5. アフターデジタル オフラインのない時代に生き残る
  6. Clean Agile: Back to Basics (Robert C. Martin Series) (English Edition)
  7. 中堅崩壊
  8. 天冥の標Ⅰ メニー・メニー・シープ(上)
  9. IT業界の病理学
  10. 天冥の標Ⅰ メニー・メニー・シープ(下)
  11. 天冥の標Ⅱ 救世群
  12. 東京の子 (角川書店単行本)
  13. バンクシー 壊れかけた世界に愛を
  14. 外資系コンサルの知的生産術~プロだけが知る「99の心得」~ (光文社新書)
  15. なんとかしたい! 「ベテラン社員」がイキイキ動き出すマネジメント (日本経済新聞出版)
  16. WIRED(ワイアード)VOL.34
  17. WIRED(ワイアード)VOL.35
  18. うつくしい繭
  19. 天冥の標Ⅲ アウレーリア一統
  20. ピーター・ティール 世界を手にした「反逆の起業家」の野望
  21. フィンテックエンジニア養成読本 Software Design plus
  22. 見るだけでわかる!ビジネス書図鑑
  23. 航路(上)
  24. 航路(下)
  25. 0秒リーダーシップ
  26. 自画像のゆくえ (光文社新書)
  27. 天冥の標Ⅳ 機械じかけの子息たち
  28. NEXT GENERATION GOVERNMENT 次世代ガバメント 小さくて大きい政府のつくり方 (日本経済新聞出版)
  29. すべての教育は「洗脳」である~21世紀の脱・学校論~ (光文社新書)
  30. AWS認定資格試験テキスト AWS認定 クラウドプラクティショナー
  31. Design It! ―プログラマーのためのアーキテクティング入門
  32. 猫楠 南方熊楠の生涯 (角川文庫)
  33. Think CIVILITY 「礼儀正しさ」こそ最強の生存戦略である
  34. 天冥の標Ⅴ 羊と猿と百掬の銀河
  35. チュートリアル (Kindle Single)
  36. 20 CONTACTS 消えない星々との短い接触 20 CONTACTS: A Series of Interviews with Indelible Stars (幻冬舎単行本)
  37. WIRED(ワイアード)VOL.36
  38. すごい論語
  39. トランスヒューマンガンマ線バースト童話集 (早川書房)
  40. PIXAR 〈ピクサー〉 世界一のアニメーション企業の今まで語られなかったお金の話
  41. 昆虫はすごい (光文社新書)
  42. みずほ銀行システム統合、苦闘の19年史 史上最大のITプロジェクト「3度目の正直」
  43. 戦略の世界史(上) 戦争・政治・ビジネス 戦略の世界史 戦争・政治・ビジネス (日本経済新聞出版)
  44. 嘘と正典
  45. 絵でわかる感染症 with もやしもん (KS絵でわかるシリーズ)
  46. 日本社会のしくみ 雇用・教育・福祉の歴史社会学 (講談社現代新書)
  47. Software Engineering at Google: Lessons Learned from Programming Over Time (English Edition)
  48. 第四次産業革命--ダボス会議が予測する未来 (日本経済新聞出版)
  49. 美しき愚かものたちのタブロー (文春e-book)
  50. MONUMENT あるいは自分自身の怪物 (ダッシュエックス文庫DIGITAL)
  51. 復活の日 (角川文庫)
  52. 死の淵を見た男 吉田昌郎と福島第一原発 (角川文庫)
  53. 人生がときめく片づけの魔法 改訂版
  54. medium 霊媒探偵城塚翡翠
  55. オイディプス王(ソポクレス) (岩波文庫)
  56. チーム・ジャーニー 逆境を越える、変化に強いチームをつくりあげるまで
  57. Agile Software Development with Distributed Teams: Staying Agile in a Global World (English Edition)
  58. グーグルが消える日
  59. 2020年6月30日にまたここで会おう 瀧本哲史伝説の東大講義 (星海社新書)
  60. 両利きの経営―「二兎を追う」戦略が未来を切り拓く
  61. 零號琴 (早川書房)
  62. THE TEAM 5つの法則 (NewsPicks Book)
  63. タイタン
  64. いかにして問題をとくか
  65. kotoba2020年夏号

文芸書のおすすめ(一般編)

少しだけSF成分が入っているけれども、「東京の子」をオススメしたい。

東京の子 (角川書店単行本)

東京の子 (角川書店単行本)

物語としてとても良かったのに加えて、いまこの本を読むと「来ることが無くなった世界線」感が興味深いだろう。オリンピックが予定通り行われた後の物語である。

東京オリンピックの熱狂は終わった。 これからみんな、搾取されて生きていくのかもしれない。 モラルも理想もすっからかんになったこの国だけど、 僕たちは自分の足で、毎日を駆け抜けていくんだ。
東京の子 (角川書店単行本)

文芸書のおすすめ(趣味のSF編)

話題となったのは昨年だけれども、やはりこの本がストーリー的にも、仕掛け的にも最高だった。ただしSF好きに加えて様々なSF作品やアニメ作品、文芸作品などに親しんでいないと楽しめないかもしれない。

零號琴 (早川書房)

零號琴 (早川書房)

ちなみに偶然だけれども本書を読む前に「ソポクレス オイディプス王 (岩波文庫)」を読んだので、さらに楽しめた。ギリシア悲劇の最高傑作すら取り込まれている。

教養書のおすすめ

問答無用でこれ。日本版ファクトフルネスだと思う。読んだ後だと世界の見方が変わる。後輩に勧められて読んだ本だけど本当に良かった。

あと「NEXT GENERATION GOVERNMENT 次世代ガバメント 小さくて大きい政府のつくり方 (日本経済新聞出版)」はすごい情報量が圧縮されていて圧巻。そして表現的にも「自作自演対談」という謎形式の記事が面白い(対談形式という形態で、すごくわかりやすいのだ)。

ビジネス書のおすすめ(マネジメント編)

ひねりは無いけれども、

は押さえておきたい本だと思う。有名な「イノベーションのジレンマ 増補改訂版 Harvard business school press」の後継となるような本である。ただし、かなり骨太。

ビジネス書のおすすめ(すぐ使える系)

マネージャーやリーダー的な立場の人に限定されるけれども、読んだ次の日から使えるという意味ではこの本が良かった。

THE TEAM 5つの法則 (NewsPicks Book)

THE TEAM 5つの法則 (NewsPicks Book)

人間が一人でできることは限られています。この世に存在するすべての人間が、他者と協働することで「自分一人ではできない何か」に取り組んでいます。「チーム」は、ビジネスパーソンは勿論、登校班で学校に行く小学生からゲートボール部で活動する高齢者まで、老若男女誰しもが関わるものです。
にもかかわらず、学校でも会社でも、チームづくりについて体系的に学ぶ機会はないと言っても過言ではありません。
THE TEAM 5つの法則 (NewsPicks Book)

という書き出しで始まる本書は、チームづくりについて方法論と根拠あわせて非常に良くまとまっていて有用度がとても高い。

技術書のおすすめ

まぁ、この本がお勧め。内容的にも素晴らしいが、前作「カイゼン・ジャーニー たった1人からはじめて、「越境」するチームをつくるまで」から格段に読みやすくなっている。著者の進化を感じられる。

本書の第一部、第二部に「直面する問題パターン」という一覧が提示されているのだが、とにかく日常の「あるある」が集約されているのだ。

あと、名著と言われていた「いかにして問題をとくか」は本当に素晴らしかった。ただし、だいぶ古い。1975年の数学の本だ。もちろん電子書籍もない。読み解くのは相当に難しいが、それでも大きな価値はありそう。この本はなんども読み返しそうな気がする。

この半期の振り返り

2020年上半期はいわゆるコロナ禍が発生した期間というわけで6ヶ月のうち約半分ほどは在宅勤務となっていた。

自分自身の読書環境としては

  • 日常生活の中でもっとも集中できる読書時間であった通勤時間が消滅
  • 公共図書館が閉鎖
  • ピーク時には書店も休業
  • 心理的にも(不安により)なんだか読書に集中できない

と、ネガティブ要因山積みだった。しかし途中で「いや、この機会に大量の積読をなんとかしよう」と奮起した結果、いつもの半期に比べて少し読書量は増えている。

下半期(7月〜)についても引き続き在宅率は高い見込み(ときどきは物理出社)である。さて次はどんな本が読めるだろうか。

『他者と働く』を読んで考えたこと #デッドライン読書会

対象を決めたら2週間で読み切り、アウトプットして、感想戦をするという読書会企画の第15回。今回の対象は『他者と働く』である。この本は一度読んでいたので再読になる。良い本なのだけれども、なんだろう、この違和感は。

どうしてわれわれは『他者と働く』のが下手なのか?

誰もがなんとなく、コミュニケーションによる課題感を感じている。なんとかしたい。というわけで、自分も様々な書籍などを読み漁ってきた。最近読んだだけでもこんなに・・・(しかも、思い出すのが面倒なだけで他にも山ほどある)

まぁ、わかっているのだ。結局のところ『他者と働く』方法をきちんと学んだことが無いから、そして何かを学べばもっとうまくやれるという期待を持ってしまうからなのだ。

人間が一人でできることは限られています。この世に存在するすべての人間が、他者と協働することで「自分一人ではできない何か」に取り組んでいます。「チーム」は、ビジネスパーソンは勿論、登校班で学校に行く小学生からゲートボール部で活動する高齢者まで、老若男女誰しもが関わるものです。
にもかかわらず、学校でも会社でも、チームづくりについて体系的に学ぶ機会はないと言っても過言ではありません。
THE TEAM 5つの法則 (NewsPicks Book)

(ちなみに「THE TEAM 5つの法則 (NewsPicks Book)」はコンパクトにノウハウが詰まっていて非常におすすめ)

THE TEAM 5つの法則 (NewsPicks Book)

THE TEAM 5つの法則 (NewsPicks Book)

というわけで沢山の働き方関連の本を読み漁ってきたわけだけれども、では本書『他者と働く』はどうなんだろう。感想をひとことでいうと「とてもエレガントだが、紹介されている方法論は極力使いたくないなぁ」という感じ。

『他者と働く』

さて本書のことは様々な書評やレビューなどで紹介されているのでそちらをご覧いただくとして

この後の所感を論じるために論旨をピックアップしておくと、だいたい本書はこんなことが書かれている。

  • 既存の方法で解決できる問題のことを「技術的問題」(technical problem)、既存の方法で一方的に解決ができない複雑で困難な問題のことを「適応課題」(adaptive challenge)と呼ぶことができる(ロナルド・ハイフェッツの定義)
  • 技術的問題はなんとかなっている。そして適応課題で社会や組織がこじれている
  • 適応課題に対応する方法として著者はナラティブ・アプローチという方法論を元に、(著者の考案した段階的プロセスによる)対話を提唱している

内容的にはかなり興味深い。特に自分の周りのソフトウェア開発界隈では、アジャイル開発コミュニティ周りでかなり話題になっていた。実際問題、わたしもいくつかの課題に対する対応方針を検討する時に参考にさせていただいた。有用な本であることには疑いはない。

だが、しかし・・・

本書が必要な状況そのものが不幸ではないか?

うまく表現できないのだけれども、本書が活用できる状況は非常に不健康な状況なんじゃないだろうか、と思ったのだ。こんなことで悩んでいる職場は、嫌だ。

そもそも論で

  • こじれないようにするほうが大事
  • こじれちゃったとしても、1対1の「対話」はかなり最終手段であって、その前にできることがたくさんありそう
    • TEAMINGのテクニックとか
    • 文化的なアプローチとか
    • 時と場合によるけれど、相手をチェンジするというのも一つの考え方だと思う

ということを考えてしまったのだ。

なんというか、本書の想定しているアプローチは「相当に煮詰まっちゃっている」ような気がする。そういう意味では、自分は煮詰まる前に水を足したいというのが本音だ。

もちろん、ちょっと目を離した隙に火にかけすぎてしっかりと煮詰まっちゃうことはあるので、その際にはきっと読み返して対話にチャレンジするとは思うのだけれども・・・

さて、次は何を読むかなぁ。

かな?

技術書、紙の本で読むか、電子書籍で読むか、Webで読むか←NEW!

「技術書、紙の本で読むか、電子書籍で読むか?」というブログ記事が興味深かったので自分の意見を書いてみた。結論から言うと、最近は紙の本でも電子書籍でもなく、Webで読むことが私は多い。

Webの本???

米O'Reillyサブスクリプションを購入して、learning.oreilly.comのサービスで読んでいる。以下の動画を見てもらうのが早い。

learning.oreilly.comにはO'Reillyだけではなく、主要な技術書出版社の多くがカバーされている点が最大のポイント。

Webの本のメリット 4つ

積読という概念の超越

サブスクリプションなので、もはや積読という概念がない。収録されている全ての書籍に無制限にアクセスできるのである。積読に魂を縛られることもない。

  • 読まなくても罪悪感ゼロ
  • つまみ食いし放題
  • つまらなかったら途中で読むのをやめる
  • 面白そうな引用や参考文献紹介などから、ディグる

コピーも翻訳も可能

learning.oreilly.comは通常のWebページとして本が読めるようになっている(固定レイアウトということも無い)。よって、紙の本や電子書籍では通常難しい次のような事も可能である。

  • 気になる用語についてCopyしてWeb検索
  • サンプルコードをそのまま利用
  • 翻訳サービスの活用

横断検索できる

learning.oreilly.comでは書籍の横断的全文検索も可能である。単純に検索できるだけで便利なんだけれども、特に最近はリアルWeb(普通のインターネット)の技術情報が急速に使い物にならなくなっている(S/N比が悪化している)。若干情報鮮度は下がるが、S/N比の良い情報ソースとしても活用できる。

なお出版社がO'Reillyである場合に限り、新刊について発売前の草稿の段階からlearning.oreilly.comで閲覧できるようになるので分野によっては実は情報鮮度の問題も小さい。

アクセシビリティが高い

PCでもスマートフォンでもタブレットでも閲覧可能だし、文字サイズも変更できる(固定レイアウトということも無い)。というわけで、アノ問題に対してもやさしい。自分は午前中は細かめ、午後は大きな文字で読んでおる……

Webの本のデメリット

もちろんデメリットもある。

まとめ

米O'Reillyのサブスク >> 電子書籍 >(老眼の壁)> 紙の本

ちなみにlearning.oreilly.comで今読んでいるのはこんなの

アフターコロナ時代を想定して分散アジャイル開発について調べてみた(Agile Software Development with Distributed Teams)

ウィズコロナなのかアフターコロナなのかはよくわからないけど、今回の新型コロナ感染拡大の事態を踏まえて分散アジャイルについての勘所について整理しようと思って、いろいろな調べてみた。世の中にはTips集と精神論ばかりが溢れている気がする。知りたいのは戦術だ。先人たちの知見から学ぶことはあるのだろうか?

Agile Software Development with Distributed Teams: Staying Agile in a Global World

以前に「A Practical Guide to Distributed Scrum」という本を読んでいる(DAD本で紹介されていた)。
agnozingdays.hatenablog.com

この本は基本的に「複数のグローバルなサイトに分散されたチームでのスクラム」について書かれていたと記憶している(若干自信はない)。今回読みたいのはそうではなくて、チームのメンバーが自宅などそれぞれのワークスペースにいて、サイトに集合しないタイプの分散である(あとで触れるがこれは「分散されたチーム」という)。

というわけで今回は「Agile Software Development with Distributed Teams: Staying Agile in a Global World」を取り上げてみた。

著者のJutta Ecksteinさんは独立したアジャイルコーチで、一時期はAgile Allianceのボードメンバーだったこともあるようだ。なお、2013年の本であり、DevOps以前のコンテキストで書かれている点には留意する必要があるだろう。

Distributed Team(分散チーム)とDispersed Teams(分散されたチーム)

本書ではひとくくりにされがちな分散を二つに区分して取り扱っている。

  • Distributed Team(分散チーム)とは、複数のサイトに配置された複数のチームのことを指す。Dispersed Teams(分散されたチーム)は多くの場所で働く人々で構成された一つのユニットを指す。大規模なプロジェクトではこの混合となる。
  • Dispersed Teams(分散されたチーム)では、チームが小さくてもチームメンバー間の効果的なコミュニケーションを確保するために、高度な調整作業が必要になる。

なお本書ではどちらの場合も取り扱っているのだけれども、本記事では自分が興味を持っているDispersed Teams(分散されたチーム)の場合の考慮点のみに触れる。

Building TeamsとEstablishing Communication and Trust

アジャイル開発であれば当然でもあるが、鍵となるのは信頼の確立である。アジャイル宣言では以下のように解説されている。

ビジネス側の人と開発者は、プロジェクトを通して日々一緒に働かなければなりません。
意欲に満ちた人々を集めてプロジェクトを構成します。環境と支援を与え仕事が無事終わるまで彼らを信頼します。
情報を伝えるもっとも効率的で効果的な方法はフェイス・トゥ・フェイスで話をすることです。
アジャイル宣言の背後にある原則

というわけで、本書では以下の戦略の説明がある。

  • 最初の1-2か月間はメンバーが一緒に作業をする形として「チームを鍛える」
  • 信頼と関係性を構築した上で分散する
  • 確立した信頼関係はゆっくりと低下し8-12週程度で閾値を下回る。よって隔月や四半期ごとに集結して信頼関係を回復する必要がある

これは、非常によくわかる。現在リモートワークでうまくやっているチームがまわっているのは、おそらく以前にしっかりとした信頼関係が構築できているからなのだろう。これから新たにチームを組成した場合にはこの問題に直面すると思う。

新規チームを構築するのに、さすがに1-2ヶ月オンサイトで作業というのは厳しいだろう。とはいえ最初は数日の合宿、1週間くらいのリモートワークの練習、再度のオンサイトミーティングによる振り返り、といったサイクルでチーム構築を開始すれば良さそうな印象がある。その後は定期的にオンサイトの振り返りを実施するのがよいのではないだろうか。

Keeping Sites in Touch

本書ではオンサイトのアジャイル開発には存在しないいくつかの役割の追加やマネジメントに関するテクニックも紹介されている。

  • コミュケーションファシリテーターの配置
    • コミュニケーションに関する問題を発見、解決する責任を持つ役割を設置する
  • (文化の異なるグローバルに分散されたチームの場合)アンバサダーの配置
    • 文化の違いなどを緩和して、信頼関係を向上させる役割を設置する
  • MBWA(Management by walking around)の積極的実施
  • ソーシャルコネクションを強化するための施策の実施
    • プロジェクトに特別なイベントをつくる(リリースを一緒に祝う)
    • Wikiなどでの写真の積極的共有(自己紹介、旅行記など仕事に直接関係ないものを含む)

この点は強く共感。スクラムであればプロダクトオーナーやスクラムマスターといった役割があるけれども、分散されたチームではおそらく何らかのプラスアルファは必要なのだろう。エンジニアリングマネージャーがやるのか、チームメンバーを任命するのかなどの振れ幅はありそうだが、工夫は必ず必要だと思う。

というわけで、いろいろとヒントがあって面白かった。

なお本書はKindle版はAmazonでも購入できるが、契約していればlearning.oreilly.comでも閲覧することが可能である。

『チーム・ジャーニー』第2部を含めて読み終わった #デッドライン読書会

対象を決めたら2週間で読み切り、アウトプットして、感想戦をするという読書会企画の第14回。今回の対象は『チーム・ジャーニー』である。味わい深い本であるため、2回に分けることにしていて、今回は後半である第2部および全体の感想だ。前半の感想はこちら

All Saints Academy Football

第2部の感想

さて、第2部は一種のエンタープライズアジャイル、もしくは大規模アジャイルのシミュレーションになっていると理解している。実際問題、このようなシチュエーションに放り込まれる経験はなかなか貴重なものなので、追体験としては極めて興味深いと言える。実際、第9話以降に発生する興味深いトラブルの多くは、おそらく筆者が経験したものなのだろう。アジャイル開発という枠組みがあるものの、おそらくそれぞれのトラブルに対する正解は一つではないし、本書に書かれた対策がベストとは限らないので「自分ならどうするか」という観点で本書と語り合えば非常に良い読書になると思う。

『チーム・ジャーニー』全体の感想

総論としては非常に有用な本だと思うし、様々な学びの入り口としても使える良書である。おそらく今後も本書と前作の『カイゼン・ジャーニー』は自分の後進指導時になんども活用する本になるとは思う。
チーム組成に関する良書だと知る限り以下のようなものがあるのだけれども、残念ながらそれぞれ視座がちょっと高すぎるのだ。現場メンバーが読む本としては難しすぎるので、本書『チーム・ジャーニー』は良い導入として使えると思う。

とはいえ、本書を読んでいていくつか突っ込みたくなる点もある。

「あなたは何をする人なのですか?」の呪い

このキーワードは前作「カイゼン・ジャーニー」から何度も繰り返されているものである。しかしこの「あなたは何をする人なのですか?」という言葉そものもは、非常に日本的な職種感に依存しているという点には注意が必要だろう。

  • (それが正しいかはさておいて)欧米系の企業を中心とした職務記述(Job Description)に基づいた就職/アサインメント観においてはそもそも「あなたは何をする人なのですか?」という問いが発せられる事がマネジメント的な観点で失敗のような気がする。
  • 主人公だけでなく全般的に、アサインメントとミッションコントロールが効いていない(もしくは、明かされていない)。読者の立場や所属企業の文化にもよるが、このあたりのギャップは本書の活用の妨げになると思う。
  • イマドキだと1on1とかOKRなどの普及によって、ここまで各人が迷走するようなことはないと思うのだけれども、これはおそらく著者がキャリアの過程であまり経験していないというのがネックのような気がする。

「ジャーニー」という言葉の選択は正しいのか

おそらく前作からの発展で著者は「ジャーニー」という単語を一つのキーワードとして採用しているのだけれども、この言葉を選ぶのは正しいのか若干疑問を感じている。

ジャーニー(journey)は、英語で船旅やあてのない旅など、比較的長い旅を意味する。
ジャーニー - Wikipedia

というそもそもの言葉の定義もあることに加えて、(ソフトウェア開発に限定しない広義の)技術者としては「ジャーニーマン」という言葉もあったりするのでややこしい。
本書の考え方は非常に有用だと思うが、自分のプロジェクトの計画や表現で「ジャーニー」を使うのはちょっと注意をしたほうが良いと思う(特にメンバーが多国籍である場合などは留意すべきじゃないだろうか)。

ロマンス不足

本書はせっかくの物語形式をとっているのだけれども、ロマンスがまったく無い! なんのための物語形式なんだ!