🔗概要

• 組織とは同一の目標を共有する集団であり、その環境を整えるのがマネジメント
• If you get the right people on your team, you're 50%+ done. Having the right people helps you find more of the right people.
• 人の心に火をつけ、見つめて得意分野を把握し、チーム全体の失敗を許容する安全と生産性を確保し、リスクを取れるような働く環境を整備し、チーム全体として結果を継続的に出し続ける
• マネージャが周りのチームの人たちとの嵐の中の仲介役となる
• 方法論は参考程度にして、自分の頭で考える。アジャイルとかに限らないところではあるのだけど、どうしてもこういう開発論っていろんなものを理想化しがちだなあ、というのと、時々現実からはかけ離れた謎の認識がコミュニティに蔓延っていたりとかもあったりしていろいろ思うところはある
  • テストファーストの欺瞞、ちゃんと最初から適切なテストを書ける人は、そんなテストを書かなくてもちゃんとしたコードを書くし、適切なコードを書けない人は適切なテストも書けないのでどんだけ最初にテスト書いてもムダ、というのがある。
  • 構造化プログラミングはアセンブリでgotoスパゲッティ地獄になったことがない人には歴史上の失敗でしかないし、オブジェクト志向は構造化プログラミングの誰が誰の脳にもアクセスできる状況が非直感的であると気づいた人以外には歴史上の失敗としか認識しようがない
• 「良いソフトウェア」を開発するためには「小さいチーム」と「優秀な開発者」が最重要で、それらの欠如をIDEやら静的型言語やらで埋めることはできるというのは幻想。チームの成功は採用で半分以上決まっている。

🔗参考

• How Big Tech Runs Tech Projects and the Curious Absence of Scrum

🔗下位ページ

• 共同作業
• プロジェクト管理ツール
• ワークショップ

🔗目次

• 分類
  • インパクトを階層的に計測する
  • インパクトのあることに集中させる
  • 重要性をなるべく少ない変数で特徴づける
  • 人の心に火をつける
  • 属人化を防ぐ環境づくり
  • 縦割り組織に積極的に戦え
  • 信用を得る
  • 得意分野を把握する
  • チーム全体の安全を確保
  • 渉外
  • 働く環境の維持
    • 技術維持
    • 維持コストの継続性
• 納期
• 人員配置
• タスク管理
• 戦略性
• Tech Lead
• タスク配備
• マネージャの役割
• 文化
  • 専門人材に専門以外のことをさせない
  • マネージャを年で雇わない・昇任という概念を作らない
  • 顧客を意識せよ
• 書籍
• 給料設定
• 縮小業界

🔗分類

🔗インパクトを階層的に計測する

• KPI の本質はは結局階層的に期待値と実際に返ってきた値を比較してフィードバックすること
• 計測できないものは改善できない

🔗インパクトのあることに集中させる

• エンジニアリングマネージャではインパクト出る・出せる可能性あるものにちゃんと bet し、重要でないことはスルーさせる能力が重要。
• 成果を出せるように方向づけのアドバイスをしたり障壁を取り除いたりする仕事。成果を出したら基本的にクレジットはほぼすべて IC にいく
• 戦略的な行動を考えよう、という言葉を使うのですが、大半の場合『KPI達成の追加アクション』の提案をしてきます。ですが、戦略的な行動とは何かを達成するために『やらないこと』や『いらないKPIの排除』だったりします。優秀なマネージャーは『KPI達成のための無駄の排除』を提案してきます。

🔗重要性をなるべく少ない変数で特徴づける

• あまり多数の変数があっても、優先度の共通認識を得ることは難しく、またどれかが高ければやるべきという風になって Assignee にとって意味がなくなっていく可能性がある。
• P, S による分類
  • Priority: 利用人数
  • Severity: 困り度
• もしもっと分類すべきならば、例えば
  • チーム目標 KPI などとの整合性
  • 競合との差別化
  • 利用人数
  • 利用頻度

🔗人の心に火をつける

• モチベーティングする

  • 金・出世
  • 社会とのつながり

• モチベーションをそぐ要素を排除する

  • 妻が英語喋れないし→妻にも英会話教室に通わせる福利厚生を作るなど

• 社会での必要性を語るより、自分たちだからこそできるという意識の方が大切そう

• 実はやりたいと思っていないタスクをやらせたりするとマジで生産性が落ちる

🔗属人化を防ぐ環境づくり

• バス係数
  • 一人がバスに惹かれたときにプロジェクトがポシャる可能性
  • つまり属人化の定量化
• 属人化しているチームだと働いていて辛くなる

🔗縦割り組織に積極的に戦え

• 人は「〜部部長」のような肩書を作らない

  • 偉くなったように思ってしまうし、その肩書を外されるのに抵抗感が発生する。
  • そもそも「〜部」のような共通のヒエラルキーが全社会的に当然だと思っているのは、最適解から遠ざかる行為
  • 自分の安住の地を作り出そうとしてしまう

• 縦割りの組織は積極的に破壊せねばならず、それにはリーダーの強い権力が必要

件名：Tesla内のコミュニケーション 企業内で情報がどのように流れるべきかについて、2つの考え方があります。これまでのところ最も一般的なやり方は、指揮命令系統に従う方法です。つまり、あなたは常に上司に指示を仰ぎます。この方法の問題点は、上司の力を強化するものの、会社のためにならないということです。 本来なら、問題が発生した場合はその部門の人が関係部門の人と話し、正しい行動を起こして迅速に解決するべきです。にもかかわらず、指揮命令系統の下では、人々はまず上司に報告せねばならず、その上司がそのまた上司に報告して、その上司の上司が他部署の管理職に相談し、その管理職が部下に相談するといった流れをとります。その後、もう一度同じ経路を逆流し情報が伝えられます。 これは信じられないほどバカげています。こんなことをしている管理職、ましてや推奨している管理職は、すぐにうちの会社で居場所を失うでしょう。冗談で言っているのではありません。

テスラにいる全員が、誰にメールしても会話しても構わないし、またすべきなのです。企業全体の利益のために、自分が考える最速の解決方法をとるべきです。 上司の許可なく上司の上司に相談しても構わないし、別の部門のトップに直接相談してもいいし、私（＊イーロン・マスクCEO）に相談してもらっても構わない。誰かと話すことに誰かの許可は要らないのです。さらに、問題が解決されるまで、自分にその義務があると考えるべきです。 この狙いは、手当たり次第に世間話をすることではなく、超高速で確実に実行することです。我々が大手自動車企業と規模で競争できないことは明らかなので、我々は知性と機敏さで勝負しないといけない。 最後に1つ言っておきたいのは、管理職が注力すべきなのは、企業にサイロ（＊縦割り組織の例え）が生まれないようにすることだ。サイロは他者との間に精神的な壁を作り出し、コミュニケーションを阻害するのです。残念なことに、サイロができるのは自然な流れなので、積極的に戦う必要があります。 部門間に障壁を立てたり、会社全体ではなく組織内の相対的な成功を重視したりすることが、どうしてテスラのためになるでしょうか。我々全員、同じボートに乗っています。自分の部署ではなく、会社の利益のために働くことをつねに意識してください。 イーロン

🔗信用を得る

• 真摯な柔和な態度を保つ

  • 一人の人として向き合う
  • 意見を尊重する
  • マネジメントがうまく言っていない場合、きちんと口に出す。あるいは出せる環境を作る。
  • 具体的に実行可能かつfeasibleなアドバイスを言う。
    • 「言いたいこと言うだけの無責任なアドバイス」はダメ。自分の意思だけ伝えて、「ほらアドバイスしたのにー」だけは言ってはいかん
  • 常に「僕はあなたをどうやったら助けられますか？」という形で自走する力を育む
    • 「このように助けて欲しい」と言われたら、必ずそれを達成する。実行を伴う行動は信頼を生む。
    • 権力を人のために使う。助けてもらった人は超感謝するし、誰かの「1番のお願い」は大抵チームにとって大切なこと
  • 上司の機嫌が悪そうだと怖がらせ、意識していないところで発言の自由が低下する可能性がある。
    • 定期的に怖さをアンケートしたほうが良さそう

• チームメンバ個人の興味に関心を向ける

  • 能力向上とキャリアに注意する
    • チームの成果はチームの興味であるが、個人の興味は昇給や解雇なども含まれる。それぞれの人生は大きな要因。
    • 特にキャリアに関しては、プロジェクトのリーダー経験など、今後のキャリアにポジティブな役割を積極的に与える。
  • 健康
  • 趣味
  • 家族

• チームメンバからの意見を尊重する

  • 極力実行に移す
    • 意見を言うことが、実際的にチームを動かしているという感覚に繋がると意識させる
  • 称賛する
    • 意見を言うことが、チームにポジティブな効果があることを意識させる
  • 自らへの批判、改善方法の具体的方法を求める
  • 極端な質問をすると、それに対する答えで気持ちが何となくわかってくる
  • 誰が意見を言ったかに依存しない意思決定プロセスを確立する
  • 会議で「〜さんが言っていたように」、と引用するのは大切。傾聴と意見の尊重の両方をアピールできる
  • 多くを喋らない。
  • 例:「育児中の社員に対して『重要な仕事はまかせない』とした結果彼の仕事へのモチベーションが下がった」ことがマネージャーによる不適切な行為
    • 育児中だからインパクトの低い仕事ばかりを振るのは良くないんじゃないかな。
    • 部下側から仕事を要求するのは情報ノ差がある場合が多いと思うので難しそう。逆にデフォルトでは同じ職責だから同じ量・重要度だけ仕事を振り、厳しいと言われたら考える、というほうがいいんじゃないかな。
    • 育児かどうかに関わらず、プライベートが忙しいので負荷を下げてほしいという話はしたほう良いと思う。ここでの問題は、そういう要望がないのに「育児をしているから」というだけで仕事を一方的に少なくされるのは良くない

• チームへの貢献を正しく測り、それを表明する

  • 褒められて悲しくなる人はいない。貢献に比例した称賛を正しく送る。
  • 同じ報酬を受け取っているメンバの間の能力を定期的にすり合わせる。不公平感が生まれてしまう。
  • タスクの完遂に対して、労い感謝の意を正しく表す。
  • 結果に対して適切な手順で作業を行っている場合、プランのゲインを下げる。その失敗はチームメンバと共有する。

• 社会的に真人間であると思われるような行動を心がけ得る

  • 傾聴
  • 言葉と態度に気をつける
    • 程度の副詞の程度に注意する。「絶対」とかなるべく言わない。
    • しかめっ面など、不快に思わせるような行動はしない。
  • 定刻を守る

• 自らが仕事内容に精通すること

  • 完全に無知な人が上に立っていると、現場の人はげんなりする。周りに押し付けることは誰でもできる
  • マネージャーは単なるリーダーではなく、チームのいちメンバーであるということを伝える
  • マネージャーがチームのメンバーとしてではなくなるとしたら、それは他のマネージャをあてがい、自分は複数のことをまとめて業界を動かすようになってから。

• 忠誠度

  • やっと育ったと思った人間にすぐ辞められても困る。ずっといたいと思う環境を作ることが大切
  • 心を折らない。上がってきたものが少し間違っているくらいなら、完璧に直すよりも、勢いを殺さず心をおらないほうが大切な場面もある。

• 情報の透明化に努める

  • 陰口も直接メールで伝えるくらいの透明性が望ましい。
  • 情報格差は社内政治のはじまり。害悪。

🔗得意分野を把握する

• 苦手なもので戦ってはいけないし戦わせてもいけない
• 見つめるためには、真摯な態度で人と向き合い続け、信頼を得る必要がある。

🔗チーム全体の安全を確保

• 他人のリスクを把握し、尊敬すること。

  • これができないやつとは仕事したくない
  • 他人の専門をリスペクトする。プッシュしない。担当亮やと専門はまかせる。

• 穴だらけの知識の中でも、チームで価値を生み出せること

  • 穴を高速に必要な部分だけ埋める
  • 穴を避けて語る
  • 穴を高速に埋められる人にお願いする人脈を作る

• 極力各自の裁量で、ルールを最低限に

  • 自由と責任の文化を大事にする。
  • ルール決めるとコストになる、オーバヘッドが生じる、イノベーティブでなくなる。
  • 失敗に厳しくしすぎるルールを入れない
    • 失敗した原因に関する詳細なレポートを求められると全部成功したことになる

• モラルの形成

  • セクハラめいたことをスタッフや学生がやりだしたら、即座に100%否定して不快感を示す
  • 大人の対応しましょうねとか被害者に言うというは一番ダメ

• ミスをチーム全体の課題とする

  • 失敗は自責の念を生むので、よほどならスタバのコーヒーくらい奢らせたほうが精神衛生上良い可能性がある

🔗渉外

• 適切な量のタスクを降る。
• 外部とのやりとりをするばあい、「メールや推薦状を部下にかかせる」方が良い。結局、分からないことが多いので。
• TBD (technical deal blockers)
  • 技術的に足りていなくて、収入が足りなくなるなどのチケットを上げ、自分のチームのタスクを適切に上げる

🔗働く環境の維持

🔗技術維持

• 開発は技術力をすり減らす

• 技術向上し続ける環境づくりを心がける

  • 上司「刃を研ぐのは業務外だから時間外にやれ」
  • 経理「砥石を買う予算なんてありません、自費で用意してください」
  • 監査「会社の備品を私物で整備することは認めない」

🔗維持コストの継続性

• 維持コストを見積もり、未来の維持コストを見据えて適切な技術的対策を講じる
  • ユーザが増えている場合、エラーは必ず増大する。
  • 人間の努力や注意力に依存したシステムは必ず破綻する

🔗納期

• エンジニアリングは不確かな要素が多いので、正確な見積ができない

  • エンジニアは納期を守らない
  • 新しい技術が必要なことがある
  • 新しい技術を取り入れないとエンジニアのモチベーションが保てない
  • もちろん古い技術を使えば早く実装できるが、新しい技術を取り入れていかないと、時代に取り残される
  • 見積もり段階で決まっていない仕様がある（60-160%の誤差がある→3倍の時間で見積もるということになる）

• 正確に見積もるために

  • 開発スピードを計測するすべを持つ

• 見積に失敗したら

  • めちゃめちゃ強い火消し屋を投入する
  • それが無理なら、開発範囲・費用・期間・品質のどれかを犠牲にする
    • 犠牲にしないと品質が落ちるので、次の開発でバッファになる
  • 人数を追加すると絶対遅れる。

🔗人員配置

• 技術に関してスペシャリストを集める際にバックグラウンドが近い人が最低2人は組めた方がいい。

  • reviewがお互いにできる
  • discussionが深くならないとそもそも働いてる側は楽しくない
  • 知的好奇心を満たせるパートナーがいないと辛い

• 適任者を見出す

  • スキルを把握し、適切に配置し、タスク達成に伴うスキルアップにも注意を払う

🔗タスク管理

• 時間単位で今後の予定を自分のカレンダーに全て入れる（カレンダー以上のものを使う必要なし）
• 何にどれくらい時間使ってるか把握する。なぜ忙しいのかがわからなければ漫然と働いているので良くない。

🔗戦略性

• 合目的的かつ網羅的に行う必要がある

  • 世界観、ビジョン、コンセプト、テクノロジーのつながりはロジカルに戦略設定する必要（信念、組織への存在理由、目標、手段、短期的ゴール）
    • 「それをやりたいと言っているのになぜそれができない方法を選択した？」
    • 「何をするかはどうでもよくてその方法を使いたかっただけちゃうんか？」

• 戦略に関係ないことを断ったり、優先順位を下げる判断を行う必要がある。

  • 逆に、他のチームの戦略と競合して優先順位が異なる場合の調整を行う必要がある

• 手戻りと開発速度の関係

  • 失敗時のリスクを考えて、仕事のクオリティの基準を適切に設定する
  • 手戻りは必要以上に恐れると開発スピードが劇的に落ちるけど、チームのモチベーションを落とす手戻りは極力避けたい（改良のための手戻りならまだしも安全性に問題があるから手戻りでは辛い）

• 戦略のためには他のチームとのコラボレーションを適切に行うイノベーティブな考え方が必要

  • 徹底的な対話をする。オフでもオンでも。

🔗Tech Lead

どんなトピックであれ決定者の決定が誤っていると思われる場合に、明確なエスカレーション経路があることが重要。ゴールは合意であって全員一致で意義がない状態ではない。「この意見には同意しないが、あなたがどうやってその結論に至ったのかはわかる」という状態は問題ではない

コストには、

• 財務コスト
• 資源コスト
• 人権コスト
• 処理コスト（行動を取るときにどのようなコストがかかるのか）
• 機会コスト (行動を取らないときにどのようなコストがかかるのか)
• 社会コスト（社会の誰が損をするのか。潜在的不正利用、公平性などにより、特定のユーザがむしろマイナスを被ることがありえる）

ホワイトボード用のペンを誰でも持ちされる場所に置くべきである。なぜなら、誰かがマーカーを盗むことを防ぐより、障害のない議論をミーティング中に行なうべきなのだ。

私がこう言うのでやるのだ、という決定方法であってはならない。データ駆動ではなくエビデンス駆動であるべき。というのも、データがない場合でも、前例や類例、論拠、エビデンスは存在するから。このようなものによる潜在的コストの推定がやり尽くされてから、直感や「一般には〜」から始まるベストプラクティスを検討スべき。

エンジニアリングでの決定とは、以下しかない。

• 必須要件（法的要件、顧客の要件）
• 現在のエビデンスに基づき、現時点わかっているなかで最良の選択なのでやる

定量・定性に対する意思決定が存在する。

• 定量「この連結リストを1人で2週間で高速化することで、CPU が 2000 個へりメモリが 100 GiB 増える」というものは明確にコスト計算できる
• 定性: 研究に投資してなるべく定量的に扱おうとするという選択肢が

明確なトレードオフ

• ビルド時間が長く、エンジニアタイムが奪われる
• ビルド時間を短くするための分散ビルドシステムを開発し、開発者にオンボーディングさせ、追加の計算リソースが必要となる 予想外のコストはしかし発生した。このような変更をしたところ、エンジニアはビルドを小さく収めることに対するインセンティブを失い、過度に富豪的なシステムになってしまった。Jevons のパラドックスに近く、リソース利用効率が上がると、時間を固定して、リソース使用量が増えるという問題となった。その後、少数の依存関係および自動依存管理システムを導入することで、コストを抑えることができたが、「エンジニア時間を回収するために、コンピュートリソースをｘドルかける」ということですら、予想外の影響の波及があった。p

重要な注意点

• データが決定を裏付けるが、時間の経過に伴い新しいデータが現れて、最適解を最高しなければならない可能性
• 計測できないものも同じだけ勝ちがある。

プログラミングはコードを生産する即時的行動 ソフトウェアエンジニアリングは、コードを利用しなければならない期間中にゆうように保つのに必要でありチーム横断共同作業を可能にするポリシープラクティスツールのセット。

人間的な問題 一人で仕事をすると長く辛い作業となり、認めが逮捕s度進捗が遅れる場合が多いことは忘れがられがち。プログラミングはきついし、ソフトウェアエンジニアリングはもっときつい。チームが一緒に着席することでそのキツさが和らぐ（あるいはペアプロによって）

「完成前に見てくる連中にはガチで不安になるっ。まるでその連中がまじで自分のことを格付けしてきてこいつ馬鹿なんじゃないかって」みたいな発想で、途中のコードを隠蔽しがち。しかし実際のところ隠蔽は有害で、欠陥にはなるべく早く気づいたほうがコストが低いし、フィードバックを得ることで質がよくなり成長機会も得られる５。

• すごい新概念を思いつく
• 隠れ家に引きこもり、完璧な実装を心がける
• 世界に解き放し、天才性でみんなに衝撃を与える
• 自分の才覚に同僚が驚愕する
• 自分のソフトウェアを使おうと人々が行列する
• 名声と財産が自然とついてくる

ただ、どれくらいの共同性が必要なのかはバランスがいる。 完全個室がいいわけでもないし、完全オープンでは全員が自分の言っていることを聞いていて不安になる。なので、4~8 人くらいでやるのがいい。集中するならヘッドフォンをつければよいが、いつもヘッドホンを付けるのは適切ではない

人付き合いの衝突のほぼすべての根本原因は以下に帰着すると信じている 謙虚: 自分は誤りを犯すので、自己研鑽に対して開かれている。（エゴを捨てろ） 尊敬: 他社の能力と成果の価値を認める。 信頼: 他社が有能で正義をなすと信じて、舵取りをまかせることもできる（過去に無能な連中に任せたことでやけどした経験があると、これはかなり難しい）

エゴは絶え間ない小規模戦争を戦い抜くコストを生む。要職がスーツを着ていないことにより、敵意を向け続けられる可能性がある。エゴを付きとうすことを選択したなら倍、キャリア全体を通じて一定の小さな犠牲を払うことになる。

失敗は選択肢の一つである。時々失敗をしないのであれば、それは十分に革新的ではないか、リスクをとっていない。失敗は次回への過学習のための値千金の機会。ただ、なんども失敗し続けるのは無能。

Google X では、失敗がインセンティブに組み込まれている。アイディアに対して、同僚は可能な限り早く論破することが求められている。

🔗タスク配備

• タスク配置時にはその背景をちゃんと説明する。

  • 重要性、現在のリソース、任せる理由など
  • 役割の範囲を示し、標準的なパフォーマンスと目標を設定する。
  • 期待される成果については明確に伝える。完了の定義はメンバに任せる。

• 担当者との密な連絡

  • 最初に同意したチェックポイントを確認

🔗マネージャの役割

• ワークグループとチームは違う

  • ワークグループは個人戦、依存関係が少ない
  • チームは3-50人のグループ（中央9人）程度くらいの規模で、相互依存性が強い

• 役割ごとの効果的なチームの差異

  • マネージャ: 売上高・サービスの立ち上げなどの結果
  • チームメンバ: チーム内文化と風土
  • チームリーダ: 売上などへの当事者意識

• チームで必要な資質

  • チームの内部で異議を唱えることに不安を感じない（心理的安全性）
  • 課題・障壁のクリアが得意であると自信がある
    • 他のメンバが、高いクオリティで時間内に仕事してくれると信頼している
  • 具体的で取り組みがいがあり、なおかつ達成可能な、短期的・長期的目標がある
  • 仕事に個々人が自分にとって意味があると感じている
  • 仕事が世界にとって意義があると感じている
  • 他人の抱える問題への関心（自分またはチームの仕事がユーザーや顧客、組織に与える影響をよく考える）

• チームの生産性で必要でない資質

  • 場所
  • 合意による意思決定
  • 外向性
  • チームメンバー個人の能力
  • 仕事時間
  • 年功序列
  • チーム規模（重要という話もある）

• 実際に何すれば良いの？

  • 積極的な姿勢を示す
  • 目の前の会話に集中する
  • 学ぼうという意欲を持って質問をする
  • 対話的なコミュニケーションを心がける
  • 返答するときは言葉で返す 「なるほど。詳しく説明してもらえますか？」
  • 相手の発言内容を要約する 「あなたがおっしゃったのは…ということですね？」
  • 話を聞くときは少し体を乗り出すようにする。会話中や会議では、話を聞いていることを示すためにうなずく
  • 相手と目を合わせる
  • 責めを負わせるような言い方はしない
    • 「なぜそのようなことをしたのですか？」はダメ
    • 「この作業をよりスムーズに進めるためにできることを考えましょう」「次に備えた行動計画を立てるため、皆で協力しましょう」
  • 否定的な表情（苦い顔や不愉快そうな顔）を浮かべない
  • 自分の仕事の進め方や好みをチームメンバーに伝え、チームメンバーにも同じように自身のやり方を皆に伝えるよう促す
  • 1 対 1 の定例外の会話、意見交換、キャリアに関するコーチングのための時間を作る
  • 定例外の会議を開く場合は、目的を明確に伝える
  • 貢献に対して感謝の意を示す
  • 他のメンバーについて否定的な言葉を口にしたときは間に入る
  • 全員に顔を向ける
  • 適度にチームメンバーと仕事以外の話をする
  • チームメンバーに意見やフィードバックを求める
  • 人の話を妨げない。 人の話を妨げようとする人がいたら間に入り、元の発言者に話を続けさせる。
  • 意思決定の背後にある根拠を説明する
  • 他のチームメンバーの貢献を認める（例: チームメンバーが成功や意思決定に貢献した場合は、その事実に言及する）
  • 自信や信念を持つ（強情にならない範囲で）
  • 議論をコントロールする（雑談を認めない、意見の対立が個人間の対立に発展しないように）
  • 明瞭に発声する
  • チームの成果を上級役員に伝える、チームメンバーの功績を認める
  • 自分の意見に対しての反論したり異論を唱えるよう促す
  • 自分の弱みを見せる
  • 失敗に関する自分の個人的な考え方を伝える
  • リスクを取るようチームメンバーに促し、自分の仕事でも実践してみせる

• 危険サイン

  • 建設的なフィードバックを求めたり与えたりすることに不安がある
  • 人と違う提案をしたりごく簡単な質問をしたりすることを躊躇する
  • プロジェクトの優先順位や進捗状況を十分に把握できていない
  • 責任分担が曖昧で、作業や問題の担当者が明確でない
  • 作業を引き受けたチームメンバーは、約束どおり作業してくれますか？
  • チームメンバーは、作業が遅れる場合に前もって連絡してくれますか？その作業に責任を負ってくれますか？ 仕事とは成長や進歩とは無関係なことであると捉えている 目標が多すぎて、意義のある形での能力開発が阻害されている

• チームメンバへの定期的な確認

  • 他のメンバーの前で躊躇なくブレインストーミングを行えていますか？
  • 失敗するリスクをとれると感じていますか？それとも失敗によってメンバーから拒絶されることを恐れていますか？
  • 個人として、仕事人として、達成感の得られる仕事を与えられていますか？
  • スキルや能力だけでなく、意欲に応じた仕事を与えられていますか？
  • 自分の仕事を「良い方向へ変化を生み出す機会」と捉えていますか？
  • 自分の仕事を「より高い目標を達成するために重要な作業」と感じていますか？
  • 現在のチームプロセスは、チームの幸福感あるいは疲弊感にどう影響していますか？
  • 休暇 - チームメンバーが勧めていたレストランはどうでしたか。[配慮を示す]
  • プロジェクト X のインパクトに関する責任者会議で高評価だったことを伝える。[全体像を示す]
  • 最近の状況はどうですか。[出席・所在を確認する / 近況を確認する]
  • 何か困っていることなどありませんか。[障壁を取り除く]
  • 今後の休みの予定は。[勤怠管理]
  • 他に話したいことはありますか。[話を広げる]
  • マネージャーとして、みんなのためにこうしてほしいという要望などがありますか。[自分が役に立っているか確認]
  • 先週したこと: プロジェクト Y の更新
  • 今週の予定: プロジェクト X v2.0 の設計ドキュメントを提出
  • プロジェクト Y のサブプロジェクトで遅れが出るかもしれないことを報告
  • 先週の 1 対 1 の ABC 会議に関するフォローアップ
  • チーム C とのプロジェクトへの関心について話し合う

🔗文化

• 管理ゼロでも成果はあがる

  • 精算的に働く（楽に成果を上げるために見直し続ける）
  • 自律的に働く（人を支配しようとしない）
  • 独創的に働く（常識と慣習に従わない）

• なにか問題が起きたときに、人に対して責任を問わない。

  • 頑張る・根性・気合・精神論はだめ。
  • 10倍効率化ができたら半分しか働いていなくても大丈夫、こういうスケール感を感じる。
  • そうじゃないと効率化と成長のための時間が確保できない

• ちゃんと時間の見積もりをして記録をするのが重要

• やる気はマラソンで短距離走ではない。はじめに無理しても絶対に続かない

• アンチパターン

  • 創意工夫が許されていない
  • なんのための仕事かわからない
  • 成果に対しての反応がない
  • 続けても成長できない
  • 意見を聞いてもらえない

• 人を頭数で見ない。

  • 本当に必要な人だけをやとう。まだ席あるんで頭数入りますわー、みたいなのはだめ。

• chatworkというビジネスが加速するクラウド会議室がある

  • 隣にいる人とでも、記録が残るので必ずチャットで行うこと。翌日に他の人が追いつくことも簡単になる。透明性を確保する
  • すごくデリケートな話や、サプライズの話以外はなるべくオープンにしておく
  • アイディアは会議室からではなく雑談から生まれる
  • 報告と連絡は不要。必要な報告と連絡だと思ったら勝手に一人ひとりがやって、それで必要十分となっているべき。
  • 「君のいけんを聞かせてもらえないか」というのを口癖にすると良い。
  • 雑談が多い職場は良い職場になる

• なんか何回も発生するしごとがあれば以下の順番で検討

  • やめる、機械で自動化、機械で半自動化、人に任せるの順番で検討する

• 優先度高い順に

  • 他社や同僚・第三者が関わることで30分以内に終わること 当日
  • 人が待っていなくても30分で終わること 当日
  • 16時以降で数時間で終わる簡単な仕事 翌日
  • 時間をかけて行う必要があるもの 場合による
  • TODOは増え続けるくらいがちょうどいい。全部直して細かいところまで行き届いている状態は効率的な状態ではない

🔗専門人材に専門以外のことをさせない

🔗マネージャを年で雇わない・昇任という概念を作らない

• 「結構歳になったので、マネージャになって若手の技術を支えたい」と言う人がいたりするんですけど、マネージャには年齢じゃなくてマネージャとしての能力を求めているのでそれだけでは厳しい
• マネージャはマネージャの面接をすべき

🔗顧客を意識せよ

• どんな内部プロダクトだとしても、何かを作るからには顧客が存在する
  • 何を作って欲しいかを示すだけではなく、継続的に開発する上では優先度を決めて回していき、その過程で顧客の最低限の要求を顧客の支払い能力や他のプロダクトとの優先順位を考えながら実装していく必要がある
  • その意味では MVP を考えるのは割と本質的な思考方法だと思う
• アジャイルで重視すべきは、開発チームの目からみたスピードではなく顧客の目でみたスピード
• 開発は常に顧客を見なければならない

🔗書籍

• ドラッガー
  • 方法論の成功例しか述べず、反証不能な形で議論が進む
  • ホパー的なやつで、これはあまりよいスタイルではない
• Googleのやつ
  • 結構勉強になる。人を大切にしましょう（特に優秀人材は）

🔗給料設定

• 日本では給料交渉が非常に少ないが、今後自由競争になっていったり外国人を雇うことになる場合、給料を内部で上げる仕組みを整えないとお互いに不幸になる
  • 現場側：無駄に転職しなくても市場価値との乖離を是正できる機会がある
  • マネジメント側：転職されてしまって同じスキルをもった人を新しく人を採用するコスト、オンボーディングコストをカットできる

🔗縮小業界

• 縮小業界では解雇しなければならない
  • これに反すると雇用創出のために賽の河原をシャレオツに正当化するVPが発生し、企業全体にダメージが入る