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