あらすじ
◆「部下やお金や人事評価の面倒なんて見たくない」けれど現実を変えたいあなたへ◆
解決できる問題だけに対応し、まちがっていても認めない
――なぜ、そんな“マネジメント”になってしまうのか？
5名ほどの小さなチームから500名を超える大きな組織までを見てきた著者が、「人を動かす」では得られない答えの探し方を教えます。
・アウトプットは60％の力でおこなう理由
・初心者を教育する仕組みをどう作るか
・技術者の貢献を評価してもらうには
・維持・メンテナンスの予算がとりにくいのはなぜか
「部下やお金や人事評価の面倒なんて見たくない」
けれど現実を変えたいあなたへ。
■こんな方におすすめ
・技術者／エンジニアのマネジメントに携わる方（特に技術者／エンジニアからマネージャーになる方）
■目次
●1章 マネジメントできるのは未来だけ
・1.1 解決病にかかってしまう問題
・1.2 未来から逆算して考える
・1.3 マネジメントの目的は「現実に変化を起こすこと」
●2章 理想を描いて余裕をつくる
・2.1 何が問題か？ 何を目指すべきか？
・2.2 アウトプットは「60％」の力でおこなうこととする
・2.3 技術の底上げと訓練に「20％」を使用する
・2.4 残りの「20％」の使い方
・2.5 マネージャーになっても技術は追いかける
●3章 部下は思いどおりに動いてくれない
・3.1 正解はない、だから試行錯誤する
・3.2 好かれていようが、嫌われていようが、部下は意地悪なテストをしてくるものだ
・3.3 自分の足りないところは公開したほうが解決しやすい
・3.4. 犬はワンと鳴き、猫はニャンと鳴くのだから、逆はやめて
・3.5 信用も信頼も、するのは相手ではないだろう
・3.6 属人性も人材の流失もリスクの1つにすぎない
・3.7 組織で生かしにくい技術者の3つのタイプ
●4章 学べる仕組みを実装する
・4.1 人を育成する悲しくも唯一の方法
・4.2 教え合ってもらう
・4.3 「問題を解く」のではなく「問題を作る」
・4.4 科学の力を利用できるようにする
・4.5 妄想するな、計測しろ
●5章 キャリアパスから組織を考える
・5.1 技術者の貢献を評価してもらうのは難しい
・5.2 報酬額は経済が決めている
・5.3 ルール違反をせずに、自分が正当だと考える報酬へ近づけるには
・5.4 成長という報酬
・5.5 「育成型のクラブ」をめざした理由
・5.6 「人材育成力を強みにする」という考え方の是非
・5.7 育成は人のためならず
●6章 組織の中のお金の理屈
・6.1 プロジェクト予算を疑う
・6.2 維持する予算は、新しく何かを作るときよりとりにくい
・6.3 人事予算をどう考えるか
・6.4 予算の仕組みを知っておく
・6.5 お金をかければ良くなるなら、かけたほうがいい
●7章 完成したマネジメントなんてない
・7.1 スクラップ＆ビルドは夢
・7.2 組織に完成はない
・7.3 組織の文化が変化の方向を決める
●8章 正解のない世界でマネジメントをしていくには
・8.1 世界を理解するためには、感情が信じたいことを否定する
・8.2 現時点でのまちがいを許容する
・8.3 仕事で任せられた役割や成果は自分そのものではない
・8.4 変化を阻む「見えないバリア」を取り除く
・8.5 目的のために手段を選ばない
■著者プロフィール
関谷雅宏（せきや まさひろ）：1962年生まれ。金融企業に新人として入社。お札を数える日々に耐えきれず退職。何かを作り上げる仕事を求めていくつかの職を転々としたのち、同僚に誘われ起業。15年間、役員として勤める。某通信会社へ40歳を過ぎてから転職。社内情報処理システムの基盤部署へ配属となる。「データベースの事故が事業のリスクになる」という上層部の判断から、データベースをはじめとして、ミドルウェアを社員でサポートできる部門を新規設立。経験のない社員に1から学習してもらい、実践を通じてエンジニアとして育てることを中心に、他部門からの信頼を得ることに成功する。ミドルウェア中心の部門を確立させたのち、サーバ、OS、データセンターなどを見る部署と合わせて管理する。その後、社内ネットワーク、などのインフラをすべて統括する責任者となる
感情タグBEST3
Posted by ブクログ
ITエンジニアがマネジメントを行う立場になったときに、マネージャーという「役割」をどのように捉えて振る舞うべきか、筆者自身の体験をベースに一緒に考えさせてくれるような構成です。
文章が若干理屈っぽくとっつきにくく感じるかもしれませんが、同じようなキャリアを辿ってきた人であれば共感できる部分も多いかと思います。
個人的には、エンジニアは「目の前の課題に取り組む」役割であるのに対し、マネージャーは「未来を描いてそこに至るまでの道筋を組み立てる」ことが主な役割と考えています。
本書にも同様のことが書かれている箇所があり、自分も共感した一人です。
Posted by ブクログ
「過去と他人は変えられないが、未来と自分は変えられる。」
前職で習ったことですが、マネジメントも同じ。あるべき未来を考えて、そこから逆算して考える。
第2章のColumn、第6章の予算の話は、普段自分はあまり意識しない部分なので参考になった。
Posted by ブクログ
マネジメントが苦手な自分にとって、本書は多くの気づきを与えてくれた。特に「自分が解決できる問題しか問題と捉えない」という指摘は、自分のマネジメントがうまく機能しなかった原因を見事に言語化しており、深く納得した。
また、間違いを認めないマネジメントをしないこと、分からない状態を自他ともに許容することの大切さも心に残った。間違いや未熟さをオープンにすることで、組織の健全な成長を支えられると感じた。
マネジメントとは未来を変えるための技術であり、理想から逆算して行動することが重要だという視点も新鮮だった。今後は、完璧を求めるのではなく、失敗や迷いを前提とした柔軟な姿勢でマネジメントに向き合っていきたい。
Posted by ブクログ
ほぼほぼ現場で聞く内容を実体験を基にして書いてある。
しかしながら良く聞くけど実践するのはなぜか難しいマネジメント。
そうだよね、と納得するけどそこを上手くやる、100%成功させるような方法手法はやはり無いんだよなと思った。
Posted by ブクログ
少し読みづらさはありましたが、全体的には納得感のある本でした。
事例は「社内インフラ」「技術サポート」の領域のものが多いです。したがって、「R&D」領域とは相容れない部分もある、との感覚はある。
ただ、全体的に「わかりみ」「ささる洞察」が多いと思った。
次は蛍光ペンでマークしながら読んでみよう。
Posted by ブクログ
最初は読みにくいなーと思いつつもだんだん慣れていって面白くなり読み切った。130ページ程度で比較的短時間で読めるのも良いところ。参考にできるところがあれば良いかな、くらいで気楽に読める本。
ソフトウェア開発技術者の著者の経験が綴られているが、ソフトウェア開発でない技術者が読んでも分かる内容だと思う。
読んでこれからこうしようと思ったことは、
・自分の仕事をチームメンバーに共有し属人化しないようにする。自分1人で問題解決しようとしない(してしまうとその人の領域という印象を与えてしまう)
・トラブル解決は成果としてインパクトが大きく周囲から見られる(ので少し業務の優先度を上げる)
・お金の報酬が限られているので、自分の成長を報酬と考える(成長させたいことを見つける)
Posted by ブクログ
ITエンジニアから経営マネジメントまで行った著者の経験がまとめられた本。
ITの詳細な話はわからないが、同じ研究開発に身を置く立場として、どう人をマネジメントしていけばよいか、興味深く読めました。
特に最終章の「正解のない世界でマネジメントしていくには」にある、感情に左右されない、現時点での間違いを許容する、マネジメントの役割、成果は自分そのものではない、は自分にとっての目指すべき、内容でした。
Posted by ブクログ
前半よりも第5章以降の後半が良かった。
全体としては相殺して★3つにしておく。
自分のコンテキストとはちょっと違うというか、そのまま当てはめられない部分もあったけど考え方は概ね同意できる。
資金繰りと信用の話は 独立系の企業にいたらきっと切実なのだと思う。今の自分は良くも悪くも親会社があることでそのあたりの意識が薄い自覚がある。
