nDiki : すごい会議

超私的配属新卒エンジニア向け推薦図書

今日新卒エンジニアに「推薦図書は何ですか?」と質問された。ということで今日その場で挙げた書籍も含めてだらだらっとリストアップしておこう。なお自分が過去読んでいいなと思った本からのピックアップなので、かなり偏ってると思ってもらって間違いない。

絶対絶対の必読書

人を動かす

これ読んでないなんてありえない。既に読んでいる人も多いと思うけれども、まだ読んでいないなら黙って読め(記事)。

• 人を動かす

考え方

すごい会議とすごい考え方

マネージメントコーチのハワード・ゴールドマンの教えによる物の考え方、問題解決やプロジェクトの進め方がわかる本(記事、記事)。

• すごい会議
• すごい考え方

日本語

日本語の作文技術

曖昧ではない明確な文の書き方がこれでわかる。

• 日本語の作文技術

ソフトウェア開発者として

ピープルウエア

古典かつ超スタンダード(記事)。

• ピープルウエア

Joel on Software

超スタンダード(記事)。

• Joel on Software

クレド

リッツ・カールトンが大切にする サービスを超える瞬間

共通のクレドを持って主体的に考え活動することの素晴しさがわかる本(記事)。

• リッツ・カールトンが大切にする サービスを超える瞬間

行動力力

こちらは個人がマイクレドを持つことのパワフルさがわかる本(記事)。

• 行動力力

2012年11月23日追加

はじめてのGTD ストレスフリーの整理術

Getting Things Done (GTD)の新訳版。仕事量が多くなってきてストレスを感じた時にきっと役に立つ。

• はじめてのGTD ストレスフリーの整理術

---

[ お薦めの本 ]

書いてから発表する

スプリントレトロスペクティブの KPT。

発言する内容をまず手元の紙に書いて、1人1つずつ順番にしれっと発表していくという「すごい会議」のルールを久しぶりに守った。やっぱり直接ホワイトボードに書いていくより、この方法の方が活性化していいね。

あと今回は書き出す時間を7分間と決めてタイマーもかけてみた。昨年秋に受けた研修で講師が使っていたテクニックで集中度がアップする。自分の Android 端末にタイマーないなーと思ってもう1人の iPhone に頼ったんだけれど、今確認したら「アラームと時計」というアプリにタイマー機能がついてた。

あと書くのは付箋じゃなくて情報カードね。個人的に。

今日のさえずり: 「誰が」「いつまでに」「なにをして」「どんな成果をだすか」を明確にしてコミットする/リクエストする

2013年04月17日

• 07:04 RT @simplemixi: 本日Ver1.0のアプリをリリースしました！https://t.co/eKnjK6xNeO
• 07:12 「おかあさんといっしょ」正座して待つ。
• 08:54 おかあさんといっしょで、そわがーる確認した。きっと母親似に違いない。
• 08:57 たいそうのおねえさん代わったの?
• 09:18 T シャツ + パーカーでも暑い。体が「じん」化してるっぽい。
• 09:52 @mushikabu じんさんの暑がりっぷりは半端ないです。
• 10:04 メーテルを見て隣のエンジニアが「ルナ」さんって。「ルナ」さんて誰?
• 10:22 ネット上の動画って1分台だったらサクッと見るけど、2分以上だとちょっとハードルが上がる。
• 10:57 “知らなかったiPhoneの意外な使い方が分かるアプリ『使い方ガイド』 : ライフハッカー［日本版］” http://t.co/tAjWRdNubP
• 11:54 トイレで「アリー my Love」した。
• 12:02 「誰が」「いつまでに」「なにをして」「どんな成果をだすか」を明確にしてコミットする/リクエストするの最近おろそかになっていたので気を引き締める。
• 12:22 「会議では『提案』『リクエスト』『明確化のための質問』以外の発言は、99%無駄な発言です。 -- すごい会議 p.30」というのも再度意識しなおし。
• 15:02 新卒懇親会で話をできた人ありがとうございました。業務理解と今後のビジョンの検討の材料にちょっとでもなれば幸いです。
• 16:02 RT @mixi_engineers: 株式会社ミクシィではユーザーサポート・健全化開発エンジニアも求めています。「求める人物像」のレーダーチャートが、さらに何やらパックマンみたいな形になってますが、そんなテイストで力をふるって頂けるかた、come join us! ht ...
• 16:03 求める事務処理能力は限りなく低いです。
• 22:03 そういえば新卒懇親会で「(昨年度内定者アルバイトに対する突っ込みをを見て)厳しい人だと思ってました」って言われた。ゆるキビと思っていただけばいいと思います。
• 22:39 ユーザサポートのマネージャと野望について話した。
• 23:09 夜行性とコーヤコーヤ星、似てる。

ミーティングの冒頭をボケてで始める

ミーティングのアジェンダに華がないので、ボケての画像貼っておいた。ウケた。

ミーティングの最初に「うまくいっていることを全員が話す」ことでイケル感じのムードをつくると良いというのは「すごい会議」で学んだ。ミーティングってけっこうムードに左右されるので重要。

みんなが自分で声を出してうまくいっていることを話すのが一番いいのだけれど、時間とか場の関係でそうもいかなかったりする。自分が進行でプロジェクタに PC をつないでいる時は、始まる前に今日の一押しボケてを表示しておいたりする。結構前からやっているのだけれど、場がゆるんで良い。

ゆーすけべー氏がトークの開始時間前にボケてを表示して、ゆるくつかみとっていたりしているのいいなと思って真似させていただいている。

レクサー・リサーチ開発同窓会

2月の Developers Summit 2015 で zakwa 氏と再会したのをきっかけに、当時一緒に仕事をしていた気が置けないソフトウェア開発者4人で同窓会をすることになった。セッティングしてくれた zakwa 氏ありがとう!

COGS DINING KAGURAZAKA (コグス ダイニング 神楽坂)

手配してくれたお店は「焼きたてパンとワインのお店」COGS DINING KAGURAZAKA。神楽坂から路地に入ったところにあるお店で、上品な味の料理で満足だった。店内もうるさくなくて話しやすかったし、たばこを吸っている人もいなかったので快適だった。

• http://www.cogsdining.com/

ソフトウェア開発

現職のまま続けている1人と、別の場所で働くことになった3人だけれどみなそれぞれソフトウェア開発現場に関わっていて、それぞれの開発スタイルなどについて情報交換したり。

大企業だからしっかりした開発をしているとか、スタートアップだからモダンな開発をしているとかでは必ずしも無いよねという話だった。例えばバージョン管理一つにしてもうまくできていない(やっていない)場合も多いとのこと。当時を振り返ってみると小規模かつ独学の状況ながら、今では普通になってきたプラクティスやツールをその時から実践/活用していたなと自画自賛した。

• プロジェクト
  • ソフトウェアかんばん
  • ITS (影舞・Redmine) の利用
    • BTS やコミットメントリストとして。
  • スタンドアップでの朝会
  • すごい会議
  • 成果物完成毎の記念撮影
• 情報共有
  • 社内 Wiki
    • 2002年3月初設置。
  • 社内 Blog
    • 2006年あたり(記事)
• 開発ツール
  • バージョン管理 (CVS・Subversion・Git)
  • pLaTeX2e を使ったドキュメンテーション
• その他
  • 書けなくなったホワイトボードマーカーはその場で床に投げ捨て

「書けなくなったホワイトボードマーカーはその場で床に投げ捨て」に共感を持ってもらえていたのが、振り返って当時の自分の一番の成果だな。

退職時に使っていた社内 Wiki は Naney 謹製のものだったのでその後どうなったのかなとたまに気になっていたのだけれど、ビル管理会社の人に社内サーバの電源を切られたことによりサーバごと死んで闇に葬られたらしい。R.I.P.

その他

同窓会らしく「あのひとは今」的な話をしたり、当時フィルムカメラで撮っていた業務風景のアルバムを持ってきて盛り上がったり。あとはレーシックやドライアイ治療ひぇー的な話題が出たり。あとは展示会の時のレクサー・リサーチポロシャツ制作秘話とか。

そういえば出席はできなかった2013年2月開催の「LEXER設立20周年記念サロン・パーティ」で会社のるぐるロゴの立体置物が配られたと聞いて、あ、欲しかったなーと。

ふりかえりは「書いてから発表する」

その場で時間をとり全員が発言する内容を手元に書いてから順番にしれっと発表するミーティングスタイルにすることで、出席者全員がミーティングにコミットするようになり、また大きな声の人が勝つことなく全員が他人の意見に左右されずに考えを話せるようになります。これを最初に学んだのは「すごい会議」でした。

「事前に各自ふりかえったことをボード(だったりシート)に書いておいて、ミーティングではそれを話し合う」というふりかえりスタイルは参加しない人が出てくるので良くないと、スクラムマスターが話してくれたこともありました。

次回のふりかえりの時間までに気がついたことを忘れないように書き出しておくというのはもちろん良いことですが、ミーティングの進行の際にも「書いてから発表する」流れを入れておくことが大切だなと思っています。

one-on-one ミーティングのノート形式

one-on-one ミーティングにあたっては相手と自分のみ閲覧・編集できるノート(アジェンダ)を用意している。

ここ数年は Google ドキュメントを使っていて、半期(半年)毎に1ドキュメント作成してそこに書くようにしている。そこに毎週(あるいは隔週)の one-on-one ミーティング前に日別の見出しを作って下に追記していっている(新しい日を上に追加していく方がスクロールせずに書き始められて楽なんだけれど見返す際に日付順の方が圧倒的に見やすい)。

今使っている形式は以下(表現上 Markdown 形式にしているけど、実際はGoogle ドキュメントのスタイルで)。

通算回数は「結構話し合っている!」感が出てくるので分かる人は書いておくようにしている。ミーティングの最初に「うまくいっていることを全員が話す」ことでイケル感じのムードをつくると良いというのは「すごい会議」で学んだ。

 # 2019年05月30日(木) (第n回)

 ## うまくいっていること
 - (相手の名前):
     - 前回: (前回のうまくいっていることを転記)
     - 今回:
 - (自分の名前):
     - 前回: (前回のうまくいっていることを転記)
     - 今回:

 ##  話したいこと・気になること

 ### (相手の名前)より

 ### (自分の名前)より

自分の方が話しすぎちゃっているかもという反省から「話したいこと・気になること」から人別のセクション消して自分の方の議題をあらかじめ書かない方がいいんじゃないかとちょっと思って今週ちょっと消してみたりした。

でも Google re:Work - ガイド: マネージャーにコーチングを指導するのサンプルテンプレートでもマネージャーとチームメンバーのセクションがあって、やっぱり問題ないかなって思えてきたので今まで通りにすることにした。ってことがあったので書いてみた感じ。

身近な人がやっている形式の記事

• 夢にでるほど1on1について考えた

できない理由を挙げることはマネージャーの仕事ではない

「高校生のバイトでもできること。」とうフレーズが強烈に印象に残っていて、でも何で読んだか思い出せずもやっとしていた。それが先日ノートテキストファイルを整理していたらメモが出てきてようやく思い出せたのだ。

15年前に読んだ『仕事のヒント』だ。

できない理由を挙げることは、高校生のバイトでもできること。マネージャーの仕事ではない。 — 仕事のヒント p.102

• 仕事のヒント

「どのようにすればで言ってみる。」というのを学んだ『すごいやり方』『すごい会議』を読んだのも2005年。この頃から強く「できない理由を探すよりできる方法を考える」ことを意識するようになったんだ。できない理由を探すよりもできる方法を考える方がかっこいいと思ってる。

[ opinion ] [ 行動原則 ] [ Naney の行動原則 ]

one-on-one ミーティングで「いままでに何が達成されたか」を話す

one-on-one ミーティングでは前向きな雰囲気を作るように「うまくいっていること」を最初に話すフォーマットにしている(one-on-one ミーティングのノート形式)。

『すごい会議』で

なかには、「うまくいっていることはない」という人(たぶん不機嫌な顔で)がいるかもしれませんが、そのときは「『部屋の電気がついている』ってぐらいのことでかまわないので3つ書いてください」とリクエストします。

と書かれていたのが印象だったこともあり、イケル感じのムードをつくるのを優先で「仕事とは関係ない話でも全然いいですよ」といってやってきた。

いい感じのアイスブレイクになるし、続けていると興味関心をもっていることや価値観が垣間見えてくるしで「仕事とは関係ない話」も悪くない。リモートワークが増えて雑談の機会が減った今、むしろ大切にした方がいいかもしれない。

とはいえ「うまくいっていることを話す」のは仕事について「いままでに何が達成されたか」を共有して気持ちを高めるというのが本来だよなと。

まずは「うまくいっていること」のアジェンダのままで自分が「いままでに何が達成されたか」を話すようにし、どこかのタイミングで質問の表現もアレンジしてみようと思う。

『amazonのすごい会議 ジェフ・ベゾスが生んだマネジメントの技法』

会議の資料は「箇条書きではなく文章で書く」のが Amazon のルールと紹介している書籍『amazonのすごい会議 ジェフ・ベゾスが生んだマネジメントの技法』が気になって全部読んでみた。

「会議資料の準備」と Amazon 流の「意思決定会議」「アイデア出し会議」「進捗管理会議」、そしてそのやり方の背景にある信条「Our Leadership Principles」との関係について読みやすくまとめられていた。

本書の内容は「Our Leadership Principles」という価値観・行動原則を体現したマネジメントや会議のスタイルだ。なので読んでやり方だけ真似てもうまくいかない。Amazon 流会議の紹介から同意できる大切にしたい価値観・行動原則を見つけ自分や組織に取り込みつつ、会議スタイルも参考にしていくのが良いのだろう。いや価値観・行動原則を取り込められたのなら、もう真似などせずとも自ずとイケてる会議スタイルになっていっているに違いない。

とはいえピンポイントで「なるほど」「やってみたい」というのもいろいろあったので、それはそれでピックアップして参考にしたい。

会議資料: 箇条書きではなく文章で書く

「箇条書きではなく文章で書く」については

いつ誰が読んでも確実に伝わる

と「伝えるための表現形式」として、また

きちんとした文章にするとなると、読んだときに辻褄が合わない部分が出て来ないように、最初から整合性をとらなくてはなりません。そのため、吟味に吟味を重ね、適切な情報を用いて推敲を重ねなければなりません。

と「書いて考えるための表現形式」として文章形式(ナレーティブ形式)の良さが説明されいた。

最近はできるだけ箇条書きではなく文章で書くようにしている。やってみると、なるほどそうだなと。お勧めのプラクティスだ。

会議資料: 定形フォーマットはつくらない

「定形フォーマットはつくらない」という話には唸った。

先人からの学びや自身の経験から「これは共通理解や意思決定に必要」という項目が自分なりにいくつかあって、ドキュメントの構成として意識していたりする。

しかしその構成に固執したり他人に強いたりすると、変化の阻害要因になりかねないと。定形にすると便利で楽だけれど思考の硬直につながりかねない。意識したい。

あとは

• プロジェクトリーダーが意思決定会議のオーナーになる。
• 本題から外れた意見をメモしておく「パーキングロット」を使って脱線から戻す。
• ソーシャル・コヒージョン (Social Cohesion) に気をつける。
• 「メトリックス・レビュー」と呼ばれる会議には、異常値の分析・対策検討など然るべき準備をした上で望むのが暗黙のルール。

は意識したりやってみたりしたいなと思った。

それから

• 意思決定会議で「What(何を) Who (誰が) When (いつ)」を明確に決める

というのは、『すごい会議』で学んだ

• 「誰が」「いつまでに」「なにをして」「どんな成果をだすか」を明確にする

というのと同じ普遍的な考え方だな。ガッツがいるのでついユルくなりがちだが、スピードと成果が圧倒的に変わってくるのでしっかり踏ん張ってコミット・リクエストしたい。

• amazonのすごい会議 ジェフ・ベゾスが生んだマネジメントの技法 (Kindle版)
• amazonのすごい会議 ジェフ・ベゾスが生んだマネジメントの技法 (単行本)

[ 読書ノート ]