別にしんどくないブログ

技術のことや読書メモを書いています

チームに必要な「5つの法則」とチェックリスト / 『THE TEAM 5つの法則』を読んだ

GWは実家に帰省していました。同様に帰省していた弟が『THE TEAM 5つの法則』という本を持ってきていました。書店でも見かけたことがある表紙だったのでパラパラと読み始めると面白かったので一気に全部読んでしまいました。

この本はよく言われる「良いチーム」への誤解を主張するところから始まります。  

例えば「目標を確実に達成するのが良いチームだ」「チームはコミュニケーションが多ければ多い方が良い」「みんなで話し合って決めるのが良いチームだ」といった当たり前のように良いと思われていることに対して、実は時にチームが十分にパフォーマンスを出せない原因になり得ると主張しています。著者は「チームの法則」を用いることで、こういった誰もが持つ誤った認識を解消し、本来あるべきチームの姿をつくることができると主張しています。

その法則は「5つの法則」に分類することができます。

これら本書はこの5つの法則が章ごとに分かれて構成されています。気になる章だけ読んでも完結するようになっています。  

また、各章は「法則」「具体的事例」「チェックリスト」「学術的背景」で構成されており、好きなところから好きなところだけ読んでもいいようになっています。   このエントリでは本書のチェックリストをベースに読書メモを書き残しておきたいと思います。自分が後からチェックするのに使うためにこのブログに残しておきますが、このエントリを読んでくださっている方も読んでて気になるところがあれば気になった章だけでも本書を読むことをおすすめします。

Aim(目標設定)

チェックリスト

  • チームの活動の意義が明確になっているか?

  • チームの創出すべき成果が明確になっているか?

  • チームは推奨している行動が明確になっているか?

  • チームではかつどうの意義と創出すべき成果、推奨している行動が適切に接続されているか?

  • チームが活動する意義、創出すべき成果、推奨されている行動を日常的に意識できているか?

メモ

チームのパフォーマンスは目標設定によって決まります。適切でない目標が設定されているとすべてが台無しになることもあります。  

目標設定には3つのレベルがあります。

  • 行動レベルの目標設定

  • 成果レベルの目標設定

  • 意義レベルの目標設定

意義レベルの目標設定では最終的に実現したい抽象的な状態や影響を示したものです。意義レベルの目標にはチームのパフォーマンスにブレークスルーを起こす力があります。  

昔は行動レベル、成果レベルの目標が重視されてきましたが、時代とともに意義レベルの目標が重視されるようになってきました。意義レベルの目標設定にはGoogleやメルカリなどが導入しているOKRを使うことができます。

チームが何のために存在し、すべてのメンバーが意義目標を意識し、自発的に行動し成果をあげることが求められるようになってきています。

Boarding(人員選定)

チェックリスト

  • チームの活動の特徴を語られるか?

  • チームのメンバーには適切な多様性があるか?

  • チームには適切な流動性があるか?

  • チームに必要なメンバーの特徴を理解しているか?

  • チームのメンバー集めやメンバー選びに貢献しているか?

メモ

環境の変化度合いや人材の連携度合いによってチームの特徴は変わります。チームにとって必要な人材を選定する前にチームの特徴を把握することが大切です。  

チームが置かれた状況に応じて多様なメンバーを集めるか均質なメンバーを集めるか変わります。どちらかに偏っている場合は採用基準を見直す必要があるのではないでしょうか。同じく状況に応じては固定のメンバーよりもメンバーに流動性がある方が良いときもあります。ビジネスの環境変化が速い今日では必要なときに必要なメンバーを選定できるようにしている組織であったほうがいいと言えるでしょう。

Communication(意思疎通)

チェックリスト

  • チームはルールを明確化できているか?

  • チームはメンバー同士がお互いの過去や特徴を理解するような機会を持てているか?

  • チームは問題やアイデアメンバーが安心して共有できる雰囲気をつくれているか?

  • チームメンバーの過去や特徴を踏まえたコミュニケーションを取れているか?

  • チームメンバーに恐れや迷いなく自分が感じる問題やアイデアを発信できているか?

メモ

適切な緻密さを保ったルールを決めることでコミュニケーションコストを少なくすることができます。逆に過度なルールはコミュニケーションコストを増やします。コミュニケーションは多ければ多いほど良いチームであればルールを再設定したほうがよいです。無駄なコミュニケーションを減らして効率化する一方で、「お互いを理解するコミュニケーション」や「安心して意見が言える場づくり」は大切にする必要があります。心理的安全と相互理解に基づくコミュニケーションによってチームメンバー間の連携が取れて相乗効果を発揮することができます。

Decision(意思決定)

チェックリスト

  • チームは状況に応じて最適な意思決定方法を選択できているか?

  • チームはスピーディーに再現性のある議論ができているか?

  • チームは意思決定者が孤独を恐れず決断できているか?

  • リーダーの意思決定を自らの手で正解にすべく活動ができているか?

  • 決断が必要なタイミングで「強く」「速く」意思決定ができているか?

メモ

まず、どのような方法で意思決定するか意思決定する必要があります。チームの意思決定には「独裁」「多数決」「合議」の3つがあります。状況に応じてスピーディーに意思決定する必要がある場合は全員で決めるより誰かが一人で決めるほうが良い場合もある。合議は時間がかかるのでスピーディーに意思決定するためには選択肢を用意します。まず選択肢を決める基準を決め、選択肢の優先順位を決めます。最後に優先順位に合致する選択肢を選択することで素早く意思決定できます。

「5秒で考えた手」と「30分かけて考えた手」は86%が同じ手なので5秒以内に打った方が良いというファーストチェス理論という考え方があります。これに基づくことでとにかく速く意思決定ができます。ソフトバンクの孫さんが実践しているそうです。

合議による意思決定に時間がかかる場合は独裁も必要です。そとのときに大切なことは意思決定者が反対や孤独を恐れずに決めること、しかしメンバーは意思決定者を孤独にしないことです。

「専門性」「返報性」「魅了性」「厳格性」「一貫性」を有したメンバーを意思決定者にすると意思決定の成功確率が上がります。

Engagement(共感創造)

チェックリスト

  • チームでは金銭報酬や地位報酬だけでなく感情報酬がメンバーに提供されているか?

  • チームではメンバーに何に共感してもらうかが明確になっているか?

  • チームにはメンバーがチームの魅力を感じる仕組みが埋め込まれているか?

  • 自分が何を求めてチームに参加しているかを明確にできているか?

  • チームがメンバーの共感を生み出すことに貢献できているか?

メモ

すべてのメンバーがモチベーションに左右されるというのはすべてのチームにあてはまることです。モチベーションを高めるために4つのPがある。

  • Philosophy(理念・方針)

  • Profession(活動・成長)

  • People(人材・風土)

  • Privilege(待遇・特権)

4つのPすべてを提供することは難しいのでどれかに注力する。例えば、マッキンゼーはProfession、リクルートはあPeople、ディズニーはPhilosophyの魅力で束ねています。社内だけでなく社外にも魅力が伝わることで応募者とのミスマッチ防止にも繋がります。

今回は『THE TEAM 5つの法則』のチェックリストと読書メモを紹介しました。
チームのパフォーマンスに悩んでいる方や他の本で良いとされている方法がうまくいかない方におすすめです。

最後までお読みいただきありがとうございました。不備や質問はブコメTwitterまでお願いします。

THE TEAM 5つの法則 (NewsPicks Book)

THE TEAM 5つの法則 (NewsPicks Book)

 

v-kansai Vue.js/Nuxt.js meetup #5でamp-scriptについて話します。 #v_kansai

AMP Conf 2019から気になっていたamp-scriptについてVue.jsを交えて話をします。 本番までに修正するかもしれませんが、以下資料です。

speakerdeck.com

もし不備や質問があれば、ブコメTwitterで教えていただけると幸いです。

参考

Node.js v12で使えるJavaScriptの新機能

Node.js v12が4/23にリリースされました 🚀

Node.jsのCoreにも新しい機能が入りました。 また、APIの追加以外にもTLS1.3のサポートやhttp_parserがllhttpに代わったりしています。 詳しくは以下をご覧ください!

github.com

JavaScriptエンジンであるV8もバージョンアップしています。
Node.js v10のV8のバージョンは6.8でしたが、Node.js v12では7.4に大幅アップデートしています。
V8のバージョンが上がることによりJavaScriptの使える機能や構文が増えます。
今回はMathias氏のツイートをもとにNode.js v12から使えるJavaScript(ECMAScript)の新機能について紹介したいと思います。

一部v11から使える機能もあります。
掲載しているコードはすべてv12.0.0で動作確認済です。

Array#flat

Array.prototype.flat() - JavaScript | MDN

ネストされた配列をフラットにします。以下MDNから引用です。

この機能はv11.14.0でも使えました。

Array#flatMap

Array.prototype.flatMap() - JavaScript | MDN

配列の値をmap関数でマッピングし、結果の配列をフラット化します。以下MDNから引用です。

この機能もv11.14.0で動作しました。

class fields

Classの中でプライベートフィールドが使えるようになります。 class fieldsについては以下の記事が参考になると思います。

developers.google.com

また、#が使われるようになった経緯をJxckさんが詳しく解説してくれています。

blog.jxck.io

動作確認済のコードは以下のとおりです。

コメントアウトしている箇所のようにプライベートフィールドの#countにアクセスするとエラーになります。

globalThis

globalThis - JavaScript | MDN

GitHub - tc39/proposal-global: ECMAScript Proposal, specs, and reference implementation for `global`

globalThisは環境を超えてグローバルオブジェクトにアクセスするためのオブジェクトです。
これまでブラウザではwindow、Node.jsではglobalがグローバルオブジェクトとして使われていました。
もちろんこれらは今まで通り各環境で使えますが、どちらでもアクセス可能なオブジェクトとしてglobalThisが追加されました。
globalThisを使うことで以下のような使い分けをする必要がなくなりました。

以下の記事も参考になるかと思います。

👻globalThis👻と🌏global🌏と🌝this🌝 - Qiita

Intl.ListFormat

Intl.ListFormat - JavaScript | MDN

配列を国ごとに形式を変えて文字列フォーマットしてくれるIntlの新しいAPIです。

Intl.Locale

GitHub - tc39/proposal-intl-locale: `Intl.Locale` specification [draft]

Intl.Locale

第一引数の文字列"pl-u-hc-h12"UNICODE LOCALE DATA MARKUP LANGUAGEで定義されている形式に沿って記述します。最初のplは言語を表しています。英語であればenです。uunicodeであること、hcはHour Cycleを表していてhc12は12時間周期であることを表しています。hc12は1〜12、hc23は0〜23といった具合です。例えば23時をフォーマットするときにhh:mm形式を指定すると11:00となり12時間周期にフォーマットされ、HH:mm23:00と0〜23時の形式にフォーマットされます。hh:mmhc12HH:mmhc23の形式を使っていることになります。

UTS #35: Unicode Locale Data Markup Language

Intl.RelativeTimeFormat

Intl.RelativeTimeFormat - JavaScript | MDN

これは言語によって時間表記を変換してくれる国際化APIです。
以下のコードを見るとわかるかと思いますが、jaを指定してformat関数に2日後を指定すると文字列"明後日"に変換してくれます。

Object.fromEntries

Object.fromEntries() - JavaScript | MDN

key, valueのペアの配列をオブジェクトに変換します。

stable Array#sort

v8.dev

Arrayのsortが安定ソートになりました。

安定ソート - Wikipedia

String#matchAll

String.prototype.matchAll() - JavaScript | MDN

正規表現にマッチするものをすべて取り出して配列にします。キャプチャした値も配列の中に含まれます。

Symbol#description

Symbol.prototype.description - JavaScript | MDN

Symbolの引数に指定した値を参照することができます。descriptionプロパティは読み取り専用です。

well-formed JSON.stringify

GitHub - tc39/proposal-well-formed-stringify: Proposal to prevent JSON.stringify from returning ill-formed strings

不正なサロゲートペアがエスケープされた文字列として出力されるようになります。

以前までは

JSON.stringify("\uD800");
// --> '"�"'

だったのが

JSON.stringify("\uD800");
// --> '"\ud800"'

になります。

最後に

今回はJavaScript(ECMAScript)の新機能を紹介しましたが、冒頭でも触れたようにNode.jsのCoreにも様々な変更が入っています。 v12がLTSになるのは10月末を予定しています。

github.com

以上、最後までお読みいただきありがとうございました。
不備や質問などがありましたらブコメとかTwitterまでお願いいたします。

『徳丸浩のWebセキュリティ教室』を読んだ

徳丸浩のWebセキュリティ教室

徳丸浩のWebセキュリティ教室

セキュリティの専門家として著名な徳丸先生が2015年に出版された本である。
170ページほどで薄めの本ながらWebのセキュリティに関して様々な事例や解説が紹介されている。
いくつか例を挙げると、XSSSQLインジェクションCSRFなどの説明やさくらVPSへの不正ログイン事件やGHOSTなどの事例をが書かれている。
本書序盤から度々出てくる「脆弱性はバグという意識を持つ」は開発者全員が意識しなければいけないと感じた。
あと発注者も意識が必要と書かれており、セキュリティ要件の提案と見積をRFPに盛り込んでおくことが勧められていた。
これにより発注側にもセキュリティ対策の責任を持つと開発者との責任のなすりつけ合いや逐一確認するといった無駄も省けて良さそうだと感じた。
またIPAの「安全なウェブサイトの作り方」や「セキュリティ実装チェックリスト」に沿って確認するのも勧められている。

www.ipa.go.jp

また「安全なウェブサイトの作り方」は2015年に改訂され、以下の脆弱性について詳細や対策を解説している。無料で公開されているので、セキュリティへの関心の第一歩として一読するのは良さそうである。

  1. SQLインジェクション
  2. 0Sコマンドインジェクション
  3. パス名パラメータの未チェック/ディレクトリトラバーサル
  4. セッション管理の不備
  5. XSS(クロスサイトスクリプティング)
  6. CSRF(クロスサイトリクエストフォージェリ)
  7. HTTPヘッダーインジェクション 8.メールヘッダーインジェクション
  8. クリックジャッキング
  9. バッファオーバーフロー
  10. アクセス制御や認可制御の欠落

1日は1440分しかない / 『1440分の使い方 ──成功者たちの時間管理15の秘訣』を読んだ

1440分の使い方 ──成功者たちの時間管理15の秘訣

1440分の使い方 ──成功者たちの時間管理15の秘訣

最近無限に時間が足りないと感じています。
時間は有限なので取捨選択していかなければいけないと感じたときにPrime Readingで本書があったので読みました。

以下読書メモです。

1440の威力

  • 一日は1440分しかない
  • 1分がどれだけ重要か意識し、自分にとって何が最も重要か考える
  • その目標につながることに集中する。

適切な優先順位の重要性

-目標は具体的にする - 例えば2ヶ月で5キロ痩せるなど具体的な数値を設定するのが重要 - 具体的な目標に向けて必要なことなすべて洗い出す - 自分の成功体験を例にすると、Node.jsのコラボレーターになると決めたときも半年という期限を設けて、それまでに必要なコミットの数を考えて進めることで達成できた - MIT(目標に対して最も重要なタスク)に注力する - 目覚めてから2時間が脳のゴールデンタイムなので、この時間に最も重要なタスクに注力する - 最も重要なタスク(MIT)を特定し、毎日、何よりも先に取り組む

ToDoはいらない

  • 重要なことはすべて、やる時間を決め、15分単位でスケジュール表に入れておく
  • 30〜90分の何も無いバッファタイムをスケジュールしておく
  • タイムブロッキングする
    • 重要なことに集中するときはカレンダーに登録してMTGなどを入れられないようにしておくとよいかも

先延ばしを克服する

  • 未来の自分は、今この瞬間の私たちを妨害しようとする
  • 人間は利益を望むよりも損失を恐れるようにできているので、目標達成時のアメを与える代わりに、目標未達成時の罰則を科せばいい
  • 理想的な自分になったつもりで自分に語りかける。例えば、「私はジョギングを習慣にしている」「私はベストセラー作家だ」と。
  • 理想的な自分になりきることで、先延ばしにしがちな問題もやらないと気持ちが悪く感じる

ノート術

  • 常にノートを持ち歩く
  • キーボード入力より手書きの方が記憶に定着しやすい
  • 日記をつけて毎年元旦に昨年分を読み返すことで自分の進捗を振り返る

メール術

  • メール購読を解除する
  • メール通知をOFFにする
  • メールは1日に3回、21分ずつ時間を制限する
  • メールは常に短く簡潔に

会議術

  • 会議前にアジェンダを共有し意見を求める
  • 会議の目的を明記する
  • 進行役を明記する
  • 議題はなるべく疑問文で書く
  • 会議の時間の目安を明記する
  • 日時の小会議は15分に留める

大成功に導く小さな一言

  • 当面の目標達成に役立たない誘いは断る

読書と勉強の80対20

  • 各章の最初と最後の段落、段落後の1文を読むだけで8割がた理解できる
  • 重要なことに注力して、それ以外は妥協するか一切やらない

外部委託する

  • 1年ごとに時間の使い方を振り返り、少なくとも15%は外部委託する

1日のテーマを決める

  • 1週間を3種類に分ける
    • 集中日: 自分が得意なことに集中する
    • 予備日: メール対応や会議、書類仕事を行う
    • 休日: 仕事を一切しない。仕事以外のことに集中する
  • 休暇は予備日で挟む。金曜日と月曜日を予備日にする

一度しか触らない

  • 5分間で終わるタスクは一度しか触らない
  • 返信しなければいけないメールはすぐに返信する
  • 先送りしない

朝を変えて、人生を変える

  • 家族より15分早く起きる。みんなより15分早く出社する。朝の15分に集中すべきことを行う

その他時間管理の秘訣

  • ベストコンディションであるためには、ダウンタイムも少しは必要

「富を失ったら懸命に働けばいい。知識を失ったら勉強すればいい。健康を失ったら禁酒するか薬を飲めばいい。しかし時間は、一度失ったら永遠に戻ってこない」――サミュエル・スマイルズ(イギリスの作家、『自助論』著者)

読後感想

1440分しかないという風には考えていなかったので、この数字を意識するだけでも日々の時間の使い方の決定に影響はありそうだと感じました。
冒頭に書いた通り、取捨選択しなければいけないことはわかりきっているので本書に背中を押してもらった気分です。

以上、最後までお読みいただきありがとうございました。
関連本やオススメ本がありましたらブコメTwitterで教えていただけると幸いです。

総関西サイバーセキュリティLT大会で脆弱性のあるJSライブラリの話をします #sec_kansai

2019-04-10に行われる『総関西サイバーセキュリティLT大会(第14回)』でJavaScriptのライブラリの脆弱性に関する発表をします。 sec-kansai.connpass.com

speakerdeck.com

5分の発表なので、あまり踏み込んだ内容にはなっていませんが参考になれば幸いです。
不備や不明確なところがありましたら、ブコメTwitter(@shisama_)にて教えていただけると助かります。

脆弱性に関してはNode.jsもnpmも尽力しています。もし使っているnpmパッケージで脆弱性があった場合は https://npmjs.com のパッケージのページから報告お願いいたします。

ライブラリではないですが、Node.jsに関する脆弱性の報告も以下のリンク先で受け付けているのでよろしくお願いいたします。

nodejs.org

『Team Geek』を読んだ。

Team Geek ―Googleのギークたちはいかにしてチームを作るのか

Team Geek ―Googleのギークたちはいかにしてチームを作るのか

本書は定評があり、以前から勧められていたのですが積読が多く読めていませんでした。
最近、チームで働くこと、特にチームメンバーとの協調や生産性向上がうまくいってないように感じているので読んでみました。

以下は各章ごとに気になったことのメモです。

1章 天才プログラマの神話

  • チームで働くための三本柱
    • Humility (謙虚)
    • Respect (尊敬)
    • Trusty (信頼)
    • HRTなのでハート(Heart)と呼ぶみたい
    • 本書の中心にどうすれば良いチームを築くことができるのかを網羅的に解説している
  • エゴをなくす
  • チームメンバーを信頼して仕事を任せる
  • 批判は個人的なものではなく優れたプロダクトを開発するための必要なプロセスであるか、そこに尊敬が含まれていなければならない
  • 建設的な批判の仕方を学ぶ必要がある。そのために気の利いたフレーズを使えるようにする

2章 素晴しいチーム文化を作る

  • ミッション・ステートメントを明確に定める
    • プロダクトのスコープを制限する
    • やること/やらないことを明確にしておくと年単位で仕事の節約になる
  • MTGは必要な人だけで行う
  • MTG前はアジェンダを用意する
  • MTGのゴールに早くたどり着けば時間内でも終わる

3章船にはキャプテンが必要

アンチパターン

  • 自分の言いなりになる人を採用する
  • パフォーマンスの低い人を無視する
  • 人間の問題を無視する
  • みんなの友達になる
  • 採用を妥協する
    • エンジニアを5人雇う計画のとき大量募集して上位5人を雇うことがあるが、このやり方はダメなやり方。ジョブズいわく「Aランクの人はAランクの人を採用する。Bランクの人はCランクの人を採用する」
    • 採用に口を挟めなくても腕のいいエンジニアが必要だと主張する。それでも標準的なエンジニアしか雇わないのであれば職場を変えた方がいい
  • チームを子どもとして扱う

    リーダーシップパターン

  • エゴをなくす
  • 禅マスタになる
    • 常に平静を保つ
    • 質問は禅マネジメントの秘密である。チームメンバーがアドバイスを求めてきたら、自分で解決しようとするのではなく、解決することを手伝うようにする。自分が答えを持っているかどうかにかかわらず、相談相手には印象が残る
  • 触媒になる
  • 先生やメンターになる
  • 目標を明確にする
  • 正直になる
  • 幸せを追い求める
    • 時間を作ってチームの幸せを計測する
    • チームの幸せを追い求めるには1on1のあとに他に必要なものがあるかを質問する
    • チームの外の幸せを考える

4章 有害な人に対処する

  • 有害な人ではなく、有害な振る舞いを排除する
  • 他人の時間を尊重する
  • 完璧主義者にならない
    • 設計に時間をかけすぎてコーディングがなかなか始められない。結果として、チームとしての生産性を下げている。
  • 優しく追い出す
    • 文句言いたいだけの人に対して優しい口調で優しく接する

5章 組織的操作の技法

  • リスクをとる
    • 年に1回でも失敗していないようなら、それはリスクを取っていないということ
  • 「攻撃的」な仕事と「防御的」な仕事
    • 攻撃的な仕事は、ユーザに見えるもの。UIの改善とかパフォーマンス改善など
    • 防御的な仕事は、プロダクトの健全性を維持するもの。リファクタリング、モニタリングなど
    • 防御的な仕事にかける時間は1/3〜2/3に収める

6章 ユーザーも人間

  • ユーザーに集中すれば、他のことはすべてついてくる
  • 成功しているソフトウェアというのは、問題を限定してそれをうまく解決している
  • Less is more

感想

定評通りの良い内容でした。読んでいて感じたのは最近勉強会やカンファレンスなどで聞くようなチームビルディングの例はこの本に影響受けているものも多いのではないのかなということです。
この本を読みながら「これ最近よく聞くよな」とか「これ何かで読んで実践してみて良かったな」とか他で得た知識が載っていたのですが、もしかすると誰かがこの本から得た知識を実践してアウトプットしていたのかもしれないです。そう考えるとこの本は多くの人に影響を与えた本だと思います。
また、この本は発売が2013年ですが、今読んでも勉強になることが多いので内容はある程度普遍的なものなのではないでしょうか。
この本も時代を超えて読まれていく本になる可能性はあります。願わくば、本書に書かれていることが当たり前の世の中になっていて読まれなくなると良いかと思います。   チームで働くことに悩んでいたり、これからチームで働く人には積極的に勧めていきたいと思います。