『レガシーコードからの脱却』を読んだ

本書はタイトルに「レガシーコード」と入っているため、イメージ的に『レガシーコード改善ガイド (Object Oriented SELECTION)』『レガシーソフトウェア改善ガイド (Object Oriented Selection)』といった書籍といった系譜の書籍を思い浮かべる人もいるかもしれない。しかし、実際には本書は『アジャイルソフトウェア開発の奥義 第2版 オブジェクト指向開発の神髄と匠の技』や『Clean Code アジャイルソフトウェア達人の技』、『アジャイルプラクティス 達人プログラマに学ぶ現場開発者の習慣』といった書籍の系譜、すなわち「より良いソフトウェアを作り出すために(レガシーコードを生み出さないために)どのようなテクニック、スキル、考え方が必要か」を説いている書籍だ。

本書は、大きくそれを次の9つのプラクティスにまとめ、1つずつをとても読みやすい内容、文量で教えてくれる。

  • やり方より先に目的、理由、誰のためかを伝える
  • 小さなバッチで作る
  • 継続的に統合する
  • 協力しあう
  • 「CLEAN」コードを作る
  • まずテストを書く
  • テストでふるまいを明示する
  • 設計は最後に行う
  • レガシーコードをリファクタリングする

本書を読んでとくにいいなあと思ったのは、ところどころで原則とプラクティスの関係、原則を見失わないように、というアドバイスを著者がはさんでくれることだ。

原則はドライブの目的地で、プラクティスはその道筋である。(...略...)プラクティスは私たちが原則を理解するのを助けてくれるし、原則は私たちがプラクティスを正しく使うのを助けてくれる。ただ、両方に目を配っておかなければ、迷子になってしまう。やり方をまったく知らない偉大な理論家か、日々のタスクはこなせても終わりを見通せない実務家のどちらかになってしまう。両方のバランスが必要だ。

こうした原則への目線は、XPに触れたときに感じた「間違えない方に方向付けしてくれる感じ」を思い出させてくれ、安心できる感じ、信頼できる感じを与えてくれる。

同じ系譜の書籍群は、いずれをとってもその厚さ(ぜんぶが500-600ページくらいの厚さ)と価格からなかなか多くの人に手に取ってもらうことは難しい。それに比べて、本書は前述の書籍群の内容をうまくカバーしながら、それを300ページという文量に抑えており、多くの人に手に取ってもらえる形にしていることがとても素晴らしいと感じた。技術的卓越に関するプラクティスが散りばめられているところも、本書を良いと思うことの一つだ。

これから現代的な技術プラクティスを身につけていこうとする人やチームに何か書籍を1つお勧めするなら、本書は最良の一冊だろう。

『Design It! ― プログラマーのためのアーキテクティング入門』

翻訳を担当した書籍『Design It! ― プログラマーのためのアーキテクティング入門』(オライリー・ジャパン)が11月25日に発売になります。本書は2017年にPragmatic Bookshelfより出版されたMichael Keeling著『Design It!: From Programmer to Software Architect』の全訳です。Pragmatic Bookshelfファンにはおなじみの「... It!」シリーズの一冊で、日本語で読める「... It!」シリーズとしては4冊目の書籍となります。

O'Reilly Japan - Design It!

本書は、設計スキルを成長させたいプログラマーに向けたアーキテクティングの入門書です。ソフトウェアアーキテクチャの基礎とデザイン思考の考え方から始まり、ソフトウェアアーキテクトとして、チームと共に優れたソフトウェアを作り上げていく方法を包括的に解説します。本書を読むことで、適切なステークホルダーを特定してニーズを理解する方法、アーキテクチャ上重要な要求に基づいて技術やアーキテクチャを適切に選択する方法、アーキテクチャを軽量かつ効果的に評価する方法、チームのアーキテクト力を高める方法などを学べます。モダンなアーキテクチャ設計のための実践的な手法が詰まった本書は、より良いプログラマー、技術リーダー、そしてソフトウェアアーキテクトになるために必携の一冊です。平鍋健児氏による「日本語版序文」を収録。

本書のテーマは、ソフトウェアをデザインすることです。主にアーキテクトの役割に焦点をあて、ソフトウェアの根幹となる部分、すなわち、ソフトウェアアーキテクチャをいかにデザインしていくかについての書籍となっています。そして、原書の「From Programmer To Software Architect(プログラマーからソフトウェアアーキテクトへの道)」というサブタイトルが示すように、今日のソフトウェア開発の現場で、新しい人たちがどうやってアーキテクト的な責任に踏み込んでいったらよいかというガイドにもなっています。

本書が良いなあと思うのは、とりあえずこれ一冊あれば、ビジネスを支えるソフトウェアのアーキテクティングにどう取り組んでいったらいいかの地図とコンパスを手に入れられるようになっているところです。

目次

第Ⅰ部 ソフトウェアアーキテクチャ入門

1章 ソフトウェアアーキテクトになる
    1.1 ソフトウェアアーキテクトが行うこと
    1.2 ソフトウェアアーキテクチャとは何か
    1.3 チームのアーキテクトになる
    1.4 素晴らしいソフトウェアを作り上げる
    1.5 ケーススタディ: Lionheartプロジェクト
    1.6 次にやること 

2章 デザイン思考の基礎
    2.1 デザイン思考の4つの原則
    2.2 デザインマインドセットを身に付ける
    2.3 Think、Do、Check
    2.4 次にやること

第Ⅱ部 アーキテクチャ設計の基礎

3章 デザイン戦略を立てる
    3.1 満足のいく設計を見つける
    3.2 どれくらい前払いの設計を行うかを決める
    3.3 リスクに道案内させる
    3.4 設計計画を立てる
    3.5 Lionheartプロジェクト:ここまでのあらすじ
    3.6 次にやること 

4章 ステークホルダーに共感する
    4.1 適切な人たちと話をする
    4.2 ステークホルダーマップを作る
    4.3 ビジネス目標を発見する
    4.4 Lionheartプロジェクト:ここまでのあらすじ
    4.5 次にやること 

5章 アーキテクチャ上重要な要求を掘り下げる
    5.1 制約によって設計の選択肢を絞る
    5.2 品質特性を定義する
    5.3 機能要求の分類を探す
    5.4 それ以外のアーキテクチャに影響するものを見つけ出す
    5.5 必要な情報を掘り下げる
    5.6 ASRワークブックを組み立てる
    5.7 Lionheartプロジェクト:ここまでのあらすじ
    5.8 次にやること

6章 アーキテクチャを選ぶ(君がアーキテクチャに選ばれる前に)
    6.1 選択肢を広げるために発散させ、決定するために収束させる
    6.3 制約を受け入れる
    6.2 望ましい品質特性を促進する
    6.4 機能的責務を要素に割り当てる
    6.5 変化に向けて設計する
    6.6 Lionheartプロジェクト:ここまでのあらすじ
    6.7 次にやること 

7章 パターンで土台を作る
    7.1 アーキテクチャパターンとは
    7.2 レイヤー(Layers)
    7.3 ポートとアダプター(Ports and Adapters)
    7.4 パイプとフィルター(Pipe and Filter)
    7.5 サービス指向アーキテクチャ(Service-Oriented Architecture)
    7.6 パブリッシュ・サブスクライブ(Publish-Subscribe)
    7.7 共有データ(Shared-Data)
    7.8 多層(Multi-Tier)
    7.9 コンピタンスセンター(Center of Competence)
    7.10 オープンソース型の貢献(Open Source Contribution)
    7.11 巨大な泥団子(Big Ball of Mud)
    7.12 新しいパターンを発見する
    7.13 Lionheartプロジェクト:ここまでのあらすじ
    7.14 次にやること 

8章 意味のあるモデルで複雑さを扱う
    8.1 アーキテクチャを見通す
    8.2 メタモデルを記述する
    8.3 コード内にモデルを構築する
    8.4 Lionheartプロジェクト:ここまでのあらすじ
    8.5 次にやること

9章 アーキテクチャデザインスタジオを開く
    9.1 アーキテクチャデザインスタジオを計画する
    9.2 適切なデザインアクティビティを選択する
    9.3 適切な参加者を招く
    9.4 グループを管理する
    9.5 リモートチームと実施する
    9.6 Lionheartプロジェクト:ここまでのあらすじ
    9.7 次にやること 

10章 設計判断を可視化する
    10.1 異なる視点からアーキテクチャを示す
    10.2 素晴らしい図を描く
    10.3 Lionheartプロジェクト:ここまでのあらすじ
    10.4 次にやること 

11章 アーキテクチャを記述する
    11.1 全体像を語る
    11.2 状況に応じた記述方法を選ぶ
    11.3 聴衆に配慮する
    11.4 ステークホルダーの関心事を中心にビューを構成する
    11.5 判断の論理的根拠を説明する
    11.6 Lionheartプロジェクト:ここまでのあらすじ
    11.7 次にやること 

12章 アーキテクチャに通知表をつける
    12.1 評価し、そこから学ぶ
    12.2 設計をテストする
    12.3 評価ワークショップを開く
    12.4 早くから評価を始め、頻繁に継続的に評価する
    12.5 Lionheartプロジェクト:ここまでのあらすじ
    12.6 次にやること 

13章 チームのアーキテクト力を強める
    13.1 アーキテクチャ思考を促進する
    13.2 意思決定を促し、スキルの成長を促進する
    13.3 安全に実践する機会を作り出す
    13.4 設計権限を委譲する
    13.5 共にアーキテクチャを設計する
    13.6 Lionheartプロジェクト:大団円
    13.7 次にやること 

第Ⅲ部 アーキテクトの道具箱

14章 問題理解のアクティビティ
    アクティビティ 1 たった一つを選ぶ 
    アクティビティ 2 共感マップ 
    アクティビティ 3 GQMワークショップ 
    アクティビティ 4 ステークホルダーインタビュー 
    アクティビティ 5 前提リスト 
    アクティビティ 6 品質特性ウェブ 
    アクティビティ 7 ミニ品質特性ワークショップ 
    アクティビティ 8 POV Madlib 
    アクティビティ 9 応答測定のたたき台 
    アクティビティ 10 ステークホルダーマップ

15章 潜在的な解決策を探るアクティビティ
    アクティビティ 11 アーキテクチャの擬人化
    アクティビティ 12 アーキテクチャフリップブック 
    アクティビティ 13 CRCカード
    アクティビティ 14 概念マップ 
    アクティビティ 15 分割統治 
    アクティビティ 16 イベントストーミング 
    アクティビティ 17 グループポスター 
    アクティビティ 18 ラウンドロビン設計 
    アクティビティ 19 ホワイトボードジャム 

16章 設計をタンジブルにするアクティビティ
    アクティビティ 20 アーキテクチャデシジョンレコード 
    アクティビティ 21 アーキテクチャ俳句 
    アクティビティ 22 コンテキスト図 
    アクティビティ 23 まずこれを読もうリスト
    アクティビティ 24 インセプションデッキ 
    アクティビティ 25 モジュール分解図 
    アクティビティ 26 選ばなかった道 
    アクティビティ 27 学習か判断のためのプロトタイプ 
    アクティビティ 28 シーケンス図
    アクティビティ 29 システムメタファー 

17章 設計の選択肢を評価するアクティビティ
    アクティビティ 30 アーキテクチャブリーフィング 
    アクティビティ 31 コードレビュー 
    アクティビティ 32 意思決定マトリクス 
    アクティビティ 33 振る舞いの観察 
    アクティビティ 34 質問-意見-懸念 
    アクティビティ 35 リスクストーミング 
    アクティビティ 36 サニティチェック 
    アクティビティ 37 シナリオウォークスルー
    アクティビティ 38 スケッチして比較

今日では、事業会社に所属し、そのビジネスを支えるソフトウェアの開発に携わるソフトウェア開発者も増えてきています。一方で、ソフトウェアをビジネスとうまく調和させた形で作り上げていく、ビジネス領域の人たちと一緒になってソフトウェアを育てていくという部分では課題がある組織もまだまだ多くあると感じています。そして、そうした課題に影響を与えているものの一つには、組織構造やこれまでのキャリアからくる無意識の線引きに影響され、私たちの側が旧来通りのソフトウェア開発のアプローチ(発注=仕様を決める側と受注=作る側)にとどまってしまっているケースも多くあると考えています。

本書は、プログラマーがそうした壁を破って、ビジネスと調和したソフトウェアをチームでデザインしていくためのヒントが得られる一冊です。

訳者後書きにも書いたことなのですが、この「... It!」シリーズというのは、自分にとって思い入れのあるシリーズで、10年ほど前の自分にとって『Ship It!』をはじめとするこのシリーズの書籍たちを「今世界のどこかで、こうやったやり方や考え方で開発していっている人たちが実際にいる!」という感覚を持ちながら日本語で読めたことは、プログラマーとしての世界観を形成していくにあたって大事な経験でした。今回のぼくの仕事が、これまでの書籍を翻訳してこられた方々のように十分にうまくできたかはわかりませんが、願わくば、当時のぼくと同じような気持ちで本書から何かを受け取ってくれる人に、この本が届くといいなと思っています。

本書の出だしは、次のような一行からはじまります。

ソフトウェアアーキテクチャとは、素晴らしいソフトウェアを構築するための土台だ。もちろん、アーキテクチャが素晴らしいからといって、ソフトウェアの成功が保証されるわけではない。しかし、多くの場合、誤ったアーキテクチャは失敗につながる。ソフトウェアアーキテクチャはとても重要なものだ。だからこそ、すべてのソフトウェア開発者はそれをどう設計するかを知る必要がある。

ぜひ、たくさんの方に読んでいただけると嬉しいです。

Design It! ―プログラマーのためのアーキテクティング入門

Design It! ―プログラマーのためのアーキテクティング入門

『進化的アーキテクチャ ― 絶え間ない変化を支える』

翻訳を担当した書籍『進化的アーキテクチャ ― 絶え間ない変化を支える』(オライリー・ジャパン)が8月18日に出版になります。原書は2017年に出版された『Building Evolutionary Architectures ― Support Constant Change』(O'Reilly Media)です。

O'Reilly Japan - 進化的アーキテクチャ

現代におけるエンタープライズアーキテクチャは、もはや静的な計画をあてにすることはできなくなっています。そしてソフトウェア開発エコシステムは、ツールやフレームワーク、技術イノベーションの流れと共に絶え間なく変化しています。こうした状況の中で、いったん構築したシステムを成長させていくには、さまざまな変化に適応しながら進化するアーキテクチャをシステムに組み込む必要があります。本書は、そうしたアーキテクチャを「進化的アーキテクチャ」と名付け、その構築に必要な考え方や技術、実践方法などについて解説するものです。 ThoughtWorksの3人のスペシャリストから現代のソフトウェアアーキテクトに向けられた本書は、絶え間ない変化を支える進化的アーキテクチャを構築するために必要なすべてを提供する実践的なガイドです。

進化的アーキテクチャ(Evolutionary Architechture)」という考え方や重要性については、これまでにも何度かThoughtWorks関係者から語られてきていました。

例えば、Sam Newman『マイクロサービスアーキテクチャ』の結びは、

進化的アーキテクチャの概念を採用する方法を身に付けましょう。進化的アーキテクチャでは、あなたが新しいことを学ぶにつれシステムは徐々に柔軟になり変化します。ビッグバン型の書き直しではなく、システムを徐々に変更していって柔軟性を保つようにしてください。

となっており、同書の内容が「進化的アーキテクチャ」という考えの傘の下にあることが伺えます。

また、Kief Morris『Infrastructure as Code ― クラウドにおけるサーバ管理の原則とプラクティス』でも、「15章 Infrastructure as Codeのための組織」に「15.1 発展的なアーキテクチャ」(原書では「15.1 Evolutionary Architecture」)という節が設けられており、こちらでもやはり進化的アーキテクチャという考えが前提にあることが確認できます。

そして、元ThoughtWorkerのJez Humbleが共著を務める『The DevOps ハンドブック 理論・原則・実践のすべて』でも「進化的アーキテクチャ」はちょこちょこと顔を出し、

これは発展的なアーキテクチャの原則である。Jez Humbleは、「成功を収めた製品、組織のアーキテクチャは、かならずライフサイクルの過程で必要に迫られて発展します」と語っている。

発展的なアーキテクチャをサポートすれば、アーキテクチャは組織のそのときどきのニーズを満たすものになる。

といった具合に、ThoughtWorkerたちに「進化的アーキテクチャ」という考え方が根付いていることが確認できます(いずれも「第13章 ローリスクリリースのアーキテクチャ」より引用。こちらも訳語は「発展的なアーキテクチャ」となっていますが、原書では「Evolutionary Architecture」)。

しかしながら、これだけさまざまな文献から言及されつつも、ThoughtWorkerたちの考える「進化的アーキテクチャ」が一体どういったもので、それを実現するためにどうしたらいいのかをまとまって確認できる文献は存在していない状況でした。

本書は、ThoughtWorkerたちが「進化的アーキテクチャ」自体をテーマにして書いた初の書籍です。

本書の執筆陣は、ThoughtWorksのディレクターであるNeal Ford、CTOであるRebecca Parsons、主任コンサルタントであるPatrick Kua。序文はMartin Fowlerが務め、データベースを扱った第5章は『データベース・リファクタリング』の共著者としても知られるPramod Sadalageによる寄稿と、そうそうたる面子による書籍となっています。

ThoughtWorkerたちは、本書の刊行を皮切りに、進化的アーキテクチャのセッションを各地で精力的に行なっているようで、そのコンセプトはさまざまなフィードバックを受けてさらなる進化をしていくことは想像に難くありませんが(なにせ「進化的」を推進する側の彼らですから)、現代のソフトウェア開発におけるアーキテクチャの捉え方として興味深い内容が含まれている一冊になっていますので、ぜひ手に取っていただけると嬉しいです。

進化的アーキテクチャ ―絶え間ない変化を支える

進化的アーキテクチャ ―絶え間ない変化を支える

コミットメント言語で大事なのはそれが制御下にあるかどうか

拙訳『エラスティックリーダーシップ ―自己組織化チームの育て方』にコミットメント言語 (Commitment Language) というものがでてきます。コミットメント言語とは、簡単にいうと「言質を与える言い方」のことで、本書では「仕事では自分が何を行うかを言質を与える言い方で約束すべきである」という話で、このコミットメント言語というものがでてきます。

具体的にいうと、希望的な物言い(「したいと思います」「しようと思ってます」「やれると思います」)やコミットメントを表明しない言い方(「はやったほうがいいとは思っています」「やらないといけないとは思ってます」)をせず、やることを約束する言葉遣い(「〜します」)をするようにしましょうという話です。

ですが、実はここだけを切り取って読んでしまうと勿体なくて、著者のロイがコミットメント言語の章で伝えたい主旨は、単に言い方だけを変えなさいという話ではありません。本当に大事なのは、そのあとに著者が続けている「自分の制御下にあるものが何かを考えること」にあります。つまり、言質を与える言い方を選ぶことを通して、それぞれのメンバーが「自分が本当に約束できることは何か」を考え、そこから外れた指示、依頼を受けた場合には、自分でスコープを調整したりした上で、約束できることだけを約束できるようになっていかないといけないよね、という話がコミットメント言語の肝になります。

ともすると、「約束させられるための言葉遣い」のように受け取られかねないのですが、そんな風に流通してしまうと切ないなあと思って、僕が訳しながら受け取めていたことを少しだけ書いてみました。

ちなみに、コミットメント言語は「約束の言語 (Language of Commitment) 」としてロイが『Clean Coder プロフェッショナルプログラマへの道』に寄稿した内容が元になっています。ボブおじさんの書籍にロイが寄稿するという、ちょうど『エラスティックリーダーシップ』の逆の形ですね。もし両方の書籍を持っている人がいたら、読み比べてみると面白いかもしれません*1

エラスティックリーダーシップ ―自己組織化チームの育て方

エラスティックリーダーシップ ―自己組織化チームの育て方

Clean Coder プロフェッショナルプログラマへの道

Clean Coder プロフェッショナルプログラマへの道

*1:英語であれば http://www.informit.com/articles/article.aspx?p=1715058 から読めます

「達人プログラマー」のこと

しばらく絶版になってしまっていた「達人プログラマー―システム開発の職人から名匠への道」が、オーム社から「新装版 達人プログラマー 職人から名匠への道」として復刊されました。原著をリスペクトした素晴らしい表紙とコンパクトな判型、訳もより読みやすく見直され、電子書籍としても手に入るようになり、とても価値のある復刊だと感じます。

新装版 達人プログラマー 職人から名匠への道」は、Andrew Hunt と David Thomas によって1999年に書かれた「The Pragmatic Programmer: From Journeyman to Master」の日本語訳です。本書の価値は、その一行目にそのままずばり書かれています。

本書はあなたがより良いプログラマーになるためのお手伝いをするものです。

Andrew Hunt と David Thomas の二人は、何かしらの方法論を押し付けるようなやり方ではなく、実践的なアドバイスとその背景にある考え方の解説を重ねていくことで、プログラマーとしての仕事の仕方を、私たちに伝えてくれます。

ぼく自身、社会人になって3年目くらいの時に本書と出会い、それから「自分がしている仕事が一体何なのか」「どういう仕事をしていきたいのか」「どういうプログラマーでありたいか」といった大事なことを、本書から教えてもらってきました。

17年も前に書かれた本に古典として読む以上の価値があるのか、そう思う人もいるかもしれません。

たしかに、文中に出てくる言語やツール、技術には時代を感じる部分がないわけではありません。しかし、何故という部分は今でもしっかりと大事なことが書かれていますし、新装版では訳註の形で現在の言語やツールのこともしっかりと触れられていて、今の人に届く価値は十分にあると考えます。

本書には、著者の二人から私たちへのメッセージが Tip として文中のさまざまなところに登場します。その中でもっとも大事な Tip は、まえがきに置かれた最初の2つの Tipでしょう。

  • 自らの技術に関心を持つこと
  • あなたの仕事について考えること!

著者の二人はここから出発して、コーディング、設計、テスト、デバッグ、開発環境、チーム、プロジェクト、そしてキャリアのことまで、ちゃんと仕事をするとはどういうことかの全体像を私たちに伝えてくれています。全体像をわかるということは、とても重要です。全体を描いて仕事をしていくことこそが達人への道であることは、本書の中で引用されている「採石場作業者の心得」の通りです。

単に石を切り出す場合でも、常に心に聖堂を思い描かねばならない

私たちの仕事の全体像を、本書くらいコンパクトにわかりやすく、大事なことに絞って伝えてくれている書籍はあまりありません。 新装版をあらためて読んでみて、現在のぼくの立ち位置から未だに新しく発見することもあり、今も活きた書籍であることを強く感じました。

せっかく復刊された新装版が、コレクターアイテムとしてだけではなく、しっかりと今の人たちのもとに届くと良いなと考えています。

新装版 達人プログラマー 職人から名匠への道

新装版 達人プログラマー 職人から名匠への道

書籍「デザインの伝え方」を読んで

デザインの伝え方

デザインの伝え方

デザインの伝え方」を読んで、「ソフトウェア開発とは創作とコミュニケーションの協調ゲームである」という Alistair Cockburn *1 の言葉を思い出しました。

デザインの伝え方」は、製品やサービスのデザインに関わるようなデザイナーに向けて、デザインの実現に影響ある人々(ステークホルダー)とどのようにコミュニケーションしていったらよいかが書かれた書籍です。具体的には、そうした人たちにデザインを伝える際に気をつけるべきこと、コミュニケーションギャップの埋め方、必要な心構え、そして合意形成のテクニックなどが書かれています。

なぜ、上記のようなデザイナー向けの書籍から、前述の言葉を思い出したかというと、語られている内容やその根本にある考え方が、Alistair Cockburnの書いた「アジャイルソフトウェア開発 (The Agile Software Development Series)*2とオーバーラップしたからでした。

たとえば、「デザインの伝え方」には「偉大なデザイナーは偉大なコミュニケーター」という章があります。その章では、デザインにとっていかにコミュニケーションが大切かということが書かれています。そして、「アジャイルソフトウェア開発 (The Agile Software Development Series)』にも「コミュニケーションスペシャリストとしてのプログラマ」という節があります。この節の前後では、「ソフトウェア開発とは創作とコミュニケーションの協調ゲーム」であるという考えのもと、プログラマーにとってコミュニケーションが重要であること、コミュニケーションの効果がどうプロジェクトとその成果物であるソフトウェアに影響するか、ということが語られています。

かといって、両者がまったく同じ内容を単に別の立場(プログラマーとデザイナー)から書かれたものであるかというと、そうではありません。大きな違いは目線の高さにあります。

アジャイルソフトウェア開発 (The Agile Software Development Series)」は、プロジェクトを設計/運営するという高い視点から「創作とコミュニケーションの協調ゲーム」への取り組み方が書かれています。そのため、記述はどうしても俯瞰的なものとなりますし、そうすることで見える景色が書籍の魅力にもなっています。

それに対して、「デザインの伝え方」は、プレイヤーという視点から「創作とコミュニケーションの協調ゲーム」への取り組み方を示します。特に上手いのは、漠然とコミュニケーションが大事だと言うのではなく、トピックを「合意形成」という一点に絞ってゲームをうまく進めるために必要な心構え、能力、テクニックを解説している点です。合意形成スキルは、私たち「コミュニケーションスペシャリストとしてのプログラマ」にも、とても大事な能力だと考えます。以上のことから、この書籍はデザイナーに限らず「創作とコミュニケーションの協調ゲーム」に参加するプレイヤーにとって実践的で魅力的な内容になっていると感じました。

デザインの伝え方」は、書籍の作り方から、一見すると開発者の人が積極的には手を伸ばし辛い雰囲気があります。けれど、少なくとも2章3章5章6章あたりは「リーダブルコード ―より良いコードを書くためのシンプルで実践的なテクニック (Theory in practice)」などと並んで、サービスやプロダクト開発に携わるプログラマーであれば、コミュニケーションスキルの基礎教養の一つとしておさえておきたい内容だと感じました。

*1:Alistair Cockburn は、アジャイルソフトウェア開発宣言 の共著者、そして「クリスタル・ファミリー 」という方法論の提唱者としてよく知られている人物です。最近では、牛尾さんのブログに彼や彼の業績を紹介するエントリ がありました。

*2:本エントリを書いていて Dave Thomas によるレビュー「People over Process, Interactions over Tools 」を見つけました。これは素晴らしいレビューで、ぼくが本書の魅力を語るよりもこれを読んでもらった方がよっぽど魅力が伝わりそうに思いました。まだ目にしたことがない人はぜひ読んでみてください。第2版をいつか新訳で読みたい/出したい。

チームビルディングにストレングス・ファインダーを活用する

新しいプロジェクトのたびに、どうチームを作っていくかということを試行錯誤しています。つい最近やってみて、とても有効性を感じた試みに、チームを始める際にストレングス・ファインダーの診断結果を交換しあうというものがあります。

ストレングス・ファインダーとは、人の持つ34の資質の中から自分の中で優位を占める特徴的な資質5つを診断してくれる診断テストです。

ストレングス・ファインダーの結果は、互いの強みや特性を知るという、自律的なチームを作る上では必須だけれど難易度の高いコミュニケーションをとてもスムーズに行える良いツールだと感じています。しかし、現状はまだあまりそうした使われ方として十分には流通していなそうなので、ここで紹介します。

ストレングス・ファインダーについて

ストレングス・ファインダーとは、企業コンサルや世論調査などを行っているギャラップ社が提供している診断テストです。オンライン上で質問に答えていくことで、自分の中で優位を占める特徴的な資質5つと、その詳細な解説が書かれたPDFレポートが送られてきます。34の資質については、ストレングス・ファインダーを解説した書籍(「さあ、才能(じぶん)に目覚めよう―あなたの5つの強みを見出し、活かす」など)に詳しい解説がありますが、たとえば以下のようなURLなどでも、どのような資質があるかを参照できます。

http://npo2acchi.com/iko/ストレングス・ファインダーの34の強み/

加えてギャラップ社は、ストレングス・ファインダーで定義している34の資質を、「リーダーシップ」という観点で「実行力」「影響力」「人間関係構築力」「戦略思考力」という4つの領域に分類しています。こちらは書籍だと「ストレングス・リーダーシップ―さあ、リーダーの才能に目覚めよう」に詳細がありますが、以下のURLなどでもその分類を確認できます。

http://ストレングスファインダー.com/entry109.html

自分が持つ5つの資質がこれらの領域のどこに属するかを見ると、ものごとを進める際に自分が強みを発揮する領域がざっくりとわかるようになっています。

具体的なサンプルとして、ぼく自身の結果を以下に示してみます。

2016年6月時点でのぼくの特徴的な資質は、「共感性」「成長促進」「回復志向」「アレンジ」「運命思考」となっていました。ここから、ぼくが強みを発揮するリーダーシップの領域は「実行力」と「人間関係構築力」に偏っていることがわかります。これらは、自己評価とも他者評価ともあっており、信頼できる診断結果だと感じました。

どう使ったか

先日始まったプロジェクトでは、クライアントと一つのチームとなってプロジェクトにあたる必要がありました。このプロジェクトはクライアント組織の業務改善がミッションとなっており、複数部署を横断して組織の進みたい方向・メッセージを正しく伝え、浸透させていく必要が生じると感じていて、そのためにプロジェクトのメンバーに「影響力」の強みを持つ人材が必要だと考えていました(前述の通り、ぼく自身はそこはあまり得意なフィールドではなかったので、より必要性を感じていました)。

プロジェクトのキックオフをセットアップするにあたって、アジェンダの一つに「得意なこと・苦手なこと・期待することなどを交換する」という議題が上がっていたのですが、まだ関係が十分に作れていないクライアント側のメンバーとどうしたらスムーズにそれらを行えるかを考えた時に、試しに事前にお互いのストレングス・ファインダーを交換するということを提案し、実際にそれで会話をしてみました(ここでこれを試せたのは、クライアント側のメンバーがストレングス・ファインダーを認知している気配を感じる機会があったということがあります)。

その結果、相手側に「影響力」「戦略的思考力」の強みがあることがわかり、まだ十分に会話をしていない段階にもかかわらず、どのように役割分担して動くチームになりそうかという具体的なイメージなどをある程度描くことができました。また、お互いの結果は、過去のエピソードなどを紹介しあう触媒ともなっており、とても円滑に「得意なこと・苦手なこと・期待することなどを交換する」という活動を進めることができました。

このプロジェクトは現在も進行中ですが、当初の想像通りのチームの形となっていると感じています。

開発チームのチームビルディングにストレングス・ファインダーを活用する

こうした、お互いの強みをチームを始める際に交換しあうことの大切さは、多くの書籍で触れられています。

たとえば、「アジャイルサムライ−達人開発者への道−」には「プロジェクトを始めるときにこんな質問をしてみたらどうだろう?」(P34)というコラムがあり、そこではプロジェクトを始めるときにチームメンバー同士で以下のような質問をしあうことが提案されています。

  • 自分は何が得意なのか?
  • 自分はどうやって貢献するつもりか?
  • 自分が大切に思う価値は何か?
  • チームメンバーは自分にどんな成果を期待してると思うか?

また、「SCRUM BOOT CAMP THE BOOK」では、「Scene No22. さまざまな状況に対応する この作業は苦手です…」にある「協力して乗り越えていこう!」という節で以下のように書かれています。

ここで大事なのは 、開発チ ームとしていろんなことができるかどうかだ 。それはスキルに限った話じゃない 。考え方や経験 、どういう仕事のやり方が得意かってことも大事なんだ 。…(略)… お互いのそうした性格や得意不得意まで知っていれば 、開発チ ームはさまざまな状況を乗り越えていけるんだ 。

ですが、キックオフくらいの段階でこうした内容を「会話」だけでうまく交換しあうのは、実際にはとても難しいことだと考えます。

ここに関して、ぼく自身はあまりいいアイディアを持っていませんでした。ですが、今回ストレングス・ファインダーの診断結果を交換しあうということをしてみて、これはチームに自分自身の情報を安価で伝えるとても良いプラクティスだと感じました。会話をすることなく自身の強みなどをある程度の正確性を持って相手に伝えられるということももちろんですが、会話の際にエピソードを引っ張り出すための引き出しとしても、とても便利なツールだと感じています。また、既にあるチームの形を確認し合うのに使ってみても良いかもしれません。

これからチーム・ビルドしようという方の参考になると嬉しいです。 機会があれば、ぜひ試してみてください。

補足1: スキルマップとの併用

SCRUM BOOT CAMP THE BOOK」では、開発チ ームとしていろんなことができるかどうかを事前に確認するためのプラクティスとして、「スキルマップの作成」が紹介されています。プロジェクトに必要なスキルや知識を列挙し、それを開発メンバーがどれくらいカバーできているかを可視化することで、メンバーの得意なこと、苦手なことを確認し合おうというプラクティスです。

ストレングス・ファインダーの診断結果から見えてくるのは「行動の傾向」だけなので、実際に開発チームのフォーメーションを考える際には、こちらのプラティスと併用すると、開発チームが集まった時点で「このチームがどういうチームで、何ができそうか」という情報をそこそこの精度で見通すことができるだろうと考えます。

補足2: 他のやり方?

以前聞いた中で、ここを上手にやられているなあと思った例としては、リコーの山本陽平さんが「リコーUCSの開発をリーンスタートアップ的視点でふりかえる 」という発表の際にお話されていた「チームで大貧民をやってお互いの性格を把握する」というプラクティスがあります。

他にも、このあたりのチーム・ビルドをこうしたプラクティスでやっているよ、というやり方があれば是非知りたいです。

補足3: ストレングス・ファインダーを受けるには?

診断には15ドルほどかかりますが、前述の書籍に付属しているアクセスコードを使って診断を受けることも可能です。オンラインでテスト資格を購入する際には、以下のURLからアクセスします(書籍のアクセスコードを使う際のURLは別らしいので注意が必要です)。

https://www.gallupstrengthscenter.com/Purchase/ja-JP/

ストレングス・リーダーシップ―さあ、リーダーの才能に目覚めよう

ストレングス・リーダーシップ―さあ、リーダーの才能に目覚めよう