Recommended
More Related Content
What's hot
What's hot (20)
Brian, Ben(2013)『Team Geek 』の要約
- 2. Brian, Ben 『Team Geek』(2013) オライリージャパン 角 征典 (翻訳), 及川 卓也 (解説) https://www.amazon.co.jp/dp/4873116309/ref=cm_sw_r_tw_ dp_x_FcR8FbRM2EFZX 著者らのOSS活動やGoogleでの経験から、Teamについて語って いる。そして、Teamが全て、Teamをよくするためにどうするのか、 ということについて、繰り返し丁寧に語っている良書。 本スライドでは、『Team Geek』のトピックを掻い摘んで、流れを追 いかけることに専念した。詳しくは本を読もう。 2
- 3. チームにおける問題の原因 HRT(Humidity: 謙虚、Respect: 尊敬、Trust: 信頼)、これらの欠 乏が問題を引き起こす。 『Team Geek』では、このHRTの原理を以下のように拡張: 1. 自分 2. チーム 3. チームをリードする方法 4. チームの外部とのやり取り(外部、組織) 5. ユーザーとのやり取り 3
- 4. 0章: プロジェクトの成功のカギ プロジェクトの成功のためには、以下の2つの要因が必要である: ● 優れたコードという技術的要因と ● みんなの協力という人的要因 ○ 人間は難しく「人間は断続的なバグの大きな塊」 ○ その一方で、チームは個人の生産性や幸福に直接影響する 4
- 6. 1章: 天才の神話 1人で籠り偉大なものを発表するという天才の神話。 実際のところ、チームが全てである。 ● 天才はコードを隠さない ○ 優れたコードだとしても不十分 ● コードを隠すのは不安の裏返しである ● 天才の本当の功績は、チームとうまくやることができたこと 6
- 7. 1章: 天才の神話 ● 1人でやることは失敗のリスクが高く、みんなでやることの方 がメリットが高い。 ○ 失敗に早期に気づける。 ■ プロジェクトには、高速でのフィードバックループが必要 ○ プロジェクトののバス係数が高まる。 ■ 1人抜けてもカバーできる。 ○ 横にも縦にもスケールできる。 チームが全てである。 7
- 8. 1章: HRTとその活用方法 謙虚(H: Humidity)、尊敬(R: Respect)、信頼(T: Trust)、これを自 分が持ち、相手も抱けるような環境を作ることが重要 HRTは、健全な対話とコラボレーションの基盤: ● これらが欠如すると人間関係が衝突する ○ 人間関係は、1つのプロダクトやプロジェクトより、長く続く ● さらに、これらがあると、いざ困ったときに、助けられる 8
- 9. 1章: HRTとその活用方法 謙虚であれ ● エゴをなくせ ○ コミュニティは信じられないほど強力なアイデンティティがある ● 自分の学習のための時間を作れ ● コードレビューの際は、謙虚になり、相手に尊敬を含め、相 手が恩恵をもたらしてくれると信頼しなさい 9
- 10. 1章: HRTとその活用方法 失敗、学習、反復を素早くやろう ● 不完全を見せても構わないという謙虚さを持ち、 ● ユーザーが、対応を賞賛し、改善を要望するという信頼で、 ● 失敗の文書化(ポストモーテム)をする ○ 文書化では、何を学んだか、何を改善するか、を扱う。 10
- 11. 1章: HRTとその活用方法 影響を受けやすくなりなさい ● 間違いや能力不足を認める ○ 謙虚さを見せる ● 他人の意見を信頼する この正直さと強さは尊敬を産みます。 11
- 12. ２章 チームにHRTの原理を持ち込む ● チーム文化 ● チーム内でのコミュニケーション 方法 ● 文化の作り方 12
- 13. ２章: チーム文化 チーム文化を作ることで、自己選択的な文化になり、また、外部 から来た悪意ある人や文化を排除することができるようになる。 ● 文化はイースト菌のようなものそしてその種菌が重要 ● チーム文化とは、エンジニアリングチームが共有する、経 験、価値、目標 ● 強い文化は自己選択的な文化である ○ 文化に合わない人は、事前に遠ざかってくれる 13
- 14. ２章: チーム文化 ● 合意ベースのマネジメントなら、チーム全体が意思決定プロ セスに参加できる ○ チーム全員がプロダクトの成功に強い責任を持ち ○ リーダーがチームの意見に耳を傾けること (尊敬) ● チームメンバーとの接し方 ○ HRTを持っていればよい ○ 前向きな批判をしてくれる友達や同僚を見つけよう ● 文化が、積極的なのか、のんびりなのかを理解し、 ● 新来者に支配されないように気をつけよう 14
- 15. 2章: チーム内でのコミュニケーション 方法 コミュニケーションなしには正しいコードを書いている保証ができ ない。 そのためのコミュニケーションについては、 ● 同期コミュニケーションの人数を減らし ● 非同期コミュニケーションの人数を増やす ○ 決める人は少なく、伝える人は多く、とも言えるだろう。 ○ 伝えられたからのフィードバックも用意しておこう。 15
- 16. 2章: チーム内でのコミュニケーション 方法 チームのハイレベルの同期 ● 高いレベルで共通の目的を持つ ○ ミッションステートメントの共有 ● 進捗を伝えるベストプラクティスに従う ○ ミーティングをし、以下の 2つを行う ■ 地理的障害があることを意識する ● 時間的な障害もあるだろう ■ 設計文書の共有 16
- 17. 2章: チーム内でのコミュニケーション 方法 ミッションステートメントを作る ● チームの方向性を定義して、 ● プロダクトのスコープを制限する ○ Making GWT Betterの例を見よ 17
- 18. 2章: チーム内でのコミュニケーション 方法 ミッションステートメントを書くことで ● 認識の違いを明らかにし ● 方向性に合意でき ■ これがなければ、スピードが落ちるか、停止するかのどちらか になる ● 共有することができる 会社の方向性に合わせねばならないから、ミッションステートメン トは適宜再評価する 18
- 19. 2章: ハイレベル同期完了後にやること ● チームの日々の調整に使うツールを与える ○ ツールは少しの手間で生産性を大きく高められるが、たいてい帯域が 狭く、誤解やHRTの欠如に繋がる ○ メーリングリスト ■ 議事録・ミーティングのメモ・決定事項・設計文書を記録するの には使った方がいい。検索可能にしておこう ○ オンラインチャット ■ 物理空間の事情を考えなくていい (通知をOFFにしていれば) ○ 課題管理ツールを使おう ■ ただの掲示板 ■ 課題をオフィシャルにして、みんなの目に触れられるようにする 19
- 20. 2章: 文化の作り方 文化やコミュニケーションの習慣をまとめる ● 好みの反映 ○ 「好み」には適切な人と正しい価値が必要 ● 主観的ではない ● 自然発生ではない ○ チームリーダーと創業者が ○ 機能不全のチームのコストを理解して、 ○ 丁寧に種を播いて育てていくもの 20
- 21. 2章: 文化の作り方 チーム文化を作ることのメリット ● 文化の定義や防御よりもコードの設計や記述に時間をかけ れる ○ 防御には、新来者への説明を含む ○ コードを書くことを目的とする強いチームを作ることには膨大なコミュ ニケーションが必要 ■ コードは、人と人とのコミュニケーションである。 21
- 22. 2章のおまけ コミュニケーションのための ● ミーティングについての5つの ルール ● コミュニケーションで意識すること ● エンジニアのコミュニケーションに ついてのリマーク 22
- 23. ミーティングについての5つのルール 1. 絶対に必要な人だけ a. その時間に別作業している人は会議に参加しなくてもよい人だから誘 うのを間違えている。 2. アジェンダを作って、ミーティング開始前に配布する a. ミーティングを設けない日や時間を設けて、クリエイターの時間を設け る 3. ミーティングのゴールを達成したら時間前でも終了 4. ミーティングを順調に進める a. 取り仕切る人がいるようにする 5. ミーティングの開始時間を強制的に中断される時間の前に 設定する 23
- 24. コミュニケーションで意識すること ● 地理的障害のあるチームで働くことを意識する ○ 「メーリングリストで議論がなかったら何も起きていない」というモットー ■ チャットの後「リアル」としてのメーリングリストに投稿 ○ リモートから話しかける時 ■ 机に向かって歩いていくかのような自然な感じであれ ○ 積極的にチームとコミュニケーションをし自分の存在だけでなくこちら の仕事も知ってもらう ○ フェイストゥーフェイスの帯域を過小評価してはいけない 24
- 25. コミュニケーションで意識すること ● 設計文書を、コードの前に、書くこと ○ 未来のハイレベルな青写真 ■ 何をどうしたいのかを低コストでチームに伝える手段でもある。 ○ 設計文書は、コーディング開始後で「生きた文書」として扱う ■ プロジェクトの進行に従って、更新していくべき ○ 設計文書を書くか、スクラッチから作るかは、経験で判断すること ■ 設計文書を書く時間で何度もスクラッチから書き直せるなら、そ の文書は時間の無駄であったりする 25
- 26. エンジニアのコミュニケーションについ てのリマーク コードコメントではなぜを簡潔に説明せよ ● 「なぜ」を説明するもの ○ 「何」ではない ● 中庸を知れ ○ コメントスタイルをチームで決めよ ■ 一貫性を守る方が大切 ● 関係なパターンマッチングによる推測が可能になる ○ 使用を制限する機能についても決めておこう Authorタグをつけるな 26
- 27. エンジニアのコミュニケーションについ てのリマーク 全てのコミットにコードレビューせよ ● 変更はレビューしやすいように小さく ● コードレビューは ○ 品質を向上させ ○ 品質に対するチームの誇りを育む 27
- 28. エンジニアのコミュニケーションについ てのリマーク リアルなテストとリリースプロセス ● 自動テストを増やせば、バグ修正や機能追加の際に自信を 持てる ● テストをコーディングやレビューのプロセスの一部にする ○ 徹底的にテストを行え ● 頻繁にリリースできるようにリリースプロセスを調整せよ ○ ユーザーからの信頼を獲得せよ 28
- 30. 3章 ● チームリーダーにならなくても、チームリーダーの行動を理 解できるようになるからこの章を読め ○ チームリーダーがどのパターンを使って、成功 (失敗)につなげている かを見て ○ チームの原動力がより具体的に理解できる 30
- 31. 3章: リーダーとは リーダーのいないチームは機能しない ● かじ取りする人のいない船みたいなもの ● ソフトウェアの方向性に影響を与えるためには、エンジニア リングリーダーシップを隅々まで理解する必要がある 31
- 32. 3章: リーダーとは マネージャー ● 誕生 ○ 産業革命期 ○ 労働者を監督するマネージャーという立場 ■ 労働者を人参と鞭(今ではもう全く効果がない )とで管理 ● 変化 ○ エンジニアは数か月間かけて新しいチームに追いつく ○ 考えたり創造したりするためにの育成・時間・空間が必要 32
- 33. 3章: リーダーとは マネージャーとリーダーの違い ● 昔のマネージャー ○ 親と子の関係のようなもの ■ どうやって仕事を完了させるかを考える ● リーダー ○ HRTでエンジニアを信頼するようにすれば、エンジニアはその信頼に 答える ○ チームのための道を作り、安全と安心に気を配る ○ 何ができるかを考える ■ どうやって完了させるかはチームが考える 33
- 34. 3章: Managerになろうよ Managerになることへの不安 ● コードを書く時間が減ることへの不安 ○ 定量化できないものが増えることへの不安 ■ チームの幸せと生産性をたかめるのが仕事の指標である ● 無能なマネージャーになるのではないかという不安 ○ ピーターの法則で、階級制度があるところでは、必ずその人の無能レ ベルまで昇進する 34
- 35. 3章: Managerになろうよ Managerになるべき大きな理由 ● 自分をスケールできるから ● マネージャーに向いているかもしれないから ○ 実際、マネージャーに向いていた人が多くいる 35
- 36. 3章: Managerになろうよ マネジメント病(管理したがり病)の負の再生産の問題について ● サーバントリーダーシップで治療する ○ チームに奉仕すること ○ HRTの雰囲気づくりをすること ■ アドバイスを与えたり、 ■ 順調に進めるよう穴を埋めたり ■ 自らの手を汚す ○ 技術的な側面とチームの人間関係の両方を扱う 36
- 37. 3章 リーダーのアンチパターン ● 言いなりになる人を採用する ● パフォーマンスの低い人を無視す る ● 人間の問題を無視する ● みんなの友達になる ● 採用を妥協する ● チームを子供として扱う 37
- 38. 3章: マネジメントのアンチパターン 言いなりになる人を採用する ● 仕事が増えるぞ ● むしろ、自分より球が良くて、代わりになる人を採用しよう ○ 新しいチャンスを産む 38
- 39. 3章: マネジメントのアンチパターン パフォーマンスの低い人を無視する ● 「願いは戦略ではない」 ○ パフォーマンスの低い人にはコーチングをする ■ HRTとともにマイクロマネジメントをする ■ 小さい目標から大きな目標へマイルストーンには明確な期待を 設定する ● 期待に応えない人をどうするかというのが一番難しい問題 ○ 立ち去ってもらうことがチームにとって一番良いこと 39
- 40. 3章: マネジメントのアンチパターン 人間の問題を無視する ● 人間的な側面を無視してしまうととんでもないことになる ● ちょっとした共感さえあればよかったことがしょっちゅうある 40
- 41. 3章: マネジメントのアンチパターン みんなの友達になる ● 友人関係のままであろうとするな ○ 友人関係も失うことになる ■ 上下関係があると人工的な友人関係を作りだしてしまう可能性 がある ● 友人関係とチームをリードすることとを混同してはならない ● 友人関係ではなく、不安を感じさせずに仲良くしたいなら、 一緒にランチしろ 41
- 42. 3章: マネジメントのアンチパターン 採用を妥協する ● 採用基準を満たす人を取れ ● 採用すべきでない人の採用のコストは高い チームを子供として扱う ● 子供・囚人として扱うことは、信頼していないということであ り、コストが高い ● 信頼されていることを感じれば責任を感じるようになる 42
- 43. 3章 リーダーシップパターン ● リーダーシップパターン ○ エゴをなくす ○ 禅マスターになる ○ 触媒になる ○ 先生やメンターになる ○ 目標を明確にする ○ 正直になる ○ 幸せを追い求める ● 人を画一で捉えるな 43
- 44. 3章: リーダーシップパターン エゴをなくす ● 謙虚になること ○ 犠牲になることではない、自信がないことでもない ● チーム全体のエゴやアイデンティティを育もう ○ チームを信頼すること ■ リーダーの仕事はチームの合意形成や方向性の決定を支援 ■ リーダーの仕事ではないことは全てに正しく、全てを知り、全て に応える ○ ミスをしたときに謝ること ■ 心から謝罪するということ 44
- 45. 3章: リーダーシップパターン 禅マスターになる ● 多くのエンジニアが懐疑的や批判的な感度が高いと思われ る ○ チームリーダーとしてはそういった言葉を慎め ● 常に平静を保つ ○ そうでないと部下に大きな悪影響を及ばす ● 問題解決モードに突入する前に、質問者の問題解決を助け るために支援をする ● そのために質問をする 45
- 46. 3章: リーダーシップパターン 触媒になる ● 合意の形成。方向性を示したり、決定したりする。 ● 妨害や障害の除去・回避 ○ 適切な答えを知るよりも、適切な人を知る方が価値がある ● 安心感を与え、リスクを取れるようにする ○ リスクをとれば大きな成功の確率が上がり、道が開ける ○ 失敗してもいいことをチームに知らせる ■ 失敗によって多くのことを素早く学べる ○ 個人の成功はみんなの前で称え、失敗はチームとして受け止め、そこ から学ぶ。また、プライベートで建設的な批判をする。 46
- 47. 3章: リーダーシップパターン 先生やメンターになる ● 自力で学ばせようとするのがリーダーの大切な役目 ○ 学ばせること: ■ 技術、コード、チーム文化、想定される責任レベル ● メンターに必要な三つのこと ○ チームのプロセスとシステムの経験 ○ 誰かに教える能力 ○ 相手がどれだけ支援を必要としているかを把握する能力 47
- 48. 3章: リーダーシップパターン 目標を明確にする ● チームメンバーが同じ方向に行かねばならない ● ミッションステートメントを見せる ○ あとは、自律性に任せて、定期的に確認 ○ これで、チームの効率は劇的に向上する 48
- 49. 3章: リーダーシップパターン 正直になる ● 褒め言葉のサンドイッチを避けた方がいい ● 本当に伝えたいメッセージを、正しく伝わっていることが重要 ○ 建設的な批判をするときは、親身になって共感すればいい ○ 失礼のないように明確に ○ 相手を防御的にするような伝え方はしない 49
- 50. 3章: リーダーシップパターン 幸せを追い求める ● リーダーとして長期にわたって生産的に、かつ、離脱者を少 なくするには、 ○ 時間を作って、チームの幸せを計測すればいい ○ 一対一の面談の後に「何か必要なものはある？」と質問する ● オフィスの外におけるチームの幸せにも注意を向けた方が いい ○ どうして生産性が高いのか低いのかが、プライベートな状況にまで目 を向けているか、わかるかも ● 暗黙的な目標を明確化する 50
- 51. 3章: リーダーシップパターン 他のリマーク ● 移譲せよ、ただし手を汚せ ● 自分自身を置き換えようとする ● 事を荒立てる時を知る ● カオスからチームを守る ● 新しいことをやりたいなら取返しがつくかどうかを見極める ● チームを空中援護する ● いいところをフィードバックする 51
- 52. 3章: 人を画一で捉えるな 人は植物(みたいにみんなそれぞれ必要なものが異なる)。 必要 なものは人それぞれ ● 「興奮/退屈」と「自発的/注意散漫」のマトリックス ○ 自発的/注意散漫には、方向性が必要 ■ 何をすべきかを理解し、構造化のスキルを身につけ、管理可能 なタスクに分割すればいい ○ 興奮/退屈には、モチベーションが必要 ■ モチベーションには二種類あり、一つは外発的 ■ もう一つは内発的動機 ● 自律性、熟達、目的 52
- 53. 4章 チームの外部とのやり取りでHRT をもつ ● 有害な外部とのやりとりの仕方 ● 有害とは ● 脅威を特定する ● 脅威を追い出す 53
- 55. 有害とは ● ある種の振る舞いのことである ○ チームの文化に含めないこと・やりたくないこと ■ これらを明確化しておくと、目に余る振舞いの特定とその批判 ができるようになり、 ■ 有害な振る舞いを排除する文化を作れる 人が変わっても文化は残る ● 強い文化は自己選択的である ○ 文化を強くし、残すため、そして、悪い方向に行かないようにするため には、すでに記述した強くする方法のおさらいをしよう 55
- 57. 脅威を追い出す ● 振る舞いを追い出す ● 人の追放は必然的な結論ではない ● 人を追い出すのが仕事ではない。仕事は: ○ 破壊的な振る舞いを受け入れず ○ HRTに対する自分の期待を明確にすること 57
- 58. 4章 脅威の古典的パターン ● 他人の時間を尊重しない ● エゴ ● 権利を与えすぎる ● 未熟なコミュニケーションと複雑 なコミュニケーション ● パラノイア ● 完璧主義 58
- 59. 脅威のパターン 他人の時間を尊重しない ● 文書を読まない人だったりして、 ● 人のエネルギーを消費する エゴ ● 合意の決定を受け入れられない人 ● 異なる視点の意見に耳を傾けられない人 ● 妥協できない人 ○ 正しさよりも結論にたどり着くかどうかが重要 59
- 60. 脅威のパターン 権利を与えすぎる ● 要求すれど貢献はしない人たち ● 権利を与えすぎるとトロルになる 未熟なコミュニケーションと複雑なコミュニケーション ● 本名を使わなかったりメディアによってニックネームを分け たりする ○ (日本のインターネット文化とはだいぶ異なる ) 60
- 61. 脅威のパターン パラノイア ● オープンで透明なコミュニケーション文化があったとしても、 ● 陰謀論を唱える被害妄想患者がいる 完璧主義者 ● プロジェクトを停滞させる 61
- 62. ４章 脅威を追い出すいくつかの方法 ● 完璧主義者には別の方向性を与 える ● トロルには餌を与えない ● 感情的にならない ● 不機嫌の真実を探す ● 優しく追い出す ● 長期的に考える ● ハンロンの剃刀 62
- 64. 脅威を追い出すいくつかの方法 感情的にならない ● 仕事は優れたソフトウェアを書くことであり、 ● ご機嫌をとったり、正当化したりすることではない ○ 争いごとはきちんと選んで、平静にたもつようにしよう 不機嫌の真実を探せ ● 積極的に事実を探そう ○ 指摘されたことを好意的に解釈し、悪口の部分を全部無視して ○ 真理をついているか、その人の経験から学べるか、等を確認する 64
- 65. 脅威を追い出すいくつかの方法 優しく追い出す ● 平静を保って事実を見るのを応用するとできる 諦める時をしる ● どんなに振る舞いを直そうと頑張ってみても ● 見込みがないと諦めて先に進まなければならないときがくる 65
- 66. 脅威を追い出すいくつかの方法 長期的に考える ● 有害な振る舞いに対応するときの2つの質問 ○ 短期的にはチームの注意や集中を無駄にしても、長期的にはプロ ジェクトにメリットがあるか？ ○ その衝突は有益な方法で解決できるだろうか？ ● 短期的なメリットのために文化を妥協する必要はない ○ HRTの重要性を認めない頭のいいコントリビューターには気をつけろ ○ 技術的に貢献できる人は交換可能であり、ポリシーを崩すわけには いかない 66
- 71. うまく機能している会社 うまく機能している会社でのやることは ● 自分の責任範囲を広げよう ● リスクをとろう ● 大人らしく振舞おう ● 質問しよう ● マネージャーはエスパーではないから伝える 71
- 72. 環境が成功を邪魔している。 悪い人。 ● 悪いマネージャー ○ 自分のキャリアしか考えていない人 ■ 失敗に対する不安、外部とのやり取りへの不安、知の独占 ● オフィスの政治家 ○ こいつを信頼するとキャリアに制限がかかる ○ すぐ他人のせいにし、自分の手柄にしようとする ○ 見分け方: ■ 影響力のある人を探そうとしていることですぐわかる 72
- 73. 環境が成功を邪魔している。 悪い組織。 ● 会社の経営に口を割り込ませないような組織 ● 封建制度のような指揮統制型の構造 ● 肩書や組織階層のことで頭がいっぱい ● 言うことを聞かない子供のように扱われている ● 成功の評価が見当はずれ ● 集中・ビジョン・方向性などの重要な要素がない 73
- 74. 理想的な組織ではなかった場合は？ 組織操作 ● まず、 ○ 振舞うべきことは多くあるが、 ○ そういうものと認めよう ● 次に、ルールは変更できる ○ 利用できる仕組みを見つけて、居心地のいい場所を作ろう ■ なお、抵抗や正当化には、政治資本が必要となる 74
- 75. ５章 組織的操作の戦略 ● 許可を求めるより寛容を求める方 が楽 ● 道がないなら道を作る ● 上司の管理方法を学ぶ ● 運と親切の経済 ● 安全なポジションまで昇進する ● 強力な友達を探す ● 忙しい経営者にお願いする方法 を学ぶ ● 逃げる 75
- 76. 組織的操作の戦略 許可を求めるより寛容を求める方が楽 ● 組織で許されていることの把握 ● アイデアに共感する仲間を見つけ、セカンドオピニオンをし てもらう 道がないなら道を作る ● 草の根でアイデアを受け入れてもらう・広める ○ (誰から聞いた言葉かは忘れたが、「壁にひざまずくのではなく、壁を 打ち砕くのではなく、壁をすり抜けよう」という言葉がある ) 76
- 77. 組織的操作の戦略 上司の管理方法を学ぶ ● 何をやっているか表明する 約束は小さくして、届けるものは大きく ● できないものに「No」と言う意味で約束を小さく ● プロダクトのローンチをするという意味で届けるものを大きく ○ プロダクトのローンチにエネルギーを注ぐべき ○ 「攻撃的」な仕事と「防御的」な仕事のバランスを取る 77
- 78. 組織的操作の戦略 運と親切の経済 ● 他人の仕事を手伝うようにするという親切を掛け金として ● 見返りが来たり気づきが得られたりという運が入り込んでく る ○ それによって人のつながりが得られ、それは会社から抜けた後でも続 く 安全なポジションまで昇進する 78
- 79. 組織的操作の戦略 強力な友達を探す ● コネクタ ● 引退選手 ● 管理スタッフ ● 君自身 79
- 80. 組織的操作の戦略 忙しい経営者にお願いする方法 ● 問題の説明については、最大3つの箇条書きと ● 1つだけの行動要請でもって ● HRTの原則に基づいたお願いや質問をすること ○ 問題の詳細等については、お願いやメールの締めの後に、追加す る。 80
- 82. 6章 ユーザーとのやりとりにHRTの原 理を持ち込む ● ソフトウェアの目的と生存のため にすること ● User Engagement ○ ユーザーの気づき ○ ユーザーの体験 ○ ユーザーとのやり取り 82
- 83. ソフトウェアの目的と生存のためにす ること ソフトウェアを書く理由は、他人が幸せにすること。 だから、 ● 他人が幸せにならなければ、 ● もしくは、feedback loopの方法を身につけなければ、 ソフトウェアは死ぬ。 83
- 84. User Engagement 1. ユーザーの気づき a. (マーケティング; どのように見られているかに気を配る ) 2. ユーザーの体験 a. (ユーザビリティ; ユーザーが離れるのを避ける ) 3. ユーザーとのやり取り a. (顧客サービス; 長期的な関係構築が、ソフトウェアの進化とユーザー の定着に影響を与える ) 84
- 85. User Engagement (Marketing) マーケティングは、エンジニアリング文化で重要視されている事 実ベースと相性が悪い。が、無視できない。が、うまくやる方法が ある ● 感情的な知覚に配慮する ○ 認知したもの勝ち ● 第一印象に注目する ● 小さく約束し、大きく届ける(見積もりを大きくしたり、予告をし なかったり) ● 業界のアナリストとうまく付き合う 85
- 86. User Engagement (Usability) ユーザーに集中すれば、他のことは全てついてくる。これが、プ ロジェクトの成否にも関わる。 ● 観客を選ぶ ○ 最重要なのは、ユーザーの技術的能力を考える ● 入り口のハードルを下げる ○ 最初の体験が超重要。 ○ アカウント作成を強要しなかったり、スピードを優先したり、と。 ● ユーザーではなく、利用を計測する 86
- 87. User Engagement (Usability) ● 速度重要 ○ 速度は機能ですらある。 (非機能要件とよく言われるが、 Googleの人 は機能要件と捉えているようだ ) ○ レスポンスが速ければ、待ち時間が短くなり、何度でも使うようになる ■ 無意識により多く使うようになる ○ 利用数の停滞の原因は、多くは速度・スループットにある。 ● 多くのユーザーの共通の問題を解決する ● ユーザーにとって使いやすいソフトウェアを作るためにはな まけないこと 87
- 88. User Engagement (Usability) ● 複雑さを隠す ○ 複雑さを隠し、簡単なことをしているように感じられるようにする、つま り抽象化する(インターフェイスの柔軟さ ) ■ しかし、ユーザーを不自由にしてはいけない ● 抽象化が漏れる場合のバイパスを用意すること ■ ユーザーの信頼を得ることが最も大切なリソースである ● これのために、インターフェイスの回避を用意すること 88
- 89. User Engagement (Customer Service) ユーザーとの関係の管理 ● ユーザーは話や自分の意見を聞いてもらいたく、関係を築 きたいと思っている ○ 話や意見の存在や内容を認知することが重要 ○ ユーザーはHRTのある会社なら好きになる ● ユーザーと開発者との間に壁を作ってはならない ○ ユーザーの増加は技術能力の平均レベルの低下を招き ○ ユーザーの失望を増やし ○ 苦情の増加を招く ○ けれど、その苦情を開発者に届けさせないことはダメなことだ。 89
- 90. User Engagement (Customer Service) ● 見下さない ○ ユーザーの質問や意見はユーザーの知能とは関係ない ○ ユーザーに敬意を払おう ● 我慢する ○ ユーザーは問題をうまく表現できない ■ 語彙の統一がされていないという問題がある 90
- 91. User Engagement (Customer Service) ● 信頼と喜びを作ろう ○ 信頼 ■ おおよそ感情的に正の状態が積み重なった結果のもの ■ すぐ吹き飛ぶ ■ 最も大切なリソース ● 残高に気を配ろう ● 長期的なイメージを持とう ○ 喜び ■ 幸せな気分にさせる驚き ● ユーザーを大切にしていることを伝える 91
- 92. まとめ 92
- 93. まとめ HRT(Humidity: 謙虚、Respect: 尊敬、Trust: 信頼)、これの欠乏 が問題を引き起こす。 HRTの原理を、以下のように広げていく。 1. 自分 2. チーム 3. チームをリードする方法 4. チームの外部とのやり取り 5. ユーザーとのやり取り 93
- 95. Thank you for Listening! 95
- 96. Brian, Ben 『Team Geek』(2013) オライリージャパン 角 征典 (翻訳), 及川 卓也 (解説) https://www.amazon.co.jp/dp/4873116309/ref=cm_sw_r_tw_ dp_x_FcR8FbRM2EFZX 重要なこと(HRT)を何度も繰り返し語っている。書いてあることは 当然なことであるけれど、当然なことを列挙しまとめることは難し く、またそれを心にとめ、実践することも難しい。 是非、この本を読んでください。 96