マネジメント のバックアップ(No.19)

• バックアップ一覧
• 差分 を表示
• 現在との差分 を表示
• ソース を表示
• マネジメント へ行く。
  • 1 (2016-08-24 (水) 10:08:44)
  • 2 (2016-08-24 (水) 10:32:58)
  • 3 (2016-08-26 (金) 07:00:20)
  • 4 (2016-09-13 (火) 07:38:01)
  • 5 (2016-10-04 (火) 21:17:52)
  • 6 (2016-11-21 (月) 11:53:47)
  • 7 (2016-11-22 (火) 15:55:04)
  • 8 (2017-01-16 (月) 20:14:39)
  • 9 (2017-03-23 (木) 05:49:53)
  • 10 (2017-03-23 (木) 22:21:30)
  • 11 (2017-05-24 (水) 18:44:41)
  • 12 (2017-07-24 (月) 15:02:59)
  • 13 (2018-03-01 (木) 14:32:58)
  • 14 (2018-10-19 (金) 00:22:37)
  • 15 (2018-12-08 (土) 17:01:20)
  • 16 (2018-12-12 (水) 18:29:48)
  • 17 (2018-12-18 (火) 14:23:02)
  • 18 (2018-12-21 (金) 11:54:34)
  • 19 (2018-12-21 (金) 12:26:35)
  • 20 (2018-12-21 (金) 20:07:26)
  • 21 (2018-12-24 (月) 23:30:53)
  • 22 (2019-01-04 (金) 20:50:17)
  • 23 (2019-05-03 (金) 02:09:39)
  • 24 (2019-08-02 (金) 23:07:03)
  • 25 (2019-12-15 (日) 01:59:56)
  • 26 (2020-03-29 (日) 16:52:24)
  • 27 (2020-10-01 (木) 23:09:24)
  • 28 (2020-12-05 (土) 15:17:31)
  • 29 (2021-06-08 (火) 23:12:09)
  • 30 (2022-04-29 (金) 22:54:20)
  • 31 (2022-07-18 (月) 01:48:13)
  • 32 (2022-07-31 (日) 21:04:57)

概要 †

• 組織とは同一の目標を共有する集団であり、その環境を整えるのがマネジメント
• 人の心に火をつけ、見つめて得意分野を把握し、チーム全体の失敗を許容する安全と生産性を確保し、リスクを取れるような働く環境を整備し、チーム全体として結果を継続的に出し続ける

下位ページ †

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

目次 †

分類 †

人の心に火をつける †

• モチベーティングする
  • 金・出世
  • 社会とのつながり

• モチベーションをそぐ要素を排除する
  • 妻が英語喋れないし→妻にも英会話教室に通わせる福利厚生を作るなど

• 社会での必要性を語るより、自分たちだからこそできるという意識の方が大切そう
• 実はやりたいと思っていないタスクをやらせたりするとマジで生産性が落ちる

信用を得る †

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

• 機嫌が良い雰囲気を出す
  • 上司の機嫌が悪そうだと怖がらせ、意識していないところで発言の自由が低下する可能性がある。
  • 定期的に怖さをアンケートしたほうが良さそう

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

• チームメンバからの意見を尊重する
  • 極力実行に移す
    • 意見を言うことが、実際的にチームを動かしているという感覚に繋がると意識させる
  • 称賛する
    • 意見を言うことが、チームにポジティブな効果があることを意識させる
  • 自らへの批判、改善方法の具体的方法を求める
  • 極端な質問をすると、それに対する答えで気持ちが何となくわかってくる
  • 誰が意見を言ったかに依存しない意思決定プロセスを確立する
  • 会議で「〜さんが言っていたように」、と引用するのは大切。傾聴と意見の尊重の両方をアピールできる

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

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

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

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

得意分野を把握する †

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

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

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

• 穴だらけの知識の中でも、チームで価値を生み出せること
  • 穴を高速に必要な部分だけ埋める
  • 穴を避けて語る
  • 穴を高速に埋められる人にお願いする人脈を作る

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

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

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

渉外 †

• 適切な量のタスクを降る。
• 外部とのやりとりをするばあい、「メールや推薦状を部下にかかせる」方が良い。結局、分からないことが多いので。

働く環境の維持 †

技術維持 †

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

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

維持コストの継続性 †

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

納期 †

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

• 正確に見積もるために
  • 開発スピードを計測するすべを持つ

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

人員配置 †

• 技術に関してスペシャリストを集める際にバックグラウンドが近い人が最低2人は組めた方がいい。
  • reviewがお互いにできる
  • discussionが深くならないとそもそも働いてる側は楽しくない
  • 知的好奇心を満たせるパートナーがいないと辛い

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

戦略性 †

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

• 戦略に関係ないことを断ったり、優先順位を下げる判断を行う必要がある。
  • 逆に、他のチームの戦略と競合して優先順位が異なる場合の調整を行う必要がある

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

• 戦略のためには他のチームとのコラボレーションを適切に行うイノベーティブな考え方が必要
  • 徹底的な対話をする。オフでもオンでも。

タスク配備 †

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

• 担当者との密な連絡
  • 最初に同意したチェックポイントを確認

マネージャの役割 †

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

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

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

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

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

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

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

書籍 †

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