- 追加された行はこの色です。
- 削除された行はこの色です。
*概要 [#geb837ed]
-技術マネジメント、経営マネジメントの方法
-組織とは同一の目標を共有する集団であり、その環境を整えるのがマネジメント
-人の心に火をつけ、見つめて得意分野を把握し、チーム全体の失敗を許容する安全と生産性を確保し、リスクを取れるような働く環境を整備し、チーム全体として結果を継続的に出し続ける
*下位ページ [#s05de21b]
-[[共同作業]]
-[[プロジェクト管理ツール]]
-[[ワークショップ]]
*目次 [#ofb70ca5]
#contents
*分類 [#e7346681]
**人の心に火をつける [#p2499a8d]
-モチベーティングする
--金・出世
--社会とのつながり
-モチベーションをそぐ要素を排除する
--妻が英語喋れないし→妻にも英会話教室に通わせる福利厚生を作るなど
**信用を得る [#xfc3f49c]
-真摯な態度を保つ
--一人の人として向き合う
--意見を尊重する
--マネジメントがうまく言っていない場合、きちんと口に出す。あるいは出せる環境を作る。
--具体的に実行可能かつfeasibleなアドバイスを言う。
---「言いたいこと言うだけの無責任なアドバイス」はダメ。自分の意思だけ伝えて、「ほらアドバイスしたのにー」だけは言ってはいかん
--常に「僕はあなたをどうやったら助けられますか？」という形で自走する力を育む
---「このように助けて欲しい」と言われたら、必ずそれを達成する。実行を伴う行動は信頼を生む。
-チームメンバ個人の興味に関心を向ける
--能力向上とキャリアに注意する
---チームの成果はチームの興味であるが、個人の興味は昇給や解雇なども含まれる。それぞれの人生は大きな要因。
---特にキャリアに関しては、プロジェクトのリーダー経験など、今後のキャリアにポジティブな役割を積極的に与える。
--健康
--趣味
--家族
-チームメンバからの意見を尊重する
--極力実行に移す
---意見を言うことが、実際的にチームを動かしているという感覚に繋がると意識させる
--称賛する
---意見を言うことが、チームにポジティブな効果があることを意識させる
--自らへの批判、改善方法の具体的方法を求める
-チームへの貢献を正しく測り、それを表明する
--褒められて悲しくなる人はいない。貢献に比例した称賛を正しく送る。
--同じ報酬を受け取っているメンバの間の能力を定期的にキャリブレーションする
--タスクの完遂に対して、労い感謝の意を正しく表す。
-社会的に真人間であると思われるような行動を心がけ得る
--傾聴
--言葉と態度に気をつける
---程度の副詞の程度に注意する。「絶対」とかなるべく言わない。
---しかめっ面など、不快に思わせるような行動はしない。
--定刻を守る
-自らが仕事内容に精通すること
--完全に無知な人が上に立っていると、現場の人はげんなりする
--マネージャーは単なるリーダーではなく、チームのいちメンバーであるということを伝える
-忠誠度
--やっと育ったと思った人間にすぐ辞められても困る。ずっといたいと思う環境を作ることが大切
**得意分野を把握する [#x85e0ae7]
-苦手なもので戦ってはいけないし戦わせてもいけない
--得意分野をきちんと把握すること。
-働きアリは2割が怠けてる、のではなく予備の交代要員としてスタンバイしている
-見つめるためには、真摯な態度で人と向き合い続け、信頼を得る必要がある。
*有能さ [#ob74d17b]
-''他人のリスクを把握すること''。''他人を尊敬すること''。
**チーム全体の安全を確保 [#f89a4720]
-''他人のリスクを把握し、尊敬すること''。
--これができないやつとは仕事したくない
--プッシュしない。他人の専門はまかせる。
--他人の専門をリスペクトする。プッシュしない。担当亮やと専門はまかせる。
-穴だらけの知識の中でも、チームで価値を生み出せること
--穴を高速に必要な部分だけ埋める、穴を避けて語る、穴を高速に埋められる人にお願いする人脈
--部下のモチベーションを上げること
--能力だけでなく、自分がいるコミュニティに貢献すること。
--穴を高速に必要な部分だけ埋める
--穴を避けて語る
--穴を高速に埋められる人にお願いする人脈を作る
-オーバヘッド
--ルール決めるとコストになるので，各自の裁量で。
-極力各自の裁量で、ルールを最低限に
--自由と責任の文化を大事にする。
--ルール決めるとコストになる、オーバヘッドが生じる、イノベーティブでなくなる。
--失敗に厳しくしすぎるルールを入れない
---失敗した原因に関する詳細なレポートを求められると全部成功したことになる
-技術的難度と開発コストを見積もれることはエキスパートの条件
-モラルの形成
--セクハラめいたことをスタッフや学生がやりだしたら、即座に100%否定して不快感を示す
--大人の対応しましょうねとか被害者に言うというは一番ダメ
-ミスをチーム全体の課題とする
--失敗は自責の念を生むので、よほどならスタバのコーヒーくらい奢らせたほうが精神衛生上良い可能性がある
*下位ページ [#s05de21b]
-[[共同作業]]
-[[プロジェクト管理ツール]]
-[[ワークショップ]]
*目的意識 [#geff43e2]
-組織は目的を共有する人の集まりである。
-必要な目的設定を見誤らないこと
-課題解決への熱意のなさに「いらっ」とくる
--「人工知能」という単語を無邪気に使うかどうかが、信用できる人かどうかの分かれ目みたいなところある。
*得意分野 [#r89a0f32]
-[[「その人にとっての天職とは、その仕事を通して、その人に多くの気づきを与えてくれるものである」>https://www.kayac.com/news/2016/11/yanasawa_blog_vol18]]
*モラル [#x6af1531]
-セクハラめいたことをスタッフや学生がやりだしたら、即座に100%否定して不快感を示す
--大人の対応しましょうねとか被害者に言うというは一番ダメ
-失敗した原因に関する詳細なレポートを求められると全部成功したことになるのはあまりにも有名。
**働く環境の維持 [#a2d0c17a]
***技術維持 [#bc12d4d8]
-開発は技術力をすり減らす
*技術維持 [#bc12d4d8]
-技術向上し続けることが大事
-技術向上し続ける環境づくりを心がける
--上司「刃を研ぐのは業務外だから時間外にやれ」
--経理「砥石を買う予算なんてありません、自費で用意してください」
--監査「会社の備品を私物で整備することは認めない」
-そうじゃないとウェブマンみたいに買い叩かれることになる
-どれくらいのバランスがよいのか？
*部下の指導 [#j16c7720]
-「言いたいこと言うだけの無責任なアドバイス」はダメ
--自分の意思だけ伝えて、「ほらアドバイスしたのにー」だけは言ってはいかんのだよな。
-常に「僕はあなたをどうやったら助けられますか？」という形で自走する力を育む
***維持コストの継続性 [#k0b6bbf0]
-維持コストを見積もり、未来の維持コストを見据えて適切な技術的対策を講じる
--ユーザが増えている場合、エラーは必ず増大する。
--人間の努力や注意力に依存したシステムは必ず破綻する
*システムは自動的に回らなければならない [#n9f298b2]
-人間の努力や注意力に依存したシステムは必ず破綻する
-人間がミスしないことを前提にした運用は必ず破綻する
*部下への仕事の振り方 [#ldd1aa55]
-「まずスケッチを描きます、つぎに奴隷をみつけます、そしてうなぎを食べさせ、レッドブルを与えます」
-「自分で何とかしろ」ではなく、「どうしたら助けられる？」と聞く。そして実現可能ならば必ず！それを行い、人を助ける。
*納期 [#g9625597]
-[[エンジニアは納期を守らない>https://speakerdeck.com/ykmc09/enziniagana-qi-woshou-reteinaitositara-sokonihaitutaihe-gaarufalsedarou-aruihaitutaihe-ganaifalsedarou]]
-不確かな要素が多いので、正確な見積ができない
-エンジニアリングは不確かな要素が多いので、正確な見積ができない
--[[エンジニアは納期を守らない>https://speakerdeck.com/ykmc09/enziniagana-qi-woshou-reteinaitositara-sokonihaitutaihe-gaarufalsedarou-aruihaitutaihe-ganaifalsedarou]]
--新しい技術が必要なことがある
--新しい技術を取り入れないとエンジニアのモチベーションが保てない
--もちろん古い技術を使えば早く実装できるが、新しい技術を取り入れていかないと、時代に取り残される
--新しい技術を取り入れないとエンジニアのモチベーションが保てない
--見積もり段階で決まっていない仕様がある（60-160%の誤差がある→3倍の時間で見積もるということになる）
-正確に見積もるために
--開発スピードを計測するすべを持つ
-見積に失敗したら
--めちゃめちゃ強い火消し屋を投入する
--それが無理なら、開発範囲・費用・期間・品質のどれかを犠牲にする
---犠牲にしないと品質が落ちるので、次の開発でバッファになる
--人数を追加すると''絶対遅れる''
--人数を追加すると''絶対遅れる''。
*人員配置 [#w4d75b3e]
-技術に関してスペシャリストを集める際にバックグラウンドが近い人が最低2人は組めた方がいい。
--reviewがお互いにできる
--discussionが深くならないとそもそも働いてる側は楽しくない
--知的好奇心を満たせるパートナーがいないと辛い
-適任者を見出す
--スキルを把握し、適切に配置し、タスク達成に伴うスキルアップにも注意を払う
*チームワーク [#k538f8ca]
-他人をリスペクトする
--デザイナーがいるなら、どうすべきと研究者コミュニティの議論をする必要はないのだ！
--ディスらない。直接言う。
--美しくないコードをuncodeとかクソースなどと呼ぶ人もいる
---これらの言葉は開発者を傷つけるので、最近アプレッソでは、あまり美しくないコードを「ひよコード」、美しくない箇所は「ここがピヨピヨしてる」と表現するようにしています。未熟だけど伸び代はあることを意味しています。
*戦略性 [#l3a638ac]
-合目的的かつ網羅的に行う必要がある
--世界観、ビジョン、コンセプト、テクノロジーのつながりはロジカルに戦略設定する必要（信念、組織への存在理由、目標、手段、短期的ゴール）
---「それをやりたいと言っているのになぜそれができない方法を選択した？」
---「何をするかはどうでもよくてその方法を使いたかっただけちゃうんか？」
-程度の副詞の程度に注意する。
--絶対とかなるべく言わない。
-マネジメントがうまく言っていない場合、きちんと口に出す。きちんと皆で仕事をする。
-戦略に関係ないことを断ったり、優先順位を下げる判断を行う必要がある。
--逆に、他のチームの戦略と競合して優先順位が異なる場合の調整を行う必要がある
-手戻りと開発速度の関係
--失敗時のリスクを考えて、仕事のクオリティの基準を適切に設定する
--手戻りは必要以上に恐れると開発スピードが劇的に落ちるけど、チームのモチベーションを落とす手戻りは極力避けたい（改良のための手戻りならまだしも安全性に問題があるから手戻りでは辛い）
*合目的的であれ [#l3a638ac]
階層として上から順に、フィロソフィー（こうあるべき）、ビジョン（こうしたい）、コンセプト（どう実現するか）、そしてテクノロジーがあると思うんだけど、テクノロジーの制約のためか分からないけど、そのビジョンには届かないとか違う方向を向いているコンセプトをたまに見て解せぬ気持ちになる
「今回採用した方法に限界があってビジョンにはつながらないことは承知の上で今できることをやることに意味がある」という考えなのかもしれないけど、「何も問題がなければ今回採用した方法を拡張していけばそれがそのままビジョンの実現につながる」ものをコンセプトとするべきなんじゃないのかなって
例えば「空を飛びたい」というときに超音波浮揚の実験とかするのは違うだろうっていう話（波長より小さいものしか浮かない）
デザイン思考disじゃなくて（むしろ階層分けとして整理できていいなと思っていて）「それをやりたいと言っているのになぜそれができない方法を選択した？」「何をするかはどうでもよくてその方法を使いたかっただけちゃうんか？」的なのに対する感想
技術も含め現状利用できる/近い将来手に入るリソースへの洞察が無いとコンセプトへの着地に失敗する、もしくはありきたりなコンセプトになってしまう。そんな例をたくさん見てきました。だからデザイン思考さえあれば技術を知らなくても良いというのは大間違い。何故なら技術を知るとは選択肢を増やすということに他ならないから。一方で「まずこの技術を使って」というのも他のより良い選択肢を無視するという意味でもったいない。技術を知った上で一旦忘れて俯瞰することが大切。必殺技だけで格闘技は勝てない。
-戦略のためには他のチームとのコラボレーションを適切に行うイノベーティブな考え方が必要
*安全は事前計画する必要 [#wd694143]
-安全をあとから考えるとメカ、電気、ソフトの作り直しが生じて結局手戻りしちゃうんですよ。それで年単位で浪費してしまう。可能なら最初から安全対応しておいた方がよいのです。
できますね。医療福祉系は少数生産がほとんどなわりに安全の比重が高いので、品質保証も通常の製造業に比べてしっかりやらざるを得ないので興味をもってくれる人が多いかも。
手戻りは必要以上に恐れると開発スピードが劇的に落ちるけど、チームのモチベーションを落とす手戻りは極力避けたいところ。改良のための手戻りならまだしも安全性に問題があるから手戻りって辛すぎる。
*ロイアリティ [#t9614a8e]
-忠誠度
--やっと育ったと思った人間にすぐ辞められても困る、
*ミスに対する対応 [#dc95dd6a]
-新卒の頃、あらゆる迷惑をかけ先輩たちの仕事を増やした自覚があるんだけど、いつも「いいよ！大丈夫だよ」と笑って引き受けてくれる先輩より、「このミスはスタバのラテでしか許されないよ」と小さい見返りを要求してくる先輩の方が、気が楽でお願いしやすかったんだよね
*タスク配備 [#a842e03d]
-タスク配置時にはその背景をちゃんと説明する。
--重要性、現在のリソース、任せる理由など
--役割の範囲を示し、標準的なパフォーマンスと目標を設定する。
--期待される成果については明確に伝える。完了の定義はメンバに任せる。
-担当者との密な連絡
--最初に同意したチェックポイントを確認
*マネージャの役割 [#k8f619de]
-そもそも組織にとって重要？
--社内アンケート・インタビューから、パフォと幸福度に寄与しているかを判定スべき
-資質
--良いコーチである
--仕事だけではなく健康など包括的環境を構築
--結果を重視
--細かい管理はしない
--効率的コミュニケーション
--キャリア開発をサポート
--ビジョン・戦略をチームと教育
--専門知識の保有
--部門間コラボ
--決断力
-創造性
--新しいアイデアの創出する力
-イノベーション
--生み出し、受け入れ、実践するを試して練り直し、最終的に有益なものにしていくプロセス
-チームとして高い生産性を保つ
-チームの心理的安全性
--メンバーが互いに信頼し合える
--チーム内で質問できる
--リスクをとれる
--失敗が受け入れられる
-対人関係の正常性
-スキルの適切さ
-チームの目的の明確さ
*マネージャの役割 [#k8f619de]
-ワークグループとチームは違う
--ワークグループは個人戦、依存関係が少ない
--チームは3-50人のグループ（中央9人）程度くらいの規模で、相互依存性が強い
-役割ごとの効果的なチームの差異
--マネージャ: 売上高・サービスの立ち上げなどの結果
--チームメンバ: チーム内文化と風土
--チームリーダ: 売上などへの当事者意識
-チームで必要な資質
--チームの内部で異議を唱えることに不安を感じない（心理的安全性）
--課題・障壁のクリアが得意であると自信がある
---他のメンバが、高いクオリティで時間内に仕事してくれると信頼している
--具体的で取り組みがいがあり、なおかつ達成可能な、短期的・長期的目標がある
--仕事に個々人が自分にとって意味があると感じている
--仕事が世界にとって意義があると感じている
--他人の抱える問題への関心（自分またはチームの仕事がユーザーや顧客、組織に与える影響をよく考える）
-チームの生産性で必要でない資質
--場所
--合意による意思決定
--外向性
--チームメンバー個人の能力
--仕事時間
--年功序列
--チーム規模（重要という話もある）
-チームの心理的安全性を高めるには
-実際に何すれば良いの？
--積極的な姿勢を示す
--目の前の会話に集中する
--学ぼうという意欲を持って質問をする
--対話的なコミュニケーションを心がける
--返答するときは言葉で返す 「なるほど。詳しく説明してもらえますか？」
--相手の発言内容を要約する 「あなたがおっしゃったのは…ということですね？」
--話を聞くときは少し体を乗り出すようにする。会話中や会議では、話を聞いていることを示すためにうなずく
--相手と目を合わせる
--責めを負わせるような言い方はしない
--- 「なぜそのようなことをしたのですか？」はダメ
--- 「この作業をよりスムーズに進めるためにできることを考えましょう」「次に備えた行動計画を立てるため、皆で協力しましょう」
--否定的な表情（苦い顔や不愉快そうな顔）を浮かべない
-マネージャとして行うべき事項
--自分の仕事の進め方や好みをチームメンバーに伝え、チームメンバーにも同じように自身のやり方を皆に伝えるよう促す
--1 対 1 の定例外の会話、意見交換、キャリアに関するコーチングのための時間を作る
--定例外の会議を開く場合は、目的を明確に伝える
--貢献に対して感謝の意を示す
--他のメンバーについて否定的な言葉を口にしたときは間に入る
--全員に顔を向ける
--適度にチームメンバーと仕事以外の話をする
--チームメンバーに意見やフィードバックを求める
--人の話を妨げない。 人の話を妨げようとする人がいたら間に入り、元の発言者に話を続けさせる。
--意思決定の背後にある根拠を説明する
--他のチームメンバーの貢献を認める（例: チームメンバーが成功や意思決定に貢献した場合は、その事実に言及する）
--自信や信念を持つ（強情にならない範囲で）
--議論をコントロールする（雑談を認めない、意見の対立が個人間の対立に発展しないように）
--明瞭に発声する
--チームの成果を上級役員に伝える、チームメンバーの功績を認める
--自分の意見に対しての反論したり異論を唱えるよう促す
--自分の弱みを見せる
--失敗に関する自分の個人的な考え方を伝える
--リスクを取るようチームメンバーに促し、自分の仕事でも実践してみせる
-危険サイン
--建設的なフィードバックを求めたり与えたりすることに不安がある
--人と違う提案をしたりごく簡単な質問をしたりすることを躊躇する
--プロジェクトの優先順位や進捗状況を十分に把握できていない
--責任分担が曖昧で、作業や問題の担当者が明確でない
--作業を引き受けたチームメンバーは、約束どおり作業してくれますか？
--チームメンバーは、作業が遅れる場合に前もって連絡してくれますか？その作業に責任を負ってくれますか？
仕事とは成長や進歩とは無関係なことであると捉えている
目標が多すぎて、意義のある形での能力開発が阻害されている
-チームメンバへの定期的な確認
--他のメンバーの前で躊躇なくブレインストーミングを行えていますか？
--失敗するリスクをとれると感じていますか？それとも失敗によってメンバーから拒絶されることを恐れていますか？
--個人として、仕事人として、達成感の得られる仕事を与えられていますか？
--スキルや能力だけでなく、意欲に応じた仕事を与えられていますか？
--自分の仕事を「良い方向へ変化を生み出す機会」と捉えていますか？
--自分の仕事を「より高い目標を達成するために重要な作業」と感じていますか？
--現在のチームプロセスは、チームの幸福感あるいは疲弊感にどう影響していますか？
--休暇 - チームメンバーが勧めていたレストランはどうでしたか。[配慮を示す]
--プロジェクト X のインパクトに関する責任者会議で高評価だったことを伝える。[全体像を示す]
--最近の状況はどうですか。[出席・所在を確認する / 近況を確認する]
--何か困っていることなどありませんか。[障壁を取り除く]
--今後の休みの予定は。[勤怠管理]
--他に話したいことはありますか。[話を広げる]
--マネージャーとして、みんなのためにこうしてほしいという要望などがありますか。[自分が役に立っているか確認]
--先週したこと: プロジェクト Y の更新
--今週の予定: プロジェクト X v2.0 の設計ドキュメントを提出
--プロジェクト Y のサブプロジェクトで遅れが出るかもしれないことを報告
--先週の 1 対 1 の ABC 会議に関するフォローアップ
--チーム C とのプロジェクトへの関心について話し合う
-OKR (Objectives and Key Results)
--定量的目標と評価指標のセットのこと。
--設定の目的は、目標に向かうモチベと締め切り効果
--3-5個の目標と、それぞれ3個の評価指標
--評価指標は結果を規定する（行動を規定しない。ちゃんと相談する、みたいなのはダメ）
--評価指標は、入手可能で、信頼性があり、容易に見つけられるものである
--60-70%の達成率を目標とする
--現実的である（マネージャがあまりに個人目標を高く設定すると、死地に社員を追いやっているダメダメマネージャのように感じさせられるので）
--階層的（部門・チーム・個人）で、下位は上位に与するように
![[PukiWiki]](image/pukiwiki.png "[PukiWiki]")
