『Team Geek』の箇条書きを一つのページにまとめる。

HRT(謙虚、尊敬、信頼)、これらの欠乏が問題を引き起こす。

そして、HRTの原理を、『Team Geek』では、以下のように広げていった。

自分
チーム
チームをリードする方法
チームの外部とのやり取り(外部、組織)
ユーザーとのやり取り

この手法は、エンジニアリングのみならず、あらゆるコミュニティが対象となる。

0 章

プロジェクトの成功には以下の2つの要因が必要である
- 優れたコードという技術的要因と
- みんなの協力という人的要因
  - 人間は難しく「人間は断続的なバグの大きな塊」
  - その一方で、チームは個人の生産性や幸福に直接影響する

1章(自分にHRTを持たせる)

1人の天才ではなくチームが全て

天才の神話
- 天才はコードを隠さない
  - 優れたコードだとしても不十分
- コードを隠すのは不安の裏返しである
- 天才の本当の功績は、チームとうまくやることができたこと
- 1人でやることは失敗のリスクが高まる。みんなでやることのメリットが高い。
  - 失敗に早期に気づける
    - プロジェクトには、高速でのフィードバックループが必要
  - プロジェクトののバス係数が高まる
  - スケールできる
- チームが全て

HRTとその活用方法

謙虚(H: Humidity)、尊敬(R: Respect)、信頼(T: Trust)、これを自分が持ち、相手も抱けるような環境を作ることが重要。
- HRT、これらが健全な対話とコラボレーションの基盤
  - これらが欠如すると人間関係が衝突する
    - 人間関係は、プロダクトやプロジェクトより、長く続く
  - これらがあると、いざ困ったときに、助けられる
- 謙虚
  - エゴをなくす
    - コミュニティは信じられないほど強力なアイデンティティがある
  - 自分の学習のための時間を作る
- コードの指摘には謙虚になり、相手に尊敬を含め、相手が恩恵をもたらしてくれると信頼する。
  - (ebiebievidenceのTweetを見よ)
- 失敗、学習、反復
  - 不完全を見せても構わないという謙虚さを持ち、
  - ユーザーが、対応を賞賛し、改善を要望するという信頼で、
  - 失敗の文書化(ポストモーテム)をする
    - 何を学んだか、何を改善するか
- 忍耐を学ぶ
- 影響を受けやすくする
  - 間違いや能力不足を認める
    - 謙虚さを見せる
  - 他人の意見を信頼する
  - この正直さと強さは尊敬を産む

要約している私のコメント

このあたりの習得は、人やチームとのやり取りと、そこからのフィードバックで得られるものが多いだろう。

2章(チームにHRTの原理を持ち込む)

チーム文化

チーム文化を作ることで、自己選択的な文化になり、また、外部から来た悪意ある人や文化を排除することができるようになる。
- 文化はイースト菌のようなもの
  - そしてその種菌が重要
- チーム文化とは、エンジニアリングチームが共有する、経験、価値、目標
- まず優秀なエンジニアを雇う
- 強い文化は自己選択的な文化である
  - 文化に合わない人は、事前に遠ざかってくれる
- 合意ベースのマネジメントなら、チーム全体が意思決定プロセスに参加できる
  - チーム全員がプロダクトの成功に強い責任を持ち
  - リーダーがチームの意見に耳を傾けること(尊敬)
- チームメンバーの接し方
  - HRTを持っていればよい
  - 前向きな批判をしてくれる友達や同僚を見つけよう
- 文化が、積極的なのか、のんびりなのかを理解し、
  - 新来者に支配されないように気をつけよう

チーム内でのコミュニケーション方法

コミュニケーションなしには正しいコードを書いている保証ができない。
- 同期コミュニケーションの人数を減らし
  - (後のミーティングの五か条を見よ。)
- 非同期コミュニケーションの人数を増やす
  - (決める人は少なく、伝える人は多く、とも言えるだろう。)
  - (伝えられたからのフィードバックも用意しておこう。)
チームのハイレベルの同期
- 高いレベルで共通の目的を持つ
- 進捗を伝えるベストプラクティスに従う
  - (それはどういうものかはわからないが、HRTをみんなが持って、オープンにコミュニケーションできるようにすればいいのではないだろうか？)
    - (日報とかいうくそみたいなものは避けたい。)
    - (日報自体は悪いものではないが、ああいう人間を無視したものは、形式的で無意味になりがち)
- ハイレベルの同期のためには、
  - ミッションステートメントの共有
  - ミーティング
    - 地理的障害があることを意識する
    - 設計文書の共有
ミッションステートメント
- やることは単純
  - チームの方向性を定義して、
  - プロダクトのスコープを制限する
    - Making GWT Betterの例を見よ
- ミッションステートメントを書くことで
  - 認識の違いを明らかにし
  - 方向性に合意でき
    - これがなければ、スピードが落ちるか、停止するかのどちらかになる
  - 共有することができる
- 再評価する
  - 会社の方向性に合わせねばならない

ミーティングについての5つのルール

絶対に必要な人だけ
1. 新しいものの設計で5人以上は不要
2. その時間に別作業している人は会議に参加しなくてもよい人だから誘うのを間違えている。
アジェンダを作って、ミーティング開始前に配布する
1. ミーティングを設けない日や時間を設けて、クリエイターの時間を設ける
ミーティングのゴールを達成したら時間前でも終了する
ミーティングを順調に進める
1. 取り仕切る人がいるようにする
2. 15分以上のスタンディングミーティングをやめろ
ミーティングの開始時間を強制的に中断される時間の前に設定する

コミュニケーションで意識すること

地理的障害のあるチームで働くことを意識する
- 「メーリングリストで議論がなかったら何も起きていない」というモットー
  - チャットの後「リアル」としてのメーリングリストに投稿
- リモートから話しかける時
  - 机に向かって歩いていくかのような自然な感じであれ
  - 積極的にチームとコミュニケーションをし
    - 自分の存在だけでなく
    - こちらの仕事も知ってもらう
- フェイストゥーフェイスの帯域を過小評価してはいけない
  - (これは、このブログでもさんざん述べているが、かなり情報量が多い)
設計文書を、コードの前に、書くこと
- 未来のハイレベルな青写真
  - 何をどうしたいのかを低コストでチームに伝える手段でもある。
- 設計文書は、コーディング開始後で「生きた文書」として扱う
  - プロジェクトの進行に従って、更新していくべき
- 設計文書を書くか、スクラッチから作るかは、経験で判断すること
  - 設計文書を書く時間で何度もスクラッチから書き直せるなら、その文書は時間の無駄であったりする

ハイレベル同期完了後にやること

ハイレベルのゴールに合意できた後で、

チームの日々の調整に使うツールを与える
- ツールはたいてい帯域が狭い
  - 誤解やHRTの欠如に繋がる
- でも欠かせられない
  - 少しの手間で生産性を大きく高められる
メーリングリスト
- 議事録・ミーティングのメモ・決定事項・設計文書を記録するのには使った方がいい
- 検索可能にしておこう
オンラインチャット
- いいぞ
- 物理空間の事情を考えなくていい
  - 前提としては、通知をOFFにしていること
課題管理ツールを使おう
- ただの掲示板
- 課題をオフィシャルにして、みんなの目に触れられるようにする
  - オフィシャルであるとは
    - 粗暴な振る舞いを許すな
    - 話や議論が長くなったらメーリングリストでやれ

エンジニアのコミュニケーションについてのリマーク

コードコメント
- 「なぜ」を説明するもの
  - 「何」ではない
- 中庸を知れ
- コメントスタイルをチームで決めよ
  - 一貫性を守る方が大切
    - 関係なパターンマッチングによる推測が可能になる
  - 使用を制限する機能についても決めておこう
Authorタグをつけるな
全てのコミットにコードレビューせよ
- 変更はレビューしやすいように小さく
- コードレビューは
  - 品質を向上させ
  - 品質に対するチームの誇りを育む
リアルなテストとリリースプロセス
- 自動テストを増やせば、バグ修正や機能追加の際に自信を持てる
- テストをコーディングやレビューのプロセスの一部にする
  - 徹底的にテストを行え
- 頻繁にリリースできるようにリリースプロセスを調整せよ
  - ユーザーからの信頼を獲得せよ

文化の作り方

文化やコミュニケーションの習慣
- 好みの反映
  - 「好み」には適切な人と正しい価値が必要
- 主観的ではない
- 自然発生ではない
- チームリーダーと創業者が
  - 機能不全のチームのコストを理解して、
  - 丁寧に種を播いて育てていくもの
文化の定義や防御よりもコードの設計や記述に時間をかけれる
- 防御には、新来者への説明を含む
- コードを書くことを目的とする強いチームを作ることには膨大なコミュニケーションが必要
  - コードは、人と人とのコミュニケーションである。

3章(チームをリードするときにHRTをもつ)

チームリーダーにならなくても、チームリーダーの行動を理解できるようになるからこの章を読め
- チームリーダーがどのパターンを使って、成功(失敗)につなげているかを見て
- チームの原動力がより具体的に理解できる

リーダーとは

リーダーのいないチームは機能しない
- かじ取りする人のいない船みたいなもの
- ソフトウェアの方向性に影響を与えるためには、エンジニアリングリーダーシップを隅々まで理解する必要がある
マネージャー
- 誕生
  - 産業革命期
  - 労働者を監督するマネージャーという立場
    - 労働者を人参と鞭とで管理していた
    - 今ではもう全く効果がない
- 変化
  - エンジニアは数か月間かけて新しいチームに追いつく
  - 考えたり創造したりするためにの育成・時間・空間が必要
- 違い
  - 昔のマネージャー
    - 親と子の関係のようなもの
    - どうやって仕事を完了させるかを考える
  - リーダー
    - HRTでエンジニアを信頼するようにすれば、エンジニアはその信頼に答える
    - チームのための道を作り、安全と安心に気を配る
    - 何ができるかを考える
      - どうやって完了させるかはチームが考える
- 二種類のリーダーがGoogleにはある
  - TL(Team Lead): プロダクトの全部・一部の技術的な方向性に責任を持つ
  - TLM(Technical Lead Manager): TLの責任に加え、チームにいるエンジニアのキャリアや幸せという、人の管理にも責任を持つ

Managerになろうよ

Managerになることへの不安
- コードを書く時間が減ることへの不安
  - 定量化できないものが増えることへの不安
    - チームの幸せと生産性をたかめるのが仕事の指標である
- 無能なマネージャーになるのではないかという不安
  - ピーターの法則で、階級制度があるところでは、必ずその人の無能レベルまで昇進する
Managerになるべき大きな理由
- 自分をスケールできるから
- マネージャーに向いているかもしれないから
  - 実際、マネージャーに向いていた人が多くいる
マネジメント病(管理したがり病)の負の再生産の問題について
- サーバントリーダーシップで治療する
  - チームに奉仕すること
  - HRTの雰囲気づくりをすること
    - アドバイスを与えたり、
    - 順調に進めるよう穴を埋めたり
    - 自らの手を汚す
  - 技術的な側面とチームの人間関係の両方を扱う

マネジメントのアンチパターン

言いなりになる人を採用する
- 仕事が増えるぞ
- むしろ、自分より球が良くて、代わりになる人を採用しよう
  - 新しいチャンスを産む
パフォーマンスの低い人を無視する
- 数名でもパフォーマンスの低い人がいるだけでチームはうまくいかなくなる
- 「願いは戦略ではない」
  - パフォーマンスの低い人にはコーチングをする
    - HRTとともに
    - マイクロマネジメントをする
      - 小さい目標から大きな目標へ
      - マイルストーンには明確な期待を設定する
        明確な期待が設定すると結果がわかりやすくなる
  - 期待に応えない人をどうするかというのが一番難しい問題
    - 立ち去ってもらうことがチームにとって一番良いこと
人間の問題を無視する
- 人間的な側面を無視してしまうととんでもないことになる
- ちょっとした共感さえあればよかったことがしょっちゅうある
みんなの友達になる
- 友人関係のままであろうとするな
  - 友人関係も失うことになる
    - 上下関係があると人工的な友人関係を作りだしてしまう可能性がある
- 友人関係とチームをリードすることとを混同してはならない
- 友人関係ではなく、不安を感じさせずに仲良くしたいなら、一緒にランチしろ
採用を妥協する
- 採用基準を満たす人を取れ
- 採用すべきでない人の採用のコストは高い
チームを子供として扱う
- 子供・囚人として扱うことは、信頼していないということ
  - これのコストは馬鹿高い
- 信頼されていることを感じれば責任を感じるようになる

リーダーシップパターン

エゴをなくす
- 謙虚になること
  - 犠牲になることではない
  - 自信がないことでもない
- チーム全体のエゴやアイデンティティを育もう
- 方法:
  - チームを信頼すること
    - リーダーの仕事:
      - チームの合意形成や方向性の決定を支援
        質問を歓迎し、オープンに受け止める
    - リーダーの仕事ではないこと:
      - 全てに正しく
      - 全てを知り
      - 全てに応える
      - 達成方法はプロダクトを作る人が決定すべき
  - ミスをしたときに謝ること
    - 心から謝罪するということ
      - 分別があり、状況判断が得意で、ＨＲＴのＨを備えた人と思われるようになる
禅マスターになる
- 多くのエンジニアが懐疑的や批判的な感度が高いと思われる
  - チームリーダーとしてはそういった言葉を慎め
- 常に平静を保つ
  - そうでないと部下に大きな悪影響を及ばす
- 問題解決モードに突入する前に、質問者の問題解決を助けるために支援をする
  - そのために質問をする
触媒になる
- 合意の形成を行う。
  - 方向性を示したり、決定したりする
- 妨害や障害の除去・回避
  - 適任者へ連絡する
  - 適切な答えを知るよりも、適切な人を知る方が価値がある
- 安心感を与え、リスクを取れるようにする
  - リスクをとれば大きな成功の確率が上がったり、道が開けたりする
  - 失敗してもいいことをチームに知らせる
    - 失敗によって多くのことを素早く学べる
  - 個人の成功はみんなの前で称え、
    - 失敗はチームとして受け止め、そこから学ぶ
    - プライベートで建設的な批判をする
先生やメンターになる
- 自力で学ばせようとするのがリーダーの大切な役目
  - 学ばせること:
    - 技術
    - コード
    - チーム文化、
    - 想定される責任レベル
- メンターに必要な三つのこと
  - チームのプロセスとシステムの経験
  - 誰かに教える能力
  - 相手がどれだけ支援を必要としているかを把握する能力
目標を明確にする
- チームメンバーが同じ方向に行かねばならない
- ミッションステートメントを見せる
  - あとは、自律性に任せて、定期的に確認
  - これで、チームの効率は劇的に向上する
正直になる
- 褒め言葉のサンドイッチを避けた方がいい
- 本当に伝えたいメッセージを、正しく伝わっていることが重要
  - 建設的な批判をするときは、親身になって共感すればいい
  - 失礼のないように明確に
  - 相手を防御的にするような伝え方はしない
幸せを追い求める
- リーダーとして長期にわたって生産的に、かつ、離脱者を少なくするには、時間を作って、チームの幸せを計測すればいい
- 一対一の面談の後に「何か必要なものはある？」と質問する
- オフィスの外におけるチームの幸せにも注意を向けた方がいい
  - どうして生産性が高いのか低いのかが、プライベートな状況にまで目を向けているか、わかるかも
- 暗黙的な目標を明確化する
他のリマーク
- 移譲せよ、ただし手を汚せ
  - 誰もやらないような仕事を担当してみる
- 自分自身を置き換えようとする
- 事を荒立てる時を知る
- カオスからチームを守る
  - チームの外側のカオスと不確実性と狂気がある
- 新しいことをやりたいなら取返しがつくかどうかを見極める
- チームを空中援護する
- いいところをフィードバックする

人を画一で捉えるな

人は植物(みたいにみんなそれぞれ必要なものが異なる)
- 必要なものは人それぞれ
- 「興奮/退屈」と「自発的/注意散漫」のマトリックス
  - 自発的/注意散漫には、方向性が必要
    - 何をすべきかを理解し、構造化のスキルを身につけ、管理可能なタスクに分割すればいい
  - 興奮/退屈には、モチベーションが必要
    - モチベーションには二種類あり、一つは外発的
    - もう一つは内発的動機
      - 自律性
        方向性は与えられているとして、
        自分で考えて行動をする
        これはプロダクトオーナーシップを感じる
      - 熟達
        新しいスキルを学び、既存のスキルを向上させるための時間をもつこと
        これにより、鋭く、効率的で、効果的になる
      - 目的
        プロダクトに対するフィードバックには目を光らせる

4章(チームの外部とのやり取りでHRTをもつ)

有害な外部とのやりとりの仕方

チームの外部の人たちとどうやり取りすればいいだろうか
- チームのが文化を破壊するアウトサイダーから身を守る方法を学ぶ
有害とは
- ある種の振る舞いのことである
- チームの文化に含めないこと・やりたくないこと
  - これらを明確化しておいた方がいい
    - 明確化しておくと、目に余る振舞いの特定とその批判ができるようになり、
    - 有害な振る舞いを排除する文化を作れる
- 人が変わっても文化は残る
  - 強い文化は自己選択的である
  - 文化を強くし、残すため、そして、悪い方向に行かないようにするためには、すでに記述した強くする方法のおさらいをしよう
脅威を特定する
- 特にリスクが高いのはチームの注意と集中であり、これは数少ないリソース
  - HRTのない、意図的にいじわるするような、トロルがやってくる
  - そのような人が出てきたときに、取扱注意とこころにとめられるようにしよう
- 古典的なパターンをいくつか
  - 他人の時間を尊重しない
    - 文書を読まない人だったりして、
    - 人のエネルギーを消費する
  - エゴ
    - 合意の決定を受け入れられない人
    - 異なる視点の意見に耳を傾けられない人
    - 妥協できない人
      - 正しさよりも結論にたどり着くかどうかが重要
  - 権利を与えすぎる
    - 要求すれど貢献はしない人たち
    - 権利を与えすぎるとトロルになる
  - 未熟なコミュニケーションと複雑なコミュニケーション
    - 本名を使わなかったりメディアによってニックネームを分けたりする
      - (日本のインターネット文化とはだいぶ異なる)
  - パラノイア
    - オープンで透明なコミュニケーション文化があったとしても、
    - 陰謀論を唱える被害妄想患者がいる
  - 完璧主義者
    - プロジェクトを停滞させる
脅威を追い出す
- 振る舞いを追い出す
  - 人の追放は必然的な結論ではない
    - (振る舞いの追放は結局人の追放に繋がるのでは？という意見があった。確かに、実際に追放したり、追放に繋がることは多いだろうが、そういう振る舞いをする人が勝手に消えてくれるのは追放したのではなく自己選択してくれた結果、ということになるであろう)
- いくつかの方法
  - 完璧主義者には別の方向性を与える
    - 完璧主義の対象となるテーマを変更する
    - 不平不満をいう人にも効果的で、テストや手戻りの確認を担当してもらうなどがある
  - トロルには黙殺し、餌を与えない
    - (これ、とても難しいし、無視することがコストではないか、という意見もある。)
  - 感情的にならない
    - 仕事は優れたソフトウェアを書くことであり、
    - ご機嫌をとったり、正当化したりすることではない
    - 争いごとはきちんと選んで、平静にたもつようにしよう
  - 不機嫌の真実を探せ
    - 積極的に事実を探そう
      - 指摘されたことを好意的に解釈し
        悪口の部分を全部無視して
      - 真理をついているか、その人の経験から学べるか、などを確認する
  - 優しく追い出す
    - 平静を保って事実を見るのを応用するとできる
  - 諦める時をしる
    - どんなに振る舞いを直そうと頑張ってみても
    - 見込みがないと諦めて先に進まなければならないときがくる
  - 長期的に考える
    - 有害な振る舞いに対応するときの2つの質問
      - 短期的にはチームの注意や集中を無駄にしても、長期的にはプロジェクトにメリットがあるか？
      - その衝突は有益な方法で解決できるだろうか
    - 短期的なメリットのために文化を妥協する必要はない
      - HRTの重要性を認めない頭のいいコントリビューターには気をつけろ
      - 技術的に貢献できる人は交換可能であり、
      - ポリシーを崩すわけにはいかない
  - ハンロンの剃刀
    - 無能(無知)で十分説明されることに悪意を見出すな
- 人を追い出すのが仕事ではない。仕事は
  - 破壊的な振る舞いを受け入れず
  - HRTに対する自分の期待を明確にすること

5章(チームが所属する組織とのやり取りでのHRT)

組織的操作
- 組織をうまく進める方法
  - 小手先のテクニック
  - 社内政治とか、ソーシャルエンジニアリングとか呼ばれる
- うまく機能している会社
  - 2つのレベルで機能している
    - マネージャー
      - HRTのあるサーバントリーダーであり、成功を支援してくれる
    - 組織
  - ここでのやることは
    - 自分の責任範囲を広げよう
      - 先を見越した行動や責任を自ら求める振舞い
    - リスクをとろう
      - 早めに失敗しよう
      - 失敗したときは自分で責任をとろう
    - 大人らしく振舞おう
      - 自分が期待していることを他人に伝える
    - 質問しよう
      - 納得いかない決定があればその根拠について質問したり議論したりすることを恐れてはいけない
    - マネージャーはエスパーではないから伝える
      - 何をしているか聞かれる前に何をしているかを報告しよう
        うまくいったことや、障害物があることや、何かを期待していることなど
- 理想的な組織ではなかった場合は？
- 環境が成功を邪魔している
  - 悪い人
    - 悪いマネージャー
      - 自分のキャリアしか考えていない人
        失敗に対する不安
        外部とのやり取りへの不安
        知の独占
    - オフィスの政治家
      - こいつを信頼するとキャリアに制限がかかる
      - すぐ他人のせいにし、自分の手柄にしようとする
      - 見分け方:
        影響力のある人を探そうとしていることですぐわかる
  - 悪い組織
    - 会社の経営に口を割り込ませないような組織
    - 封建制度のような指揮統制型の構造
    - 肩書や組織階層のことで頭がいっぱい
    - 言うことを聞かない子供のように扱われている
    - 成功の評価が見当はずれ
    - 集中・ビジョン・方向性などの重要な要素がない
- 組織操作
  - 振舞うべきことは多くあるが、
  - そういうものと認めよう
  - ルールは変更できる
    - 利用できる仕組みを見つけて、居心地のいい場所を作ろう
    - なお、抵抗や正当化には、政治資本が必要となる
- 戦略
  - 許可を求めるより寛容を求める方が楽
    - 組織で許されていることの把握
    - アイデアに共感する仲間を見つけ、セカンドオピニオンをしてもらう
  - 道がないなら道を作る
    - 草の根でアイデアを受け入れてもらう・広める
      - (誰から聞いた言葉かは忘れたが、「壁にひざまずくのではなく、壁を打ち砕くのではなく、壁をすり抜けよう」という言葉を思い出した。)
  - 上司の管理方法を学ぶ
    - 何をやっているか表明する
  - 約束は小さくして、届けるものは大きく
    - できないものに「No」と言う意味で約束を小さく
    - プロダクトのローンチをするという意味で届けるものを大きく
    - プロダクトのローンチにエネルギーを注ぐべき
      - 「攻撃的」な仕事と「防御的」な仕事
        政治的信頼性の獲得をしやすい攻撃的な仕事、UI改善や新規機能開発
        防御的な仕事というのは生産性をあげるためのリファクタリングなどの負の遺産の整理である。
        筆者らは、3分の1から2分の1までしかかけないようにしており、それ以上は政治的自殺行為であるから、と述べている。
        (なお、私がここまで防御的な仕事になったのは、昨年外部と関わった仕事で、内部の攻撃的な仕事に関われなかったことがきっかけなのかもしれない。)
  - 運と親切の経済
    - 他人の仕事を手伝うようにするという親切を掛け金として
    - 見返りが来たり気づきが得られたりという運が入り込んでくる
      - それによって人のつながりが得られ、それは会社から抜けた後でも続く
  - 安全なポジションまで昇進する
  - 強力な友達を探す
    - コネクタ
    - 引退選手
    - 管理スタッフ
    - 君自身
  - 忙しい経営者にお願いする方法
    - 問題の説明については、最大3つの箇条書きと
    - 1つだけの行動要請でもって
      - HRTの原則に基づいたお願いや質問をすること
      - 問題の詳細等については、お願いやメールの締めの後に、追加する。
- 逃げる
  - 正しいことをして、後は、解雇を待つ
  - 自分自身の将来をコントロールできる能力を身につける。

6章(ユーザーとのやりとりにHRTの原理を持ち込む)

ソフトウェアの目的と生存のためにすること

ソフトウェアを書く理由は、他人が幸せにすること。
だから、
- 他人が幸せにならなければ、
- feedback loopの方法を身につけなければ、
- ソフトウェアは死ぬ。

User Engagement

ユーザーの気づき(マーケティング; どのように見られているかに気を配る)
ユーザーの体験(ユーザビリティ; ユーザーが離れるのを避ける)
ユーザーとのやり取り(顧客サービス; 長期的な関係構築が、ソフトウェアの進化とユーザーの定着に影響を与える)

マーケティングは、エンジニアリング文化で重要視されている事実ベースと相性が悪いが無視できないが、うまくやる方法がある
- 感情的な知覚に配慮する
  - 認知したもの勝ち
- 第一印象に注目する
- 小さく約束し、大きく届ける(見積もりを大きくしたり、予告をしなかったり)
- 業界のアナリストとうまく付き合う
ユーザーに集中すれば、他のことは全てついてくる
- これが、プロジェクトの成否にも関わる
- 観客を選ぶ
  - 最重要なのは、ユーザーの技術的能力を考える
- 入り口のハードルを下げる
  - 最初の体験が超重要。
  - アカウント作成を強要しなかったり、スピードを優先したり、と。
- ユーザーではなく、利用を計測する
- 速度重要
  - 速度は機能ですらある。(非機能要件とよく言われるが、Googleの人は機能要件と捉えているようだ)
  - レスポンスが速ければ、待ち時間が短くなり、何度でも使うようになる
    - 無意識により多く使うようになる
  - 利用数の停滞の原因は、多くは速度・スループットにある。
- 多くのユーザーの共通の問題を解決する
- ユーザーにとって使いやすいソフトウェアを作るためにはなまけないこと
- 複雑さを隠す
  - 複雑さを隠し、簡単なことをしているように感じられるようにする、つまり抽象化する(インターフェイスの柔軟さ)
    - しかし、ユーザーを不自由にしてはいけない
      - 抽象化が漏れる場合のバイパスを用意すること
    - ユーザーの信頼を得ることが最も大切なリソースである
      - これのために、インターフェイスの回避を用意すること
ユーザーとの関係の管理
- ユーザーは話や自分の意見を聞いてもらいたく、関係を築きたいと思っている
  - 話や意見の存在や内容を認知することが重要
  - ユーザーはHRTのある会社なら好きになる
- ユーザーと開発者との間に壁を作ってはならない
  - ユーザーの増加は技術能力の平均レベルの低下を招き
  - ユーザーの失望を増やし
  - 苦情の増加を招く
  - けれど、その苦情を開発者に届けさせないことはダメなことだ。
- 見下さない
  - ユーザーの質問や意見はユーザーの知能とは関係ない
  - ユーザーに敬意を払おう
- 我慢する
  - ユーザーは問題をうまく表現できない
    - 語彙の統一がされていないという問題がある
- 信頼と喜びを作ろう
  - 信頼
    - おおよそ感情的に正の状態が積み重なった結果のもの
    - すぐ吹き飛ぶ
    - 最も大切なリソース
      - 残高に気を配ろう
      - 長期的なイメージを持とう
  - 喜び
    - 幸せな気分にさせる驚き
      - ユーザーを大切にしていることを伝える

まとめ

HRT、これの欠乏が問題を引き起こす

HRTの原理を、『Team Geek』では、以下のように広げていった。

自分
チーム
チームをリードする方法
チームの外部とのやり取り
ユーザーとのやり取り

この手法は、エンジニアリングのみならず、あらゆるコミュニティが対象となる。

team