今日新卒エンジニアに「推薦図書は何ですか?」と質問された。ということで今日その場で挙げた書籍も含めてだらだらっとリストアップしておこう。なお自分が過去読んでいいなと思った本からのピックアップなので、かなり偏ってると思ってもらって間違いない。
これ読んでないなんてありえない。既に読んでいる人も多いと思うけれども、まだ読んでいないなら黙って読め(記事)。
マネージメントコーチのハワード・ゴールドマンの教えによる物の考え方、問題解決やプロジェクトの進め方がわかる本(記事、記事)。
曖昧ではない明確な文の書き方がこれでわかる。
古典かつ超スタンダード(記事)。
超スタンダード(記事)。
共通のクレドを持って主体的に考え活動することの素晴しさがわかる本(記事)。
こちらは個人がマイクレドを持つことのパワフルさがわかる本(記事)。
Getting Things Done (GTD)の新訳版。仕事量が多くなってきてストレスを感じた時にきっと役に立つ。
[ お薦めの本 ]
ミーティングのアジェンダに華がないので、ボケての画像貼っておいた。ウケた。
ミーティングの最初に「うまくいっていることを全員が話す」ことでイケル感じのムードをつくると良いというのは「すごい会議」で学んだ。ミーティングってけっこうムードに左右されるので重要。
みんなが自分で声を出してうまくいっていることを話すのが一番いいのだけれど、時間とか場の関係でそうもいかなかったりする。自分が進行でプロジェクタに PC をつないでいる時は、始まる前に今日の一押しボケてを表示しておいたりする。結構前からやっているのだけれど、場がゆるんで良い。
ゆーすけべー氏がトークの開始時間前にボケてを表示して、ゆるくつかみとっていたりしているのいいなと思って真似させていただいている。
2月の Developers Summit 2015 で zakwa 氏と再会したのをきっかけに、当時一緒に仕事をしていた気が置けないソフトウェア開発者4人で同窓会をすることになった。セッティングしてくれた zakwa 氏ありがとう!
手配してくれたお店は「焼きたてパンとワインのお店」COGS DINING KAGURAZAKA。神楽坂から路地に入ったところにあるお店で、上品な味の料理で満足だった。店内もうるさくなくて話しやすかったし、たばこを吸っている人もいなかったので快適だった。
現職のまま続けている1人と、別の場所で働くことになった3人だけれどみなそれぞれソフトウェア開発現場に関わっていて、それぞれの開発スタイルなどについて情報交換したり。
大企業だからしっかりした開発をしているとか、スタートアップだからモダンな開発をしているとかでは必ずしも無いよねという話だった。例えばバージョン管理一つにしてもうまくできていない(やっていない)場合も多いとのこと。当時を振り返ってみると小規模かつ独学の状況ながら、今では普通になってきたプラクティスやツールをその時から実践/活用していたなと自画自賛した。
「書けなくなったホワイトボードマーカーはその場で床に投げ捨て」に共感を持ってもらえていたのが、振り返って当時の自分の一番の成果だな。
退職時に使っていた社内 Wiki は Naney 謹製のものだったのでその後どうなったのかなとたまに気になっていたのだけれど、ビル管理会社の人に社内サーバの電源を切られたことによりサーバごと死んで闇に葬られたらしい。R.I.P.
同窓会らしく「あのひとは今」的な話をしたり、当時フィルムカメラで撮っていた業務風景のアルバムを持ってきて盛り上がったり。あとはレーシックやドライアイ治療ひぇー的な話題が出たり。あとは展示会の時のレクサー・リサーチポロシャツ制作秘話とか。
そういえば出席はできなかった2013年2月開催の「LEXER設立20周年記念サロン・パーティ」で会社のるぐるロゴの立体置物が配られたと聞いて、あ、欲しかったなーと。
その場で時間をとり全員が発言する内容を手元に書いてから順番にしれっと発表するミーティングスタイルにすることで、出席者全員がミーティングにコミットするようになり、また大きな声の人が勝つことなく全員が他人の意見に左右されずに考えを話せるようになります。これを最初に学んだのは「すごい会議」でした。
「事前に各自ふりかえったことをボード(だったりシート)に書いておいて、ミーティングではそれを話し合う」というふりかえりスタイルは参加しない人が出てくるので良くないと、スクラムマスターが話してくれたこともありました。
次回のふりかえりの時間までに気がついたことを忘れないように書き出しておくというのはもちろん良いことですが、ミーティングの進行の際にも「書いてから発表する」流れを入れておくことが大切だなと思っています。
one-on-one ミーティングにあたっては相手と自分のみ閲覧・編集できるノート(アジェンダ)を用意している。
ここ数年は Google ドキュメントを使っていて、半期(半年)毎に1ドキュメント作成してそこに書くようにしている。そこに毎週(あるいは隔週)の one-on-one ミーティング前に日別の見出しを作って下に追記していっている(新しい日を上に追加していく方がスクロールせずに書き始められて楽なんだけれど見返す際に日付順の方が圧倒的に見やすい)。
今使っている形式は以下(表現上 Markdown 形式にしているけど、実際はGoogle ドキュメントのスタイルで)。
通算回数は「結構話し合っている!」感が出てくるので分かる人は書いておくようにしている。ミーティングの最初に「うまくいっていることを全員が話す」ことでイケル感じのムードをつくると良いというのは「すごい会議」で学んだ。
# 2019年05月30日(木) (第n回) ## うまくいっていること - (相手の名前): - 前回: (前回のうまくいっていることを転記) - 今回: - (自分の名前): - 前回: (前回のうまくいっていることを転記) - 今回: ## 話したいこと・気になること ### (相手の名前)より ### (自分の名前)より
自分の方が話しすぎちゃっているかもという反省から「話したいこと・気になること」から人別のセクション消して自分の方の議題をあらかじめ書かない方がいいんじゃないかとちょっと思って今週ちょっと消してみたりした。
でも Google re:Work - ガイド: マネージャーにコーチングを指導するのサンプルテンプレートでもマネージャーとチームメンバーのセクションがあって、やっぱり問題ないかなって思えてきたので今まで通りにすることにした。ってことがあったので書いてみた感じ。
「高校生のバイトでもできること。」とうフレーズが強烈に印象に残っていて、でも何で読んだか思い出せずもやっとしていた。それが先日ノートテキストファイルを整理していたらメモが出てきてようやく思い出せたのだ。
15年前に読んだ『仕事のヒント』だ。
「どのようにすればで言ってみる。」というのを学んだ『すごいやり方』『すごい会議』を読んだのも2005年。この頃から強く「できない理由を探すよりできる方法を考える」ことを意識するようになったんだ。できない理由を探すよりもできる方法を考える方がかっこいいと思ってる。
[ opinion ] [ 行動原則 ] [ Naney の行動原則 ]
one-on-one ミーティングでは前向きな雰囲気を作るように「うまくいっていること」を最初に話すフォーマットにしている(one-on-one ミーティングのノート形式)。
『すごい会議』で
なかには、「うまくいっていることはない」という人(たぶん不機嫌な顔で)がいるかもしれませんが、そのときは「『部屋の電気がついている』ってぐらいのことでかまわないので3つ書いてください」とリクエストします。
と書かれていたのが印象だったこともあり、イケル感じのムードをつくるのを優先で「仕事とは関係ない話でも全然いいですよ」といってやってきた。
いい感じのアイスブレイクになるし、続けていると興味関心をもっていることや価値観が垣間見えてくるしで「仕事とは関係ない話」も悪くない。リモートワークが増えて雑談の機会が減った今、むしろ大切にした方がいいかもしれない。
とはいえ「うまくいっていることを話す」のは仕事について「いままでに何が達成されたか」を共有して気持ちを高めるというのが本来だよなと。
まずは「うまくいっていること」のアジェンダのままで自分が「いままでに何が達成されたか」を話すようにし、どこかのタイミングで質問の表現もアレンジしてみようと思う。
会議の資料は「箇条書きではなく文章で書く」のが Amazon のルールと紹介している書籍『amazonのすごい会議 ジェフ・ベゾスが生んだマネジメントの技法』が気になって全部読んでみた。
「会議資料の準備」と Amazon 流の「意思決定会議」「アイデア出し会議」「進捗管理会議」、そしてそのやり方の背景にある信条「Our Leadership Principles」との関係について読みやすくまとめられていた。
本書の内容は「Our Leadership Principles」という価値観・行動原則を体現したマネジメントや会議のスタイルだ。なので読んでやり方だけ真似てもうまくいかない。Amazon 流会議の紹介から同意できる大切にしたい価値観・行動原則を見つけ自分や組織に取り込みつつ、会議スタイルも参考にしていくのが良いのだろう。いや価値観・行動原則を取り込められたのなら、もう真似などせずとも自ずとイケてる会議スタイルになっていっているに違いない。
とはいえピンポイントで「なるほど」「やってみたい」というのもいろいろあったので、それはそれでピックアップして参考にしたい。
「箇条書きではなく文章で書く」については
いつ誰が読んでも確実に伝わる
と「伝えるための表現形式」として、また
きちんとした文章にするとなると、読んだときに辻褄が合わない部分が出て来ないように、最初から整合性をとらなくてはなりません。そのため、吟味に吟味を重ね、適切な情報を用いて推敲を重ねなければなりません。
と「書いて考えるための表現形式」として文章形式(ナレーティブ形式)の良さが説明されいた。
最近はできるだけ箇条書きではなく文章で書くようにしている。やってみると、なるほどそうだなと。お勧めのプラクティスだ。
「定形フォーマットはつくらない」という話には唸った。
先人からの学びや自身の経験から「これは共通理解や意思決定に必要」という項目が自分なりにいくつかあって、ドキュメントの構成として意識していたりする。
しかしその構成に固執したり他人に強いたりすると、変化の阻害要因になりかねないと。定形にすると便利で楽だけれど思考の硬直につながりかねない。意識したい。
は意識したりやってみたりしたいなと思った。
それから
というのは、『すごい会議』で学んだ
というのと同じ普遍的な考え方だな。ガッツがいるのでついユルくなりがちだが、スピードと成果が圧倒的に変わってくるのでしっかり踏ん張ってコミット・リクエストしたい。
[ 読書ノート ]
Naney (なにい) です。株式会社MIXIで SNS 事業の部長をしています。
※本サイトの内容は個人的見解であり所属組織とは関係ありません。