技術的負債と向き合うオープンセミナー2017@岡山での発表スライドです
マネジメントの秘伝のタレ - Flicker's Style++
今回は私が今までチームマネジメントやヒューマンマネジメントを通して学んだTIPSを整理してみたいと思います。 マネジメント(≒コミュニケーション)を支える技術について都度メモして、自分への戒めとして利用していたものを箇条書きにまとめました。 ある特定の状況だけでしか適用できないものが多いですが、応用はいろいろ効くと思っています。 マネジメントの立場にこれからチャレンジしていきたい人の一助になればと思ってます。 ※自分向けのメモを整理しただけなので、一般的にこうあるべきという内容ではありません。 会議編 -全員の参加を促そう 全員の発言機会が均等になっているか常に意識しよう 一言でも意見を言うことによって、その議題を決めたという意識を持てる - 自分自身(チーム自身)で決めたという感覚に落としもう 「決められたこと」ではなく、「自分たちで決めたこと」という意識を促そう その決定が実行されなか
失敗しないプロジェクト、10人のトップPMが伝授する3つのカギ
「プロジェクト」の特徴の一つは「独自性」。プロジェクトには同じものはなく、マネジメントも過去にうまく行ったやり方が通用するかどうか分からない。だが、プロジェクトマネジャー（PM）の中にも、成功率が高い人と、そうでない人がいる。成功率が高い人はきっと、どんなプロジェクトでも成功に導くための共通的な「何か」を持っているのではないか――。 日経SYSTEMSでは2016年4月から、「プロジェクト成功/失敗の分かれ道」というインタビュー形式の記事を掲載。ベンダー各社の経験豊富なトップPMに、若手PMに伝えたい言葉として、プロジェクトマネジメントで重要視していることを語ってもらった。 マネジメントのやり方は千差万別だし、各社のトップPMが重要と考えていることは、それぞれ違うだろう。と見ていたのだが、2016年4月号から2017年1月号までのトップPM10人の話には、共通的な内容が多かった。 そのキー
システムエンジニアがやるべき顧客の期待マネジメント - Qiita
システムエンジニアが顧客に提供するものは、システムではなく、お客さまに満足してもらえるサービスだと私は思います。 http://www.slideshare.net/kawasima/kawasima さて、サービス業に学ぶと、CSのために重要なのは、事前期待マネジメントです。 http://www.insightnow.jp/article/6506 簡単にいうと、顧客の期待を少しだけ上回るように成果をもっていく。そのために、事前の期待値もコントロールしよう。というお話です。 期待が過小にならないようにマネジメントする。 言われたことだけに答えない。 特に提案案件でありがちなのは、言われたことにとりあえず答えを用意するだけで、あっぷあっぷになって、何のエッジも立たないものになりがちです。 何が一番達成したいことかをハッキリさせ、リアリティの高い解決策を考えます。 言われたことには全部答え
新米管理職向け。「組織づくり」とは6つのものをつくること。
先日、訪問した会社で「組織づくり」を手伝って欲しいと依頼された。 「組織づくり」とは何をイメージしていますか、とお伺いした所、人によって大分イメージが異なっていた。 例えば、 ・理念の話をする人 ・組織図、業務分掌や職務権限など、指揮命令系統の話をする人 ・教育や育成の話をする人 ・目標や評価の話をする人 など、バラバラであった。 もちろんこれらは間違いではなく、大事な話ばかりである。だが、これらはすベて断片的な情報だ。 「組織づくり」を包括的に教えて貰える機会は、人にもよるがそれほど多くないため、こうなってしまうのだろう。新米の管理職が悩むわけだ。 必要なのは「組織として機能するために、最低限、何が必要か」を見極めることである。逆に言えば最低限、すなわち下の6つのうちどれがかけていても、それは組織として不十分である。 1.目標をつくる ピーター・ドラッカーは 「組織は目的ではなく手段」
NAKAHARA-LAB.NET 東京大学 中原淳研究室 - 大人の学びを科学する: 上司は「部下のネガティブ感情」をいかにマネジメントすればいいのか？
中原淳（東京大学准教授）のブログです。経営学習論、人的資源開発論。「大人の学びを科学する」をテーマに、「企業・組織における人の学習・成長・コミュニケーション」を研究しています。 昨日は大学院中原ゼミ、2016年度のスタートでした。 僕のゼミでは、毎回のごとく大学院生の皆さんに研究の進捗報告を伺うほか、英語の文献（実証研究）を読むことにしています。昨日の英語文献は、伊勢坊綾・ゼミ長によるLittle and Williams(2016)の研究報告でした（お疲れ様です！）。 Little and Williams(2016)は リーダーは「部下の感情」をいかにマネジメントするか？ ということをテーマにした論文です。The leadership quarterly. Vol.27に所収されている論文になりますね。 ▼ 伊勢坊さんの報告を引用しつつ、同論文の要旨をかいつまんで説明させていただくと、
実際に読んで選んだマネジャーのための100冊 - Kentaro Kuribayashi's blog
このエントリでは、僕がこの2年弱で読んだ約300冊のマネジメント関連本から、100冊を選んでカテゴリ別に紹介します。 背景 2014年8月に、それまで前々職から現職に至るまでいちエンジニアとしての経験しかなかったところから、総勢70人を越えるエンジニア組織のマネジャーになりました(参照: GMOペパボ株式会社の技術責任者に就任いたしました)。 僕は、決して地頭がいいわけでもなければ、コミュニケーション力に長けているわけでもなく、他人以上に努力をして初めて人並みに近づけるかもしれないというぐらいの人間です。それに加えて、冒頭に書いた通り、エンジニアとしては多少の経験は積んだものの、マネジメントについては完全に門外漢。経験に頼るわけにもいきません。諸先輩方にOJTしてもらいつつ身に付けるにも、既にマネジメントの業務は始まっているわけです。 「さて、どうしよう？」と考えた時、まずはとにかくマネジ
R&Dはマネジメントできるか - yoshidashingo
どうも、セクションナインの 吉田真吾（@yoshidashingo）です。 昔FeBeで買ったドラッカーのマネジメントを聞き直して、1963年HBRに寄稿された「R&Dはなぜマネジメントできないか」を聞いてグッとくるところがあったので【自分としてR&Dに対して思うこと】をまとめておこうと思います。 IT企業のR&D部門はなにをやっているか 大手のベンダーから中小企業のWeb企業まで「R&D」が冠につく部門、職業あるいはミッションを与えられている人は相当多いと思います。なぜならこのロールに期待されていることが、次世代の企業のメシのタネを担っているからです。ただし「次世代の」というのがいつ頃を指し示すかによってこのロールに期待される研究内容に個々の大きな違いがあるのが実情だと思います。 大手ベンダーの製品に関するR&D部門であれば5〜10年後に市場に投入されるプロダクトの開発を行ってることもあ
【資料公開】強いチームの作り方 | Ryuzee.com
2015年11月10日に某社の社内勉強会で、「強いチームの作り方」というテーマで話をしたのでその際の資料を公開しておきます。 内容自体は、WEB+DB PRESS 83号に書いた内容なので興味があればそちらを参照ください。 最近DevOpsの文脈ですぐに「インフラ自動化しないといけない」とか「ツール使って効率化」みたいな話を頻繁に聞きます。 が、端的にいえば、「実際のところ、ソフトウェア開発上の問題の多くは、技術的というより社会学的なものである」というデマルコの一節の通りであり、 DevOpsの本質もツールではなく、CLAMS(Culture、Lean、Automation、Measurement、Sharing)であって、土台となるのはやはり組織やチームの文化になります。 一度自分たちのチームや組織について考えてみるとよいと思います。
Tech Lead（TL/テックリード）の役割 - サンフランシスコではたらくソフトウェアエンジニア - higepon blog
Tech Lead（TL/テックリード）の役割。聞きなれない名前かもしれない。リードプログラマやテクニカルリードと呼ばれることも。過去にいくつものチーム（最大で10人以上）の Tech Lead をやってきた自分の経験を踏まえて書いてみる。 Tech Lead の主な役割 Tech Lead はエンジニア班長と言いかえるとイメージがわきやすいかもしれない 顧客に提供したい価値（プロダクトゴール）を正しく理解する エンジニアチームの生産性を可能な限り最大化。プロダクトマネージャ・デザイナと顧客に価値を提供する Product の Launch に責任を持つ Product の Launch 後のメンテナンスに責任を持つ エンジニアを過負荷から守る ときにはマネージャ、プロダクトマネージャのアイデア、スケジュールに NO を言う。代替案を提示する チーム内のテクニカルデザイン、採用技術などに責
開発組織のマネジメント
フロントエンドのパラダイムを参考にバックエンド開発を再考する / TypeScript による GraphQL バックエンド開発
KAIZEN platform Inc. の開発マネジメント
フロントエンドのパラダイムを参考にバックエンド開発を再考する / TypeScript による GraphQL バックエンド開発
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
【資料公開】強いチームの作り方(デブサミ2016版)