関谷雅宏の作品一覧
「関谷雅宏」の「マネジメントは嫌いですけど」ほか、ユーザーレビューをお届けします！
- 作者をフォローする
- フォローすると、この作者の新刊が配信された際に、お知らせします。
作品一覧
-
3.8◆「部下やお金や人事評価の面倒なんて見たくない」けれど現実を変えたいあなたへ◆ 解決できる問題だけに対応し、まちがっていても認めない ――なぜ、そんな“マネジメント”になってしまうのか？ 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、データセンターなどを見る部署と合わせて管理する。その後、社内ネットワーク、などのインフラをすべて統括する責任者となる
ユーザーレビュー
-
-
Posted by ブクログ
ITエンジニアがマネジメントを行う立場になったときに、マネージャーという「役割」をどのように捉えて振る舞うべきか、筆者自身の体験をベースに一緒に考えさせてくれるような構成です。
文章が若干理屈っぽくとっつきにくく感じるかもしれませんが、同じようなキャリアを辿ってきた人であれば共感できる部分も多いかと思います。
個人的には、エンジニアは「目の前の課題に取り組む」役割であるのに対し、マネージャーは「未来を描いてそこに至るまでの道筋を組み立てる」ことが主な役割と考えています。
本書にも同様のことが書かれている箇所があり、自分も共感した一人です。 -
-
Posted by ブクログ
ネタバレマネジメントが苦手な自分にとって、本書は多くの気づきを与えてくれた。特に「自分が解決できる問題しか問題と捉えない」という指摘は、自分のマネジメントがうまく機能しなかった原因を見事に言語化しており、深く納得した。
また、間違いを認めないマネジメントをしないこと、分からない状態を自他ともに許容することの大切さも心に残った。間違いや未熟さをオープンにすることで、組織の健全な成長を支えられると感じた。
マネジメントとは未来を変えるための技術であり、理想から逆算して行動することが重要だという視点も新鮮だった。今後は、完璧を求めるのではなく、失敗や迷いを前提とした柔軟な姿勢でマネジメントに向き合ってい -
