1 on 1 で 何を話すのか？ マネージャ/ソフトウェアエンジニアの立場から - サンフランシスコではたらくソフトウェアエンジニア - higepon blog
1 on 1 (ワンオンワン) とは1対1のミーティングの事。ここでは毎週もしくは隔週で行われるマネージャとその部下(direct reports)であるソフトウェアエンジニアの 1 on 1 に焦点をあてる。よく 1 on 1 で何を話したらよいか分からない。話題がない。と相談されるので僕の思うところをまとめてみる。 僕はマネージャもソフトウェアエンジニアのどちらも経験があるので両側からの視点を提供できると思う。 マネージャ編 マネージャは 1 on 1 を部下のために開催しなければならない。自分のための時間ではないことを肝に銘じよう。部下には話したいことを何でも話してもらう。事前に「1 on 1 は君のための時間だよ」と説明しておこう。 1 on 1 が始まったら「何か話したいこと、気になることある？」と問いかけよう。焦ってはいけない。じっくりと待ってみよう。 たとえマネージャとしてプ
徹底討論！社内の技術情報共有ツール - GitHub Wiki, Qiita:Team, esa.io （特別編：トップエンジニアたちの夜 『シドニアの騎士』観賞会＆座談会 ～Part4～） | Tokyo Otaku Mode Blog
こんにちは、ライターの岡田大です。 お待たせしました。特別編「トップエンジニアたちの夜」のPart4をお届けします。 ※Part1～3未読の方＆内容を忘れてしまった方は、Part1・Part2・Part3を一読してからお楽しみください！ リモートワークを成功させるために必要なモノとコトについては前回お伝えした通り。ルールとマナーなくして成り立たないことは言うまでもなく、そのことをメンバー（とくに新人）に徹底させるために、リモートワークを積極的に導入している伊藤氏は、ガイドラインをドキュメント化することにより意識の共有を図っているという。その際に活用しているのが、技術情報共有サービスQiita:Teamである。堀木氏の口から「Qiita:Team」という言葉が発せられるやいなや、参加メンバー一同がこれに食いつき、座談会はチーム内における情報共有に関する話題で持ち切りになっていった……。なお、
Martin Fowler's Bliki in Japanese - 朝会のパターン：立ってるだけじゃないよ
朝会（デイリー・スタンドアップ・ミーティング、デイリー・スクラム、デイリー・ハドル*1、朝のロールコール*2）を説明するのは簡単だ。チーム全員が毎日顔を合わせ、現在の状況を迅速に確認しあう。立ってやるのはミーティングの時間を短くするためだ。以上。 でもこれだけじゃあ、「良い朝会」と「悪い朝会」の微妙な違いは分からないだろう。 朝会の定義は非常に簡単なものなのに、 うまくいっていない朝会があって私はとても驚いた。 すぐに原因は分かったが、そのチームはそれが何なのか分かっていなかった。 朝会の基本原則と詳細を意識していなかったのだ。 そのために朝会の問題について診断や解決がなされていなかったわけだ。 良い朝会を経験した人たちは、 うまくいってないときに何をすればいいかを知っている。 朝会に慣れていない人たちは、 うまくいってないときに何をすればいいかに気づかない。 「暗黙知なんだから、とにかく
辞めたくなる会社 | mediologic
mediologic my thoughts on media/communication/marketing and everyday life. Search Primary menu 以前にいた会社の、自分がいた組織の離職者率が増えているのを聞いていると、それまで「働きたい会社」だったのが「辞めたくなる会社」になってきているということなのだろう、ということに悲しくなる。 ベンチャー的な気質をもった会社だと、「この会社、このプロダクトを使って何かをしてやろう」というチャレンジャーが集まり、その“志”がエンジンとなって前進していくものだが、あるタイミングからその会社がメジャーになってしまうと「入りたい会社」となってしまい、学歴だけよかったり、対して仕事ができないのに過去の会社での経歴を“華麗に言う”人間が増えてしまう。つまり実力者が入ってこない。またそういう傾向になると、「マネージャー」
モチベーションの源泉：何のために働くのか、転職か起業か | Social Change!
この１〜２年、転職であったり起業であったり人の動きが激しいような気がします。私の知人も、大手企業でエリートだったのに起業したり、大手メーカーからソーシャルゲームの会社に転職したりしています。そうした人たちを見ていて、人の働く動機には色々ある中で、いくつかパターンがあるのかなと思い、人は何のために働くのかについて考えてみました。 ※この記事は、2011年07月07日に公開された記事を再編集したものです。 モチベーション４つのパターン 私なりに人が働くモチベーションとして、以下の４つのパターンがあるのではないかと考えてみました。（これは私の知り合いからの類推なので、専門的で正確な話ではありません） ・「アントレプレナー」タイプ ・「クラフトマン」タイプ ・「サラリーマン」タイプ ・「サポーター」タイプ アントレプレナータイプの方にとっての仕事に対する動機は「夢」が大きく影響しているように思いま
優れたリーダーはいかにして周りの人間の能力を高めるか
経営者は従業員の成長を高めることも制限することもできる 「ディミニッシャー」は周りの人間の可能性を閉ざしてしまう。そして、自分の会社の長期的可能性を小さくしてしまう 「マルチプライヤー」は従業員から無限の生産力を引き出すことができる 「タレントマグネット」は最も優れた従業員を引き付け、成長させる 「解放者」は間違いを犯しそこから学ぶ余地を作り出す 「チャレンジャー」は最大限のチャンスを追い求めるようグループを鼓舞する 「ディベートメーカー」はディベートの場を設け、たくさんの意見を広め、グループが最終決断によりたくさん貢献することを可能にする 「投資家」は部下にプロジェクトの指揮権と成長の機会を与える マルチプライヤーになるには、得意とすることを磨き、最も弱い部分を取り除き、じっくりとしかし確実にコア・コンピテンシーを積み重ねること この要約書から学べること 「マルチプライヤー」と「ディミニ
グーグル式「管理しない人事」がイノベーションを起こす | 職場の人間関係学
「社員が自発的に自分の仕事にバリューを加えるような創造性を維持するには、できる限り階層をつくらず、仕事を管理しないことに尽きる」 ジャーナリスト 溝上憲文＝文 組織が巨大化してもベンチャースピリットを失わず、斬新なアイデアを発信し続けるグーグル。社員の自発的な創造力を促すためにあえて組織を管理しないその経営手法は知識創造型産業のモデルとなるのだろうか。 「普通の会社」では新しい技術は生まれない いかなる大企業も最初は小さなベンチャー企業だった。新しい技術や商品を武器に市場に少人数で攻め入るが、やがてシェア拡大とともに社員が増え、組織が肥大化していく。必然的に階層化と人事管理による業務の効率的遂行を追求していくことになる。 しかし、そうした管理手法は、ベンチャーの持つ絶えざる技術革新と、それを支える社員の“情熱”を奪うという、副作用を伴う。ある者は組織に息苦しさを感じて退出し、ある者は組織
Rails3.1の初期化プロセスを細かく追いかけたRailsGuidesの記事を和訳したよ:ミームの死骸を越えてゆけ
This domain may be for sale!
ヒッキーがリーダやってみた
すぺっく 仕事：ソフトウェア開発 性格：ヒッキー。 立場：特定派遣。メンバーは自社の人。人事権はない。 何の因果か、リーダーとかやるはめになったのでその経験を書いてみる。 技術的な話はない。 ■方針：プブチャラティの精神。 「任務は遂行する。部下も守る。両方やらなくちゃならないのが『幹部』のつらいところだな。覚悟はいいか？ 」 プブチャラティさん！俺やるよ！ …というわけで、尊敬するプブチャラティさんの姿勢をすべての行動の方針とした。 ■実際にやったこと。 ○作業日誌を送りつけた。 本日やった作業とともに顧客と自社の上層部に送りつけた。 われわれたはちゃんとやってますよという言い訳と、問題が発生した場合に上司に詰め腹を切ってもらうため。 ○朝会 毎朝、問題点と作業の状況を２，３分で確認した。 これで、問題点を抱え込まない状況を作り出すのと、一体感、連帯感的なものを演出した。 ○作業の目的を
リーダーがチームの力を活かして育てるためにやるべき5つのこと - My Life After MIT Sloan
チームを率いるリーダーにとって、チームメンバーを活用して、仕事そのものを成功に導くことは最も大切なことだ。 加えて、チームの人の力を最大限に活かして、長期的視点で育てていくことも大切だと思う。 特に性格的にENFJ(=teacher,memtor)の私は、どうしても後者の方に関心が行ってしまうらしい。 チームを任されるようになって半年程度の私自身が出来てるとは限らないけれど、 後者のポイントでこれが出来ると人の力を活かせるなあと常々思っているポイントを5つ、自戒をこめて書いてみるです。 （個人的には4と5が大切だと思うです） 1．動きやすいように、見通し・段取りをつけてあげること これは単にプロジェクトを成功させるためだけでなく、人を活かすという観点でも重要だと思う。 ある仕事を達成するために、どの時点でどのようなことが出来ていなければならないのかを明確にし、合意する。 そうすれば、チーム
Rails3.1の初期化プロセスを細かく追いかけたRailsGuidesの記事を和訳したよ:ミームの死骸を越えてゆけ
This domain may be for sale!
人を雇う〜小さなチーム大きな仕事｜恵比寿で働く社長のアメブロ
恵比寿で働く社長のアメブロ 株式会社ビープラウド(http://www.beproud.jp)の社長が、日々の活動や、日々の思いなどを記録していきます。 ブログテーマ一覧Theme ブログ ( 24 ) 会社 ( 35 ) 仕事論 ( 84 ) 仕事 ( 10 ) 記念 ( 1 ) 記事 ( 2 ) 開発方法論 ( 15 ) 要件定義 ( 1 ) 記事 ( 3 ) 見える化 ( 1 ) 技術者 ( 7 ) 技術 ( 1 ) 自分の話 ( 8 ) WWW技術 ( 1 ) 趣味 ( 7 ) 野球 ( 22 ) BPStudy ( 61 ) 経営 ( 4 ) 恵比寿 ( 1 ) 書籍 ( 5 ) 勉強会 ( 11 ) edge2.cc ( 8 ) BP Camp ( 3 ) ７つの習慣 ( 5 ) Google App Engine ( 6 ) 執筆 ( 3 ) HumanCentricComp
【有能リーダの鉄則】同コンテキストでの有能リーダ vs 無能リーダ - レベルエンター山本大のブログ
今僕らのプロジェクトは大きな危機に直面していると言える。 なぜなら、商流の変化からワケの分からない人が大量に流入してきているからだ。 それも、プロジェクトマネージメントメンバーとしてだ。 今、僕らが参画しているプロジェクトは、 某大手メーカーさんの優秀なエンジニアをかき集めた一大プロジェクトだ。 しかし、どれだけ優秀なメンバーを集めても、リーダシップをとるべき人たちがダメだと プロジェクトは烏合の衆にならざるを得ない。 羊がライオンを率いる状況のまずさを実感する。 しかし、このプロジェクトの面白いところは、 過去の巨大なプロジェクトで功績のあった優秀なリーダ（AさんとYさんとYさんの3人）が サブリーダ的なポジションにいて、リーダーの 無能 vs 有能 の比較が同一コンテキストで測れることだ。 プロジェクトは上流工程段階ですでに壊滅的だが リーダーの資質についてエッジの効いたエピソードを集
会議中に話すのを我慢する - jkondoの日記
役割上、会議の多い仕事をしています。全社的な経営責任者という立場に加え、はてなのサービスの責任者として進捗や方向性を見ていますので、各ディレクターと方向性や成果を確認したり、サービス以外の責任者との会議もあります。なので会議の生産性を上げるのは非常に重要で、いろいろな工夫しています。その中で、最近重要だな、と思っている事を少し紹介したいと思います。 会議中は聴くことに集中して、最後にまとめて話す 最近心がけているのは「会議中にあまりしゃべらない」ということです。基本的なフォーマットとしては、会議をする相手に必ずアジェンダを作ってきてもらい、主に報告内容と相談内容をまとめてもらいます。そしてその内容を全部聴くまで基本的にしゃべりません。とにかく聴きます。途中で質問はしますが、それをどうするのかという話は、聴き終わってからやります。聴き終わったあとで、「ここはどうするか」「こうしたほうが良くな
yomugakachi.com
yomugakachi.com 2018 Copyright. All Rights Reserved. The Sponsored Listings displayed above are served automatically by a third party. Neither the service provider nor the domain owner maintain any relationship with the advertisers. In case of trademark issues please contact the domain owner directly (contact information can be found in whois). Privacy Policy
【書評】失敗学 失敗を個人の責任にするのはもう止めましょう。
失敗学を簡単に説明すると、「失敗やミスをやらかしても、それをきちんと省察することによってその後に活かそう」という考え方の事です。至極当たり前のことのようですが、これが時には難しく実践出来ていません。ましてや組織単位で失敗学を実践しようとすると、体面を重視する日本人には、まず失敗を隠蔽しようという真理が働いてうまくいかないです。 「同じ失敗を繰り返さない、失敗を活かすための考え方。」、一見ごくまっとうな考えのように思えるかもしれません。でも失敗学を学んだ私には、日本の多くの組織においてこの失敗学が全く実践されていないように思えます。 以下、失敗学を活用するための3段階の手順です。 人は必ず失敗する。人は失敗をやらかすものである事をまず認める。 失敗を隠そうとするのは自然の真理。だからこそ失敗が表に出てくる仕組みを作ること。 個人を責めるのではなく、失敗を繰り返さないための仕組みづくりをするこ
なぜ新人は聞きに来ないのか? - teruyastarはかく語りき
プログラマで、生きている: ググるな危険 http://el.jibun.atmarkit.co.jp/hidemi/2009/11/post-9d2b.html わたしが新人が検索に頼ってしまうことを危険視するのは、コピペの寄せ集めでもなんとなく動くコードが書けちゃって、それで自分は仕事を達成したという錯覚に陥ってしまうからです。 たいていの場合、新人プログラマには「きちんとしたコードを書くこと」は期待していません。先輩たちが期待しているのは「きちんとしたコードを書ける人になってくれること」です。 そこらへんの意識が行き違っちゃってるから、仙台に行くことよりも、新幹線に乗ることの方が重要事項になっちゃうんですかねえ。 最後に、わたしが新人の時に先輩から言われた言葉をご紹介させていただきます。 「自分で説明できないコードを1行たりとも書くな！」 間違うのはしかたありません。けれども、「自分
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
日経BP
サービス終了のお知らせ
マネジメントの達人とは「会社と社員の利害の一致」を作り出せる人 - SHINOBY'S WORLD