エンジニアがチームで価値を発揮するために気をつけたいこと

この記事は、はてなディレクターアドベントカレンダー2016の17日目のエントリです。（昨日は id:daiksy の『嫌われない勇気』でした。）

id:motemen です。過去には立ち上げ期の Mackerel チームのディレクターをしていましたが、当時のことは 過去の記事 にあるとおりで、あまりディレクターとしてほかに書けることもないので違う話を。

今年のはじめごろに エンジニアの専門性を伸ばすためにディレクターに気をつけてほしい3つのこと - Hatena Developer Blog という記事が書かれましたが、これはディレクターからエンジニアに向けた話だったのでこれの逆バージョンを書いてみようと思います。

先に書いておくと、ぼくは新卒ではてなに入社し、ディレクターの id:nmy さん（アドベントカレンダー最終日）や id:chris4403 さん（アドベントカレンダーのエントリ）のもとアプリケーションエンジニアの一人として（当時はそれほど数もいなかったこともあって）、それなりに重宝されながら働いていました。当時は若者特有の万能感でもってバリバリ仕事をこなしていた……ように思っていたような気がするんだけど、いやー今思い返してみるとかなりの寛大さをもって許されていたのだな、と思うばかりです。自分があまりに近視眼的な仕事ばかりして満足していたのは、当時ディレクターとしてチームをまとめていた人たちが足りない部分を埋めてくれていたからだったんだ……って気づいたのは数年経っていろいろなチームを経験してからの話。

これはそういう過去の自分への戒めでもあり、はてなでいえば2年目あたり、会社での働きかたにも慣れてきたなって思えるエンジニアに気をつけてみてほしいことでもあります。

ユーザはどこにいるのか

ぼくたちエンジニアはたまさか技術というものを持っているから、それを日々の仕事として、少なくない時間をかけてお金を稼いでいるわけだけど、そのお金はユーザに何らかの形で価値を提供していることから出てきている。ウェブサービスやスマートフォンアプリで生計を立てている企業の一員として、この最終的に価値を届けたい人のために何が必要か、というのを考えていなければいけない。

どんなに古くメンテナンスされていないコードベースでも、それがユーザに使われて喜びを与えている限りは、新しく美しいまだデプロイされていないサービスよりは100倍も価値があるのだって視点は忘れないようにしたい。

自分たちがやりたいことは何か

自分じゃなくて自分たち。エンジニアは手を動かして触れる対象が身近にあって、問題は探せばいくらでも転がっているので、やろうと思えば好きなだけ技術的に深追いできてしまう。それで何かがよくなることもあるけど、それが局所最適に陥ってしまうこともまたよくあることだと思う。

思いついた解決にすぐに飛びつく前に、いまいちど自分たちが何のためにチームを組んでいるのかを考えることが必要。エンジニアの仕事は問題解決であって、プログラミングではない。

エンジニアの殻に閉じこもっていないか

自分たちの作ったシステムが直接にでも間接にでもユーザに近いところで価値を発揮していること、システムなしではその価値が実現しないことをエンジニアは誇ってもよいと思うけれど、それは裏を返せばエンジニアがボトルネックになりうるということでもある。最終的な成果物というのは多かれ少なかれエンジニア以外の職種の手が入って初めてユーザに届くものなので、デザイナや営業やサポートや編集や企画、そしてディレクターといった職能の人々にエンジニアの仕事がスムーズに渡っていくように見守らなければいけない。そして彼らのために技術的な支援が行えるのなら、それを積極的にしていくこともエンジニアの仕事になるはず。

そういう意味ではチームメイトもエンジニアの顧客であり、チーミングの技術というものもエンジニアがカバーすべき技術のひとつに数えられるのじゃないかと思います。

---

はてなディレクターアドベントカレンダー2016、明日は id:shimobayashi です。

直感的なグラフを簡単に作れるウェブアプリ

を作った。どうぞご利用ください。

The Beautiful Graph Maker

下の画像のようなグラフを簡単に生成できます。🙁 から 😊 になったことがひと目でわかりますね。説得力もあるのではないでしょうか。

矢印やY軸のラベルはクリックで変更できます。

実装には Elm を使ってみた。アーキテクチャが強制されるせいか、予想以上に書きやすかった。prompt() したいだけのところが妙に面倒で window.prompt() in Elm を参考に JavaScript も書くはめになった。あと画像ダウンロードのとこも生 JS です……。

GitHub - motemen/beautiful-graph-maker

なぜプレゼンで失敗するのか

自分も大方の人間と同じように人前で喋るのは苦手で、可能であれば避けたいと思っているけれど、一方でこの業界で生きのこる方法のひとつとして避けられないものでもあると思っている（ので苦しい）。若かりしころ手痛い失敗をしたこともあって、かなり苦手意識を持ちつづけていたが、最近はわりかし上手く付き合えるようになってきたかなとふり返って思う。

今もうまいプレゼンテーションをする方法は知らないし、それを僕から知りたいという人はいないとおもうが、プレゼンでしくじる方法なら経験から知っている。準備をしないこと。自分の経験からはそうだし、まずいプレゼンを見ていてもそうなんだろうな、と思うことはやっぱり多い。

このエントリはプレゼンがいやでいやで仕方がなかった自分のための分析であり、プレゼンのマイナスレベルをゼロまで引き上げようとする努力です。ソフトウェアエンジニアの技術者間交流のためのプレゼンというのが前提。

準備にかける時間が足りていない

そもそもの話。『パブリックスピーカーの告白』という本を昔に読んで、今となっては内容はほとんど覚えていないが、プレゼン時間×聴衆の人数くらいの時間はかけよ、というようなことが書いてあったはず。愚直に従うものではないだろうけど、他人の時間を使うのだという意識を持とういうことだと思う。

やる気が出なくて準備に体が動かない、というパターンがもっともあると思う。人前で話すことは怖いし、準備に時間をかければかけるほどその失敗が具体的になって目の前に現れてくるように感じてしまう。それだったら何も準備しないで臨んで失敗したほうがマシだ……という風にすら考えてしまう。自分の場合はアルコールが使えるので、自分をシラフの自分と酒を飲んだ自分に分けて、ここから先は酒を飲んだときにやる、あとはシラフのときに考える……という風に分業しています。酒を飲むと気が大きくなって別のことをしはじめたりするので、諸刃の剣ではある。

他人が「資料できてない」みたいなことをツイートしていても、絶対に安心したり、真似しようとしたりしてはいけない。そういう人たちは強者であって、すでに自分たち自身のなかに蓄えがあるからそういう所業ができるのであり、それにプレゼンテーションは一人きりの舞台なので他人がどうこうというのは全く関係がないことだからだ。

時間を割く対象が間違っている

これまで、だいたい最初に資料を作りはじめて失敗するパターンが多かった。プレゼンテーションの準備というのは聴衆に受けいれられるストーリーを作ることが一番であって、資料を作ることではない。最近はとりかかる際に、アウトラインも書かず、完全に頭のなかにあるものだけから口に出して喋ってみるようにしている。喋ってみると話の内容を直列化しなければいけないので、話の内容の依存関係から意外と整理しやすくなったりする。

このストーリー作りにもっとも時間を割かないといけない。どんな聴衆がいて、何を持ち帰ってもらうのかもはじめに考えておくと手戻りが少ない。勝手だけど、自分の場合は id:hakobe932 さんを想定聴衆に置くことがおおいです（自分が喋れる分野ならまず押さえているし、にこやかに聞いてくれるから）。

巷のスライドを見ると凝ったものが多く、こんな風にできればわかりやすいだろうな、と思うものの、そんな能力はないので愚直に箇条書きする。凝りだすとキリがないので最初から諦めていく。

プレゼンは喋りがメインであるという前提のもと、話したい内容の全部ではなく、それをさらに蒸留したものをスライドには書く。フォントサイズをあまりに小さくしない。ページからあふれる場合は削るか分けるかする。

リハーサルをしていない

前の項目に被るが、独立した一項目にしていいやつ。とても重要。

リハーサルはやった方がいいことは分かっているものの、失敗をより具体的にイメージさせるものなので、やらないですむならそれがいいと思ってしまう。しかし本当のところは、やった方がいいものではなくてやらなければならないこと。ストーリーなしの資料作りが設計なしの実装なら、リハーサルなしのプレゼンはテストなしの本番投入。たまにはスリルがあっていいかもしれない。短くない時間、自分のために他人を拘束するのにぶっつけ本番で舞台に登るなんてのは大変おこがましいことである。

……などと建前上はわかっていても、できないから苦しいのである。わかります。経験上、とりあえず自分の作ったスライドを見ずに喋りだすと、言葉が続くことが多い。先の、ストーリーをまず喋ってみることをしながら作っていると、身体も慣れているのだと思う。腕を振ったり歩き回ったりしながら喋るとやりやすい気がする。

巷のエントリを読むとリハーサルをもとに時間の調整をする……とされていることが多いが、正直本番で冷静に時計が見られたためしがないので、せいぜい時間がオーバーしないようにしておくくらい。

他人に聴いてもらうのが一番だと思うけど、自主的にこれをできたことはないので口をつぐみます。

自信がない

一番つらいやつ。準備不足の最初にして最大の原因。ストーリーを作らずリハーサルもせず無目的にスライド作りに手を動かしてしまうのは自信がないから。対処方法は各自見つけるしかないと思うけど、ストーリーを口の中でくり返しているうちに、プレゼンがだんだんと精神を使う作業というよりは身体的なものになって気が楽になってくることはあった。あまり頭を使わなくなる。

自信がないからといって本論から逸れる話をしない。より自信がなさそうに見える。楽屋ネタやアニメネタを入れない。笑いを取りにいくのも難しいのでやめよう。

自分以外の人物が自分のプレゼンをハキハキと行っていることを想像するのもいい。全方位的に恥ずかしい話だけど、自分の場合はアニメ『アイドルマスター』のプロデューサーを代わりに演台に立ててます。スーツにネクタイなのが好印象なのだと思う。なんそれって感じですけど。

まとめ

プレゼンは身体技術なので身体に叩き込む。身体を動かすと、やる気もあとからついてくる。

おたがい頑張りましょう。

パブリックスピーカーの告白 ―効果的な講演、プレゼンテーション、講義への心構えと話し方

英国王のスピーチ スタンダード・エディション [DVD]

吃音者のスピーチ。一緒にするなと言われるかもしれないけど何か通じるものはあるんじゃないかと思う。