読者です 読者をやめる 読者になる 読者になる

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

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

ストレングス・ファインダーとは、人の持つ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から出版されていて、とても読みやすい訳となっていました。他人のコードや設計にフィードバックする機会のある人、フィードバックを受ける機会のある人は、ぜひ一度読んでおくことをお勧めします。

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

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