書評)実務でつかむ!ティール組織
-
自分に自信を持っていると、うまく育成できず、人に任せられない
-
-
右腕候補を見つけても、自ら首を突っ込み、あなたはダメだという
-
-
マネジメントの考えてることとメンバーが考えていることのズレが心配
-
-
メンバーが重要な勘所を抑えて仕事しているか不安
-
メンバーが、自然と業務上の勘所がわかるような環境、仕組みがないことが原因
-
目的地図と重要指標の透明化でメンバー自ら進み、管理できる仕組みを
-
-
マネジメントとメンバーの、会社のことを考えている度合いのズレが心配
-
-
メンバーにとっては経営理念は人が作ったもの
-
想いを伝え、行動を共にし、組織のビジョンへ近づいていることを共有しないと伝わらない
-
-
仕事の役割の不透明性
-
-
誰が何やってるのか、自分はどこまでしても良いのか
-
-
役職による意見交換のしにくさ
-
-
上司に聞いてもらえるか
-
-
意思決定プロセスの曖昧性や不納得
-
-
どういうプロセスで新規投資や給料が決定されているのか
-
-
重要指標が見える化されていない
-
-
結果に至るまでのプロセスの指標が見えているか
-
価値のあるプロセス上の重要指標はなんなのか
-
-
理由は変数が多いから
-
移行前に部分的にでも実践期間を持ち定着させるとこから始める
-
「生命体」に比喩される
-
社長や上司が管理/実務介入しなくとも、組織の目的実現に向けてメンバー進むことができる独自の仕組みや工夫にあふれている組織
-
3つの要点
-
-
(進化する)存在目的
-
-
競争、市場シェアよりも、存在目的という一定の方向性を示すことを重視
-
-
自主経営(がかのジュとなる仕組みや工夫を有している)
-
-
ピラミッド構造からチーム制へ
-
決定に前には専門家やCEOからの助言を受ける助言プロセス
-
-
(個人としての)全体性の発揮
-
-
人間性を保つことを重視
-
感情的な部分にも目を向ける
-
-
-
ティール組織の一形態
-
人/役職ではなくロールが主役
-
個人ではなくロール、ガバナンスプロセスに権限を委譲する
-
-
各ロールの目的、ミッション、権限を決めるのは上司ではなくガバナンスミーティング
-
-
役職ではなく役割を与える
-
役割は柔軟に修正可能で全メンバーがその意思決定に関われる
-
役割に基づいて日々業務を行う中、良いアイデア、懸念があればそれに寄り添うことを約束事にする
-
重要な指標を透明化
-
チャレンジしたい役割に一定時間さける
-
マネジメントの考えてることとメンバーが考えていることのズレ
-
-
メンバーが重要な勘所を抑えて仕事しているか不安
-
メンバーが、自然と業務上の勘所がわかるような環境、仕組みがないことが原因
-
-
マネジメントとメンバーの、会社のことを考えている度合いのズレ
-
-
メンバーにとっては経営理念は人が作ったもの
-
想いを伝え、行動を共にし、組織のビジョンへ近づいていることを共有しないと伝わらない
-
-
変数の多さ
-
まずはマネジメントの「心の奥の想いに気づき」、メンバーと対話すること
-
目的地図と重要指標の透明化
-
-
目的地図は計画段階で重要な勘所が漏れないようにある
-
指標は進捗管理や評価のためではなく、メンバーが、確認するためのもの
-
-
組織の目的とメンバーの目的の繋がり度合いの向上の仕組み作り
-
-
PDCAのCの前に出来なかったことだけでなく、小さくても出来たことを確認する
-
その結果感じたメンバーが大切にしたい価値観と組織の目的が緩やかに繋がっていることを感じる
-
自分として、仕事をする際に大切にしたい価値観や考え方と、組織目的の繋がりを見つける
-
また、繋がっていることを伝える
-
-
これらを移行前に実践期間を持ち定着させるとこから
-
役割
-
-
組織の方向性や重要指標の透明化
-
事業の優先順位
-
資金の事業への配分
-
ロールへのメンバーの配置
-
メンバーへのアドバイス
-
-
認められないこと
-
-
指示命令
-
-
ザッポスの事例では、社長から社内的にはリードリンクのロールへ
-
組織目標を実現するための必要な環境を整える
-
仕事の役割の不透明性
-
-
誰が何やってるのか、自分はどこまでしても良いのか
-
-
役職による意見交換のしにくさ
-
-
上司に聞いてもらえるか
-
-
意思決定プロセスの曖昧性や不納得
-
-
どういうプロセスで新規投資や給料が決定されているのか
-
-
重要指標が見える化されていない
-
-
結果に至るまでのプロセスの指標が見えているか
-
価値のあるプロセス上の重要指標はなんなのか
-
-
自分に自信を持っていると、うまく育成できず、人に任せられない
-
-
右腕候補を見つけても、自ら首を突っ込み、あなたはダメだという
-
-
組織を一枚岩にするために価値観を定め、採用もこれに従う
-
-
誠実に向き合う
-
力をあわせる
-
本質を考える
-
最高にこだわる
-
自分を磨く
-
-
若手の定着の組織課題に向き合うため次のビジョンの作成に取り組む
-
-
若手社員も関わり時間をかける
-
複数チームでビジョン餡を作り持ち寄る
-
できあがった7つのビジョン
-
-
歪みない事業/関係性を作る
-
全てのステークホルダーと真摯に向き合う
-
みんなで会社を作る
-
志を尊重する
-
ワクワク感を大切にする
-
違いこそを組織の力に変える
-
厳しく求め、支え合う
-
-
-
新人事制度
-
-
基本給与は「能力/姿勢への対価」
-
賞与は「成果への対価」
-
書評)サーバント・リーダーシップ実践講座
-
難しい問題はリスクをとって自分で意思決定せず、上位者に判断を委ねようとする傾向
-
リーダー待望論は他責で依存状態
-
組織や社会の中に多数のリーダーが存在しネットワークを組みながら進んでいくのがこれからの姿
-
「想い」の罠
-
-
個人的な想いのために周囲を巻き込もうとする
-
想いを実現するために全てを自分でやろうとする
-
-
部下の意見を取り入れつつもビジョンを示す
-
部下の自己成長の邪魔をせず、支援し、環境づくりをする
-
部下だけでなく協力してくれる関係者にも感謝を表する
-
細分化され高度化する状況においてメンバーが指示通りに動くだけでは成果が上がらない
-
ネット社会
-
雇用環境の変化
-
-
忠誠によるコントロールができない
-
-
ただの親切ではない
-
-
本来はこうあるべきだ/こうしたいとビジョンを描くこと
-
それを実現するために人を巻き込みその人たちが活躍できるように奉仕すること
-
-
物事を全体として捉える
-
-
個々の事象を解決するのではなく大きな枠組みを変えようとする
-
-
リーダー
-
-
任命、選ばれて肩書きがつくケース
-
自然発生的にリードする立場になるケース
-
-
リーダーシップ
-
従来のリーダーシップとの違い
項目
|
従来のリーダーシップ
|
サーバント・リーダーシップ
|
モチベーション
|
最も大きな権力の座に就きたいという欲求
|
組織上の地位にかかわらず、他者に奉仕したいという欲求
|
競争を勝ち抜き、達成に対して自分が賞賛されることを重視
|
みんなが協力して目標を達成する環境で、みんながウィンウィンになることを重視
|
|
影響力の根拠
|
目標達成のために、自分の権力を使い、部下を畏怖させて動かす
|
部下との信頼関係を築き、部下の自主性を尊重することで、組織を動かす
|
コミュニケーションスタイル
|
部下に対し、説明し、命令することが中心
|
部下との信頼関係を築き、部下の自主性を尊重することで組織を動かす
|
業務遂行能力
|
部下に対し、説明し、命令することが中心
|
部下の話を傾聴することが中心
|
成長についての考え方
|
車内ポリティクスを理解し活用することで、自分の地位をあげ、成長していく
|
他者のやる気を大切に考え、個人と組織の成長の調和を図る
|
責任についての考え方
|
責任とは、失敗した時にその人を罰するためにある
|
責任を明確にすることで、失敗を学ぶ機会とする
|
-
5つのバリュー
-
-
個人を尊重する
-
導く(共有できるビジョンを打ち出し勇気付けて導く)
-
サーブする(お互いに尽くす)
-
人の持てる力を引き出す
-
-
強みに正しい評価を与え勇気付ける
-
-
個人の成長へとつなげる
-
-
癒しと学びの過程を通して成長を促す
-
-
-
10の特徴
-
-
傾聴
-
-
相手と自分の内なる声
-
-
共感
-
癒し
-
-
相手の心を癒し本来の力を取り戻させる
-
-
気づき
-
納得(相手の)
-
概念化
-
-
大きな夢やビジョナリーなコンセプトを持つ
-
-
先見力/予見力
-
-
現在と過去から将来を予想する
-
-
執事役
-
-
自分の利益よりも相手の利益
-
-
人々の成長に関わる
-
-
一人一人が秘めている力や価値に気づき信じる
-
-
コミュニティ創り
-
-
人々が大きく成長できるコミュニティを
-
-
-
奉仕は実行力を高める
-
-
人は欲求充足という理屈で動く
-
-
リーダーの指示で欲求を満たせると思うならやる気を持って取り組む
-
君臨型リーダーの指示は熱心に行動しているように見せかける方向に
-
-
-
5つのバリュー、10の特徴の意味
-
-
相手の欲求を満たす
-
より効果的な行動をとる支援ができる
-
協力学習やチームビルディングにより相乗効果を生み出す
-
-
目的の力:人は大義に燃える
-
-
目標だけでなく目的を明確にすべき
-
目的のない仕事は人に悪影響を与える
-
ビジョンは目標/目的の意味合いがあり、ミッションは目的そのもの
-
-
ミッションも合わせて示す
-
-
リーダーの個人的な欲求のみにフォーカスしたビジョンにも大義はない
-
-
-
管理職になって偉くなったと勘違いする人がいる。偉くなるとは神に近づくことだがそれは違う。
-
-
管理職になったら遅く出社するのがその例
-
人の上に立つものはむしろ模範を示さなくてはならない
-
-
リーダーは難しいときほど根明であれ
-
人を許すことを身につけるべき
-
一人一人に参画意識を持たせることが大事
-
-
部下自身がこれをやらねばと思うように導く必要がある
-
そのためにはコンセンサスが大事である
-
しかし「皆で決める」は衆愚であり最悪
-
-
大事な事は自由に意見を言える事
-
リーダーはその中で最良のものを選ぶが、意見が採用されなかった人もこれは俺の意見だと皆が思えるように導くべき
-
-
-
-
-
サーバントハート
-
-
日頃陽の当たらないバックヤードの従業員を表彰
-
他部署の仕事を1日体験し相手の立場を知る
-
従業員だけでなくその家族も家族としてみる
-
-
家族で会社イベントに参加など
-
-
人事部はHuman resourceではなくPeople & Leadership development
-
-
楽しむ
-
-
採用時にユーモアを重要項目として扱う
-
Kick offやプレゼンも楽しみ要素を、など
-
-
-
-
コアバリュー
-
-
人を大切にする
-
-
ミッション
-
-
私たちはコーヒーを売っているのではなく、コーヒーを提供しながら人を喜ばせるという仕事をしている
-
-
ビジョン
-
-
人々の心に活力と栄養を与えるブランドとして世界で最も知られ、尊敬される企業になる
-
-
-
チックフィレイ
-
-
S:将来を見極め、計画を作り込む
-
E:周りの人たちと積極的に関係を持ち、
-
R:常に新たな発明/改善に取り組む
-
V:ビジネスの結果だけでなく従業員、お客、家族のリレーションシップを重要視する
-
E:それぞれの価値を具体化して実行する
-
-
P&G
-
-
権限移譲をし、部下の話をしっかりと聞き、何をサポートすればビジネスがアップするのか。お客様を頂点に置いた、組織スタイルを構築するにはどうすれば良いのか。このマインドを常に持ち、リーダーシップを取るのが、サーバント・リーダーである
-
-
-
会社のような組織をサーバントリーダーとして動かそうと思ったら、まず自分の中にミッション、ビジョンを明確に持ち、それを組織のメンバーに伝える努力が不可欠になる
-
大切な事は変革の必要性や可能性を社員に理解させ、ゴールを示して、そこに主体的に向かうようにモチベートする事だ
-
-
-
リーダーが指示するのは1割でいい。自分たちで考えて思う存分活動できる舞台を与えてあげてほしい
-
哲学や企業理念といったしっかりとした幹があればあとは自由でいい。異なった能力が集まった企業が一番強い。同質が集まっても発展性はない。
-
-
メンバーに奉仕する
-
-
-
全員経営
-
-
細かい経費含めすげて公開、社員が当事者意識をもつ
-
-
公私混同の禁止
-
-
お金ほど人をダメにするものはない
-
-
-
社員を信用しやりたい人に任せる
-
失敗したら任せた側も一緒に連帯責任
-
-
連帯感/コミュニケーション
-
-
一緒に食事をしたり語ることを大事に
-
-
-
-
席替え
-
-
社長役員の席を通路側にして気軽に報告相談ができるように
-
-
肩書きではなく名前で呼び合う
-
-
肩書き文化はポジションパワーで人を動かしコミュニケーションが一方的に
-
名前で呼び合うことでポジションパワーが効きづらい風土に
-
お互い甘えられない
-
-
部下が上司に「〇〇さんどうしたらよいでしょうか?」と安易に答えを求めてきても、「○○さんはどう思ってるの?」と返す
-
-
管理職が「社員の成長に関わる」ように支援した事例
-
-
-
-
飼育研究会という勉強会
-
-
実はベテランでもわかってないことや、固定観念に囚われていることがわかった
-
-
理想の動物園というビジョンは明確になっても予算がなかった
-
-
「全員が自分が今できることをやる」という方針を掲げこれがコアバリューに
-
職員の工夫から「行動展示」につながった
-
-
人の成長への関与とコミュニティづくりによる社員の支援の事例
-
-
-
再生への第一歩
-
-
倒産したリゾートを再生するときに始めにやるのは従業員の話を聞くこと
-
新しい経営者が自分たちの話をしっかり聞いてくれることが「癒し」に
-
-
キャリア像を押し付けない
-
-
本人のキャリア目標をサポートする育成制度
-
-
究極のフラット
-
-
言いたい事は言いたい人に言いたい時に
-
自由でフラットなコミュニケーションを会社の環境として保証していく
-
-
侃侃諤諤な組織
-
-
誰もが意思決定者になる組織
-
立場で発言に重みをつけない
-
管理者の謙虚さとメンバーの力を引き出してあげたい思い
-
-
威厳は必要ない
-
-
若いスタッフに頭にきたらこちらも頭にきて物を言えばいいだけ
-
-
自分の不完全さを認める
-
-
権限で威厳を保つのは正しいことを言うことを要求され続けること
-
常に正しいことを言ってるわけではないと伝える
-
-
社員の本気のコミットメントを引き出す
-
-
散々テーブルに意見を出した上で意思決定したならば、みんなでそれを達成する
-
最終的に自分の意見が採用されなくても、発言できること自体、自分の話をきちんと聞いてもらえること自体でかなり欲求を満たすことができる
-
-
オープン主義
-
-
愚痴で多い1つは意思決定への不満。誰がこんなこと決めたのか。
-
意思決定プロセスは公開した方が良い
-
経営会議に一般の社員が入ることができるように
-
-
立候補制
-
-
愚痴でもう1つ多いのが上司、人事の悪口
-
リーダーに複数人立候補させて誰がベターかを選ばせる
-
-
欠点はあるがこういう長所がある、と欠点を認識して選ぶ
-
-
共感、納得、人々の成長に関わる、により自律とモチベーションを引き出す事例
-
-
-
セコム
-
-
従業員への統制は極力しない
-
-
予算統制、権限規定も設けない
-
統制することが社員の自発的なアイディアの蓋をすることになる
-
-
後継者が自由に采配を振るために自身が障害になると思ったら身を引く
-
-
-
全国を回って組織の問題点を4つに分類
-
人災
-
-
売り上げが悪いのを店長のせいだと言う
-
実際、問題は商品力、接客技術など企業の総合力から起きている
-
-
経験頼みの個人プレー
-
-
共通のオペレーションがないとノウハウが積み重なっていない
-
-
仕組みがないこと
-
-
現場で起こっていることを組織や仕組みに反映させる作業が経営者の仕事
-
-
社風
-
-
バイヤーが買いすぎることによる大量在庫の問題
-
-
バイヤーのせいにして人災として対処療法に終始していると解決しない
-
全員で共有できるシステムを作り見える化を徹底
-
全社共通のフォーマットを導入して解決
-
感性を大切にする社風にメスを入れシステム的にアプローチ
-
-
計画95%、実行5%という企業文化を変更
-
-
どうせ計画は狂う
-
-
社風、企業文化を変え、仕組みを変えて社員を支援
-
-
-
キャノン電子
-
-
震災復旧時、工場長に社長の権限を委譲
-
-
現場を知っているのは現場
-
-
いざという時に自分の判断で動ける人や組織を
-
-
日頃から情報共有、目的を明確に伝える、権限移譲をすることにより
-
-
-
未来工業
-
-
「常に考える」というモットーを掲げている
-
-
何か提案するために500円
-
習慣の積み重ねが差別化のアイディアを生む
-
-
勤務時間を抑え休日を多くする
-
-
みんなが勤務時間内に能率や生産性をあげ、競争力を確保しようと必死に
-
徹底してメンバーを信じた仕組み
-
-
-
代議あるミッション/ビジョン/バリューを示す
-
-
-
社名の変更
-
ビジョンの明確化:リゾート運営の達人になる
-
-
待遇など未整備なことが多くてもビジョンを示すことはできる
-
これにより採用もできるように
-
-
ビジョンとのギャップに悩みやめる人も
-
-
仕方ないと言ってはいけない
-
最大限ギャップを埋める努力を
-
-
-
セコム
-
-
ビジョン:あらゆる不安のない社会へ、困った時はセコム
-
事業展開の判断基準
-
-
社会にとっての正しさの追求
-
-
他の企業がやった方がいいと世間が思えばチャンスがあってもやらない
-
-
既成概念の打破、創造的破壊
-
-
既存事業の撤退も躊躇せず
-
-
-
-
-
サービスが先、利益が後、という考え方を社員に徹底
-
-
全員経営
-
-
グループ全体で社員数17万、本社にはわずか300人
-
-
本社が全部コントロールするのは不可能
-
どんどん権限移譲を
-
-
公益資本主義
-
-
会社を社会的存在と捉え、株主のことだけを優先するのではなく、従業員の働きがいや、顧客、地域社会などへの貢献をバランスよく重視する考え方
-
-
-
日本企業の苦戦
-
戦略と実行にどう影響するか
-
-
実行への影響
-
-
権限移譲しないことによるモチベーションの低下
-
-
双方向コミュニケーションで共感を作り出すことが必要
-
100%価値観に合わなくても納得して取り組んでもらうために
-
-
権限移譲しないことによる自律性の低下
-
自律性が育たないのでメンバー間の相乗効果も生まれない
-
-
戦略への影響
-
なぜサーバント・リーダーシップか
-
-
自分の不完全さを認めることで効果的な戦略を立てることができる
-
認めるために謙虚さを持つ
-
認めることで学び続ける
-
-
-
想いが強烈になると野心になるが悪いことではない
-
-
強い野心が成功を支えることは間違いない
-
野心がエゴに向くと君臨型に
-
私の成果、ではなく私たちの成果、に
-
-
自分の弱みをさらけ出すこと
-
-
常に自分が一番正しい、ではサポートもできない
-
-
相手に関心を持ち考えや背景を知ろうとする
-
感謝の気持ちを持ち心から言葉にする
-
自分にしてもらいたいことをまず相手にする心を大切にする
-
-
これらの価値観を浸透させる
-
-
自分たちのあり方、どうありたいかに向き合う
-
愛
-
-
愛は行動
-
たとえ本当はメンバーへの愛情がさほどなくても積極的に声をかけ傾倒し、関わりを多く持てば愛情は湧いてくる
-
-
謙虚さ
-
-
自分を客観視する
-
-
自分にとって耳の痛い話をしてくる人をそばに置く
-
-
現場に出て自分の成功体験だけでは通じないことを知る
-
自分が何らかの繋がり合うネットワークの中の一員と認識する
-
高い目標を持ち、自分の能力の不足を知る
-
書評)エンジニアのためのマネジメントキャリアパス
-
まずは話す
-
-
オープンドアポリシーでは疎遠な部下はより疎遠になる
-
-
評価と採用
-
-
会社の行動規範は抽象的すぎることが多い
-
日々の業務で自分たちが尊重するものは何かを考える
-
-
メンバーにも関与してもらい実例を加え自分たちが使えるものとして
-
それを実際の評価と採用で用いる
-
-
-
上司に何を求めるか
-
-
1対1のMTG
-
-
目的1:上司と部下の人間的なつながりを作ること
-
目的2:要検討事項について1対1で話す定期的な場を設けること
-
-
定期的であることで準備、態勢を整えられる
-
-
-
フィードバックと指導
-
-
悪い癖や習慣は早く知れば知るほど直しやすい
-
褒めるのは人前で、叱るのは1対1で
-
-
人前で褒められるのが苦手なら先に伝える
-
-
成果物の助言を上司に仰ぐのは一目置いていることを示す手っ取り早い方法
-
昇進したいならどういう方向に照準を定めるべきかを聞くのが早い
-
面白くない仕事でも価値や会社への貢献をしっかり理解させる
-
-
トレーニングとキャリアアップ
-
-
キャリアアップに必要なトレーニングなどのリソース、役に立つ他部門の専門家を見出し繋げる
-
昇進基準を満たすための準備の指導をする
-
-
-
管理のされ方
-
-
自分が何を望んでいるのかをじっくり考える
-
-
新人であろうとベテランであろうと自分と向き合う責任は自分が負っている
-
-
自分に対する責任は自分で負う
-
-
希望を表明するのは前へ進む一番手っ取り早い方法
-
否定的な反応を上司が返してきたら自分が今おかれている立場を認識させてくれる材料となる
-
-
上司も人の子
-
-
自分の手で変えられるのは自分自身だけ
-
地位が上がれば問題の報告だけでなく解決策の提案も期待される
-
上司へ解決を求めるのではなく助言を仰ぐ
-
-
上司は賢く選ぶ
-
-
上司次第であなたのキャリアは大きく差が出る
-
社内での駆け引きの仕方を心得ている上司はあらゆる面で後押ししてくれる
-
-
-
チームの新人に対するメンタリングの意義
-
-
メンターにとっては他者への責任を負う経験をする好機
-
メンティーにとっては専任のお目付役に教えを請う好機
-
-
インターンシップ制度
-
インターンのメンタリング
-
-
最高の夏を体験させる
-
-
大学へ戻って仲間へ語れるような
-
-
受け入れ態勢/環境を整える
-
プロジェクトを用意し学生とともにマイルストーンへ至る過程を検討する
-
-
プロジェクトを振り返って自分なら2、3日で完成できるような機能や要素を見つける
-
-
締めくくりにプレゼン
-
-
やり遂げた仕事が有意義であったと実感してもらう
-
会社が仕事を認めてくれたと実感してもらう
-
-
自分が将来リーダーとなるために必要なスキルを磨くチャンス
-
-
傾聴
-
-
きちんと伝わる形で話すのが下手な人が多い
-
口にする言葉以上のことを聞き取る
-
-
口調、しぐさなどのシグナル
-
-
相手の質問がわかりにくいと感じたら表現を変えて返したり絵を描いたりする
-
質問しやすい雰囲気を作る
-
-
明確な伝達
-
-
なすべきこと、出すべき結果を的確に伝える能力を磨く
-
-
まずは自分で調べて、わからなければ質問して良い、など伝える
-
-
-
自身の対応の調整
-
-
相手の能力や進捗など状況に応じて対応を調整する
-
-
報告は週1か、毎日がいいか
-
フォローはどの程度が適切か
-
-
-
-
-
新入社員のメンタリング
-
-
研修、会社に溶け込むための支援、社内の人脈作り、など
-
日常になってしまっている「不文律」を伝える
-
新人の人脈は自分の人脈ともなる
-
-
技術/キャリアに関わるメンタリング
-
-
その関係に対する期待や目標を明確にすることが大切
-
-
メンターになったら
-
-
メンティーに何を望むのかを伝える
-
-
質問の仕方、割ける時間
-
-
-
メンティーになったら
-
-
この指摘関係から何を得たいのかを考える、必要がない場合もある
-
-
すごい上司/ひどい上司ーアルファギーク
-
メンターを管理するコツ
-
-
焦点を絞った計測可能で明確なゴールを設定
-
プログラミングの職務以外で功績をあげたい人を選ぶ
-
一つの責任を追加で引き受けた功績を認める
-
ある業務スキルの向上を目標とする場合はその熟練者が最適
-
メンタリングは未来のリーダーを育成する好機
-
-
内気な開発者も視野が広がるきっかけ
-
傲慢な開発者はインターンのメンターで謙遜を感じるきっかけに
-
-
-
メンターの重要な心得
-
-
常に好奇心を絶やさずオープンな心で
-
-
フレッシュな目を通して見つめ直す機会
-
不明確な仕組み、自分の理解の浅さ、再検討に値すること
-
-
相手の言葉で話す
-
-
傾聴の訓練
-
-
人脈作り
-
-
キャリアは長く、業界は狭い
-
-
-
シニアレベルに達したエンジニアが順次一時的に担う職責群
-
-
メンバーコミュニケーションと育成
-
プロジェクト管理
-
チーム全体の生産性向上
-
難局の打開
-
他部門との協業
-
キャリアパスを登るために必要なスキルを身につける段階
-
-
なるタイミング
-
-
まだ早いと感じているなら受けない方が良い
-
将来もっと上の職位についてから「技術力不足」とならないように
-
-
テックリードのコツ
-
-
技術面での貢献とチーム全体のニーズへの対応のバランスを取る
-
自分の時間管理
-
チームの負担への配慮
-
プロジェクト全体への大局的な視点
-
-
システムアーキテクトとビジネスアナリストとしての役割
-
-
対象のシステムの十分な把握
-
複雑なソフトウェアを設計する方法の理解
-
ビジネス要件に対する理解と要件定義能力
-
-
プロジェクトプランナーとしての役割
-
-
デリバリ可能な単位で大まかに分割
-
熟知している人から助言をもらい進め方を考える
-
優先順位を検討しプロジェクトの初期に最優先事項に取り組む計画を立てる
-
-
開発者兼チームリーダーとしての役割
-
-
問題が生じたら自分で解決しようとせずすぐに伝える
-
PDMが妥協するであろう課題にチームが疲弊するのを割ける
-
メンバーに任せられる作業を見つける
-
-
プロジェクトの管理
-
-
まぁまぁ満足できるほどに予測し計画できる範囲内で、幾分かでも洞察力を働かせる
-
立案作業に費やす時間に比べれば完璧度は重要度が劣る
-
-
時間を割いて説明することの大切さ
-
-
相手が納得するまで懇切丁寧に説明する
-
相手は肩身の狭い思いをせずに必要な知識を得られる
-
自分の判断や忠告を信頼してくれるようになる
-
-
プロジェクト管理の実務
-
-
複数の工程に分割する
-
-
大枠から徐々に細かく
-
必要な人の支援を仰ぎながら
-
始められるタスクはチームに割り振ってさらに細分化してもらう
-
-
細部の引っ掛かりや道の要素にもくじけない
-
-
未知の要素に納得がいくまで向き合う
-
-
プロジェクトを始動し、調整を加えながら進行させる
-
-
どこまで進捗して完遂まであとどのくらいかを大まかに把握できる計画に価値がある
-
-
立案過程で得られた洞察を活かし、その後の要件の変化に対応する
-
-
諸要件に配慮してプロジェクトを分割する過程で洞察が得られる
-
変化のコストをみんなに伝え妥協点を探る
-
-
完了に近づいたら細部の詰めを
-
-
大失敗に終わる想定で逐一検討してみる
-
公開の計画だけでなくロールバックの計画も
-
-
-
技術職か管理職か
-
-
どちらにもメリデメはあり進路変更は可能なもの
-
-
ひどい上司ープロセスツァー
-
-
プロセス信者
-
プロセスはチームや作業のニーズを満たさなければならないことを理解する
-
仕事のやり方はチームによって違う
-
順守状況を見守る番人ではなく守りやすいものへの改変を検討する
-
プロセスで縛るのは失敗を恐れる不安から
-
「ゆるい」状況でも大丈夫だと安心できる働きかけを
-
-
優秀なテックリードとは
-
直属の上下関係
-
-
信頼感と親近感の構築を
-
-
その人の管理をやりやすくしてくれる質問をする
-
褒められる場合は人前が良いか1対1がよいか
-
重要なフィードバックは検討できる書面か口頭か
-
ここで仕事をする理由、希望、意欲、期待など
-
不機嫌/落ちてる時ははたから見てどんな感じか
-
いつも不愉快になる要因で事前に知っておいた方がいいもの
-
耐え難いと思う上司の振る舞い
-
キャリアアップの明確な目標
-
この部署にきて何か言っておきたいことができたか
-
-
今後1ヶ月/2ヶ月/3ヶ月の計画を立てさせる
-
-
部下が明確に目標を立案できれば理解が進んでいることがわかる
-
人選の誤りを検知し対処が必要なことを認識できる
-
-
新人研修用のドキュメントを更新させて理解を促す
-
-
前回更新後のUPDATEを反映してもらう
-
不明瞭な点を改善する
-
-
自分の流儀や要望をはっきり伝える
-
-
1on1の頻度や報告の仕方
-
進捗や結果をどのように把握/レビューしたいか
-
どのくらい自力で問題解決を努力したら応援を求めても良いか
-
-
新人からもFBを得る
-
-
最初の3ヶ月間のチームに関する感想や意見をできるだけ述べてもらう
-
批判を煽る行為は禁止
-
-
-
チームメンバーとのコミュニケーション
-
-
定期的な1on1は必要
-
1on1のスケジューリング
-
-
週一でやってみて頻度を調整する
-
お互いにとって都合の良い日時を選ぶ(月金を避けるなど)
-
-
1on1にまつわる調整
-
-
頻繁にやり取りする相手なら不要な場合も
-
新人ならコーチング、ベテランなら業務内容などにフォーカス
-
報告が得意でない部下なら頻繁に
-
良好な関係でも実施する
-
-
良好と相手も思ってるとは限らない
-
優秀な部下を顧みず問題児にだけ時間を費やすのは誤り
-
-
会社が変化/不安定なときは部下も気になっている
-
-
ちゃんと答えてあげることに噂を封じる効果がある
-
言えない場合は今は言えないと伝えてあげる
-
-
-
1on1の進め方
-
-
ToDoリスト型
-
-
口頭で済むようなToDoリストをトピックにすると不自然
-
口頭がふさわしいのは「微妙なニュアンスを伝えたい」もの
-
-
キャッチアップ型
-
-
部下の最新情報を入手するための1on1
-
部下主導で進めさせること
-
重要だと思う議題を気楽に持ち出せる雰囲気づくり
-
不満を並べ立てる場にならないように、建設的であること
-
-
フィードバック型
-
-
スキル向上や知識獲得のため
-
目標の達成度のレビュー
-
問題児は頻繁に
-
解雇を検討中なら文書で記録し上司から要望も添えて送付
-
悪いFBは直後に
-
-
経過報告型
-
-
管理者が下級管理者と開く1on1の多くは経過報告型になる
-
直前のプロジェクトレポートからの差分更新だけになっている場合は注意
-
プロジェクトと無関係なトピックを用意する
-
-
チーム、会社、etc.
-
-
-
相手を知るための機会
-
-
相手のことを一個の人間として気にかけているという姿勢を見せる
-
家族、ペット、趣味、これまでのキャリアについて話してもらったり
-
今後の長期目標を尋ねて見ても
-
部下を後押ししたいという気持ちを表明する
-
-
議事録
-
-
共有のドキュメントで作成し管理することがオススメ
-
書記は上司
-
議論の要点、持ち上がった考慮点、ToDoなど
-
-
-
細かすぎる上司と、任せ上手な上司
-
-
効率よく仕事を任せるために
-
-
チームの目標
-
-
成功の計測基準をチームに尋ね、その結果を報告させる
-
計画がない場合は期限を切って目標を立てさせる
-
-
チームに尋ねる前にシステムからの情報収集を
-
-
自分が入手できる情報でチームの時間を犠牲にしない
-
チームの目標に基づいて情報を収集する
-
-
プロジェクトの進行に伴って焦点の当てどころを調整
-
-
初期とデリバリ前は支援が必要
-
それ以外は順調に進んでいる作業と手間取っている作業を大雑把に
-
-
コードやシステムに関する基準を設定する
-
-
不安を払拭するために大きな共通の物差しを作っておく
-
基準を決めておくことでFBから個人的要素が排除できる
-
技術スタックに大幅な変更を加える場合は上位のレビューをするなど
-
-
情報は良きにつけ悪しきにつけオープンな形で共有する
-
-
正しい報告の仕方を教える
-
個人に責任を問わない
-
-
批判を避けるために手遅れになるまで報告しなくなる
-
-
-
-
継続的なフィードバックの文化を根付かせる
-
勤務評価
-
-
360度評価
-
-
多数のFBを集める
-
継続的なFBで見過ごす可能性のあるパターンや傾向が見えてくる
-
悪意のこもったFBを共有するかは見極める
-
-
勤務評価の要約の作成と面談
-
-
評価をする十分な時間を確保する
-
直近のことだけではなく期間全体に目を向ける
-
-
常時記録を取る、メールを見返す
-
全体を視野に入れることで成長や変化に気づく
-
-
具体例をあげ、周りのFBも引用する
-
-
色眼鏡を通して評価しない
-
-
功績や長所にはたっぷり時間をかける
-
-
昇進を決定する際の重要な判断材料になる
-
-
要改善点は焦点を絞って
-
-
周りのFBの中の共通項で自身が同意見のもの
-
良くある事例
-
-
手伝いすぎて自分の時間を取れない
-
共同作業で批判的すぎる
-
作業の分割が下手
-
多部署との共同作業が苦手
-
プロセスに従うのが苦手でやっつけ仕事になる
-
-
-
予想外の評価で驚かせない
-
-
昇進したばかりなら基準が変わっていることを事前に伝えたり
-
-
悪い評価は具体的に理由を説明できるように
-
-
どうすれば良い評価を得られるか具体例も含めて
-
-
潜在的な可能性
-
-
一定期間勤続していてこれといって手腕を発揮できない場合はこの会社で将来性はないと見ても良いかもしれない
-
真の可能性は時を置かずに芽吹くもの
-
-
もうひと頑張りの努力を惜しまない
-
問題が発生すれば鋭い提言をする
-
手付かずだった領域でチームを助ける
-
-
独自のやり方を持った人の評価が悪い場合は開花するところに移す
-
-
プログラミングは苦手だが危機管理はピカイチなら運用チームへ、など
-
-
-
-
-
キャリアアップへの取り組み
-
-
自分の会社が昇進に対してどのような方針と手続きを取っているのかを把握する
-
昇進を希望するがそれに満たない部下に対してはそれを知らせ、改善すべき事柄を把握できるようにする
-
昇進が近い部下に対して昇進材料となりそうなプロジェクトをアサインして成果を上げさせることも必要
-
一定のランクまで昇進して打てる手がない場合は多部署に紹介してメンタリングや支援を要請するなどして新たな挑戦課題を
-
-
地位によって職務が異なり、経過とともに能力限界まで昇進して無力化する
-
現在の職位での成績は昇進後の活躍を保証してくれない
-
ある職位に昇進させる以前からその職務を課す
-
-
そうしたキャリアアップの好機がチーム内にない場合、より大きな責任を負わせられるよう仕事の割り振りや進め方を再検討する必要があることを示唆しているかもしれない
-
-
-
-
成績不振者の解雇
-
-
徹底したコーチングが必要
-
期待されているレベルの仕事ができていないことをはっきり知らせる
-
与えたFBについて記録を取る
-
-
脱皮のためのコーチング
-
-
希望するが昇進する見込みがない、一定レベルまで昇進して足踏み状態
-
次のレベルで求められるスキルがどういったものなのか
-
-
説明しても見合う努力をしない
-
そのためここはキャリアップを図る上で最適な場所ではない
-
昇進を望むなら別の部署へ移る必要がある
-
-
他の部署など仕事を見つける機会を与えてあげる
-
-
開発グループマネージャのJD
-
管理者にとって一番大切なこと
-
-
最高の技術力を持つことではない
-
チームの人々を後押しし成功を極力サポートすること
-
-
ITスキルの維持
-
-
確かな技術力の持ち主という評価が得られないと、ある会社で管理職になってもそのあとの選択肢が限られる
-
小規模な技術的作業への従事で得られるもの
-
-
システムの課題、負債を察知できる
-
構築に手間取っている、デプロイが遅い、オンコールの負担が高いなど
-
要件の実現可否、難易度の評価が自身で可能
-
新機能実装の最短ルートを見分けられる
-
-
中間管理職より上に登るのに必要な技術力を十分に身につける
-
-
機能不全におちいったチームの「デバッグ」の基本
-
-
デリバリにこぎつけられない
-
-
人は些細なゴールであっても定期的に達成することで精神衛生を維持する
-
ペインポイントに気づきボトルネックを解消する
-
-
リリースに関わるツールの不備
-
手作業に頼りすぎなテスト
-
規模が大きすぎる機能
-
作業の細分化のコツを心得ていない開発者
-
-
-
厄介な部下への対応
-
-
波風を立てる、マイナスにこだわり続ける、噂話がすぎる、排他的など
-
必要なら上司に応援をあおいでも構わない
-
他チームへ配転させるだけでも解消することも
-
-
嫌な思いをせずにチームから出ていけるように手を貸す
-
-
チームのエネルギーを吸い取り枯渇させないように
-
巧みな攻撃こそが最大の防御、迅速な行動が不可欠
-
-
過労による士気の低下
-
-
システムの不安定性が原因であれば当面安定性のためのロードマップを
-
計画立案の段階で持続可能性のためのリソースを確保
-
納期が間近で過労状態の時はチアリーダーたるべし
-
-
一丸となって難局を乗り切ることで結束が固まる効果も
-
ともに乗り切ったかが嫌だったかを部下は覚えている
-
-
難局から学び再発防止に努める
-
-
協働に関する問題
-
-
関係部署との協働で足を引っ張られる形になっているケース
-
管理者が改善の意欲をみせるだけでも効果がある
-
相手責任者に不満があってもチームの前では前向きに
-
皆で一緒にちょっと息抜きをするような機会を考える
-
-
-
元同僚を自分の部下として管理する立場になったら
-
-
気まずい状況を認め向き合う
-
助けが必要であることを腹を割って話す
-
決断を独りで下そうとしない
-
自分が手放さなければならない技術的作業を任せる
-
売られた喧嘩は「価値ある戦い」のみ応戦する
-
管理者になった後の移行期間は「大人の対応」で乗り切ったほうがうまくいく
-
-
盾になる
-
-
チームが目標に集中できるように不要ないざこざの盾になる
-
ただし目標のコンテキストを理解することに役立つならチームの中に入れてしまった方が良い場合もある
-
知らせた方が良い会社のことを隠蔽してはいけない
-
-
他から伝わると疑心暗鬼に
-
-
管理者はチームのメンバーの親ではない
-
-
チームの意思決定を主導するコツ
-
-
「データ重視」の文化を根付かせる
-
顧客に対する共感を深め、チームにコンテキストを伝える
-
将来を見据え2歩先に立って考える
-
-
変化を起こしうる新技術を把握するための情報収集の時間を設ける
-
-
意思決定やプロジェクトの結果を振り返る
-
-
自分たちの意思決定から常に何かを学べる
-
-
-
「対立を手なずけられる」と「避けて通りたがる」上司
-
-
多数決、投票結果に従って決定を下す方法だけに頼ってはいけない
-
-
時には管理者が決定する責任を負うことも必要
-
-
意思決定から個人的要素を排除するための明確なプロセスを確立する
-
-
チームに委ねたいなら明確な基準を用意する(リリース承認の例)
-
-
「爆発寸前」の問題に見て見ぬ振りをしてはいけない
-
-
問題に気づいたらすぐに指摘する、指摘できる関係性を作る
-
-
本当に対処を要する問題だけを取り上げる
-
-
管理者がチームのセラピストになることが目的ではない
-
マイクロマネジメントにならないように
-
-
他チームへの責任転嫁は禁物
-
-
側からの見た目を気にしすぎず、自チームの問題にも目を向ける
-
-
人に好かれたいのはやまやまだが、管理者は優しさよりも親切を旨とすべし
-
-
昇進にはまだ早いと判断した部下がいたら正直に伝えて支援するのが親切
-
-
気休めをいうのはただの優しさ
-
-
-
恐れずに勇気を出して
-
-
対立を避ける気持ちは恐怖から生まれる
-
-
我が身を振り返る
-
-
対立を恐れる気持ちを克服する秘訣
-
-
-
やりにくい仕事/チームの結束を乱す人への対処
-
-
心理的安全性を作る
-
-
人として扱い、プライベートな話もする
-
チームに馴染む人材を採用する
-
-
ブリリアントジャーク
-
-
非常に有能だが自己中心的で周囲を攻撃する人
-
変わることを望んでいない人を変えるのは土台無理
-
好ましくない言動は断固、公然と否定する
-
-
叱るのは1対1で、の例外
-
チーム全体に有害であると判断された場合のみ
-
-
自身に向けられた場合は1対1で
-
-
あくまで冷静に
-
-
-
秘密主義者
-
-
隠し事をし、レビューなど必要な協力を得ない人
-
期待されている職務をこなせていないと明言しても良い
-
根元には恐怖心が隠れている
-
-
力不足がバレる、興味のない作業を振られる、など
-
-
恐怖心の元を探る
-
-
レビューが辛辣すぎるなど
-
チームの文化を変えさせるか、配転するかどちらが良いか考える
-
-
-
無礼者
-
-
本当にこのチームで働きたいか聞いてみる
-
-
働きたいなら期待値を伝える
-
そうでないなら異動を
-
-
-
-
管理者が担当すべき、より専門的なプロジェクト管理
-
-
管理者は大局的な計画と進捗の管理
-
-
短期的な目標はチーム主導によるアジャイル型手法が有効
-
-
システムの持続可能性維持に2割割く
-
-
本筋で遅れが出た時に振り分けることも可能
-
-
納期間近の立ち回り
-
-
期限を優先してスコープを狭めるか伸ばしてでも実現するか
-
本当に期限内に完成させなければならないものをチームと共に厳選しなければならない
-
-
即席の見積もりには倍増ルールを適用
-
長期的作業の見積もりには立案のための時間を要求する
-
チームメンバーに見積もりを頼むなら厳選して
-
-
ただでさえ忙しいメンバーの気を散らさないように
-
-
-
コラム:小さなチームの新米の管理者
-
-
チームのプロセスを深く理解して技術的信頼を得る
-
適任者を見つけてシステム、アーキテクチャ、テスト、リリース手順を説明してもらう
-
現場作業に加わって経験してみる
-
-
現場の勘所を維持する方法
-
-
これまでやってきた分野でレビュワーなどの形で関わり続ける
-
週に半日は創造的な活動に時間を使う
-
-
技術ブログ、カンファでの発表、OSSへの参加など
-
-
-
時間の管理
|
緊急でない
|
緊急
|
重要
|
必須。時間を作る
|
明らかにやるべきこと
|
重要でない
|
明らかに回避するべきこと
|
ついつい注目しがちな「気の散る要因」
|
-
重要性よりも緊急性にインパクトを感じがち
-
-
メールやチャットで流れ込んでくる情報や依頼
-
それほど重要でないことに時間を使ってしまう
-
-
重要だが緊急ではないこと
-
-
効率的なミーティングのための準備
-
将来を考える、計画する、焦点の当てどころを見直すこと
-
-
緊急だが重要でないこと
-
-
出る必要が明らかにないミーティング
-
ミーティングで参加者の様子を確かめる
-
-
集中していない人が多い場合は浪費的なものになっている
-
-
-
意思決定と委任
-
-
一度に回さなければならない皿の数が多すぎる場合の委任という秘訣
-
|
頻繁
|
頻繁でない
|
単純
|
委任
|
自分でやる
|
複雑
|
(慎重に)委任
|
訓練目的で委任
|
-
複雑な仕事を委任して後任やチームを強化
-
-
頻繁でない:評価の要約を書く、人材募集の計画を立てる
-
頻繁:プロジェクト計画立案、システムデザイン、障害復旧のまとめ役
-
チームに不可欠な仕事を管理者なしにできるように
-
-
やり方を完璧に知ってるのが自分だけの仕事をリストアップ
-
-
-
委任により空いた時間を新しく楽しい仕事に当てられる
-
やりにくい仕事/「ノー」にも言い方がある
-
-
はい、それでですね
-
-
肯定しつつも限界と実情を伝える
-
優先度を見据えた現実的な交渉に持ち込む
-
-
ポリシーを決めておく
-
-
管理者からイエスを引き出すための要件をメンバーに理解させる
-
-
私にイエスと言わせてみて
-
-
1回限りの判断で明確なポリシーがない場合
-
疑わしい部分に突っ込んだ質問を重ねる
-
相手が甘さに気づくことも、斬新なアイディアで驚かせてくれることも
-
好奇心を持って質問することでノーと言いやすくなり教育ともなる
-
-
時間や予算を盾にとる、今すぐは無理
-
-
後日、真剣に考える
-
-
手を組む
-
-
チームのために権限を行使してあげる
-
関係部署長に後押ししてもらう、悪者になってもらう/なる
-
-
ズルズルべったりは禁物
-
-
ノーを先伸ばさない
-
ノーが速合点であれば素直に謝る
-
全てにおいて調査分析して判断する余裕はない
-
-
-
コードの作成以外のITスキル
-
-
会社から求められている職務をきちんと把握しているか
-
-
どのようなコードを書くべきかを把握している
-
-
自分の職務を遂行する上で必要な機器やツールを持っているか
-
-
ツール、自動化、プロセスが用意されている
-
-
毎日最高の仕事ができる機会を得られているか
-
-
インシデントに忙殺されずにコードが書けている
-
-
-
直属の開発チームの健全性を見極める
-
-
コードのリリース頻度
-
-
問題を抱えているのに無視していないか
-
頻度を上げるための技術的チャレンジの指揮をとる責任がある
-
-
コードへのチェックインの頻度
-
-
作業が細分化されテストコードを書くプロセスになっているか
-
-
インシデントの発生頻度
-
-
対処するだけでなく発生件数を減らすことに取り組んでいるか
-
予防を重視しすぎてもベストではない
-
-
-
「イングループ」を作りたがる上司とチームプレイを重んじる上司
-
-
イングループ:愛着や忠誠心で所属意識を持つ集団
-
チームプレイを重んじる上司
-
-
全社の目標や文化を土台とし、強く永続性のある協調関係を構築したチームを作る
-
リーダーやメンバーが辞めてもすぐに立ち直れるチーム
-
-
全社レベルの目標を基盤としているため人が辞めても針路を見失うことがない
-
-
目標駆動型のチーム
-
-
達成に有用なことを出どこに構わず取り入れる
-
-
部長クラスの同僚こそがチーム
-
-
直属のチームだけに目を向けない
-
会社全体のニーズに配慮した意思決定を下すことができる
-
-
目標達成に役立つ変化を喜んで受け入れる
-
-
-
無精と短期の効用
-
-
チームが進めている仕事の効率が悪いと感じたらすぐに自問する
-
合計所要時間を減らして同レベルの価値を会社にもたらすことを考える
-
-
労働時間を増やすのではない
-
-
帰宅できるよう集中して仕事をする、せざるを得なくなる文化を
-
-
各チームの健康度に目を光らせ、目標設定を支援する
-
-
人材募集
-
メンバーのコーチング/育成
-
目標のレビュー
-
プロジェクトの状態
-
インシデントの事後検証と報告
-
-
スキップレベルミーティング
-
-
各チームの健全度や焦点の絞り方を把握する
-
-
上層部への立ち回りが上手い管理者で見えない問題を察知する
-
-
2つ上の上司に質問できる機会が生まれる
-
重要なトピックに水を向け部下から話を引き出す
-
部下のための面談であることを示唆
-
質問例
-
-
今担当しているプロジェクトで最高/最悪だと思う点は?
-
自分のチームで特に素晴らしい動きをしているのは誰?
-
直属の上司に何かフィードバックは?
-
担当している製品にどんな改良ができるか
-
我々が見落としていると思われるチャンスは?
-
うちの部の活動についてどう思うか?改善、増強、削減できるところは?
-
社の経営戦略でピンとこないところは?
-
あなたが持ち味を出し切れてない理由は?
-
この会社で働くことに満足しているか?
-
この会社で働くことの満足度を上げるために我々ができることは?
-
-
-
部下である管理者たちに責任を課する
-
-
管理者たちが各自きちんと職責を果たし、上位の管理者が務めを果たしやすくする
-
管理者はチームの健全性と生産性に関する責任を負っている
-
-
ロードマップが安定しないならプロダクト部門と調整を
-
テックリードが本筋から外れていたら方向修正と支援を
-
火消しに追われていたら火事の原因に対処するための計画と支援の要請を
-
-
管理者の後ろ盾となって解決策の模索や実施を助ける
-
-
ノーと言える管理者とイエスマン
-
新任管理者の管理
-
ベテラン管理者の管理
-
-
最初の難題は統括するチーム全体の文化に合う人物かどうか確認すること
-
-
文化的な相性で妥協してはいけない
-
-
自分なりのフィードバックを遠慮してはならない
-
-
管理という仕事に対する捉え方の違いを埋める必要がある
-
-
自分が最良だと思うチーム文化を直属の管理者が尊重できるように計らう必要がある
-
-
透明性の高い運営を望むなら情報共有の場を
-
アイディア模索を奨励するならそのための時間確保の支持を
-
-
ベテランは管理の仕事そのものは独力でできる
-
-
担当分野における戦略策定と方向付けに関するコーチングが多くなる
-
自分の職務のうちどれをベテランに異常できるか検討する
-
-
-
チーム管理者の中途採用
-
-
今求めているスキルの有無を確かめる
-
組織の文化にあっているかを見る
-
-
スタートアップ→大企業のケース
-
-
複数ステークホルダーとコンセンサスをとって進められるか
-
-
大企業→スタートアップのケース
-
-
上下フラットな関係の中でのコミュニケーション
-
形式ばらず迅速/柔軟に進められるか
-
-
まずは自分が自社の価値観をしっかり理解する
-
身元照会
-
-
前職の上司同僚に勤務状況を問合せる
-
-
-
-
自分が疎い分野のチームの管理
-
-
自分をメンティーに見立ててどんどん質問する
-
新任の仕事を理解して真価をよく認められることを目的として
-
勝手知ったる分野よりも時間をかける必要がある
-
-
機能不全に陥った組織のデバッグの基本
-
-
仮説を立てる
-
-
うまくやっているように見えるが退職者が多い、など
-
-
データ(事実)をチェックする
-
-
チャットやメール、コードレビューの内容
-
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、ストレージ、ツールなど
-
日常的な作業の前に負担の大きなプロセスを設けないように
-
-
レビューの価値はその準備段階にある
-
-
リクエストする人は理由を深く考えざるを得ない
-
-
考えてなかったリスクに気づくことができる
-
-
-
レビューの担当者はよく考えて選ぶ
-
-
変更で一番影響な受けそうな人たちを都度当てるのが望ましい
-
-
管理者が全ての意思決定の責任を負わなくても済む
-
関与すべき人たちがその意思決定の評価に加われるように
-
-
無関係な人から反対されるほどやる気の削がれる事はない
-
-
-
書評)OKR シリコンバレー式で大胆な目標を達成する方法
-
大事なことは3つかな?
-
-
ゴールへのフォーカスの維持
-
-
本当に重要でみんなが鼓舞されるようなゴールを見つけて
-
組織やチームでそのゴールに向かってぶらさずやりきる
-
やりきるモチベーションを維持する仕組みをもつ
-
大事に見えるけどゴールの達成に関係しないものは優先されない
-
-
継続的な向上と学習のサイクル
-
-
KRはノルマじゃない
-
失敗したら次どうするかを考える
-
容易に達成したらより高いゴールを考える
-
-
OKRは連鎖する
-
-
個人OKRは→組織/チームのOKRは→会社のOKRに貢献するものじゃないと
-
-
-
大きく三部構成で理解しやすくなってる
-
-
前半はストーリー仕立てでOKRがスタートアップに浸透して変わっていくイメージを持って
-
中盤で方法を学び
-
後半は実ケースをあげて実践のイメージを持つ
-
-
ゴールに優先順位をつけていない
-
-
Oを一つだけ、KRを3つだけ設定することでフォーカスを維持する
-
4半期の途中で変えない
-
-
誤っていても結果が出てから経験を踏まえて改善する
-
-
-
熱意を持ってゴールを伝えていない
-
-
職場環境にリマインダーを織り込む
-
毎週自信度を更新し上下について話し合う
-
-
やり遂げるためのプランがない
-
-
脱線しないようなプロセスが必要
-
コミットメント、お祝い、チェックインMTGなど
-
-
重要事項のための時間を空けていない
-
-
緊急の仕事は重要でなかろうが終わる
-
繰り返さずにやめてしまう
-
-
何が機能するかを観察し、機能する点を増やし、機能しない点を減らす
-
-
公式にあてはめ推敲する
-
-
私たちは『価値提案』によって『市場』における『問題点を取り除きます/生活を向上させます』
-
-
少なくとも5年支えてくれるミッション
-
-
目標との違いは期間
-
-
四半期ごとのOはミッションを前に進めるものにする
-
定性的で人を鼓舞する内容にする
-
-
すばらしいMVPを立ち上げる
-
○○におけるクーポンの使い方の慣習を変える
-
-
1ヶ月や4半期で実現できるものにする
-
-
1年などかかる目標は戦略やミッションが近い
-
-
個人のOは個人で、チームのOはチームで完結するようにする
-
-
あちらのせいで達成できませんでしたという言い訳が通用しなように
-
-
下位のOKRは上位のOKRの達成に貢献する
-
-
個人OKRは個人の成長とともに会社のゴールに貢献する
-
-
問題のある従業員
-
-
MGRはその人のOKRを一緒に設定すれば、測定可能なKRで結果を評価できる
-
-
ノルマを課すためではなく自分ができることを学ぶためにある
-
-
失敗は高い目標に挑戦しているポジティブな指標
-
-
プロダクトチームとはデザインとエンジニアリングといった機能別部署で構成されるプロダクトのためのチーム
-
機能別部署ごとにOKRを定義するのはよくある失敗
-
-
それぞれのフォーカスが異なることが板挟みを招く
-
-
OKRをプロダクトチームレベルにする
-
プロダクトチームへの貢献を妨げないレベルで個別の目標を持つのは構わない
-
コミットメント:例えばスクラムのプロセスに乗せて毎週月曜日に以下を話し合う
-
-
今週の優先事項
-
-
OKR達成に向けて取り組むべき重要な事項
-
-
今後の4週間
-
-
チームに知らせるべき予定
-
メンバーが貢献したり準備したりできるように
-
-
自信度
-
-
上下したら話し合う
-
-
健康/健全性
-
-
結果を目指す一方守りたいことを2つ
-
追い込みすぎたり手抜きが発生していないか
-
-
-
プレゼンよりも話し合いの時間を多く
-
金曜日のウィンセッション
-
-
どれだけ近づいているかを見せ合うことで不安をなくす
-
チームビルディングの役割も持つ
-
-
アルコールやおやつなどを提供して大事にされているという気持ちを持ってもらう
-
-
-
幹部など責任者を入れる
-
メンバーから取り組むべきだと思う目標を提出してもらう
-
優れたOと多かったOをまとめる
-
-
責任者も1つか2つ考える
-
-
MTG時間は十分に確保するが集中して早く終わらせる
-
付箋に書いて議論し3つに絞る
-
測定するための指標を10分くらいでできるだけ多く書き出す
-
書き出した付箋をグルーピングしランクづけする
-
最後に3つの指標を選ぶ
-
KRの値を設定する
-
-
達成が五分五分となる数値を選ぶ
-
互いの案に対する懸念を出し合う
-
バランスよく様々な角度で見つける必要がある
-
-
売上だけに注目すると短期的アプローチで顧客定着率を損なうおそれ
-
-
-
出来上がったOKRを納得するまで微調整する
-
最初は全体のOKRを一つだけ決める
-
-
幹部が高い基準を自らに課していることがメンバーへ伝わる
-
次の四半期に同じようにOKRを指示されても驚かない
-
-
一つのチームで導入してみる
-
-
成功したら広められる
-
-
プロジェクト単位で適用する
-
MVPの開発ではOを仮説にしてもいい
-
状況報告メールにOKRを応用する
-
-
冒頭にOKRと自信度の更新を書く
-
優先タスクと達成されたかを書く
-
来週の優先事項を書く(最優先は3つまで)
-
リスクや障害を挙げる
-
-
ゴールが多すぎる
-
-
大きな企業は事業ドメインごとに1つ、スタートアップなら会社で1つ
-
-
短すぎる
-
-
プロダクトマーケットフィットの前にOKRを持ってもすぐ変えないといけない
-
-
Oに数字を入れてしまう
-
-
様々な立場の人を鼓舞しなければならない
-
-
自信度レベルの設定を忘れてしまう
-
自信度レベルの変化の追跡を忘れてしまう
-
4つの四角形を状況報告に使ってしまう
-
-
本当に達成できるのか、問題が発生してないかを話し合おう
-
-
ウィンセッションで厳しい話をしてしまう
-
-
何ができたかを共有しよう
-
My英語の勉強教材
TOEICがそこそこ点数上がった後に、実際に英会話ができるように勉強していく中で、よかったものをメモしていってます。
オンライン英会話
オンライン英会話は普段インプットした内容をアウトプットする場として利用します。他の方も言われてますが、インプットなしにこれだけやっても上達しません。
オンライン英会話/イングリッシュベル英会話
発音コースからCNNコースからビジネス英会話などなどいろんなコースがあって、かつ料金体系もいろいろ選べます。僕はペースに合わせて月10回コースでDME Businessクラスというコースを選択して勉強してます。予約がとりやすいです。
DMM英会話よりちょっと高いですが先生がオフィスから接続するので回線が安定してるのとオリジナル教材がいいです。
英語発音/発声
正しい発音、発声を学ぶことでリスニング力も飛躍的にアップするそうです。自分も実際学習を始めてみて聞き取りやすくなったことを実感できています。またもちろん伝わる英語のために必須です。
http://free-academy.jp/senior/index.php?HP10
動画と絵でフォニックスの発音が学べて練習できます。学習初期にやっておくと発音の基本が身についていいと思います。
※2018/8/26追記
久しぶりに見たら500エラーになってました。。。図解と発音字の口の形の動画の組み合わせで非常にわかりやすかったので残念です。。。
最初は丁寧な解説とともに目と耳両方で口や舌の形を含めて学習できるコンテンツがおすすめです。「フォニックス 口の動き」とぐぐるといろいろ出てくるので探してみてください。下のドクターDに行く前にそういうコンテンツで基礎をやっておくとよいです。
※2018/10/21追記
上のサイトの動画がYoutubeに残ってました!
英語声プログラム® | ドクターDイングリッシュ
【おすすめ】元々はYoutubeで見つけたドクターDという方のレッスンが動画で受けられます。有料ですが教室に通ったりするよりは全然安いです。(教室だとうん十万円)
低くて渋い、アメリカ人っぽい発声法と英語独特の発声リズムを学びたくて、「動画コース」を購入して現在勉強中です。これを始めてから自分の発音の工場とリスニング力の向上を実感しています。
多聴多読
所詮テキストの英語は教科書英語、ネイティブはそんなゆっくり丁寧に話してくれません。ということで生の英語でリスニング、音読、シャドーイングができる教材として利用しています。時事ネタが読めるので内容も面白く、和訳、単語解説もついているので辞書と行ったり来たりせずとも読み進められ、かつ各記事30秒にまとめてくれているのでテンポよく勉強できます。
ビジネス英語
有名な瞬間英作文ですが、例文が割と仕事的に実用的なのが良いです。基本的な文の形がパッと思いつくようになるのでスピーキング力の向上に効きます。
2段階のスピードで意味の塊で区切って(サイトトランスレーション)英語→日本語を繰り返してくれますので勉強した後は通勤中の聞き流しにも良いです。ただCDの音声がネイティブっぽくなく聴きやすいので初学者向きっぽいです。初級レベルで、プレゼンテーションの時の会話の流れやボキャブラリーといったビジネスのシーンに合わせた学習ができます。リアルな英語リスニングはやっぱり上記のCNNがよいです。
PHP Conference 2013 に行ってきました。
http://phpcon.php.gr.jp/w/2013/
【主な収穫】
- PHP ComposerのパッケージはPackagistで。
https://packagist.org/ - 電話APIがすごい。Webサービスに付加価値を。
http://twilio.kddi-web.com/ - ログの運用にFluentdが良く使われてる。
http://codezine.jp/article/detail/6958 - Vargrant入門ガイドが電子書籍で出てる。
http://www.amazon.co.jp/dp/B00F418SQ8/ - PHP Quick profiler が便利そう。
http://www.particletree.com/features/php-quick-profiler/
http://sssslide.com/www.slideshare.net/MiuraKatsu/ss-26186401
━━━ 以下、雑なログ ━━━━━━━━━━━━━━━━━━━━━━━━━━━━
≪ミッションクリティカルなシステムの勘所≫ 広告配信システム ・リアルタイムレポート ・膨大な配信ボリューム ・無停止メンテナンス ・柔軟な改修 ・インフラ ほぼAWS 富豪構成:Multi Load Balancer、Multi-Datacenter、Multi-Server 多数のインフラを手動構築では危険 Stack Deploymentパターン CloudFormation テンプレート+CLIの利用で柔軟に 点プレから変更が少ないネットワーク部分を構築 次にCLIでネットワーク上に置く変更の激しいものを設置 ・アプリケーション 広告配信はScala:Servlet 計測部分はPHP+Gouche 管理画面はPHP+Symfony2 ‐テストコード ‐Pull Request運用 ‐CI ‐ワンクリックデプロイ ‐本番同等検証環境完備 サービス停止がまずい 配信できない 計測できない ぼっちで動く:連携システムが落ちても単体で動く。多少情報が古くても動かす。 レスポンスを速攻で返すために: レスポンスだけ先に返す ⇒ 取り込みは裏バッチで。Fluentd か所によってはPHPをやめる ⇒ PHP→Scalaで3倍速く。 富豪的に解決 ⇒ スケールアウト+スケールアップ 自動リトライ機能で運用を楽に。 ・モニタリング fluentdでログ収集 GrouthForecast:グラフ事前定義不要 Xymon 手軽に計測、手軽に関し、足らんなら作って公開 PHPはどのような部分に? どこでも。あなたがそれが良い選択だと評価できるならば。 自分たちで検討して、動かして、計測して、評価する。 ≪Composer≫ ライブラリはPackagistで探す。https://packagist.org/ VersionUP,Downも自在に。 PEARもインストールできる。 autoload.phpだけをrequireすれば二度とrequire_onceを呼ぶ必要がない。 使う必要が出てきたタイミングで必要なものをLoadしてくれる。 ライブラリごとのファイル名規則など把握する必要なし。 PSRを守っていれば自作クラスでもautoloadされる。 ≪パフォーマンスが悪い実装≫ ・DB接続のキャッシュ __construct()でオープン __destruct()でクローズ とか。 Apache child process (MINITとか)を理解して改善する。 ・大量のdefine コストが大きく、リクエストごとに実行される。 phpのextensionに記載すると改善できる。 extensionが使えないか環境なら、hidefを活用するのが良い。 ・ホスト名取得(exec) execによるプロセスの生成コストは非常に大きい Preforkの設計努力が無駄に。 PHP5.3移行でサポートされたgethostname()を使いましょう。 ・PFテストは継続的に ツールでサポートして促しましょう。 Jenkinsでパフォーマンステストを自動実行して可視化するとか。 ≪PHPからTwilioで電話を掛ける≫ ・アメリカのサービスをKDDIが展開 http://twilio.kddi-web.com/ ・電話API 電話発信、受信API(050番号取得) ダイヤル操作、録音などなど ・SMS ・VoIP連携 ・初期費用が低く、スモールスタートでも使える。 ・手順 電話番号を買う。 電話がかかってきたときにPOSTされるURLが発行される。 ・既存サービスに付加価値をつけるのがフィットしている 匿名通話 電話番号を交換せずに。 他者間通話 海外からの電話に通訳をクラウドソーシングで入れる。 電話受付 かかってきた番号を記録して、後からかけなおしますと案内 2要素認証 ID/PASSと、自分の電話にSMSでコード送信 ・利点 Webサーバ連携が簡単 1つの電話番号で同時着信可能 電話番号でユーザ識別可能 ・セキュリティ ほんとにTwillioサーバからのリクエストかを判別必要がある。 サイトのドキュメントにその説明がある。 署名の付加など。SSL証明書が必要。自己証明書ではできない。 SMSにURLなど含めるとフィルタされる可能性あり。(au) SMSで迷惑メール設定などで届かない可能性あり ≪MySQL admin≫ ・4.0から5.6への移行について Slaveから。 mysql_upgradeで。 mysqldumpで。 ・スケールアップ INSERT/DELETEが重いときはパーティショニングが有効。 パーティショニングキーを指定しないとSELECTは早くならない。 SELECT、UPDATEが重いときはインデックスやパラメータが原因 ・SQLレビュー 今よりレコード件数が増えても想定のインデックスが使われることを考える。 DEPENDENT SUBQUERY, type ALL, Using temporary table, using file sort 辺りは 件数が増えると重くなる。 テストデータの件数と分布も大事。 ・外部キー制約 嫌いな人が多い。パフォーマンスには影響ないので使いましょう。 ・遅いクエリ 相関サブクエリを使っている。 CPU使用率が跳ね上がったらこのパターンを疑う。 インデックスが足りない 重いクエリーには複合インデックス ANDの条件を順番に並べる。それにORDERBYで使われているカラムを足す。 不等号とかORを使うと、ORDERBYまで波及しない。 LIMIT使ってるならWHEREよりもORDERBYを狙ったインデックスのほうが改善できるケースもある。 パラメータ中忍具 innodb_buffer_pool_sizeはデータ格納寮歌搭載メモリーの75%くらい突っ込む。 MyISAMと同居するとメモリを取り合うので別にする。 SSDなどの場合はパラメータチューニング クエリチューニング スロークエリに乗らないクエリもいろいろすると拾える。 EXPLAINは基本。 KEYが使われてるか、key lengthが想定している長さで使われているか。 (int, datetime, varchar(32))なのにkey lengthが4とかだと、intのキーしか聞いていない。 Using file sortは意外と重い。ORDER BYをIndexを狙う。 ≪Vagrant≫ Vagrant入門ガイドが電子書籍で出た。Kindle。Gihyo Digital Pulishing. 関西PHP祭りで使った入門セッションのスライドがスライドシェアーに。 ・用語 Boxファイル ⇒ マシンイメージファイル Vagrantfile ⇒ 仮想マシン構築設定 vagrantコマンド ⇒ 全ての操作 ・PHP開発環境を構築 流れ: $ git clone repos $ vagrant up 完了 Gitで管理 Vagrantfileはプロジェクトごと ソースと一緒にGitで管理 .vagrantは.gitignoreへ vagrant up 仮想マシン構築、起動、OS起動 構築 Boxファイル名 IPアドレス(ホストPCないだけのもの) ポートフォワード プロバイダ VirtualBoxの設定 ミドルウェアインストール まずはシェルでやりましょう。 php.ini, httpd.confは用意しておいてコピー。 DB構築、データ投入 アプリケーションデプロイ ・クラウド環境を構築 AWSへも同じ環境を作成可能 ・Vagrantが見せる夢 Projectごとに独立した環境 CIサーバにも使える。 いつでも構築できる安心感。 ≪WebAPI≫ ・地図アプリAPI(ゼンリンデータコム) 混雑状況、エリアの指定人数をリアルタイム表示 ・駅データ.jp 例)鉄道アラーム:乗り過ごし防止。 ・Dropbox Dropboxへの送信をAPIで。 ・WebPay クレジットカード決済 ≪Phpstorm≫ ・最初から高機能 ・コード保管 ・静的解析が優秀 ・ライブラリや自作クラスも補完 ・Symfony2、CakeStormなどのプラグイン ・Ctrl+Shift+AでFind Action、Jump to Class/File, Go to Decralation, Recent File ・自動アップロード、branch変更時も自動で, ・Local history ・Bookmark ・リモートデバッグ ・LiveEdit ≪プロファイラ≫ ・New Relic SaaS型パフォーマンス管理ツール お手軽。有償。フリートライアル有。 ・xhprof facebookの人が作成。 処理のフローをグラフ化。 xhprof_enable()をbootstrap前に。 /tmpのボリューム インストールが面倒 詳細な情報がない。 ・PHP Quick profiler ProfilerLog ≪PHPコアから読み解く定石の嘘ホント≫ ・エラー演算子”@”のあるなし 結果⇒エラーが起きるケースで比較すると、ある場合のほうが早い。 error_reporting をクリアする処理が入るが、 エラーログの出力などの処理の分の差が出る。 ・比較演算子 == or === === のほうが倍早い。===は方が違えばその場で処理終了。 == は型変換がある。型が同じ変数の比較なら差が出ない。 ・print / echo ややechoが早い。printは戻り値がある。ので戻り値を返した後に、 変数を開放するプロセスがある。 かつ、内部でechoを使う。 参考) http://d.hatena.ne.jp/koto2/20080518/1211070116
[javascript]Javascriptを順番に動的ロード
※はてなブログ始めました。(昔のブログ: エンジニアで行きたいです。 - 楽天ブログ)
以下のようにappendChildしていくと解決するように思えるのですが、この場合非同期での読み込みになり、読み込みの順番が保証されないようです。
var ele1 = document.createElement("script"); ele1.type = "text/javascript"; ele1.src = "js/first.js"; document.body.appendChild(ele1); var ele2 = document.createElement("script"); ele2.type = "text/javascript"; ele2.src = "js/second.js"; document.body.appendChild(ele2); var ele3 = document.createElement("script"); ele3.type = "text/javascript"; ele3.src = "js/third.js"; document.body.appendChild(ele3);
これでは困るので、ネットの情報 (d:id:os0x:20080827:1219815828) を参考にチェーン式にappendChildする方法を考えてみました。
function JSSyncLoad(srces) { if (srces.length == 0) { return; } var sc = document.createElement('script'); sc.type = 'text/javascript'; sc.src = srces.shift(); // クロスブラウザ対応(IE : readyStateはファイルのキャッシュ有無で変わるようです) if (window.ActiveXObject) { sc.onreadystatechange = function() { if (sc.readyState == 'complete' || sc.readyState == 'loaded') { JSSyncLoad(srces); } }; } else { sc.onload = function(){ JSSyncLoad(srces); }; } body = document.getElementsByTagName('body')[0]; body.appendChild(sc); }
使い方は、ロードしたい順にソースパスを配列で渡すだけです。
JSSyncLoad(['js/first.js', 'js/second.js', 'js/third.js']);
以下のブラウザで動作確認しました。