テックリードという役割
なぜこの文章を書くか?自身が数ヶ月テックリードの役割で経験した内容を基に、テックリードがどういう役割で、毎日の仕事の中でどのような仕事をするのかについて書いていく。 テックリードはサンフランシスコのWeb系企業では一般的なようだが、日本ではまだそれほど広まっているとはいいづらいと思う。 テックリードに求められるのは一言で言えば”技術でエンジニアチームをリードすること”である。Webエンジニアのキャリアパスでたびたび二元論的に語られる、”技術一本で生きていく”職人的なトラックとも”人やプロジェクトのマネジメントをする”マネジメント系のトラックともニュアンスが異なる。 自身の技術力、そしてリーダーシップをもってエンジニアチームのアウトプットを最大化させていくのがテックリードの役割である。 多くの人にその役割を知ってもらい、エンジニアとしてのキャリア形成の助けになればと思っている。 なお、このポ
de:codeで澤円さんが伝えたかった「エンジニアに必要なマネジメント」の真意とは？
de:codeで澤円さんが伝えたかった「エンジニアに必要なマネジメント」の真意とは？ 馬場 美由紀（HTML5 Experts.jp編集部） 5月23・24日の二日間に渡って開催された日本マイクロソフトの開発者向けカンファレンス「de:code 2017」。その中でも定員数をはるかにオーバーし、入場規制もかかった澤円さんのセッション「これからのエンジニアに必要な『マネジメント』の考え方」が興味深かったので、レポートしたいと思います。 マネジメントは「管理職」のことだけはない エンジニアの世界では日常茶飯事で交わされている以下のセリフ。皆さんも聞き覚えがありませんか？ 「これさ、なるはやでチャチャっと作ってよ」 「とりあえずいい感じに仕上げといて」 「なんかこれ、あんまり動かないよ」 実はこれ、澤さんいわく「マネジメントが欠けている状態」なのだとか。どんなマネジメントが欠けているのかというと
問題は人や組織ではなく、「間」にある
サイバーエージェントが4年ほど前に導入したらしいミスマッチ制度。 個人的には、とても従業員に優しい制度だなぁと思っている。 その後運用でどうなっているかは知らないけれど、当時の話では、従業員の下位5％をD評価とし、D評価1回でイエローカード、2回目でレッドカードとなり、2回目で部署異動または退職勧奨のいずれかを選択してもらうというもの。 仕事のパフォーマンスだけでなく、価値観、文化の合わない人も対象になるとか。 photo credit: Melee 100: Learning to Let Go via photopin (license) これだけみると、ずいぶんと厳しい制度に見えるが、合わない人には早めに合わないと言ってあげることは、とても誠実な行為だと思う。 しかも、名前が示す通り「ミスマッチ」制度であって、社員をダメ認定するということではなく、あくまでも「合わない」という話である
経営の”踊り場”問題 - Yamotty Blog
2016 - 12 - 28 経営の”踊り場”問題 プロダクト-プロダクトマネージャー 本記事は「経営の踊り場問題」と勝手に呼んでいる問題とその対策について、わざわざクリスマスの夜に行った4つのツイートをまとめ・補記したもの。主にスタートアップや新規事業など「急速な成長」を前提とした組織体を想定している。 停滞期に起きること 踊り場を抜けるにはユーザーやプロダクトと向き合い切る以外に解はないと思ってるんだけど、「これまで順調に伸びて来た売り上げがストップ」みたいな状況は社内の雰囲気を悪くする。 結果、マネジメントが組織や人間関係の問題にフォーカスしがちに。これを「経営の踊り場問題」と呼んでる。→続 — Yamotty (@yamotty3) December 25, 2016 踊り場が目線を内に向ける リリースした直後は底にいるので、サービスは伸びるしかない。難しいのは伸ばし続けること。ふ
初めての技術力評価会を終えたので感想を書いた - CARTA TECH BLOG
こんにちは、fluct SSP開発本部の@saxsirです。 今年の4月に入社した新人ですが、職場ではgolangとかAWSとかを使って社内向けのプロダクトをゴリゴリと開発しています。 さて、VOYAGE GROUPでは人事評価制度の一つとして技術力評価会という相互評価の仕組みがあります。 これは年に2回ほど開催されており、直近半年くらいの仕事から何かテーマをピックアップし、別チームのエンジニア2名（評価者）に「私はこんなすごいことをやったんだよ、どやっ」とお話しながら自分の技術力を評価してもらうという場になります。 もちろん、新卒も例外なく技術力評価会を行います。 今回は初めての技術力評価会を終えて私が学んだこと、を社外の方向けに書こうと思います。（言うまでもなく、私は被評価者です） ※以下、「技術力評価会」を「評価会」と略して表記する場合があります TL;DR 「なぜやったのか」を説明
チームパフォーマンスモデルとは？
みなさんこんにちは。@ryuzeeです。 人が集まっただけでは機能するチームにならない、というのはみなさんご存知のとおりです。 そしてチームの形成過程をあわらすモデルの1つとして有名なものに「タックマンモデル」があります（こちらを参照）。 今日はもう1つ別のモデルとしてDrexlerとSibbetが提唱している「チームパフォーマンスモデル」を紹介します。 タックマンモデルでは、チームの形成過程は形成期・混乱期・統一期・機能期・解散期の5段階（初期は4段階）で構成されていましたが、このチームパフォーマンスモデルでは、以下の7段階で構成されます。 オリエンテーション信頼の醸成ゴールの明確化コミットメント実行ハイパフォーマンスリニューアルこれらのステージは前半上から下に向います（形成段階）が、この段階では、徐々に制約を感じるようになっていきます。一方で後半に下から上にあがっていく（持続段階）につ
マネジメントを経験してようやくわかってきた、半年で部下を１人前にするコツ - トイアンナのぐだぐだ
試行錯誤しながら手に入れた部下や後輩を半年で１人前にするコツをまとめました。 嫌な先輩から、まあまあの上司になるまで まずは私の経歴を少し。昨年独立するまで外資で働いていました。新卒で入ったのは少数精鋭にしたって、いくらなんでも少なすぎない？ と人事の肩を揺さぶりたくなる部署でした。 入社2年目には「もう１年いるんだからシニアだね！後輩指導よろしく」と宣告され、必死で３人指導してのち転職。その後はプロジェクトごとに部下を持っていました。独立した現在は外注マーケターとしてトレーニング業務も担当することもあります。合計で指導した部下・後輩は約10名前後。 最初は最悪の上司だったと思います。詳しくは「いつの間に自分が「細かいことにウルサイ嫌な先輩」になっていた 」に書きましたが、もうタイトルだけでお察しください案件。自分でもこれはいけないと思い四苦八苦した今、半年くらいで「いいね、それで行こうか
エンジニアを成長させるためのマネジメントと組織づくりとは～アドテクを中心とする組織の取り組みの例。Developers Summit 2016 － Publickey
エンジニアを成長させるためのマネジメントと組織づくりとは～アドテクを中心とする組織の取り組みの例。Developers Summit 2016 ソフトウェアによるビジネスを行う組織にとって人材はもっとも重要な資産の1つであり、その人材と組織をつねに優れたものに成長させ続けていくことはマネジメントにとって最大の課題でしょう。 ではマネジメントはどのような考えや方法でエンジニアを成長させ得るのか。2月19日、20日に行われたイベント「Developers Summit 2016」（通称デブサミ）でリクルートコミュニケーションズの阿部直之氏が行ったセッション「エンジニアを成長させるための組織づくり」では、その一例を見ることができました。 この記事では、そのセッションの内容をダイジェストで紹介します。 エンジニアを成長させるための組織づくり リクルートコミュニケーションズ 阿部直之氏。 リクルート
辞める時に会社のほんとうの姿が見えるよね、という話
私自身、独立するまで3回転職しているので、何度かは「会社辞めます」と上司や社長に伝えていることになるのですが、その際に思ったのは、辞める時に伝えた時の反応やコミュニケーションで会社の本当の姿が見えるなーと思いました。 いままではぼんやりとそう思っていたのですが、先日友人との話の中で「会社が本当に社員をどう思っているか」「辞めた社員がその会社のことを何と言うか」は辞める時の対応によってだいぶ変わるなーと感じる場面がありました。 辞めるときの対応として印象的だったのはその友人が話していたことを簡単に書くと、前職はIT系スタートアップを辞めることを代表の方に伝えたところ、「なるほど…。そういうことか、わかったよ。給与2倍にするから」と言われたそうです。 まじか…という感じですが、結構こういう社長というか会社あるんですかね！？ どうやらこの会社は退職者が続いていて、本当の理由はこの代表の価値観につ
第3章「 自己探求の時代」自己啓発本を10冊読むよりも実りがある24ページ｜ハーバード・ビジネス・レビューBEST10論文／ギックスの本棚 - GiXo Ltd.
第3章「 自己探求の時代」自己啓発本を10冊読むよりも実りがある24ページ｜ハーバード・ビジネス・レビューBEST10論文／ギックスの本棚 己を「マネジメント」せよ！ 本日は、第3章、もしドラで一躍時の人となった、ピーター・ドラッカー氏の「自己探求の時代（1999年7月）｜ページ数：24p」を紹介します。 連載一覧はコチラ 自己啓発本を買うな。これを読め。 この論文は、非常に本質的です。その辺に転がっている自己啓発本を10冊読むよりも、この24ページを読んだ方が良いです。ホントです。この24ページだけでも、1800円の元を取って余りあると僕は思います。オススメです。 強みを知れ この論文では、まず「強みを知れ」と述べられます。 自己の強みと信じているものは、たいていが見当違いである。知っているのは、強みならざるものである。それさえ見当違いのことが多い。何事かを成し遂げるのは、強みゆえである
答えの組織と問いの組織 - β2
色々な組織と仕事でお付き合いすることがある。 上層部の人と話すと、こちらが提案したことについて二種類の反応がある。 「私はそれは正しいと思う（思わない）」と、「私はそれが狙いに合っていると思う（思わない）」である。 この違いは、組織それ自体の考え方の違いだと思う。 世の中には、答えの組織と、問いの組織がある。 答えの組織では、組織をよい答えを出す場所と定義している。 組織の階層は、よい答えを出せるかどうかで上下に分かれる。よい答えを出せるかどうかは、能力だけでなく、経験が重要になる。だから一般に言って、年長者が上につく。 特徴として、問い（何をするべきか、何が良いことか？）は外から与えられる必要がある。 問いの組織では、良い問いを出すことが、よい答えにつながると考えている。 組織の階層は、よい問いが出せるかどうか、大きな（難しい）問いを小さな（簡単な）問いに分割していけるかどうかによって上
研究開発マネジメントノート : コア・リジディティ
2010年09月05日22:28 カテゴリ研究マネジメント・トピックス コア・リジディティ コア・コンピタンス、コア・ケイパビリティという考え方は、企業の競争優位の源泉として、技術開発の場面においてもよく話題になります[注]。どんな研究テーマに取り組むべきか、技術開発の方向はどうあるべきかなどを考える時に当然おさえておくべきことには違いないと思うのですが、下手をすると研究開発活動に過度の制約を加える因子ともなるように思います。そこで、今回は、コア・コンピタンスに伴う負の側面と考えられる「コア・リジディティ（硬直性）」についてまとめておきたいと思います。 「コア・リジディティ」とはLeonard-Bartonにより提案された言葉とのことですが、著書[文献1、p.46-86]ではその概念の重要性について、「コア・ケイパビリティをマネジメントするうえで問題になるのは、それが逆説的にコア・リジディ
わたしが知らないスゴ本は、きっとあなたが読んでいる: 名著！「デッドライン」
長くなりすぎたこのエントリのレジュメ …というか、見出しの一覧。これ見てご興味ある方はお読み下さいませ。 マネジメントの4つの本質 マネジメントおける簡潔で痛切なエッセンス（一部） 設計とデバッグに関する恐ろしい事実 残業と生産性とプレッシャーに関する恐ろしい事実 生産性の測定について 管理者の怒りについて 会議を効率よく行うための、たったひとつの冴えたやりかた 大事なことが、ずばり書いてある。背中を押したのは「ソフトウェア開発の名著を読む」なんだけど、確かに名著だ。初読は物語を楽しみ、再読、再々読で血肉にすべきだな。 延ばし延ばしにしてた一冊を読み始めて「どうして今まで読まなかったんだあぁぁっ」と叫びだすような逸品がある。本書がまさにそう。デマルコは「ピープルウェア」がピカイチと決め付けてた自分が恥ずかしい。 「ピープル」がプログラマ・チームリーダーの視点で書いているが、「デッドライン」
Treehouse: 本当にフラット、つまりマネージャーがいなくなった会社、そして個の時代がくるのか？ - ワザノバ | wazanova.jp
http://blog.teamtreehouse.com/working-in-a-flat-company 1) Treehouseで起きていること プログラミング/デザインのオンラインコースを運営しているTreehouseは、６月に週４日勤務にしたことに続き、９月に、フラットカンパニー宣言をしました。つまり、マネージャーと呼ばれる人が社内から突然いなくなったということです。 会社は、幅広めのゴール、ミッションステートメント、キャッシュフローへのインパクトのガイドラインのみを提示。それ以外の優先順位の判断は社員に任せる。 社内のプロジェクトは、提案 -> 社内フォーラムサイトで議論 -> 投票 -> 自主的判断で各メンバが “Join”ボタンを押して自分をアサイン、というプロセスで進みます。そして、各メンバは、1日1回ステータスをサイトでアップデートすることで進捗管理。各プロジェクトに
自律的に現場を改善できるチームをつくるための「ふりかえり」の進め方 〜 KPTと進め方のノウハウ | Social Change!
現場のオペレーションを改善するために、最初に着手するなら何か？と聞かれたら、いつも「ふりかえり」から始めましょう、と答えています。かつてトラブルの起きているプロジェクトに入ったときも、まず始めたのは「ふりかえり」からでした。 「ふりかえり」とは、文字通り現場の活動を振り返って、改善のアクションを考えることです。反省会のようにも思えますが、すべてが終わってから反省する訳ではなく、現状分析を行って、うまく続けていくための未来を向いた活動です。 この記事では「ふりかえり」という習慣について、そして、ふりかえりを実践するにあたって、進め方とポイントについて紹介します。 ふりかえりの進め方”KPT”とは 上の写真は、私たちソニックガーデンで「ふりかえり」をしている様子です。ソニックガーデンでは弟子を採用していて、その弟子と師匠とのふりかえり風景です。このように、特別な道具はなにも必要ありません。必要
自社のビジョンに利害関係者も巻き込む「価値観連鎖（Values Chain）」の再発見―『絆の経営（DHBR2012年4月号）』
谷藤友彦のブログ。P・F・ドラッカーを私淑する青二才コンサル・中小企業診断士が、マネジメント、リーダーシップ、経営とは何か？を追求。 ※2012年12月1日より新ブログに移行しました。 ＞＞＞現行ブログ free to write WHATEVER I like ⇒2019年にさらにWordpressに移行しました。 ＞＞＞現行HP シャイン経営研究所（中小企業診断士・谷藤友彦） ⇒2021年からInstagramを開始。ほぼ同じ内容を新ブログに掲載しています。 ＞＞＞Instagram @tomohikoyato 新ブログ 谷藤友彦ー本と飯と中小企業診断士 （DHBR2012年4月号のレビューの続き） 組織の「接着剤」と「潤滑油」が生み出す 「集合的野心」の力（ダグラス・A・レディ、エミリー・トゥルーラブ） 集合的野心（collective ambition）とは、リーダーと社員が、みず
なぜなぜ分析があぶり出すチェックリスト症候群
ちょっと想像してみてほしい。あなたの勤務先に2つの職場があるとする。「業務を遂行する際に大量のチェックリストを渡されて、作業を終えるたび成果物をチェックするよう命令される職場」と「チェックリストが無くても作業ミスを防げるよう作業手順の改善が日々行われている職場」だ。どちらかを選びなさい、と言われたら、どちらへの配属を希望するだろうか。たぶんほとんどの人が、後者を望むのではないだろうか。 それにもかかわらず「ヒューマンエラーで起きた品質事故の再発防止策を考えろ」と言われると、原因は「担当者の注意不足」とし、対策は「チェックリストを作り確認を徹底」としてしまうマネジャーが、少なくないらしい。 筆者がこのことを意識するようになったきっかけは、旧所属部署（2010年12月まで日経情報ストラテジー編集部）で担当した「なぜなぜ分析」の連載記事だ。この連載は、独立コンサルタントであるマネジメント・ダイナ
スケジュールを作るプログラマが一番効率が良い。 - レベルエンター山本大のブログ
現場の周りのプログラマさんたちが残業する中、 僕が毎日定時で帰って高品質なプログラムを作れる理由は、 僕が自分でスケジュールを作ってから仕事を始めるからだ。 僕が今の現場に入って始めにリーダーさんからこういわれた。 「スケジュールがきついので、 管理工数がもったいないから、管理資料に手間をかけたくありません。 イキナリ作業に入ってもらってかまいません。」 若い頃ならうっかりその言葉に惑わされているところだが、 そうはいかない。スケジュールがきつい時ほどコントロールが必要なのだ。 何を先にやっておかないといけないか、 今週末までにどこまで進めておけば安心か。 これらがわからなければ、不安に駆られるばかりだ。 不安を取り除くという意味だけでもスケジュールを組むことは非常に役に立つ。 ドラッカー風に言えば、 「ミッションに集中するにはマネジメントを駆使しなくてはならない」 ということだ。 プログ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Amazon.co.jp: 完全なる経営: アブラハム・マズロー (著), 大川修二 (翻訳), 金井寿宏 (監訳): 本
Amazon.co.jp: 35歳からの「脱・頑張(がんば)り」仕事術 (PHPビジネス新書): 山本真司: 本
