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

好きなことを好きなぶんだけ

podcast もやっています http://lean-agile.fm/

1000はてブとなったスライド。何を意識して書いていたか。

2016年に3つスライドを作成・公開したのですが、ありがたいことに、そのうち2つで 1000はてブを頂くことができました。

ただ、 1000はてぶをいただけたのは、私がどうというよりは、テーマが普遍的で、なかなか明確な答えが出るものでもなく(いつの時代でも文脈ごとに悩まれるもの)、エンジニアに限定せず様々な人の広く興味関心を引くものであったからだとは思っています。

ただ、個人的には 「伝わらないのは伝える側のせい」 というのを座右の銘にしていて、どうすれば伝わるのか?というのを常に考えるようにしています。 ですので、書くときに意識していたことというのは、ある程度ほかの方にも役立つのかなと思っていますので、自分の整理のためにも書いてみようと思います。

ぜひご一読をばと思います。

書き手、読み手、双方にメリットがあると確信したテーマで書く

くだんの2スライドは、本来は自分自身の知見や思考が整理したいがために書いたスライドです。つまりは自分のメリットのために書いたものということになります。自分にメリットがないと、情熱的に筆がすすみませんから。

一方で、自分の経験や知識を知ってもらうことや、そもそもその課題自体に目を向けてもらって少しの時間でも考えてもらうことが、読み手のメリットにもなると確信していたがゆえ、それらのテーマで実際にプレゼンテーションをし、公開をしました。

相手の時間を奪う わけですから、当然ですね。少なくとも自分なりの確信を持って、人の時間を頂戴すべきです。

しかし、この「確信」は、次の「スライドをいきなり書き始めない」のフェーズで、徐々に確立されていくものでもあります。 ですので、 最初からこれがなくても、とりあえず考え初めてみる ことをおすすめします。

スライドをいきなり書き始めない

上述のとおり、私の場合は特に、スライドを書くこと自体よりも、自分の思考を整理することが目的であるため、書く内容をあれやこれやと考えている時間が最も重要です。80%の時間はこれに費やしているイメージです。

そもそもですが、自分の思考を整理のためにプレゼンを利用することは非常に有効だと思っています。 やはり、 だれかに伝わる状態に持って行けたものが、整理された思考 だと思うからです。

シンプルですが、非常におすすめなのが、 「書く」 ことと、 「話す」 ことです。

ひたすら書いては消し、書いては並び替え、を繰り替えながら、何を言えば聞き手の/読み手のメリットとなるだろうか、どの順番で話せばストーリーとして成り立つだろうか、と試行錯誤します。 私は、初期はマインドマップ、その後はマークダウンで書きます。この段階で、スライドにし始めてしまうと、修正コストがかかり、修正することが億劫になってしまいます。

そして、なるべく速い段階で、その内容を誰かに話してみるのが良いです。 誰かと話すことで自分の思考が確立されていく 、というのは誰しも経験したことがあるのではないでしょうか? またこのタイミングになると、もはや いち聴衆の気持ちというのは自分の中から失われている ので、客観的な意見ももらえることになります。

これらの繰り返しによって、「書き手、読み手、双方にメリットがあると確信したテーマ」が生まれていきます。

ストーリー・テラーになる

人間はストーリーが好きです。(少なくとも僕は大好きです。) スライドもストーリーを意識し、なにもしらないまっさらな読み手の感情の変化を想像しながら、書きます。 もうこれは、恥ずかしがらずなりきるしかないですね。

ちなみに、 スライド中に「問いかけ」のことばを入れる ことは、読み手をストーリーへ引き込む良い方法だと思って多用しています。

スライドだけ読んでもわかるように意識する

プレゼンテーションを伴う場合、当日のプレゼンテーションだけでなく、その先の スライド公開にも目を向けた方が良い と思います。 ただしこれは、聞き手が、言葉ではなくスライドに注目しすぎてしまう恐れもあるので、プレゼンテーションという観点では逆効果にもなりえるので、トレードオフでもあります。 その場合は、せめて文ごとにアニメーションをつけるなど、なるべく聞き手が「読んでしまわない」ような工夫をするようにしています。

プレゼン用と公開用のスライドを作れるのがベストですが・・・!

文脈や前提を明記する

「マサカリ対策をする」と言い換えることもできます。

至極当然のことですが、 書き手は自分の文脈で書くし、読み手は自分の文脈で読みます

マサカリには、 良いマサカリ(示唆をあたえ議論を深めるもの) と、 悪いマサカリ(ただ論点がずれてしまうもの) がありますが、後者が投げられてしまうのは、多くの場合、 投げた当人が悪い訳ではなく、書いたもので「伝えられていない」 と思っています。

読み手として読み解く努力(もしくは、見えていない前提があるということを前提とする読み方)も必要ですが、書き手の正しく伝える努力は欠かせません。

冒頭に「前提」のスライドをもうけたり、要所で(小さめのフォントで)但し書きをするのが良いと思います。

これもスライドが冗長になる恐れがあるのでトレードオフですね。

スライド内でメリハリをつける(フォントや色にこだわる)

「スライドだけ読んでもわかるようにする」「文脈や前提を書く」と、どうしてもスライド内の文字量が多くなります。 そうなってくると、スライドにメリハリをつけ、 伝えたいポイント一目でわかるようにする ことが重要です。

  • 見出しと本文のメリハリ
  • 重要なポイントのメリハリ

私は、前者をフォントの使い分け(e.g. ヒラギノ角ゴ StdN W8 と ヒラギノ丸ゴ ProN W4)、後者を色(赤系)で表しています。

おとしめない、挑発しない

これはスライドにかかわらず日常のコミュニケーションでも同じですが、 何かをおとしめたり、挑発するような表現は、受け手の気持ちを本質から遠ざけるだけ です。悪いマサカリを飛ばしたくなりますよね。

どうしても何かを否定せざるを得ない場合は、「文脈や前提を明記する」ことを忘れないようにしています。

id:konifar さんの以下記事が、とてもよくまとまっている素晴らしい記事です。

伝えたいことがあるなら汚い言葉は控えた方がいい - Konifar’s WIP

引用の力をかりる

著名な書籍などから引用するパターンです。

特に、あまり深掘りしたら伝えたいことから遠ざかってしまうような前提情報などについては、積極的に使います。 どこぞの誰かもわからない私なんかが一生懸命言うより、 皆から信頼される権威的な人物の言葉を借りた方が手っ取り早い ですね。

ただし、スライドのメイン部分となるような部分で乱用するのはよくありません。 スライドのメイン部分は自分の経験、知識を元に、自分の言葉で表現しなければ、何の意味もありません。

興味を喚起するタイトルをつける

タイトル(での釣り)は大切です。 そもそも開いてもらわないと、なにも始まらない ですから。

これももう恥ずかしがらず、ラノベ作家になったつもりで考えます。 ただし、過剰に期待をあおるものはだめです。内容と丈のあったタイトルをつけましょう。

私のスライドは、基本的に自分自身の課題を起点にしたものなので、各人の中にもあるであろう同じ課題を喚起するような、「質問」のパターンとしています。 「質問」の力はすごいですね。

タイトル パターン
あなたのチームの「いい人」は機能していますか? 内在している課題へ質問して、喚起するパターン
エンジニアが納期を守れていないとしたら、そこにはいったい何があるのだろう?(あるいはいったい何がないのだろう?) 内在している課題を自問の形で、喚起するパターン

猫の写真を多用する

  • 猫かわいいよ猫

ということで、私が「伝える」ために意識していたことを、つらつらと書いてみました。 なにかの役に立てれば幸いです・・・!

登壇の目的と、発表の作成で念頭に置いていた4つのこと(『あなたのチームの「いい人」は機能していますか?』 #SGT2016 登壇の記録)

Regional SCRUM GATHERING® Tokyo 2016 で、「あなたのチームの「いい人」は機能していますか?」 という発表をさせていただきました。 長いスライドにもかかわらず短い期間で多くの方に見ていただけたようで、ありがとうございます。

www.slideshare.net

伝えたかった事自体はほとんどスライド内で表したのですが、 登壇の目的(個人的なビジョン)と、発表スライド作成において気をつけていたことを、忘れないように書きとどめておこうと思います。

公募セッションへの応募に至った思い

大きくふたつありました。

ひとつ目は、 半年ほど前、今のプロダクトで開発責任者というポジション(≒ 開発チームマネージャ)になったのですが、 その着任の前、私自身がいちメンバーとして感じていた「焦り、慢心、自責の念」が入り組んだ複雑な感情、そして私と同様の悩みを抱えていた一人の信頼するメンバーの気持ちに、カタルシスを与えたいというパーソナルなものです。

今ではもう前向きに進んでいますが、きちんと "忘れてはならないけれど、もう昇華された過去の話" としたかったのです。 (※当日の発表の際に述べましたが、スライド No.47 で出てくる「マネージャになった人」は私です。)

ふたつ目は、できれば世の中の同じような人をひとりでも減らしたいという強い思いです。だって本当につらかったですからねw

ひとつめについては、不思議と作り上げるプロセスの中でほとんど達成されていき、結果的にはふたつ目を、登壇を通して成し遂げたいことと設定し、常に心の中心において準備をしていました。

作る際に念頭に置いていたこと

上記の強い思いをどうしても実現したかったので、内容の組み立てとスライド作成においては以下をずっと気にしていました。

  1. 事象に目をむけてもらえるように、名前をつけること(「いい人」「雪かき」)
  2. 聞く側のコンテキストとの共通点を見つけてもらえるように、可能な限りストーリーで語ること
  3. アクションをおこしてもらえるように How を織り交ぜること(仕分け、ランダムアサイン Bot、 OKR)
  4. その時の聴衆だけでなく、あとからスライドだけを見た人にもなるべく伝わるようにすること

すべてのプレゼンテーションにあてはまることとは思わないですが、今回の目的の達成のためには、これらが必須だと思っていました。

結果どうだったか

明確な計測はできないので、正直なんともいえません。

しかしひとつ大きく反省しているのは、ランダムアサインにしても OKR にしても、その実行に至るまでにチーム内でストーリーがあったことを語りきれなかったことです。

チームメンバーの対話や、そこから醸成された信頼関係、それを土台としたチーム内の合意があったことが、これらを実現へと導きました。(本当にいいチームメンバーに恵まれていると思います)

ここをすっ飛ばして、なにか無理にアクションを起こしてしまうことは誰のためにもならないと思います(それこそ旧来型マネジメントです)ので、そういった勘違いを読み手に与えていないかなとすこし心配になっています。

今回の発表のタイトルでオマージュした「あなたのチームは、機能していますか?」でも、「信頼」が土台として語られていますね。耳の痛い良本です。おすすめです。

あなたのチームは、機能してますか?

あなたのチームは、機能してますか?

予想していなかったこと

はてブコメントや Twitter のコメントを見ていると、ソフトウェア開発に関連しないであろう方々のコメントも多く見られました。

そもそもそういった方の目に届くこと、しかも共感が起こるとはまったく想定していなかったので、どこにでもある普遍的な問題なのだなぁと気付かされる良い機会となりました。

(「自己組織化チーム」という考え方を前提にしていることが伝わっていないであろうコメントがいくつかあったのは、すこし心苦しかったです。上記の 4 のツメが甘かった証拠ですね。)

終わって思うこと

終わった直後に感じたのは、「もう二度と登壇なんてしたくない!」ということですw 途中 胃腸炎にかかりながら(Not ストレス)、幾週かの週末をまるまる考える時間と作る時間に注いだので、もうほんとにしばらく自堕落になりたくて仕方なかったですw

ただ、色々なフィードバックや気付きをもらいましたし、思考に費やした時間はムダではなかったと思うので、またやってもいいかなぁとちょっとだけ思い始めています。

最後に、スライド内のストーリーにあらわれるもう一人の「いい人」(元シェル芸人さん)は、構想の段階から何度も対話相手になってくれ、切り口のアイディアのキッカケのキーワードをくれたり、話すことで思考を整理する相手になってくれたので、ほんと感謝してます。「いい人」だ。ほんとあざすです。

(このもう一人の「いい人」とノリで Podcast を始めてみたので、怖いもの知らずの方はぜひ → omoiyari.fm

補足:スライド内で紹介した書籍

裏方ほどおいしい仕事はない!

裏方ほどおいしい仕事はない!

How Google Works (ハウ・グーグル・ワークス)  ―私たちの働き方とマネジメント

How Google Works (ハウ・グーグル・ワークス) ―私たちの働き方とマネジメント

凡庸なSEが、大規模SIerの集団でできること - DevLOVE甲子園 2013

昨日 DevLOVE 甲子園が開催されていましたね。
とても熱く、すごく勇気づけられるイベントです。
今回諸々重なり参加ができず、タイムラインやアップロードされているスライドで楽しんでいます。

このイベントは私自身も、前職の SIer にいた 2013年に登壇させていただきました。
自分の中で本当に大きな人生のターニングポイントになった機会でした。
当時、なかなか自分の考えや行動を振り返る機会はなく、ただがむしゃらに走っていたのですが、この発表を通して自分が本当になにを重要に思ってなにを心に据えているのか、というのが自分のなかですっきり整理された覚えがあります。 (資料はかなり詰め込みまくっていて、資料が整理されているかというのは別ですが笑)

当時は、当時の現場を貶めてしまっているのでは、というような感覚がありスライドは公開しなかったのですが、当時から決してそのような思いはなかったこと、またこのスライドを見て「今の現場を理想の現場にする」一歩を踏み出す人がたったひとりでもいればいいなと思い、公開してみました。

また、当時の自分の頑張りに励まされている自分がいて、その頑張りに顔向けできないなと感じたことも、あえて古い資料を公開しようと思ったキッカケのひとつです。頑張れ自分。

Apple Watch + MacID なんか楽しい

macid.co

初期設定

↓ に詳しい記事がありますね。 touchlab.jp

オートロック

以下設定をしておくと、Mac から(iPhoneが)離れると自動的にロックしてくれます。

f:id:ykmc:20150524161438p:plain

カフェで作業していて、トイレに立つときにいちいちロックする必要がなくなりました。 しかも「ロックしました!」って 通知してくれるので、(正直別にいらいないけど、)ちょっと安心感もあります。

f:id:ykmc:20150524161810p:plain

ロック解除

ロック状態で Mac の近くに戻ると、以下のような通知が来ます。

f:id:ykmc:20150524161817p:plain

ここで「Authorise」を押すとロック解除されます。

自動ロック解除

以下設定をしておくと、近づいただけでロック解除されます。

f:id:ykmc:20150524162610p:plain

でもちょっとタイムラグがある感じかな?

「アジャイルソフトウェア開発宣言」を引用する際の注意

述べられている価値

「アジャイルソフトウェア開発宣言」では以下の4 つの価値が述べられています。

私たちは、ソフトウェア開発の実践
あるいは実践を手助けをする活動を通じて、
よりよい開発方法を見つけだそうとしている。
この活動を通して、私たちは以下の価値に至った。

  • プロセスやツールよりも個人と対話を、
  • 包括的なドキュメントよりも動くソフトウェアを、
  • 契約交渉よりも顧客との協調を、
  • 計画に従うことよりも変化への対応を、

価値とする。すなわち、左記のことがらに価値があることを
認めながらも、私たちは右記のことがらにより価値をおく。

よく聞く誤解

アジャイル開発に触れ始めた方がよく持つ誤解として「ドキュメント書かなくていいんでしょ?」「計画立てなくていいんでしょ?」というものがあります(結構マジで。)

左記のことがらに価値があることを認めながらも、、、」の部分がすっかり読みとばされてしまっているのです。

誤解を生まないために

誤解を生む原因のひとつとして、アジャイルを解説する記事やスライドで、上記の4つの価値の部分だけが引用されその部分だけが一人歩きしてしまう、ということがあると思います。

そもそも、「アジャイルソフトウェア開発宣言」のサイト内に、

© 2001, 上記の著者たち
この宣言は、この注意書きも含めた形で全文を含めることを条件に
自由にコピーしてよい。

という注意書きがありますね。 きちんと守らないとですね。

スライド修正しました(反省)

先日公開した「スクラム再入門」というスライドでも、「アジャイルソフトウェア開発宣言」を引用したページがあったのですが、まんまと例の 4行のみの引用をしてしまっていたので、追記して更新しました。反省・・・。

【おすすめアプリ】Apple Watch に時間管理の調教をしてもらおう

Appe Watch (無印、38mm)を買ってから1週間が経ちました。

色々良いところありますが、あえてひとつ上げるとすれば、 「Taptic Engine の振動、めっちゃ気持ちいいよ!」です。

このご褒美のような気持ちいい振動で、Pomodoro Technique の時間サイクルを調教してもらっています。

使っているアプリは「5217 Pomodoro plus」です

機能はいたってシンプルで、 こんな感じで時間が表示されて、、、 f:id:ykmc:20150504200425p:plain

こんな感じで時間のサイクルの節目で通知してくれます f:id:ykmc:20150504200926p:plain

このご褒美振動に合わせて、作業の「集中 - 休憩」のサイクルを繰り返しています。

ちなみにこのアプリは時間のカスタマイズもできるので、こらえ性のない私は、まずは「20分 - 5分」のサイクルで調教してもらっています。

Scrum をひもとくパタン

社内でのリーン/アジャイル開発の学習、推進活動の一環で、「パタン・ランゲージを用いてスクラムの本質をひもとく」という発表を行いました。

www.gitbook.com

スライド内にも書いていますが、この発表の直前まで、本家の Scrum Petterns について全く知りませんでした。
「後発で質の悪いもの作ってしまったな・・・」という恥ずかしい思いと、「自分がやっていたことも検討違いってわけじゃなかったんだな」という嬉しい思いが入り混じった不思議な気分でした。

www.scrumplop.org

ただ、スクラムのパタンを作る過程自体がとても有益で楽しものだったので、興味がある人と引き続き取り組んで行きたいなー。

あと、 Agile Japan 2015 の翌日の Comeback Japan 2015 ~日本のアジャイルを応援しよう~ で、このスライドを飛び入り発表させてもらいました。

僕はデブサミ 2012 の平鍋さんのセッションで稲妻を受けてエンジニア人生が変わったので、平鍋さんの前で話をさせていただくだけでも感慨深かった・・・。

www.publickey1.jp