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

拙訳『エラスティックリーダーシップ ―自己組織化チームの育て方』にコミットメント言語 (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/

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

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

子どもに向けてデザインする

先日、プログラマー的思考法を育む知育絵本「ルビィのぼうけん こんにちは! プログラミング」を翻訳された鳥井雪さんの話を聞く機会がありました。「ルビィのぼうけん」をどう作っていったかという内容で、子どもたちに実際に試してもらい、書籍を(表現やレイアウトなども含めて)つくり直していったというお話でした。

鳥井さんの話を聞いて思い出したのは「子どものUXデザイン ―遊びと学びのデジタルエクスペリエンス」という書籍です。「子どものUXデザイン」は、子ども向けのデジタルエクスペリエンスのデザインに関する書籍なのですが、知育絵本という分野も同じようにデザインしていくことが大事なのだろうということに感心しました。

そうした気持ちがあって、お話のあとで「子どものUXデザイン」のことを少し振ってみたりしたのですが、会場の雰囲気でこの書籍があまり知られていなそうな印象があり、勿体無いと感じました。そこで、広く知られるといいなと思い、ここで紹介しておきます。

子どものUXデザイン」は、子どもを対象としたデジタルプロダクト、サービスなどをデザインする際に何に気をつけていくべきか、を教えてくれる書籍です。

具体的には、ピアジェの認知発達理論をベースにして、認知能力の発達段階ごとにデザインするうえで気をつけるべきポイントを知ることができ、また、子どもにたいしてデザインリサーチを行うための方法などがコンパクトにまとめられています。

たとえば、ぼくがこの本を読んでいて得心がいった内容には、次のようなものがあります。

 多くのデザイナーは、子どもになにかをクリックさせるには、子どもの注意を惹きつける必要があると考えています。その結果、ナビゲーションのボタンがロールオーバーされると、くっきりと強調されたり、動いたり、チャイムが鳴ったりするのです。ところが皮肉なことに、そうした変化があるがためにかえって子どもは、強調や動きやチャイムがその場所でおきるすべてだと思い、クリックしようとしなくなります。

他にも、抽象的にものごとがイメージできるようになるまではアイコンは具象的なもの(たとえば計算機ではなく「1+1=2」みたいな)のほうがわかりやすいといった話や、10章にある「年齢層ごとに見るアプリ」は同じアプリを題材にして年齢層ごとにどう変えていくとよいかという具体的な例になっていたりして、全編をとおして、子ども向けのデジタルプロダクト、サービスなどの開発・デザインに関わるのであれば知っておくとよい内容となっています。 

教育用途を含め、子ども向けのデジタルプロダクト、サービスは今後ますます増えていくと思います。本書にあるような内容がたくさんの開発者、デザイナーに知られ、子どもたちがより良いデジタル体験をできるようになっていけるといいなと考えます。

子どものUXデザイン ―遊びと学びのデジタルエクスペリエンス

子どものUXデザイン ―遊びと学びのデジタルエクスペリエンス

 

 

ルビィのぼうけん こんにちは!  プログラミング

ルビィのぼうけん こんにちは! プログラミング

 

 

チーム開発で暗黙的に行なわれている批評というプロセス

Pull Request を通して行うコミュニケーションに「レビュー」という言葉がつくことに違和感を感じるときがあります。

Wikipediaコードレビューを引くと、「見過ごされた誤りを検出・修正することを目的として体系的な検査(査読)を行う作業 」とあります。もちろん、これを目的として行うやり取りもあるのですが、その手前の「コードや設計について議論し、もっと良い判断を探る」ために行うコミュニケーションもあると思います。むしろ、そちらのコミュニケーションをやりやすいことが、Pull Request というプラットフォームが提供する価値なのではと感じることが多いのが、違和感の元かもしれません。

2015年6月に O'Reilly から出版された「Discussing Design: Improving Communication and Collaboration through Critique」という書籍があります。ぼくは、この書籍に書かれていることが、すなわち Pull Request を通して行っている活動の「レビュー」ではない側面なのだと感じています。

Discussing Design: Improving Communication and Collaboration through Critique」は、デザインを洗練させるための批評(Critique)というプロセスを扱った書籍です。本書における批評とは「チームでデザインを行う際に、目的に照らしてデザインを分析しフィードバックするプロセス」のことで、本書にはこのプロセスを行う際に大切なことが、とてもよく整理されまとまっています。

Discussing Design: Improving Communication and Collaboration through Critique

Discussing Design: Improving Communication and Collaboration through Critique

具体的に挙げると、

  • 良いフィードバック(批評)とは何か
  • フィードバックを与える側が気をつけるべきこと
  • フィードバックを受ける側が気をつけるべきこと
  • より良いフィードバックのためのファシリテーションの仕方

などといった内容が書かれています。

たとえば、だいじだなと思ったことの中には次のようなことがあります。

  • フィードバックとは、感情を押し付けるためのものでも、説明のない指示を与えることでもなく、受け手が成果物をより良くするために必要な情報をきちんと届けること
  • 「今はデザインプロセスのどの段階ですか?」「どうしたらいちばんあなたの役に立てますか?」という情報をもとにフィードバックの内容を調整する
  • フィードバックを与える際は、なぜそんな反応をしたくなったのか、感情をいだいたのかを一旦深く潜ってかんがえることが大事
  • フィードバックに問題解決を含めないこと。議論の分析的な焦点が損なわれ、ずれてしないかねないので、問題解決をしてはいけない
  • フィードバックをうまく与える/受けるには練習が必要

「Discussing Design」( デザインについての議論)、Pull Request を通して行われているやりとりは、まさにこのことだと思います。「批評」という用語自体がぼくらの業界に馴染むかどうかはわかりませんが、本書にあるデザインのプロセス/考え方は、開発者の人にも広く共有されると良いものだと考えます。

気がついたら本書の翻訳書が「みんなではじめるデザイン批評―目的達成のためのコラボレーション&コミュニケーション改善ガイド」というタイトルでBNNから出版されていて、とても読みやすい訳となっていました。他人のコードや設計にフィードバックする機会のある人、フィードバックを受ける機会のある人は、ぜひ一度読んでおくことをお勧めします。

みんなではじめるデザイン批評―目的達成のためのコラボレーション&コミュニケーション改善ガイド

みんなではじめるデザイン批評―目的達成のためのコラボレーション&コミュニケーション改善ガイド