![[商品価格に関しましては、リンクが作成された時点と現時点で情報が変更されている場合がございます。]](https://hbb.afl.rakuten.co.jp/hgb/0c58688e.abba34f6.0c58688f.06b7b08a/?me_id=1213310&item_id=19283903&m=https%3A%2F%2Fthumbnail.image.rakuten.co.jp%2F%400_mall%2Fbook%2Fcabinet%2F8482%2F9784873118482.jpg%3F_ex%3D80x80&pc=https%3A%2F%2Fthumbnail.image.rakuten.co.jp%2F%400_mall%2Fbook%2Fcabinet%2F8482%2F9784873118482.jpg%3F_ex%3D240x240&s=240x240&t=picttext "[商品価格に関しましては、リンクが作成された時点と現時点で情報が変更されている場合がございます。]")
感想
著者の体験を基にした、マネジメントキャリアに関する勘所がメンター、テックリード、人／チームの管理、複数チーム／複数管理者の管理、経営幹部、とそれぞれのステージごとにまとめられています。
自分の今のステージの章を読む事でいま期待されている事は何か、要注意点は、といった理解が得られ、一つ上のステージの章を読む事で上司が何を見ているのか、そこへ行くためにはどうすればいいかといったヒントが得られるような感じです。
エンジニアのための、とはありますがそれ系の組織にいる非エンジニアの人が読む事でも、技術系組織でのマネジメントの勘所に気づきを得られそうです。
何人か読んでもらいたいメンバーがいるので年明けに勧めてみたいと思います。
ポイントサマリ
まえがき
-
まずは話す
-
-
オープンドアポリシーでは疎遠な部下はより疎遠になる
-
-
評価と採用
-
-
会社の行動規範は抽象的すぎることが多い
-
日々の業務で自分たちが尊重するものは何かを考える
-
-
メンバーにも関与してもらい実例を加え自分たちが使えるものとして
-
それを実際の評価と採用で用いる
-
-
マネジメントの基本
-
上司に何を求めるか
-
-
１対１のMTG
-
-
目的1：上司と部下の人間的なつながりを作ること
-
目的2：要検討事項について1対1で話す定期的な場を設けること
-
-
定期的であることで準備、態勢を整えられる
-
-
-
フィードバックと指導
-
-
悪い癖や習慣は早く知れば知るほど直しやすい
-
褒めるのは人前で、叱るのは1対1で
-
-
人前で褒められるのが苦手なら先に伝える
-
-
成果物の助言を上司に仰ぐのは一目置いていることを示す手っ取り早い方法
-
昇進したいならどういう方向に照準を定めるべきかを聞くのが早い
-
面白くない仕事でも価値や会社への貢献をしっかり理解させる
-
-
トレーニングとキャリアアップ
-
-
キャリアアップに必要なトレーニングなどのリソース、役に立つ他部門の専門家を見出し繋げる
-
昇進基準を満たすための準備の指導をする
-
-
-
管理のされ方
-
-
自分が何を望んでいるのかをじっくり考える
-
-
新人であろうとベテランであろうと自分と向き合う責任は自分が負っている
-
-
自分に対する責任は自分で負う
-
-
希望を表明するのは前へ進む一番手っ取り早い方法
-
否定的な反応を上司が返してきたら自分が今おかれている立場を認識させてくれる材料となる
-
-
上司も人の子
-
-
自分の手で変えられるのは自分自身だけ
-
地位が上がれば問題の報告だけでなく解決策の提案も期待される
-
上司へ解決を求めるのではなく助言を仰ぐ
-
-
上司は賢く選ぶ
-
-
上司次第であなたのキャリアは大きく差が出る
-
社内での駆け引きの仕方を心得ている上司はあらゆる面で後押ししてくれる
-
-
メンタリング
-
チームの新人に対するメンタリングの意義
-
-
メンターにとっては他者への責任を負う経験をする好機
-
メンティーにとっては専任のお目付役に教えを請う好機
-
-
インターンシップ制度
-
インターンのメンタリング
-
-
最高の夏を体験させる
-
-
大学へ戻って仲間へ語れるような
-
-
受け入れ態勢／環境を整える
-
プロジェクトを用意し学生とともにマイルストーンへ至る過程を検討する
-
-
プロジェクトを振り返って自分なら2、3日で完成できるような機能や要素を見つける
-
-
締めくくりにプレゼン
-
-
やり遂げた仕事が有意義であったと実感してもらう
-
会社が仕事を認めてくれたと実感してもらう
-
-
自分が将来リーダーとなるために必要なスキルを磨くチャンス
-
-
傾聴
-
-
きちんと伝わる形で話すのが下手な人が多い
-
口にする言葉以上のことを聞き取る
-
-
口調、しぐさなどのシグナル
-
-
相手の質問がわかりにくいと感じたら表現を変えて返したり絵を描いたりする
-
質問しやすい雰囲気を作る
-
-
明確な伝達
-
-
なすべきこと、出すべき結果を的確に伝える能力を磨く
-
-
まずは自分で調べて、わからなければ質問して良い、など伝える
-
-
-
自身の対応の調整
-
-
相手の能力や進捗など状況に応じて対応を調整する
-
-
報告は週1か、毎日がいいか
-
フォローはどの程度が適切か
-
-
-
-
-
新入社員のメンタリング
-
-
研修、会社に溶け込むための支援、社内の人脈作り、など
-
日常になってしまっている「不文律」を伝える
-
新人の人脈は自分の人脈ともなる
-
-
技術／キャリアに関わるメンタリング
-
-
その関係に対する期待や目標を明確にすることが大切
-
-
メンターになったら
-
-
メンティーに何を望むのかを伝える
-
-
質問の仕方、割ける時間
-
-
-
メンティーになったら
-
-
この指摘関係から何を得たいのかを考える、必要がない場合もある
-
-
すごい上司／ひどい上司ーアルファギーク
-
メンターを管理するコツ
-
-
焦点を絞った計測可能で明確なゴールを設定
-
プログラミングの職務以外で功績をあげたい人を選ぶ
-
一つの責任を追加で引き受けた功績を認める
-
ある業務スキルの向上を目標とする場合はその熟練者が最適
-
メンタリングは未来のリーダーを育成する好機
-
-
内気な開発者も視野が広がるきっかけ
-
傲慢な開発者はインターンのメンターで謙遜を感じるきっかけに
-
-
-
メンターの重要な心得
-
-
常に好奇心を絶やさずオープンな心で
-
-
フレッシュな目を通して見つめ直す機会
-
不明確な仕組み、自分の理解の浅さ、再検討に値すること
-
-
相手の言葉で話す
-
-
傾聴の訓練
-
-
人脈作り
-
-
キャリアは長く、業界は狭い
-
-
テックリード
-
シニアレベルに達したエンジニアが順次一時的に担う職責群
-
-
メンバーコミュニケーションと育成
-
プロジェクト管理
-
チーム全体の生産性向上
-
難局の打開
-
他部門との協業
-
キャリアパスを登るために必要なスキルを身につける段階
-
-
なるタイミング
-
-
まだ早いと感じているなら受けない方が良い
-
将来もっと上の職位についてから「技術力不足」とならないように
-
-
テックリードのコツ
-
-
技術面での貢献とチーム全体のニーズへの対応のバランスを取る
-
自分の時間管理
-
チームの負担への配慮
-
プロジェクト全体への大局的な視点
-
-
システムアーキテクトとビジネスアナリストとしての役割
-
-
対象のシステムの十分な把握
-
複雑なソフトウェアを設計する方法の理解
-
ビジネス要件に対する理解と要件定義能力
-
-
プロジェクトプランナーとしての役割
-
-
デリバリ可能な単位で大まかに分割
-
熟知している人から助言をもらい進め方を考える
-
優先順位を検討しプロジェクトの初期に最優先事項に取り組む計画を立てる
-
-
開発者兼チームリーダーとしての役割
-
-
問題が生じたら自分で解決しようとせずすぐに伝える
-
PDMが妥協するであろう課題にチームが疲弊するのを割ける
-
メンバーに任せられる作業を見つける
-
-
プロジェクトの管理
-
-
まぁまぁ満足できるほどに予測し計画できる範囲内で、幾分かでも洞察力を働かせる
-
立案作業に費やす時間に比べれば完璧度は重要度が劣る
-
-
時間を割いて説明することの大切さ
-
-
相手が納得するまで懇切丁寧に説明する
-
相手は肩身の狭い思いをせずに必要な知識を得られる
-
自分の判断や忠告を信頼してくれるようになる
-
-
プロジェクト管理の実務
-
-
複数の工程に分割する
-
-
大枠から徐々に細かく
-
必要な人の支援を仰ぎながら
-
始められるタスクはチームに割り振ってさらに細分化してもらう
-
-
細部の引っ掛かりや道の要素にもくじけない
-
-
未知の要素に納得がいくまで向き合う
-
-
プロジェクトを始動し、調整を加えながら進行させる
-
-
どこまで進捗して完遂まであとどのくらいかを大まかに把握できる計画に価値がある
-
-
立案過程で得られた洞察を活かし、その後の要件の変化に対応する
-
-
諸要件に配慮してプロジェクトを分割する過程で洞察が得られる
-
変化のコストをみんなに伝え妥協点を探る
-
-
完了に近づいたら細部の詰めを
-
-
大失敗に終わる想定で逐一検討してみる
-
公開の計画だけでなくロールバックの計画も
-
-
-
技術職か管理職か
-
-
どちらにもメリデメはあり進路変更は可能なもの
-
-
ひどい上司ープロセスツァー
-
-
プロセス信者
-
プロセスはチームや作業のニーズを満たさなければならないことを理解する
-
仕事のやり方はチームによって違う
-
順守状況を見守る番人ではなく守りやすいものへの改変を検討する
-
プロセスで縛るのは失敗を恐れる不安から
-
「ゆるい」状況でも大丈夫だと安心できる働きかけを
-
-
優秀なテックリードとは
人の管理
-
直属の上下関係
-
-
信頼感と親近感の構築を
-
-
その人の管理をやりやすくしてくれる質問をする
-
褒められる場合は人前が良いか1対1がよいか
-
重要なフィードバックは検討できる書面か口頭か
-
ここで仕事をする理由、希望、意欲、期待など
-
不機嫌／落ちてる時ははたから見てどんな感じか
-
いつも不愉快になる要因で事前に知っておいた方がいいもの
-
耐え難いと思う上司の振る舞い
-
キャリアアップの明確な目標
-
この部署にきて何か言っておきたいことができたか
-
-
今後１ヶ月／２ヶ月／３ヶ月の計画を立てさせる
-
-
部下が明確に目標を立案できれば理解が進んでいることがわかる
-
人選の誤りを検知し対処が必要なことを認識できる
-
-
新人研修用のドキュメントを更新させて理解を促す
-
-
前回更新後のUPDATEを反映してもらう
-
不明瞭な点を改善する
-
-
自分の流儀や要望をはっきり伝える
-
-
1on1の頻度や報告の仕方
-
進捗や結果をどのように把握／レビューしたいか
-
どのくらい自力で問題解決を努力したら応援を求めても良いか
-
-
新人からもFBを得る
-
-
最初の３ヶ月間のチームに関する感想や意見をできるだけ述べてもらう
-
批判を煽る行為は禁止
-
-
-
チームメンバーとのコミュニケーション
-
-
定期的な1on1は必要
-
1on1のスケジューリング
-
-
週一でやってみて頻度を調整する
-
お互いにとって都合の良い日時を選ぶ（月金を避けるなど）
-
-
1on1にまつわる調整
-
-
頻繁にやり取りする相手なら不要な場合も
-
新人ならコーチング、ベテランなら業務内容などにフォーカス
-
報告が得意でない部下なら頻繁に
-
良好な関係でも実施する
-
-
良好と相手も思ってるとは限らない
-
優秀な部下を顧みず問題児にだけ時間を費やすのは誤り
-
-
会社が変化／不安定なときは部下も気になっている
-
-
ちゃんと答えてあげることに噂を封じる効果がある
-
言えない場合は今は言えないと伝えてあげる
-
-
-
1on1の進め方
-
-
ToDoリスト型
-
-
口頭で済むようなToDoリストをトピックにすると不自然
-
口頭がふさわしいのは「微妙なニュアンスを伝えたい」もの
-
-
キャッチアップ型
-
-
部下の最新情報を入手するための1on1
-
部下主導で進めさせること
-
重要だと思う議題を気楽に持ち出せる雰囲気づくり
-
不満を並べ立てる場にならないように、建設的であること
-
-
フィードバック型
-
-
スキル向上や知識獲得のため
-
目標の達成度のレビュー
-
問題児は頻繁に
-
解雇を検討中なら文書で記録し上司から要望も添えて送付
-
悪いFBは直後に
-
-
経過報告型
-
-
管理者が下級管理者と開く1on1の多くは経過報告型になる
-
直前のプロジェクトレポートからの差分更新だけになっている場合は注意
-
プロジェクトと無関係なトピックを用意する
-
-
チーム、会社、etc.
-
-
-
相手を知るための機会
-
-
相手のことを一個の人間として気にかけているという姿勢を見せる
-
家族、ペット、趣味、これまでのキャリアについて話してもらったり
-
今後の長期目標を尋ねて見ても
-
部下を後押ししたいという気持ちを表明する
-
-
議事録
-
-
共有のドキュメントで作成し管理することがオススメ
-
書記は上司
-
議論の要点、持ち上がった考慮点、ToDoなど
-
-
-
細かすぎる上司と、任せ上手な上司
-
-
効率よく仕事を任せるために
-
-
チームの目標
-
-
成功の計測基準をチームに尋ね、その結果を報告させる
-
計画がない場合は期限を切って目標を立てさせる
-
-
チームに尋ねる前にシステムからの情報収集を
-
-
自分が入手できる情報でチームの時間を犠牲にしない
-
チームの目標に基づいて情報を収集する
-
-
プロジェクトの進行に伴って焦点の当てどころを調整
-
-
初期とデリバリ前は支援が必要
-
それ以外は順調に進んでいる作業と手間取っている作業を大雑把に
-
-
コードやシステムに関する基準を設定する
-
-
不安を払拭するために大きな共通の物差しを作っておく
-
基準を決めておくことでFBから個人的要素が排除できる
-
技術スタックに大幅な変更を加える場合は上位のレビューをするなど
-
-
情報は良きにつけ悪しきにつけオープンな形で共有する
-
-
正しい報告の仕方を教える
-
個人に責任を問わない
-
-
批判を避けるために手遅れになるまで報告しなくなる
-
-
-
-
継続的なフィードバックの文化を根付かせる
-
勤務評価
-
-
360度評価
-
-
多数のFBを集める
-
継続的なFBで見過ごす可能性のあるパターンや傾向が見えてくる
-
悪意のこもったFBを共有するかは見極める
-
-
勤務評価の要約の作成と面談
-
-
評価をする十分な時間を確保する
-
直近のことだけではなく期間全体に目を向ける
-
-
常時記録を取る、メールを見返す
-
全体を視野に入れることで成長や変化に気づく
-
-
具体例をあげ、周りのFBも引用する
-
-
色眼鏡を通して評価しない
-
-
功績や長所にはたっぷり時間をかける
-
-
昇進を決定する際の重要な判断材料になる
-
-
要改善点は焦点を絞って
-
-
周りのFBの中の共通項で自身が同意見のもの
-
良くある事例
-
-
手伝いすぎて自分の時間を取れない
-
共同作業で批判的すぎる
-
作業の分割が下手
-
多部署との共同作業が苦手
-
プロセスに従うのが苦手でやっつけ仕事になる
-
-
-
予想外の評価で驚かせない
-
-
昇進したばかりなら基準が変わっていることを事前に伝えたり
-
-
悪い評価は具体的に理由を説明できるように
-
-
どうすれば良い評価を得られるか具体例も含めて
-
-
潜在的な可能性
-
-
一定期間勤続していてこれといって手腕を発揮できない場合はこの会社で将来性はないと見ても良いかもしれない
-
真の可能性は時を置かずに芽吹くもの
-
-
もうひと頑張りの努力を惜しまない
-
問題が発生すれば鋭い提言をする
-
手付かずだった領域でチームを助ける
-
-
独自のやり方を持った人の評価が悪い場合は開花するところに移す
-
-
プログラミングは苦手だが危機管理はピカイチなら運用チームへ、など
-
-
-
-
-
キャリアアップへの取り組み
-
-
自分の会社が昇進に対してどのような方針と手続きを取っているのかを把握する
-
昇進を希望するがそれに満たない部下に対してはそれを知らせ、改善すべき事柄を把握できるようにする
-
昇進が近い部下に対して昇進材料となりそうなプロジェクトをアサインして成果を上げさせることも必要
-
一定のランクまで昇進して打てる手がない場合は多部署に紹介してメンタリングや支援を要請するなどして新たな挑戦課題を
-
-
地位によって職務が異なり、経過とともに能力限界まで昇進して無力化する
-
現在の職位での成績は昇進後の活躍を保証してくれない
-
ある職位に昇進させる以前からその職務を課す
-
-
そうしたキャリアアップの好機がチーム内にない場合、より大きな責任を負わせられるよう仕事の割り振りや進め方を再検討する必要があることを示唆しているかもしれない
-
-
-
-
成績不振者の解雇
-
-
徹底したコーチングが必要
-
期待されているレベルの仕事ができていないことをはっきり知らせる
-
与えたFBについて記録を取る
-
-
脱皮のためのコーチング
-
-
希望するが昇進する見込みがない、一定レベルまで昇進して足踏み状態
-
次のレベルで求められるスキルがどういったものなのか
-
-
説明しても見合う努力をしない
-
そのためここはキャリアップを図る上で最適な場所ではない
-
昇進を望むなら別の部署へ移る必要がある
-
-
他の部署など仕事を見つける機会を与えてあげる
-
チームの管理
-
開発グループマネージャのJD
-
管理者にとって一番大切なこと
-
-
最高の技術力を持つことではない
-
チームの人々を後押しし成功を極力サポートすること
-
-
ITスキルの維持
-
-
確かな技術力の持ち主という評価が得られないと、ある会社で管理職になってもそのあとの選択肢が限られる
-
小規模な技術的作業への従事で得られるもの
-
-
システムの課題、負債を察知できる
-
構築に手間取っている、デプロイが遅い、オンコールの負担が高いなど
-
要件の実現可否、難易度の評価が自身で可能
-
新機能実装の最短ルートを見分けられる
-
-
中間管理職より上に登るのに必要な技術力を十分に身につける
-
-
機能不全におちいったチームの「デバッグ」の基本
-
-
デリバリにこぎつけられない
-
-
人は些細なゴールであっても定期的に達成することで精神衛生を維持する
-
ペインポイントに気づきボトルネックを解消する
-
-
リリースに関わるツールの不備
-
手作業に頼りすぎなテスト
-
規模が大きすぎる機能
-
作業の細分化のコツを心得ていない開発者
-
-
-
厄介な部下への対応
-
-
波風を立てる、マイナスにこだわり続ける、噂話がすぎる、排他的など
-
必要なら上司に応援をあおいでも構わない
-
他チームへ配転させるだけでも解消することも
-
-
嫌な思いをせずにチームから出ていけるように手を貸す
-
-
チームのエネルギーを吸い取り枯渇させないように
-
巧みな攻撃こそが最大の防御、迅速な行動が不可欠
-
-
過労による士気の低下
-
-
システムの不安定性が原因であれば当面安定性のためのロードマップを
-
計画立案の段階で持続可能性のためのリソースを確保
-
納期が間近で過労状態の時はチアリーダーたるべし
-
-
一丸となって難局を乗り切ることで結束が固まる効果も
-
ともに乗り切ったかが嫌だったかを部下は覚えている
-
-
難局から学び再発防止に努める
-
-
協働に関する問題
-
-
関係部署との協働で足を引っ張られる形になっているケース
-
管理者が改善の意欲をみせるだけでも効果がある
-
相手責任者に不満があってもチームの前では前向きに
-
皆で一緒にちょっと息抜きをするような機会を考える
-
-
-
元同僚を自分の部下として管理する立場になったら
-
-
気まずい状況を認め向き合う
-
助けが必要であることを腹を割って話す
-
決断を独りで下そうとしない
-
自分が手放さなければならない技術的作業を任せる
-
売られた喧嘩は「価値ある戦い」のみ応戦する
-
管理者になった後の移行期間は「大人の対応」で乗り切ったほうがうまくいく
-
-
盾になる
-
-
チームが目標に集中できるように不要ないざこざの盾になる
-
ただし目標のコンテキストを理解することに役立つならチームの中に入れてしまった方が良い場合もある
-
知らせた方が良い会社のことを隠蔽してはいけない
-
-
他から伝わると疑心暗鬼に
-
-
管理者はチームのメンバーの親ではない
-
-
チームの意思決定を主導するコツ
-
-
「データ重視」の文化を根付かせる
-
顧客に対する共感を深め、チームにコンテキストを伝える
-
将来を見据え２歩先に立って考える
-
-
変化を起こしうる新技術を把握するための情報収集の時間を設ける
-
-
意思決定やプロジェクトの結果を振り返る
-
-
自分たちの意思決定から常に何かを学べる
-
-
-
「対立を手なずけられる」と「避けて通りたがる」上司
-
-
多数決、投票結果に従って決定を下す方法だけに頼ってはいけない
-
-
時には管理者が決定する責任を負うことも必要
-
-
意思決定から個人的要素を排除するための明確なプロセスを確立する
-
-
チームに委ねたいなら明確な基準を用意する（リリース承認の例）
-
-
「爆発寸前」の問題に見て見ぬ振りをしてはいけない
-
-
問題に気づいたらすぐに指摘する、指摘できる関係性を作る
-
-
本当に対処を要する問題だけを取り上げる
-
-
管理者がチームのセラピストになることが目的ではない
-
マイクロマネジメントにならないように
-
-
他チームへの責任転嫁は禁物
-
-
側からの見た目を気にしすぎず、自チームの問題にも目を向ける
-
-
人に好かれたいのはやまやまだが、管理者は優しさよりも親切を旨とすべし
-
-
昇進にはまだ早いと判断した部下がいたら正直に伝えて支援するのが親切
-
-
気休めをいうのはただの優しさ
-
-
-
恐れずに勇気を出して
-
-
対立を避ける気持ちは恐怖から生まれる
-
-
我が身を振り返る
-
-
対立を恐れる気持ちを克服する秘訣
-
-
-
やりにくい仕事／チームの結束を乱す人への対処
-
-
心理的安全性を作る
-
-
人として扱い、プライベートな話もする
-
チームに馴染む人材を採用する
-
-
ブリリアントジャーク
-
-
非常に有能だが自己中心的で周囲を攻撃する人
-
変わることを望んでいない人を変えるのは土台無理
-
好ましくない言動は断固、公然と否定する
-
-
叱るのは1対1で、の例外
-
チーム全体に有害であると判断された場合のみ
-
-
自身に向けられた場合は1対1で
-
-
あくまで冷静に
-
-
-
秘密主義者
-
-
隠し事をし、レビューなど必要な協力を得ない人
-
期待されている職務をこなせていないと明言しても良い
-
根元には恐怖心が隠れている
-
-
力不足がバレる、興味のない作業を振られる、など
-
-
恐怖心の元を探る
-
-
レビューが辛辣すぎるなど
-
チームの文化を変えさせるか、配転するかどちらが良いか考える
-
-
-
無礼者
-
-
本当にこのチームで働きたいか聞いてみる
-
-
働きたいなら期待値を伝える
-
そうでないなら異動を
-
-
-
-
管理者が担当すべき、より専門的なプロジェクト管理
-
-
管理者は大局的な計画と進捗の管理
-
-
短期的な目標はチーム主導によるアジャイル型手法が有効
-
-
システムの持続可能性維持に2割割く
-
-
本筋で遅れが出た時に振り分けることも可能
-
-
納期間近の立ち回り
-
-
期限を優先してスコープを狭めるか伸ばしてでも実現するか
-
本当に期限内に完成させなければならないものをチームと共に厳選しなければならない
-
-
即席の見積もりには倍増ルールを適用
-
長期的作業の見積もりには立案のための時間を要求する
-
チームメンバーに見積もりを頼むなら厳選して
-
-
ただでさえ忙しいメンバーの気を散らさないように
-
-
-
コラム：小さなチームの新米の管理者
-
-
チームのプロセスを深く理解して技術的信頼を得る
-
適任者を見つけてシステム、アーキテクチャ、テスト、リリース手順を説明してもらう
-
現場作業に加わって経験してみる
-
複数のチームの管理
-
現場の勘所を維持する方法
-
-
これまでやってきた分野でレビュワーなどの形で関わり続ける
-
週に半日は創造的な活動に時間を使う
-
-
技術ブログ、カンファでの発表、OSSへの参加など
-
-
-
時間の管理
|
|
緊急でない
|
緊急
|
|
重要
|
必須。時間を作る
|
明らかにやるべきこと
|
|
重要でない
|
明らかに回避するべきこと
|
ついつい注目しがちな「気の散る要因」
|
-
重要性よりも緊急性にインパクトを感じがち
-
-
メールやチャットで流れ込んでくる情報や依頼
-
それほど重要でないことに時間を使ってしまう
-
-
重要だが緊急ではないこと
-
-
効率的なミーティングのための準備
-
将来を考える、計画する、焦点の当てどころを見直すこと
-
-
緊急だが重要でないこと
-
-
出る必要が明らかにないミーティング
-
ミーティングで参加者の様子を確かめる
-
-
集中していない人が多い場合は浪費的なものになっている
-
-
-
意思決定と委任
-
-
一度に回さなければならない皿の数が多すぎる場合の委任という秘訣
-
|
|
頻繁
|
頻繁でない
|
|
単純
|
委任
|
自分でやる
|
|
複雑
|
（慎重に）委任
|
訓練目的で委任
|
-
複雑な仕事を委任して後任やチームを強化
-
-
頻繁でない：評価の要約を書く、人材募集の計画を立てる
-
頻繁：プロジェクト計画立案、システムデザイン、障害復旧のまとめ役
-
チームに不可欠な仕事を管理者なしにできるように
-
-
やり方を完璧に知ってるのが自分だけの仕事をリストアップ
-
-
-
委任により空いた時間を新しく楽しい仕事に当てられる
-
やりにくい仕事／「ノー」にも言い方がある
-
-
はい、それでですね
-
-
肯定しつつも限界と実情を伝える
-
優先度を見据えた現実的な交渉に持ち込む
-
-
ポリシーを決めておく
-
-
管理者からイエスを引き出すための要件をメンバーに理解させる
-
-
私にイエスと言わせてみて
-
-
１回限りの判断で明確なポリシーがない場合
-
疑わしい部分に突っ込んだ質問を重ねる
-
相手が甘さに気づくことも、斬新なアイディアで驚かせてくれることも
-
好奇心を持って質問することでノーと言いやすくなり教育ともなる
-
-
時間や予算を盾にとる、今すぐは無理
-
-
後日、真剣に考える
-
-
手を組む
-
-
チームのために権限を行使してあげる
-
関係部署長に後押ししてもらう、悪者になってもらう／なる
-
-
ズルズルべったりは禁物
-
-
ノーを先伸ばさない
-
ノーが速合点であれば素直に謝る
-
全てにおいて調査分析して判断する余裕はない
-
-
-
コードの作成以外のITスキル
-
-
会社から求められている職務をきちんと把握しているか
-
-
どのようなコードを書くべきかを把握している
-
-
自分の職務を遂行する上で必要な機器やツールを持っているか
-
-
ツール、自動化、プロセスが用意されている
-
-
毎日最高の仕事ができる機会を得られているか
-
-
インシデントに忙殺されずにコードが書けている
-
-
-
直属の開発チームの健全性を見極める
-
-
コードのリリース頻度
-
-
問題を抱えているのに無視していないか
-
頻度を上げるための技術的チャレンジの指揮をとる責任がある
-
-
コードへのチェックインの頻度
-
-
作業が細分化されテストコードを書くプロセスになっているか
-
-
インシデントの発生頻度
-
-
対処するだけでなく発生件数を減らすことに取り組んでいるか
-
予防を重視しすぎてもベストではない
-
-
-
「イングループ」を作りたがる上司とチームプレイを重んじる上司
-
-
イングループ：愛着や忠誠心で所属意識を持つ集団
-
チームプレイを重んじる上司
-
-
全社の目標や文化を土台とし、強く永続性のある協調関係を構築したチームを作る
-
リーダーやメンバーが辞めてもすぐに立ち直れるチーム
-
-
全社レベルの目標を基盤としているため人が辞めても針路を見失うことがない
-
-
目標駆動型のチーム
-
-
達成に有用なことを出どこに構わず取り入れる
-
-
部長クラスの同僚こそがチーム
-
-
直属のチームだけに目を向けない
-
会社全体のニーズに配慮した意思決定を下すことができる
-
-
目標達成に役立つ変化を喜んで受け入れる
-
-
-
無精と短期の効用
-
-
チームが進めている仕事の効率が悪いと感じたらすぐに自問する
-
合計所要時間を減らして同レベルの価値を会社にもたらすことを考える
-
-
労働時間を増やすのではない
-
-
帰宅できるよう集中して仕事をする、せざるを得なくなる文化を
-
複数の管理者の管理
-
各チームの健康度に目を光らせ、目標設定を支援する
-
-
人材募集
-
メンバーのコーチング／育成
-
目標のレビュー
-
プロジェクトの状態
-
インシデントの事後検証と報告
-
-
スキップレベルミーティング
-
-
各チームの健全度や焦点の絞り方を把握する
-
-
上層部への立ち回りが上手い管理者で見えない問題を察知する
-
-
２つ上の上司に質問できる機会が生まれる
-
重要なトピックに水を向け部下から話を引き出す
-
部下のための面談であることを示唆
-
質問例
-
-
今担当しているプロジェクトで最高／最悪だと思う点は？
-
自分のチームで特に素晴らしい動きをしているのは誰？
-
直属の上司に何かフィードバックは？
-
担当している製品にどんな改良ができるか
-
我々が見落としていると思われるチャンスは？
-
うちの部の活動についてどう思うか？改善、増強、削減できるところは？
-
社の経営戦略でピンとこないところは？
-
あなたが持ち味を出し切れてない理由は？
-
この会社で働くことに満足しているか？
-
この会社で働くことの満足度を上げるために我々ができることは？
-
-
-
部下である管理者たちに責任を課する
-
-
管理者たちが各自きちんと職責を果たし、上位の管理者が務めを果たしやすくする
-
管理者はチームの健全性と生産性に関する責任を負っている
-
-
ロードマップが安定しないならプロダクト部門と調整を
-
テックリードが本筋から外れていたら方向修正と支援を
-
火消しに追われていたら火事の原因に対処するための計画と支援の要請を
-
-
管理者の後ろ盾となって解決策の模索や実施を助ける
-
-
ノーと言える管理者とイエスマン
-
新任管理者の管理
-
ベテラン管理者の管理
-
-
最初の難題は統括するチーム全体の文化に合う人物かどうか確認すること
-
-
文化的な相性で妥協してはいけない
-
-
自分なりのフィードバックを遠慮してはならない
-
-
管理という仕事に対する捉え方の違いを埋める必要がある
-
-
自分が最良だと思うチーム文化を直属の管理者が尊重できるように計らう必要がある
-
-
透明性の高い運営を望むなら情報共有の場を
-
アイディア模索を奨励するならそのための時間確保の支持を
-
-
ベテランは管理の仕事そのものは独力でできる
-
-
担当分野における戦略策定と方向付けに関するコーチングが多くなる
-
自分の職務のうちどれをベテランに異常できるか検討する
-
-
-
チーム管理者の中途採用
-
-
今求めているスキルの有無を確かめる
-
組織の文化にあっているかを見る
-
-
スタートアップ→大企業のケース
-
-
複数ステークホルダーとコンセンサスをとって進められるか
-
-
大企業→スタートアップのケース
-
-
上下フラットな関係の中でのコミュニケーション
-
形式ばらず迅速／柔軟に進められるか
-
-
まずは自分が自社の価値観をしっかり理解する
-
身元照会
-
-
前職の上司同僚に勤務状況を問合せる
-
-
-
-
自分が疎い分野のチームの管理
-
-
自分をメンティーに見立ててどんどん質問する
-
新任の仕事を理解して真価をよく認められることを目的として
-
勝手知ったる分野よりも時間をかける必要がある
-
-
機能不全に陥った組織のデバッグの基本
-
-
仮説を立てる
-
-
うまくやっているように見えるが退職者が多い、など
-
-
データ（事実）をチェックする
-
-
チャットやメール、コードレビューの内容
-
MTGの量、1on1の有無
-
-
チームを観察する
-
-
チームに悪影響を及ぼすかもしれないがMTGに参加する
-
-
活気はあるか、みんな発言しているか、公平か
-
準備は十分か、頻度は適切か
-
-
ただし参加することでチームの振る舞いが変わる可能性もある
-
-
質問をする
-
-
チームが目標は何か、理由は何かを把握しているか
-
メンバーが意思決定に関与してなければそれは何故か
-
-
チームの人間関係をチェックする
-
支援に乗り出す
-
-
問題のあるチームの管理者だけの責任にしない
-
-
常に好奇心を失わない
-
-
なぜ？と究明することを繰り返して育っていく
-
-
-
期日の見積もりと調整
-
-
技術部長は見積もりに関して強気に通すのが鉄則
-
-
見積もりのプロセスに関する交渉も務め
-
-
見積もりの誤りから学ぶ
-
-
見逃していた複雑性
-
見積もる価値のある事柄
-
見積もりの伝え方、遅延した時の対処
-
-
なんでこんなにかかるのかという質問
-
-
相手の状況を理解し共感することで理解を得られることも
-
-
最終的にはスコープ縮小の判断と責任を負うことも
-
-
やりにくい仕事：ロードマップにまつわる不確実性への対処
-
-
変化は必ず発生しメンバーからの不満をぶつけられる
-
その中で、技術的負債に対処する時間をどう捻出するか
-
会社の成長に合わせて方向転換の可能性を受け止める
-
-
半年で終わらない作業をチームに確約するのを避ける
-
-
ある程度の結果を出せる単位に細分化する
-
-
その時々で最大価値に焦点を絞って再検討を繰り返す
-
-
そのうちやる、と安請け合いしない
-
-
重要なら直近でスケジュールに乗せる
-
-
2割をメンテナンスに割り振る
-
技術プロジェクトであっても重要性を見極める
-
-
規模、価値、完遂後のチームにとっての意味、KPI
-
-
変化にチームが意欲的になるよう取り計らう
-
-
これまで取り組んできた仕事を仕上げる時間を確保する
-
計画立案の初期に関与させる
-
理由と目標を理解させる
-
-
-
技術力の点で時代遅れにならないためには
-
-
技術的投資の監督
-
-
チームから提案された技術要素に目を光らせる
-
-
情報収集のための質問
-
技術と事業のトレードオフと分析
-
-
事業に予想外の影響を与えそうなら懸念を表明できるように
-
事業目標を把握しどの技術プロジェクトで達成できるか助言できるように
-
-
上層部とチームの間の伝言役にならないように
-
-
ただ要求されたことをやるだけでなく、より高次の目標の達成を可能とする方法を模索する
-
-
技術的な感を磨くための取り組み
-
-
時々でも自分たちのシステムのコードを読む
-
その領域に詳しいエンジニアに解説を仰ぐ
-
障害の振り返りに参加する
-
-
自分が当然と思うことがなされていないことも
-
-
開発プロセスに関する業界のトレンドを把握する
-
社外でも技術系の人脈づくりを
-
-
経営幹部
-
技術系の幹部として
-
-
-
変化を受け入れ非効率を改善し変化を組織へ導入する媒介となる
-
望ましい変化を実現できる組織を生み出す
-
-
素養
-
-
情報が揃わない中での難しい決断と責任を負う覚悟
-
自社の事業の把握と将来を想定し計画する能力
-
組織を強化する管理体制を敷くことの価値への理解
-
事業を前進させるために建設的な駆け引きをする能力
-
非技術系の同僚たちとも協力して仕事を進める能力
-
皆の決断に違を唱える能力
-
同意できなくても決定された事項を尊重し結果を出す能力
-
個々の部下、部課に対して責任を課し、責任を問う能力
-
-
4つの職務（High Output Managementより）
-
-
情報の収集・共有
-
-
会議、メール、1on1などにより様々な意見に耳を傾ける
-
情報を素早く集め、選り分け、第三者に理解可能な方法で共有する
-
-
注意喚起
-
-
質問することにより相手に責任事項を想起させる
-
質問を投げかけて注意を喚起し組織の脱線を防ぐ
-
-
意思決定
-
-
管理者の仕事の中でも一際労力のいる気苦労の絶えない仕事
-
-
-
気の進まない場面でも最良の模範を示す
-
-
-
技術系の経営幹部の肩書と役割
-
-
研究開発
-
-
開発チームとは別に技術戦略に関わる職権や新たなアイディアを掘り起こす役割を果たす
-
-
技術戦略・ビジョナリー
-
-
技術戦略と製品開発を結びつける役割
-
業界や技術の動向に基づいて意思決定を導く
-
-
組織化
-
-
組織構造、要員計画立案、配置にも責任を持つ
-
-
執行
-
-
通常、組織化と兼任し各部署の職務執行に関する責任を負う
-
各部署のロードマップの連携、作業の計画立案、広範な事業の調整を支援
-
プロジェクトの優先順位付け、進行の妨げの除去、意思決定も
-
-
技術部門の対外的な「顔」
-
-
ソフトウェア製品を販売しようとする際の顔
-
クライアントとの会合への出席やカンファレンスなどでの講演なども
-
-
社内の技術インフラとその運用
-
-
会社の成長段階において経費、セキュリティ、規模拡大などに焦点を当てる
-
-
事業化
-
-
事業そのものに焦点
-
-
これらをいくつか組み合わせ、兼任しCTO、VP、CIOなどの役割を果たす
-
-
技術担当バイスプレジデントとは？
-
-
人員、プロジェクト、チーム、部課の事情に精通したベテラン管理者として期待される
-
企業の成長に伴い戦略志向の度合いを務め組織管理を部課長に任せる傾向にある
-
技術担当VP1名のみの企業における仕事
-
-
作業工程を把握し下位の作業完遂を促す影響力を持つ
-
CTOがより広範な戦略と社内での技術部門の位置付けに、VPがアイディアの実現にそれぞれ焦点を絞るのが一般的
-
ロードマップ実現のための採用計画・活動の責任を担う
-
既存の優秀な人材の発掘や人事部と連携した人材開発も
-
-
組織をよく知り作業状況を素早く把握し人的・技術的信頼もあることが求められるポストであり、外から入れるのは困難
-
組織戦略に対する全責任を負うことも少なくない
-
-
プロダクトチームとも緊密に連携
-
ロードマップ、事業目標が技術部門にとって達成可能な目標の中にあるか目を光らせる
-
-
-
CTOとは？
-
-
技術系（エンジニアの延長上）の役職ではない
-
-
経営幹部たるべき、エンジニアであることは2の次
-
-
その会社が現在の成長段階で必要としている戦略的技術系幹部
-
-
戦略的：長期的視点に立って、事業の未来と、それを可能にする要素とを計画する作業を支援する仕事
-
幹部：戦略的な思考の成果を実現、運用可能にする作業を支援
-
CTOが採用など人的管理に焦点を当てているのであれば、それが現時点でその会社の技術チームの最重要事項だから
-
-
何よりも事業戦略に関わる仕事を優先すべし
-
-
コラム：CTOと技術担当VPの区別
-
優先順位の変更
-
-
最優先事項の変更は訪れる
-
-
あなた自身が最優先を理解しているか
-
チームは理解しているか、伝えられているか
-
割り込ませるか否かの判断ができるだけの現場理解をしているか
-
割り込ませる前に完遂すべき作業を上層部に伝えられているか
-
-
重要事項を相手の意識に刻み込む工夫を
-
-
下にも上にも方法や回数を多めに
-
予想される質問の準備
-
進路変更が好ましいものである点を売り込むことも
-
3回繰り返すことで真剣に受け止め出す傾向
-
-
上層部へは常時先を見越した形で知らせることが求められる
-
-
最優先事項は十分理解しておりチームにも徹底している
-
取り掛かるべく現場で進めている具体的な対応策も知らせる
-
-
-
戦略の策定
-
やりにくい仕事／悪いニュースを伝える
-
-
大きなグループに血の通わないメッセージを一斉送信するのは禁物
-
-
詳細は背景をきちんと説明してあげる人がその場にいないと誤解や恨みを生じる恐れが大きく
-
全員を一堂に集めて知らせるのは2番目に悪いやりかた
-
-
できる限り個別に話す
-
-
相手に反応したり質問したりするチャンスも
-
大規模な部署に知らせなければいけない場合はまず管理者たちに詳しく説明し各チームに
-
-
言語道断だと思うようなメッセージなら代役を立てても構わない
-
-
全部1人でやらなければならないわけではない
-
-
その悪いニュースが招きそうな事態を直視する
-
-
現実を直視して部下と腹蔵なく話し合う姿勢を貫く
-
-
自分ならどのように告げて欲しいのか、想像してみる
-
-
コラム：非技術系の上司に手を焼いています
-
-
専門用語の連発で煙に巻くのは禁物
-
1on1はこちらが用意周到に
-
問題を持ち込むのではなく、解決策を提案する方向で
-
アドバイスを仰ぐ
-
-
相手への敬意を表す方法
-
-
重要なことなら遠慮せずに2度3度念を押す
-
支援を惜しまない
-
-
他にお役に立てることは？
-
-
積極的な自己研鑽を
-
-
経営幹部としては新米、上は大ボスのみ
-
-
-
他部門を統率する幹部仲間
-
-
幹部仲間こそがチーム、全社レベルの成功に照準を
-
部門の枠を超えた協業ができている状態
-
-
仲間の縄張りを荒らさず、仲間もあなたの縄張りを荒らさない
-
-
幹部仲間の専門分野を尊重する場面では敬意を表する
-
-
根本レベルの信頼
-
-
畑の異なる相手とはカルチャーショックが起きがち
-
-
分析思考型の人
-
創造・直感型の人
-
迅速性や変化を重視する人
-
長期計画や納期、予算にこだわる人
-
-
相手の流儀を理解し信頼するための努力と工夫が欠かせない
-
-
非技術系幹部にわかるように言葉を選ぶ、など
-
相手を尊重すべき局面でつまづくのは、エンジニアこそ誰よりも頭の冴えた人種という思い込みによるものがある
-
-
-
「ここだけの話」の手法
-
-
幹部間の衝突を外で持ち出さず、決定事項に対して幹部全員が共同戦線を張る
-
トップレベルでは共同歩調を取るか辞職するか選ぶしかないような状況も
-
-
-
-
反響
-
-
もはやチームの一員ではなく、今のあなたのチームは首脳陣となる
-
直属の技術部門チームと距離を置くべき
-
-
結びつきが強すぎると特別扱いせずにはいられなくなる
-
会社を引っ張る立場として部下たちが本気で耳を傾ける関係を構築する必要がある
-
-
発言が仲間のものなのかトップからの命令なのか混乱させてはいけない
-
-
幹部レベルの心配事や不満を不用意に打ち明けることはチームの安定性を揺るがす有害な要因に
-
-
距離を置くコツは、自分が関わる職務対象を慎重に選ぶこと
-
-
チームの意思決定の場に入ってしまうと多大な影響を与えてしまう
-
-
チームの一員でなくともメンバーそれぞれを生きた人間として気にかけることをやめてはいけない
-
-
距離を置くことに成功すると社員を歯車として見られなくなる危険性も高まる
-
社員のロールモデルとして
-
-
どのような手本を示して後継者を育てたいか
-
会社にどのような文化や伝統を残したいか
-
-
-
-
恐怖で支配する上司と信頼を基盤に置く上司
-
-
恐怖の文化
-
-
部下たちは失敗の責任を問われたり人前で批判されるのを嫌ってリスクを冒さない方向へ、失敗を隠す方向へ、というチーム文化を生み出す
-
自己組織化するチームに育てるには、リスクを承知で賭けに出るようなメンバーが必要
-
オープンに議論できた関係も、あなたが幹部になることで一変し、相手が萎縮してしまう事態も
-
-
恐怖の文化を改めるには
-
-
心を通わせる習慣を
-
-
兆候の一つは部下を人間扱いしようとしない傾向
-
何気ないやりとりで徐々に相互理解が成り立つ
-
-
謝る
-
-
ミスをしたら率直、簡潔に謝る
-
-
長々と謝るとかえって言い訳がましく
-
-
謝罪の目的
-
-
自身が悪影響を及ぼしたことを認める
-
間違いを犯しても大丈夫だが、人の感情を害したら謝罪が必要ということを教えるロールモデルになる
-
謝罪しても立場が弱くなるわけではなく、チームが強くなることもあることを示す
-
-
-
好奇心を持って
-
-
あることに同意できなくても糾弾するのは禁物
-
-
非難された側は心を閉ざしていく
-
-
さらなる情報を引き出そうと手間暇かけて質問する
-
-
理解不足による過剰反応に過ぎなかったと判明するケースも
-
率直に質問することでチームはその事柄を別の角度から見る視点を明かしてくれる
-
-
-
部下を悪者にせずに責任を取らせるコツを身につける
-
-
チームがしくじった場合は責任を問うのも役目だが、途中に様々な要件がある
-
-
成功の度合いを測る基準は？
-
成功に必須の能力をチームは備えているか
-
過程で上司のフィードバックを与えるべきか
-
-
それらを明確にした上で最善を尽くしてもダメだった場合には、責任を問うにしても個人攻撃とはならないように
-
-
-
恐怖の文化は技術系の世界では割とよくあるが、他のことがスムーズな環境だと見過ごされがち
-
-
他に問題が生じた時に乗り越えられない
-
信頼の文化の構築には手間暇かかるがそれだけの価値がある
-
-
-
True North
-
-
「その部門で真に卓越した手腕がどのようなものか、その基準値を自ら示す」役割のこと
-
-
管理者が職務を果たす上で外してはならない勘所
-
※目指すべき基準そのもののようにも読める
-
-
製品部門の幹部
-
-
まず顧客とニーズに配慮すること
-
測定と実験を可能な限り徹底させること
-
チームが定めた目標に沿わないプロジェクトを先送りすること、など
-
-
-
数字に注意を払うこと
-
そうした数字が会社に有利に働く運用方法を見極めること
-
想定外の出費がないよう注意すること
-
チームが予算超過のリスクに直面した場合、チームにそれを認識させること、など
-
-
技術部門の幹部
-
-
チームに製品をデザインさせ、リリース可能な状態にまで仕上げさせること
-
レビュー、運用、テストにおいて、合意済みの方針を尊重すること
-
顧客に体験してもらえる状態に達していないと判断した要素はリリースしないこと
-
誇りにできるようなソフトウェアやシステムを作り出すこと、など
-
-
技術系幹部が設定に寄与すべきトゥルーノースはリスク分析を駆使する
-
-
例えば一定の状況下では可となるリスク
-
-
SPOFがある状態
-
既知のバグや問題点がある状態
-
高負荷が許容できない状態
-
データの喪失
-
テスト中のコードの公開
-
作業の進捗が悪い状態
-
-
量産段階では慎重に勘案すべき事項
-
-
その点への注意を喚起してくれるのがトゥルーノース
-
-
-
前者レベルでは緊張関係の要因ともなり得る
-
-
製品部門では生産の支援よりも顧客体験を
-
財務部門は可用性よりも全社的なインフラコストを
-
あらゆる部門のリスクに配慮せざるを得なくなる、健全な緊張関係
-
-
トゥルーノースを熟慮することで自分の権限とその範囲に対する理解を深められる
-
-
技術系幹部の例
-
-
リリース
-
スケールアップ
-
システム設計
-
テスト
-
システム開発言語
-
-
意思決定の際に評価基準となる指針を定める
-
-
現場でどう運用するかは部門の管理者に任せる
-
-
-
文化の構築
-
チームに文化を明示し、以後も常に配慮を怠らない
-
自分の役割の見極め
-
-
舵取りをしている乗り物の大きさの見定め
-
-
社員数
-
-
多くなれば全体を正しい方向へ引っ張る組織構造が必要になる
-
現場が目標を設定するボトムアップ型の意思決定が多くなっているが、目標の設定と周知を円滑に行える構造画筆よう
-
-
創業からの年数
-
-
長いほど定着している慣行習慣が多く今後も存続する可能性が高まる
-
-
既存のインフラの規模
-
-
ビジネスルール（顧客への請求金額の設定方法など）やインフラが多いほどその扱いを明確化する必要性が高まる
-
-
リスク許容度
-
-
業界の規制なども会社の構造とプロセスに反映されているべき
-
-
-
不都合の生じ始めが組織構造の修正箇所の見極めの機会
-
-
キャリアパスが規定されていないことで人材を逃し始めれば策定を検討することになる
-
-
当時はリスクが大きいと考えられていたが今ややらないとリスクになること
-
-
リリース頻度
-
-
構造の欠陥による不具合の例
-
-
会社や担当部署の文化の創成
-
-
組織文化
-
-
企業文化は存在し重要だが理解していない人が多い
-
リーダーが注意を怠ればあっという間に懸念事項となり得る
-
-
文化とは
-
-
あるコミュニティで共有されている暗黙のルール
-
構成員全員が同じ価値観を有するわけではないが、行動規範のように作用する
-
複雑な状況では接着剤の役割を果たし、先行き不透明な状況に陥っても一致団結して判断を下すことができる
-
-
会社のコアバリューに自分の重視する事柄がどれだけ重なるかで、会社に溶け込む際の努力の程度が決まる
-
-
コアバリューの活用
-
-
第1に、担当部署の文化を定義すること
-
-
会社がすでに価値観を打ち出していればそれをチームに当てはめてみる
-
独自の価値観を足したりチームにしっくり来るように言い換えたり
-
例
-
-
多様性の尊重
-
学びの文化
-
-
-
第2に、会社やチームの価値観をプラスの形で体現している社員を褒めることによって文化を強調する
-
-
組織文化の周知徹底という点では勤務評価も有用
-
-
重視している価値観を勤務評価の柱の一つにすることがポイント
-
価値観が合わない部下を見抜くコツも身につけるべき
-
-
-
第3に、コアバリューを採用面接のプロセスに組み込む
-
-
面接担当者に価値観を再確認させ、面接時に積極的に探るように指示する
-
友人として好ましく思える人だけを雇っても強力なチーム作りには繋がらない
-
-
-
文化に関するポリシーの策定
-
-
オープンソースの雛形や他の会社のものを参考にすることでゼロから作る負荷を減らすことはできる
-
が、ある会社で成功したポリシーが別の会社でも成功するとは限らない
-
-
キャリアラダー作成のコツ
-
-
チームのメンバーにも応援を仰ぐ
-
-
シニアエンジニアに求められるスキルについてはトップエンジニアに検討してもらうなど
-
-
実例をさらに集める
-
-
自社より規模の大きい会社のものなど多角的に参考にする
-
-
細部の表現を大切に
-
-
やる気を引き出し、過不足なく、社風や実情に合った解説文
-
あるランクで欠員が1人でて、新規採用にするか、それとも誰かを昇進させるか、判断を迫られている、という状況を想定し、その際に目安にするであろう詳細な基準をあげてみて、それを適切な表現でまとめると良い
-
-
詳細な説明と要約とを併用する
-
-
表形式で、昇格に伴う変化を段階を追って容易に把握できる簡易バージョン
-
各ランクについてもの画たちの形で詳細を補う詳細バージョン
-
-
ラダーと給与の関連性を考える
-
キャリアの初期段階では昇進の機会を増やす
-
-
初期段階では頻繁な昇給が期待される
-
-
キャリアの初期段階では給与の幅は狭くする
-
ランク数の少ないそうでは給与幅を広くする
-
-
ランク間のスキルの差が明確になる
-
上下のランクの給与幅を重ならせる
-
-
今のランクでかなり成績をあげているが次のランクの責任を追わせるのにはまだ早い、という状況でも優遇できる
-
-
-
ブレークポイントに当たるランクの設定も検討する
-
-
そのランクに達すれば以後昇進しなくても期待される成果を出しさえすればクビにならないというランク
-
これから先は昇進が難しくなる境目
-
-
実績報酬の手段としても
-
-
バイスプレジデントへの昇進など、キーストーンとなるランクを位置づけ、目標としてもらう
-
-
途中で管理系と技術系のパスを分ける
-
人的管理のスキルを中堅社員の必須要件にするという選択肢も
-
経験年数を条件とする場合は慎重に
-
ラダーは常に見直される
-
-
職能の枠を超えたチーム
-
-
管理は職能ごと、作業はチームごと
-
職能の枠を超えた製品チーム、専門チームそれぞれ状況に応じて
-
-
一丸となって一つの製品を生み出す目的
-
革新的、先端的な技術を生み出す目的
-
-
-
作業プロセス
-
-
作業プロセスが皆無だと規模拡大で苦労
-
チームに合わない作業プロセスは作業停滞を招く
-
作業プロセスはリスク管理
-
-
みんなで連携を軸にプロセスを確立し、リスクが誰の目にも見えるように
-
リスクが低い、明らかな作業のプロセスはシンプルに
-
メンバーか完全に従わなくても価値の得られるプロセスを
-
-
変更やリスクをチーム全体で共有
-
-
-
-
意思決定のプロセスから個人的要素を排除する
-
-
コードレビュー
-
稼働停止（トラブル）の事後検証
-
-
犯人を名指しし問い詰めたい気持ちは押しとどめる
-
-
メンバーが失敗を恐れるようになる
-
-
インシデントをめぐる状況を吟味し、経緯や背景を把握する
-
-
学習のための検証となるように
-
-
事後検証の成果は現実的な視点で取捨選択する
-
-
リストアップされたものすべてには対処できない
-
ハイリスクで再発する可能性高いものにまず絞る
-
-
-
アーキテクチャレビュー
-
-
大きな変更について関連グループ内で共有しリスクを明確にしておく目的
-
-
新しいシステム／言語を使いこなせる人が何人いるか
-
訓練／教育のプロセスは
-
使用上の注意点は
-
-
レビューの対象としてふさわしいのはどのような変更かを明確に
-
-
言語、FW、ストレージ、ツールなど
-
日常的な作業の前に負担の大きなプロセスを設けないように
-
-
レビューの価値はその準備段階にある
-
-
リクエストする人は理由を深く考えざるを得ない
-
-
考えてなかったリスクに気づくことができる
-
-
-
レビューの担当者はよく考えて選ぶ
-
-
変更で一番影響な受けそうな人たちを都度当てるのが望ましい
-
-
管理者が全ての意思決定の責任を負わなくても済む
-
関与すべき人たちがその意思決定の評価に加われるように
-
-
無関係な人から反対されるほどやる気の削がれる事はない
-
-
-
