🔗概要

• ソフトウェアエンジニアとして成長し、チームで働くときの必要条件
• ろくでなしが使うとろくでもないコードが生まれやすいというのはフレームワーク自体の潜在的な問題。「賢い人間が使うと問題は起きない」という論調を張っても解決するものが何もない。

🔗目次

• 成長
• Hyrum の法則
• チームで働くときの適正
• エンジニアのタイプ
• 文化の種菌
• コードフリーズ
• Design Doc
• 決済処理
• SRE

🔗成長

• ポストモーテム：学習した結果として何を学んだかと何を変更するかを記述する。
• 専門家になり人に教えることは重要だが、同じだけ自分も謙虚に学ぶ必要がある。
• LaTeXは一人で作られたが、普通の人間は一人で作ることはない。
• コードを隠さない。

🔗Hyrum の法則

• 順序なし辞書を乱数生成に使う。
• 50Hzの電源をタイムスイッチに使う。
• Unixが"."から始まるファイルを表示しないのは、本来の仕様ではなくバグだった。もともとlsコマンドは "." と ".." だけを非表示にするはずだったのだが、KenとDennisはこれを手抜き実装した:
  • if (name[0] == '.') continue;
  • 以後、この「仕様」が悪用され今日に至る。

🔗チームで働くときの適正

• Humility, Respect, Trustが大切

• 人間関係は非常に大切

  • 仲良くしていると、1時間のお手伝いくらいならしてくれるかも。これは10000円の価値がある。

• コードへの批判と人格批判を明確に区別する

  • コードレビューは人格攻撃としてマネージャに避難されるべきものではない

• アンチパターン

  • 自分が最も重要な人物であるかのように振る舞う人とは一緒に働きたくない。自分の宣伝をしない。

• 郷には郷に

  • 周囲に合わせる。周りがスーツならスーツを着る。小さな大小を払い続けることになる。

• 柔らかい表現を心がける

  • 相手への指摘は、「Aを使うべき」ではなく「この部分がよくわからないのですがAを使うと読みやすくなるでしょうか？」としたほうがいい

• 柔軟に影響を受ける

  • 影響を受けやすいと、影響を与えやすくなる。頑固者は障害物として話を聞いてもらえなくなる。

🔗エンジニアのタイプ

• 以下の2パターンはかなり相性が悪くて、チームとしてはたらくにはHRTが必要
  • ボトムアップエンジニア：ガチャガチャやって全体像を見てから詳細に取り掛かるエンジニア
  • トップダウンエンジニア：メソッドの実装を全て理解しながら作業を始めるエンジニア。

🔗文化の種菌

• 創業時の文化（種菌）をちゃんと設計

  • 新しく入ってきた人が持ち込む文化（雑菌）に耐えられない。
  • 種菌を守るには文化は強くしておかないといけない。
  • 強烈な個性を持つ新人が入ってくると、彼の文化がチームに根付いてしまう。それは避けなければならない。

• 「文化の健全性」に気を使わなければならない

  • 強い文化は改善に対してオープンだが、外を与える急激な変化に対しては防御的。
  • 文化を作ると、その文化に賛同してくれる人が集まっってくる（自己選択的、自己組織化）。

• 文化の面接大切

  • 技術の面接の前に文化の面接をするところもある。
  • 文化は明示的に作り出すものであって、偶然生まれるものであってはならない。

• 優秀なエンジニアは優秀なエンジニアと働きたいと思っている。

  • 成長したいからと
  • そうでない組織で仕事を押し付けられ続けられた経験から

• 文化は文化にあった人を引きつける。ミソジニー的になる。

  • 見栄をはったり威嚇し合ったりするような文化はだそういう人を引きつける
  • 男性はそれが心地よいと思う人もいるかもしれないけど、女性はたいていそうは思わない

• チームのプライドは重要だが、個人のプライドは大惨事につながりうる

• のんびり文化と積極文化

  • のんびり文化は積極的な新人に支配されやすいので注意

• エンジニアは予測可能で論理的な人間を好むが、コミュニケーションも生産性とチームの幸福度に重要

  • 同期的・非同期的コミュニケーションを両方やりましょう。

• コミュニケーションのレベル

  • 最もレベルが高いのはミッションステートメント
    • 目指すことと目指さないことを明確にする必要
    • 方向性（ウェブ体験を改善など）とスコープの制限（Javaツールを使って、など道具の制限）が必要
    • ミッションの変更は合理的ならやっていい。

• ミーティングは状況確認のために開かない

  • メールで済むでしょ
  • 議論が必要な最低限必要な人で議論すべき（15分くらいなら別に良さそう）
  • 新しいものを設計するときはミーティングは任意化
  • 木曜日はミーティング0というルールがある
  • ミーティングの開始時間を昼休みや就業時間前に設定して長引かせない。

• ミーティングではパソコンを開くなとか言う出す人もいるが、それはナンセンス

  • メールを読み出すのはミーティングに参加しなくてもいい人だから。

• リモートはツールを使って障害をなるべく取り除くべきだが、対面も重要なので飛行機ででもいいので会いに行くのが大事。

• ソフトウェア設計文書は大切だが適切な量で。

  • 一人の人が書いて、2, 3人が承認する。
  • 設計文書はアジャイルに変えても良い。
  • 過剰なドキュメントは時間の無駄だけど。

• コメント

  • コードのwhyを説明するものであって、whatを説明するものではない
  • それは別のドキュメンテーション。

• うるさいマイノリティなど有害な人

• ソースコードに名前を入れるのは百害合って一理なし

  • こういうテリトリー作りは、人を嫌な気持ちにさせるし、手動管理の手間がめんどい
  • 20年前ならやってもよかったかもだけど、ソフトウェアは映画のエンドクレジットのような固定された作品ではなく、変化し続ける。

• 優れたチームリーダは重要。

  • 工場で交換可能な従業員に命令するようなマネージメントをエンジニアリングに持ち込まない。
  • 人間をラバのように扱うマネージャは未だに蔓延している。
  • エンジニアは数日のトレーニングで工場ラインに入れるわけではなく、3ヶ月~6ヶ月のオーダでのトレーニングがいる。
  • もはやマネージャという表現をさけてリーダと行ったほうがいい

• マネージャはエンジニアを信頼すればよい

  • その信頼に答えなければという重圧ドリブンに仕事をする。
  • その重圧はポジティブなものなのでHRTに反さない。
  • それと、別にチームの安全と安心に気を配ればよい。
  • 週にn時間働いたらいつ帰っても良いよ
    • fixed timeの労働は、単純に勤怠管理をしないと人は働かないという子供扱いに由来している。
  • マネージャはエンジニアのキャリアと幸せに責任を持つ
  • TLはチームリードでプロダクトの技術に責任を持つ、TLMはそれに加えてエンジニアのキャリア・幸せに責任を持つ。

• 無能化する組織構成員(終点到達症候群を抑える方法=ピーターの法則)

  • 企業などの組織に属する構成員は、その全員が自己の能力を進展させ続けなければ組織がいずれ無能化し、機能しなくなるという階層社会学の法則
  • 能力主義の階層社会において、人間は能力の限界まで出世すると無能な管理職になる。
  • 無能な人材はそのままの地位に落ち着き、有能な人材は出世して無能な管理職の地位に落ち着く。その結果、どの階層においても無能な人材で埋め尽くされる。
  • 組織の仕事は、出世する余地のある無能に達していない人材によって行われる。
  • 会社や企業などでは昇進すれば地位を与えられ、給料も上がるので出世を望む人が多いのは当然
  • 社員は自分の能力を認められるため、業績を上げるために努力する
  • その結果、仕事ができる人間と評価されれば出世して管理職の立場になります。
  • 昇格して中間管理職になり、さらに出世する人もいれば、そこで落ち着く人もいます。
  • そのポジションで「落ち着く」というのは、たとえその地位で業績を上げなくても降格はしないという状態です。
  • 昇進することを目標に努力してきた有能な人材が、ある地位を得ることがゴールになってしまい、さらに技術を磨いたり、業績を上げようとしない無能状態に陥ってしまうのです。
  • 無能レベルで実績の上がらない人は、昇進のためにガツガツすることをやめ、労働者はその立場で労働の素晴らしさについて語り、教育者は教育の価値をたたえ、宇宙飛行士はSF小説を書けばよい。つまり、自分の実績が上がらないことを考えないために自分のいる位置における労働についての尊さを語ればよいとしています。
  • 結局、無能な人を降格させることが必要というのがピーターによる提案。
  • 管理したくなる衝動を抑えるというのが非常に大切。サーバントリーダーシップ。夜遅くにジュースを買ってくるようなことも視野に入っている。必要であれば自分の技術でチームの穴を埋める。
  • 自分の言いなりになる人を採用しようとしない。それよりも、頭が良くて代わりになる人を入れたほうが刺激になる。
  • パフォーマンスの低い人にはちゃんとすぐに対応しなければならない。
    • 願いは戦略ではなく、パフォーマンスが低い人が奇跡的に成長したりどこかに行くことを願うだけではダメ。
    • そういう人を放置すると、能力の高い人の意欲を損ない、能力の高い人はチームのレベルが下がったと思ってどこかに行き、能力の低い人はどこかに行くよりしがみつく。
    • すぐに成長させるか退席させるかどちらかを選ぶ必要がある。

• 友人がマネージャになった時の対処

  • 今までのように友人関係を続けていくというのはもちろんできるならよいが、ちゃんとマネジメントはする。
  • 同じチームでリーダーになると、マネジメントを忘れがち

• マネジメントバグと採用バグは区別がつかないケースがある

  • マイクロマネジメントしなければならないような人を雇わない。Aランクの人はAランクの人を採用する、Bランクの人はCランクの人を採用する。50人面接して上位5人を採用基準と関係なく採用するというのは、最速でダメなチームを作るためのやりかた。生産性・ストレス・成長or退席・解雇・書類作業などのコストに比べたら可愛いもの。もし改善しないなら職場を変えたほうがいい。

• マネージャの達成感

  • エンジニア複数人使って一人ではできないことを達成できるので楽しいよ

• 従業員を子供扱いしない

  • Tech Stopで部品を自由に持っていって良い、とするうれしさ、楽しさ、生産性に比べて、人を子供のように扱うことによる雰囲気の堅苦しさ・コストをどちらがよいですか

• エンジニアは性質として懐疑的・批判的だが、マネージャはそのような癖を抑えたほうが良い。

• 歯車の連鎖

  • マネージャの歯車 歯車の歯が連鎖し、部下は歯が小さくCEOは歯が多い。
  • レポートするごとに大きな問題を解決していく。

• どんなにひどいことが起きても、必ず冷静に、問題の状況を質問する。

  • 問題解決の依頼が来た時、マネージャがやるべきことは自分で問題解決するのではなく、質問者が問題解決するのを助けること。
  • プロジェクトの障害は技術的なものも組織的なものもある。単に質問者をrouteする先を知っているだけで嬉しいかもしれない。
  • 失敗は学習の機会

• 目的を明確にするだけで生産性が向上する。

• 批判的なフィードバックは和らげるのではなく、親身になる

  • あなたにも、みんなにも得がないということを両面から述べる。
  • なるべく和らげるのだが、褒める・批判・褒めるとサンドイッチすると、批判の部分をまともに聞いてもらえなくなる。
  • そうではなくて、明確かつ失礼のないフィードバックを行うのが大事。
  • 親身になる。例え話を使う。

• 「何か必要なものはある？」は忘れがちな質問

• 家庭が大変なときに余裕を与える

  • そうすると、報おうと納期が迫ったときに長時間労働してくたりするもの。

• ことを荒立てる必要があるときにはことを荒立てる

  • 週に30時間しか働かない
  • エンジニアの技術レベルが低い
  • 何事にもつっかかるエンジニア 新しいことに挑戦したいと言われた場合、それを任せたあとにどういう取り返しのつかないことが起きるかを考えている。ツールの高速化なら別にいいけど、10年サポートする必要のあるサービスなら慎重に。この辺の感覚に優れて。 自立・熟達・目的意識三つを内発的動機づけにしているので、それを満たして

• アンチパターン

  • 他人の時間を尊重しない。
    • ドキュメント・ミッション・FAQ・メールを理解しない。
    • 不正確な情報を流して偉い人に訂正させる。
    • 提案は既にやられていないかを確認せず、妄想やアイディアを垂れ流すことで、正しくない・不可能・進行中・前に議論した・文章化されているなどのコメントをつけるコストがかかる。
  • 合意の決定を受け入れない
  • 異なる視点の意見に耳を傾けない
  • 妥協できない
  • 議論を蒸し返す
  • 自分の思い通りにならないと自分の意見を含めなければプロジェクトは失敗するという。
    • そのような主張をする人に何度も話し合い、説得するのに何週間もかけるのは生産性が低い。
    • 根本改善の提案が正しく予言は的中するとしても、今はベータ版かなど取り返しがつくかどうかを判別して、取り返しがつかないなら前に進む。損切り大事。
  • 優秀でも、あまりに完璧主義で周りの人に指摘しまくったりして時間を奪うのは良くない。
    • 「自分の振る舞いで他の人を遠ざけていることに気づいているか」と質問するなど、振る舞いを正す。

• 誰がチームのどれくらいエネルギーを吸い取っているか？に敏感になる。

• 完璧主義者には別の方向性を示す

  • 完璧を求めてしまう部分を他の人にアサインするなどがある。
  • 設計にこだわりすぎる人がいるなら、他の人に設計を任せて、その人にはアドバイスに留めるようにするなど。
  • 「黙ってコード書けクソが」をララバイして「パッチ歓迎」などと書いておけば良い。

• 有害な人には徹底的に優しく対応するという手もある。

  • そうすると拍子抜けしてあちらも同じ丁寧さで返してくれる。

• 小さな進歩より文化が退治

  • PRにファイルの頭に自分の名前を入れるのを混ぜたとする。それは文化に反するが、PR自体は価値がある。しかし、自分の名前を入れなければPRをしない、と言われた場合、それはrejectすべき。
  • 文化のほうが大切。

• 技術的負債の処理にかけるリソースは1/2に留める

  • なぜなら政治資本がショートして自殺行為なので。

• 裏の組織図を把握する、このような人とのつながりは問題解決上大切

  • コネクタ（友達がめっちゃ多い人）
  • 引退選手
  • 管理スタッフ

• 偉い人にメールするときは、3行で状況説明してやってほしいアクションを1行で説明するというのが良い

• 未完成の機能を事前に約束しない

  • Googleでは、何日にどんな機能を公開しますとは約束しない
  • エンジニアの保身に繋がる。世界に驚きをもって伝えられるし、デスマが起きるようなことはない。

• ユーザ第一にすれば他のことは全てあとからついてくる

  • 例えばクリック率が低い広告はGoogleがリジェクトする。
  • 収入源をわざわざrejectするのは短期的に損だが、検索者がクリックしたい広告を出せているというのはGoogleの検索広告システムの有用性が高まり、長期的には良い。
  • ユーザが出来ることはなるべく少なくする。
    • オプションを増やしすぎない。
    • 裏でどんなに複雑なことをしていてもそれを誇示してユーザに見せない、隠す。
    • 例えばGoogle文字入力はとてつもない技術だけど、それは隠されている。

• ソフトウェアは第一印象が重要

  • viははじめ入力できない。それでは印象が最悪。
  • 全てのアプリケーションでも同様のことが言えよう。
  • ソフトウェアを技術系の人と非技術系の人の療法に使ってもらうと驚くような知見が得られる。

• プロダクトはダウンロードではなく、利用されなければならない。

  • 300万回ダウンロードされたから300万人のユーザではない。
  • 3億のデバイスで使われていても意味がない。

• レイテンシは結構ユーザエクスペリエンスに効く

  • 未告知でGoogle mapのレイテンシ向上をしただけで、継続的なユーザ増加に繋がったりしたらしい

• 良いアプリケーションは、Unix哲学的であるべき

  • 多機能にしない・1つの問題をうまく解決することにフォーカスし、複数の問題を同時に解決しようとしない。

• ユーザは増えると技術レベルが下がり、苦情の質が下がってプログラマの時間を奪う

  • エンジニアとユーザはダイレクトに繋がず、クッションを置く組織づくりをしたほうがいい。

• 信用に二度目はない

  • Netflixは自社都合で会社を分けて、ユーザには２つの会社に課金せよと通達した。
  • その結果3ヶ月その状態を解消したが80万人のユーザを失った。信用は二度目はない

🔗コードフリーズ

• 12月やBFCMは、バグを埋めるとビジネスインパクトが大きいのでプログラムのリリースを止めたりする。

🔗Design Doc

• デザインドックの書き方 https://note.com/kosukemori/n/n968cd16c53eb

🔗決済処理

• クレカ情報を自前で持ってはいけない。決済代行業者ならまだしも、一般のところがやっちゃダメ
• RDBには決済代行会社に登録したIDだけ持ってカード情報は、何枚持ってるかも含め決済代行に全て預けてAPIで処理するのが正解
• GMOPGとかだと複数登録できてデフォルトも設定できたはず。

🔗SRE

• 一般にシステムのもっとも危険な要素はそれを運用する人間です。成熟した SRE 部門は自分たち自身からシステムを保護するように構築します