勉強会から持って帰る:OSN勉強会

cc:jwyg ※実際のW/S風景ではありません

今日は、OSN主催W/Sのトライアルに参加してきました。

※配付資料がなかったので記憶だけに頼って書きます。間違ってたらごめんなさい。

4月に開催されるAgile Japanで実施されるW/Sの中の一つの、「お試し&フィードバック」を目的とした勉強会でした。

W/Sのテーマは「現場に持って帰るまでがAgile Japan」。「AgileJapanでの学びや気づき、プラクティスを現場に持ち帰り、どのようなアクションで根付かせていくか」をみんなで考えよう!という主旨です。

そんなW/Sのテーマ自体も新鮮で楽しめたのですが、W/S(トライアル)の後に、W/S自体についての振り返りがあり、それがまた面白かったです。

  • タイトルはこれで良いのか
  • 各ワークの時間は十分だったか
  • 参加者がどのような人たちなのか、それにあわせた内容になっているか
  • そのW/Sに参加される人たちはどのような雰囲気になっているのか
  • 他のW/Sもある中でこのW/Sに求められるであろうことは何か

などなど。そういうことを考えながらW/Sするのか…と非常に参考になりました。

さて、W/S自体での私の気づきは以下の通りです。

  • 変革への障害
    • 拒絶反応(アレルギー反応)
    • 無関心(自分たちに関係ないと思われてしまう)
    • 優先順位が低い/時間が無い
    • やり方がわからない
    • メリットがわからない(わかってもらえない)

  • 対策
    • 拒絶反応・無関心への対策:
      • 抽象化
        あえて具体的な名称をあげたり、具体的な内容を明確にしないことで拒絶しにくくする。名前がついてないものは攻撃しにくいものです。
        ただし、やりすぎると、何をやったらいいのか、どんな良いことがあるのかイメージしにくくなるのでバランスが重要。

    • 優先順位が低いことへの対策:
      • 習慣化
        定期的に実行するように決めてしまう。週1水曜とか月1第二月曜とか。やるタイミングを考えなくて良いというのは、「とっかかり」の心理的コストを下げる手段の一つです。
        ただし、これをいつまでも続けていると「習慣」が「惰性(悪い意味で)」となってしまい、もはや必要のないことをやり続けるようになってしまうので、定期的な"振り返り"も一緒に習慣化する必要があります。
      • 価値観の共有
        時間がない、というのは「他にやることがある」の裏返しです。他のことより優先度が高いことは「時間を作ってでも」やりますから、そのような価値観を共有できるようにします。
        ただし、これをやりすぎると「価値観の押しつけ」になってしまい、そこはかとなく「やらされ感」が漂ってしまうという事態を招きます。このあたりも見極めと忍耐が重要かな、と思います。

    • やり方がわからない/メリットがわからないことへの対策:
      • 具体化
        どうやれば、どのような結果が得られるのか? 社内でもチームや部署によって微妙にことなる文化やプロセスを考えた上で、どのように適用していくのか、具体的なプランとメリットを説明するようにします。
        ただし、これをやり過ぎると拒絶反応や無関心といった反応を引き出してしまうおそれもあるので、きめ細かい対応とバランス感覚が重要です。

総括としては、「バランスが重要」ということ、「どのような方法論・テクニックも得手不得手がある」ということ、をよく考えて、それを把握した上で使い分けていくしかないんだな、と思いました。

「企画書は見た目で勝負」読みました。良いものを見極める目を育てる本

企画書は見た目で勝負 契約が面白いほどとれる企画書デザインのコツ

先日、知り合いの方から企画書のレビューを頼まれたときに、指摘のついでにこの本を紹介したら、次のレビューの時には別人が作ったかのような出来映えになっていて驚きました。

この本では、実際に幾つものbefore/afterを見せてくれます。良い例と悪い例。同じコンテンツでも見せ方を変えるとホラこんなに違うので
す、というのを最初はピンとこなくても幾つも幾つも見ていくうちに、そこにある「違い」とその「要因」が見えるようになってきます。

これは、mori log academy(残念ながらもうオンラインでは読めません)の受け売りですが、パッ見たときの違いを生み出すちょっとした「要因」を具体的に把握できること、計測できることというのが、仕上がりをコントロールするための第一歩
です。要因となる箇所をいかに緻密にコントロールするか、というテクニックも必要ですが、それは精密な観測に基づいたフィードバックがあってこそ成り立つ
ものだからです。

例えば、直径3mmの穴を空けるには、直径3mmピッタリを計測できなければなりません。ちょうど直径3mmの穴を開けられるドリルを持っていたとしても、それが直径3mmピッタリであることが分からなければ意味が無いのです。

プログラミングも同じだと思っているのですが、その話はまたいつか書きたいと思います。

GoogleBuzz出た。Twitterよりも高機能ぽい。Twitterは制限が多いからこそ上手くいったという意見を読んだことがあるけど、Buzzは上手くいくだろうか。

下はデモ・ビデオ。

「ユニクロ思考術」読みました。

ユニクロ思考術、私の大好きなデザイナさんの話が載っていたので読んでみました。(ユニクロも好きですが)

ビジュアルデザインを仕事にしている人は、VAKでいうVの表現が上手いですね。

…ユニクロが何を考え、可士和さんが何をしようと企んでいるのかが目の前にブワーっとビルが建つようにはっきり見えてくる。

とは、インテリア/デザイナー 片山正通さんの言葉。職業柄が出てます。

んー、プログラマ風に言うとこうでしょうか。

…ユニクロが何を考え、可士和さんが何をしようと企んでいるのかがプログレスバーがグワーっと100%になるようにはっきり見えてくる。

ちょっと違うな(笑)

読書メモ:人を助けるとはどういうことか

人を助けるとはどういうことか 本当の「協力関係」をつくる7つの原則

支援する状況というのは、本質的に不釣り合いで、役割も曖昧なもの。

クライアントが陥りやすい5つの罠

  1. 最初の不信感
  2. 安堵
  3. 支援の代わりに、注目や安心感、妥当性の確認を求めること
  4. 憤慨したり防衛的になったりすること
  5. stereotype化、非現実的な期待、(対人)知覚の転移

支援者が陥りやすい6つの罠

  1. 時期尚早に知恵を与えること
  2. 防衛的な態度にさらに圧力を掛けて対応すること
  3. 問題を受け入れ、相手が依存してくることに過剰反応する
  4. 支援と安心感を与えること
  5. 支援者の役割を果たしたがらないこと
  6. stereotype化、事前の期待、逆転移、投影

支援者の知らない5つのこと

  1. クライアントは情報や助言、あるいは訪ねられた質問を理解できるだろうか
  2. クライアントは支援者の提案に従うだけの知識やスキルを備えているだろうか
  3. クライアントの本当のモチベーションは何か
  4. クライアントの置かれた状況はどんなものか
  5. クライアントは経験に基づいて、期待や固定概念、恐怖心といったものをどう決定するだろうか

クライアントの知らない5つのこと

  1. 支援者には助けを与えるだけの知識やスキル、モチベーションがあるか
  2. この人に助けを求めれば、どんな結果が得られるか
  3. 何かを売りつけたり不適切に強制したりするために、状況を利用しようとしない支援者なら、本当に信じられるのか
  4. クライアントとして、私は提案されたことを実行できるだろうか
  5. 支援を受け入れると金銭面や感情面、また社会的な面でどれだけの代価を払うことになるだろうか

支援者の3つの役割

  1. 情報やサービスを提供する「専門家」
    クライアントが問題を正しく診断しているかどうか
    クライアントがこの問題を支援者ときちんと話しているかどうか
    支援者には情報やサービスを提供する能力があると、クライアントが的確に評価しているかどうか
    支援者にそうした情報を集めさせることや、支援者が進める改革を実行するという結果を、クライアントが考慮するかどうか
    客観的に情報を研究して、それをクライアントが利用できるようにする外的現実があるかどうか
  2. 診断して、処方箋を出す「医師」
    クライアントが正確な情報を明かす気があるかどうか
    クライアントが診断や処方を受け入れ、信じるかどうか
    診断のプロセスによる結果が正確に理解されて、受け入れられるかどうか
    進められた変化をクライアントが実行に移せるかどうか
    クライアントが依存心を強めた結果が、最終的な解決策の助けとなるのか、妨げになるのか
  3. 公平な関係を築き、どんな支援が必要か明らかにする「プロセス・コンサルタント」
    クライアントというモノは経営者であれ、友人や同僚であれ、あるいは学生や配偶者、子供などであっても、何が本当にうまくいっていないのか、実際の問題が何かを診断する上で、どんな助けが必要かを知らない場合が多い。しかし、問題を抱えて生きていくのはクライアント自身だけなのだ。
    クライアントは、コンサルタントがどんな支援を与えてくれるのかを分かっていない場合が多い。どのような助けを自分が求めているかを知るためのガイダンスが必要だ。
    クライアントの大半は物事を改善しようという意図を持っている。だが、何をどのように改善するかを見極めるには、支援が必要だ。
    自分が置かれた状況で何が最終的に効果を上げるかが分かるのは、クライアントだけだ。
    自分自身で問題を見抜いて対応策を考えない限り、クライアントが解決方法を実行に移す可能性は低い。また、そうした問題が再発したときに、修復する方法が身につかなくなる。
    支援の最終的な機能は、診断するためのスキルをクライアントに伝え、効果的な介入を行うことだ。そうすればクライアントは自力でもっと状況を改善していくことができる。

問いかけのかたち

  1. 純粋な問いかけ
  2. 診断的な問いかけ
  3. 対決的な問いかけ
  4. プロセス指向型の問いかけ

一般的にフィードバックは、求められたものでない場合は有益と言えない。

選択肢を与えてクライアントを巻き込むことは、支援を求めるという、ワンダウンにいる気持ちを間違いなく改善させる。…最も役に立つやり方は、自由に答えられる質問をすることだった。

支援関係における7つの原則とコツ

  1. 与える側も受け入れる側も用意が出来ているとき、効果的な支援が生じる。
    支援を申し出たり、与えたり、受け入れたりする前に、自分の感情と意図をよく調べること。
    支援したいとか、支援されたいとかいう自分の欲求がよくわかるようになること。
    支援しようという努力が快く受け入れられなくても、腹を立てないこと。
  2. 支援関係が公平なものだと見なされたとき、効果的な支援が生まれる。
    支援を求める人は気まずい思いをしていると言うことを思いだそう。だからクライアントの本当の望みは何か、どうすれば最高の支援が出来るかを必ず尋ねること。
    あなたがクライアントなら、何が役に立ち、何が役に立たないかというフィードバックを支援者に与える機会を探そう。
  3. 支援者が適切な支援の役割を果たしているとき、支援は効果的に行われる。
    先ずは調べてから、どんな支援の形が具体的に必要とされているかを推測すること
    支援する状況が続く中で、あなたの演じている役割が未だ役に立つモノかどうか、定期的に調べること。
    あなたがクライアントなら、もはや助けられていないと感じたとき、恐れることなく支援者にフィードバックを与えよう。
  4. あなたの言動全てが、人間関係の将来を決定づける介入である。
    支援者としての役割の中では、人間関係に与えそうな衝撃によって、自分の言動を全て評価すること。
    あなたがクライアントなら、やはり自分のあらゆる行動がメッセージを伝えていることを自覚するべきだ。
    フィードバックを与えるときは、現実の姿の記述に留めるようにし、判断は最小限に抑えること。
    不適切な励ましは最小限にすること。
    不適切な修正は最小限にすること。
  5. 効果的な支援は純粋な問いかけと共に始まる。
    純粋な問いかけから常に始めるべきである。
    求められた支援がどれほどおなじみのモノに聞こえても、これまで一度も効いたことがない、全く新しい要求だとして考えよう。
  6. 問題を抱えているオーナーはクライアントである。
    関係を築くまでは、クライアントの話の内容に関心を示しすぎないように注意すること。
    あなたが全て知っていると思う問題にどれほど似ているようでも、それは他人の問題であって、あなたのものではないことを絶えず思いだそう。
  7. 全ての答えを得ることは出来ない。
    支援の対象となる問題を分かち合うこと。

「プログラマーのジレンマ」読みました。混沌の闇に落ちる…

プログラマーのジレンマ 夢と現実の狭間

  • ソフトウェアベンチャーを創業者として大成功させ、たっぷりの資金をもったリーダー。
  • 彼が目指すのは、世界を変えるソフトウェアを作ること。
  • それは、プログラマ以外のユーザが容易に機能を拡張し、組み合わせ、あらゆる情報を管理できるようにしてくれるツール。
  • 彼のビジョンに賛同し、集まる一流の開発者達…。

これは、2001年にはじまった、あるオープンソース・プロジェクトに、3年間密着取材したドキュメンタリーです。

およそ考えうる最高の条件で始まったとしか思えないプロジェクトですが、序盤からすぐに難関が立ちはだかります。決まらない仕様、決まらないアーキテクチャ、他の事に興味がうつり去ってゆくメンバ…。重く辛い日々が延々と続きますが、本の終わり近くになって、ようやくプロジェクトは動き始めます。

これはドキュメンタリであって、フィクションではありません。物語の都合よりも、現実が優先されるのです。かなり余裕をもってこのプロジェクトに付き合えるように準備していた著者の持ち時間も、ついに尽きてしまうのですが、取材の期限終了が終わってもプロジェクトはまったく終わることなく、なんとそれから6年たった現在でも続いています。この物語のラストは、まだ決まっていないのです。

私には「ドリームチームを結成して凄いソフトウェアを開発する」という夢があります。この本の題材となった「チャンドラー・プロジェクト」は、まさに、私の夢そのものの世界だったのに、どうしてこんなことになってしまったのか…いや、まだプロジェクトが失敗に終わったわけではないのですが、明らかに大成功とは言えない状況でしょう。いろいろと学びの多い本でした。