1on1.md
1on1.md これは私が支援先に提供した、1 on 1 に関するノウハウや、思いを述べたドキュメントを元にしています。企業の枠を超えて共有したいことが多いので、ここに貼ります。 概要 世の中には 1 on 1 の本があるようですが、とりあえずは『1 on 1 で 何を話すのか？ マネージャ/ソフトウェアエンジニアの立場から - サンフランシスコではたらくソフトウェアエンジニア』を読んでもらえればよいと思います (higepon さんに感謝!)。 1 on 1 は 1 対 1 で話すミーティングで、基本定期的にやります。上長とメンバーとの間で行うのが基本です。 グループ/チームでのミーティングを補完するためのものです。 みんなの前では話しづらい、込み入った内容を話します。 チームとして行っているタスクの進捗確認に 1 on 1 を使うのは避けましょう。それは 1 on 1 の目的に沿ってい
全然わからない。俺たちは雰囲気でマネージャーをやっている。 - アルパカログ
自分は今、コード書かずにマネジメントしかしてなくて、そんなポジションの人にそれほど価値ないでしょ、とか思ってしまうけれど、こういうポジションの人がいないチームの話とか聞くと、やっぱりいたほうがいいんじゃないか、と思うし、ほとぼりが冷めるとまた自分は無価値のように思えてしまう。 こんな心境の吐露を「エンジニアリングマネージャのキャリアについての悩み」で拝見して、私も何か発信しなければと思ったのがこの記事のきっかけである。筆者のdaiksyさんは、 エンジニアマネージャってなんか実績を示しづらいので、世の中の数多のマネージャ職に埋もれて、自分にスポットが当たりづらい、結果、キャリアに不安が拭えない、みたいなとこないです？ とも述べていて、これら2つのメッセージに込められた心の葛藤は、全てのエンジニアリングマネージャー(以下EM)が感じていることではないかと私は思う。少なくともEMの一人として私
HRzine
HRzine Day（エイチアールジン・デイ）は、人が活き会社が成長する人事のWebマガジン「HRzine」が主催するイベントです。毎回、人事の重要課題を1つテーマに設定し、識者やエキスパードが持つ知見・経験を、参加者のみなさんと共有しています。
管理職のためのエンジニア組織構築マニュアル | DevelopersIO
はじめに クラスメソッド株式会社 AWS事業部長の佐々木です。 私は前職で創業メンバーの1人としてビジネスを立ち上げた後、エンジニアとして実業務に携わりながら、統括マネージャーとして50人規模のエンジニア組織を構築しました。 また2014年にAWSエンジニアとしてクラスメソッドに入社し、2015年7月よりAWS事業部の部長に就任。事業は順調に拡大しており、2015年と比較して組織も2倍以上に大きくなりました。これは優秀な仲間に恵まれたのはもちろんのこと、組織設計と構築プランが功を奏したことも一因だと感じています。 そこで、私がこれまでに培ってきた経験から得たエンジニア組織の構築の仕方をお伝えしたいと思います。 エンジニア組織構築マニュアル 骨子を定義する これはエンジニア組織に限りませんが、組織には3つの骨子が必要です。 ポリシー ビジョン ターゲット ポリシーは、その組織が最もこだわる一
エンジニアが「明日からマネジメントして」と言われたら
製品開発におけるマネジメントの全体感最初に結論エンジニアがマネジメント始める際には、↑のようにざっくり簡単にでいいので開発チームのマネジメントの全体像を掴んだうえで、自分がマネジメントするべき範囲を明確にして動くことをオススメしてみます。 以降、もう少し詳しく説明します。 なんで書こうと思ったかエンジニアにとってマネジメントとはなにか。突出した技術力を持った人というのがエンジニアでは花形なイメージが一般的にはあるでしょうし、マネジメントはエンジニア全員にとって必須科目ではありませんが、一定の経験、年齢、スキルになったら考えることだと思います。 しかし、エンジニアにとってマネジメントという言葉はとても曖昧。必須科目でない分、特定技術に関するものよりもずっとドキュメントや教材がすくなく、なにをやればいいかけっこうわかりにくい。 最近だとVP of Engineeringみたいなポジションがメジ
優秀な技術者を追い出してしまう方法 - Qiita
若手エンジニアを不幸にしないための開発の「べからず」集 組織運営編から記事を独立させました。 優秀な技術者ほど辞めてしまいやすいのは、多くの会社に共通していることです。 この文章では、どうして優秀な技術者が辞めていってしまうのか、その理由を探るとともに、そうならないようにするための対処方法を少しずつ書き足していきたいと思っています。 マネジャーのみなさんへの前書き 会社の資産であるソースコードはきちんと管理されてますか？ 「きちんと金庫にしまってある」ではありません。 開発が進みやすく、今のソースコードはどのように品質が保たれているのかがわかるようになって 管理されてますか。 ソフトウェアの開発などで生じている課題は、どのように管理されていますか。 「去年の△月ごろに問題になっていたあの件は、結局どうなったのかい。」 「担当していた○○さんがだったら知っているんですけれども、もうやめちゃい
「ノーアジェンダ・どうしましょうか会議」の傾向と対策 - UNIX的なアレ
wadap.hatenablog.com 先日、こんなエントリーを書きました。割とエンジニアやデザイナーの方は経験したことがある会議ではないでしょうか。このワードに反応されていたので、少し掘り下げてみたいと思います。 「ノーアジェンダ・どうしましょうか会議」とは もうこの名前に全てが詰まってはいるので、経験したことがある人はすぐにわかるとおもうのですが、以下の点が揃っているとまさにその会議かと思います。 アジェンダが用意されていない とりあえず関係がありそうな人を呼ぶ 会議が始まり次第「どうしましょうか」的な空気が流れる ダラダラ長い 丸投げ感満載 というところでしょうか。会議そのものに主催者側の専門性があるものでは起きづらいのですが、自身が理解できない or 経験の無い領域の話になるとわりとこういう会議になりがちなのかなと思います。 会議の傾向 そしてこの会議が始まり「どうしましょうか」
社内横断の技術組織を終わらせました - nottegra’s blog
内容がネガティブに取られそうで、公式なところに書くべきではないので個人ブログで書きます。 この記事は、公式なブログで僕が書いた「社内横断の技術組織をはじめました」という記事へのアンサーブログになります。 ※元の記事は探せば出てきそうだし、個人的なブログと紐付けるべきではないのであえて出しません。 特定の誰かを陥れる目的ではなく、完全に個人の責任として、始めたものを終わらせてしまったことへの事の顛末を記録する目的で書きます。 はじめに 始めた理由 CTOの不在 品質面に対するレビュー不足 技術広報の不足 それぞれの施策の結果 時間がかかってみんなストレスが溜まる新規レビュー 当たり障りの無いことしか表現できない運用レビュー 兼任状態が続き、進まない新規技術検証 やる必要の薄い「全社」広報 終わった理由 成果が出せなくて、そもそも証明出来ないかもしれない 問題解決は組織じゃなくても出来ると気が
【追記あり】inside 売れないサービスの開発現場から
この二年間、ある一つの売れないサービスを開発し続けてきた。 GWに実家に帰ったときに地元の友達に話したら面白がってくれたのでちょっと書いてみようと思う。 今作っているアプリは、売れていない。 二年前に開発が始まって、リリースして一年半ほどになるが、一円も稼いでいない。 エンタメ系snsのはずなんだが、アクティブユーザーが増えるはずの大型連休で、起動したユーザーがたったの三人だった日があるほど、売れていない。 売れてないが故に常駐しているエンジニアは僕一人だ。外部のエンジニアにスポットでたまにタスクベースでお願いする程度。 ディレクターっぽい人が二人（マーケティング兼任）と、デザイナーが一人いて、 この3人と僕とのやりとりを地元の友人は面白がってくれた。 いわゆる「エンジニアあるある」ではあると思う。 例えば新機能の開発が始まったとき、 ーーーーーーーーーーーーーーー ディ「〇〇な機能が欲し
エンジニアの技術力評価は難しい? - 5年間運用してきた技術力評価制度の改善の歴史 ‒ / Regional SCRUM GATHERING Tokyo 2017
Jan 12, 2017 @ Regional SCRUM GATHERING Tokyo 2017
なぜプロジェクトは炎上するのか？炎上しやすい4つの傾向と、炎上を防ぐ3つの対策 - paiza開発日誌
Picture by ITエンジニアを目指す女子高生たちの学園ライフ4コマ漫画『ぱいじょ！』 こんにちは、谷口です。 某Mずほ銀行の案件のニュースが出たとき、弊社でも結構話題になりました。 あんなに巨大なプロジェクトをしずめるのは、もう本当に不可能なんじゃないかと思いますが、どんなに大きな炎上も、恐らくは小さな火種が集まって、やがて大きな炎となってしまった結果だと思いますし、最初の小さな火種の段階からぷちぷち消していけたらこんな結果にはならなかったはず……。 という話をしていたときに、paizaのエンジニアが「かつて炎上しているプロジェクトに自ら突入していくのが趣味だった」などと言い出しました。「そういう性癖なのかな」と思ったんですが、聞いてみると 「炎上しているプロジェクトに行くと『優秀な人たちはどんな振る舞いや働きをして炎上をしずめているのか』『何が原因で炎上したのか、どの時点で何をし
開発会社におけるエンジニアスキル向上施策の過去と今｜TechRacho by BPS株式会社
morimorihoge@Webチーム部長です。ご無沙汰しています。ゴ魔乙はギルド戦が実装されてから拘束時間が多くなり、そろそろ見切りを付けようかとも思い始めた今日この頃です。とりあえずポケモンGOは始めました。 しばらくTechRachoに投稿できていなかったわけですが、別に遊んでいたわけではなく、むしろ開発会社としての本業の方で一杯一杯でなかなか記事を書く気合を充填できていませんでした。 今回は、最近社内で（というか主に僕のいるWebチームで）取り組んでいる社内エンジニアのスキルアップへの取り組みについて、これまでの経過と近況を書こうと思います。長いです。 ※今年に入ってから弊社は事業拡大を目指して採用活動を強化しており、現在進行形でメンバの増強を行っています。新しい人が入ってくる中で古くからの人もいるという当たり前のことではありますが、過去にこういう取り組みをしていたんだよという記録
プロジェクト・マネジメントの目的とは何か | タイム・コンサルタントの日誌から
中堅エンジニアが壁を破って成長するには、何を学ぶべきか。そういう問いに関連して、ここ何回か書いている。初級の仕事を一通りおえて、とりあえず一人前のことはできるようになっても、その先にしばしば壁がある。そこを乗りこえて面白い仕事をしていくためには、もう少しマクロにものを見て、人を動かせるようになっていく必要がある。 今年の1月に、静岡大学と浜松ソフト産業協会の共催によるプロジェクト・マネジメント講座に呼ばれて、初日の講師を務めさせていただいたときも、その話から始めた。集まった方はほぼ全員がIT技術者だった。IT分野は勉強会も盛んで、知識欲に燃えた熱心なエンジニアも少なくない。わたしはたずねた。 「この中で、現在プロマネの仕事をされている方はいらっしゃいますか？」 手を上げた方は全体の1/3もいなかった。ある意味、予想通りではある。プロマネの仕事をばりばりこなしている人は、こうした講座を聴きに
エンジニアのハマり時間とその技術的難易度の相関関係 - Qiita
めちゃくちゃにハマったからと言って、その問題は技術的難易度が高い訳ではないんじゃね？という話。 ここで言う「ハマる」とはなにかに夢中になって没頭することではない。バグとかエラーがあって、なかなか解決できなくてそのために時間を割かれてハマる、の「ハマる」。 先日、ハマった問題が解決した時の感情は「ついに解決したぞ」という安堵感と「しょーもないハマりポイント作りやがって、あのボケが！」という前任者への怒りが混ざった状態だった。 サイトのSSLの有効期限切れが２週間後にせまっていた。やる事は証明書の更新、新しい証明書をAWSのELBに入れること。ただこれだけ。しかしハマった。どうやってもELBから「あなたのキーは無効です」みたいなエラーメッセージが返ってきた。２年前にSSLを設定したエンジニアは退職してしまって、もう居ない。その前任者とほぼ同じことをすればOkなはずなのに、なぜかできなかった。
エンジニアの専門性を伸ばすためにディレクターに気をつけてほしい3つのこと - Hatena Developer Blog
こんにちは、 id:stanaka です。 先日、社内ミーティングでディレクターから「エンジニアの専門性を伸ばすためにディレクターとしてなにができるか」という質問を受けて回答した社内向けエントリを公開します。 (ちなみに、はてなでのディレクターは、エンジニア、デザイナーなどの数名のメンバーからなるチームの率いる、現場にもっとも近いマネージャー、というポジションです。) エンジニアの専門性を伸ばすためにディレクターに気をつけてほしい3つのこと 1. 引き出しの数を増やすことができるようなタスクを振る エンジニアにとって自分が持つ引き出しの数と専門スキルは強い相関関係があります。サービス開発において遭遇するさまざまな局面において、いくつかの選択肢を提示でき、さらにその中から最適なものを選びとれることは、エンジニアの専門性が高いことの証です。 そのためには、いろいろな経験をさせてあげることが大事
他のチームに｢技術的支援｣をする時に気をつけていること - Masteries
自分が働いているGaiaxのように, 社内に複数の事業があり, それぞれにエンジニアが所属して働いている場合, ｢ねえ, ○○のチームの××って仕組み, どうやってるの? うちのチームでもやってみたい!｣といったコミュニケーションから, 他のチームに対して｢技術的支援｣をする機会が生まれる事が多々あります. 最近の例だと, 社内の新規事業の立ち上げや, オンプレからクラウドへの移管のタイミングで, Infrastructure as Codeやデプロイ施策, ChatOpsなど整えたいので, 相談に乗って欲しい! という声を何度か頂いた事がありますし, よくよく考えると今やっているPhotosynthへの留学も, 見方を変えれば｢Photosynthへの技術支援｣と言えるかもしれません. そういった｢技術的支援｣をする時に気をつけている事についてFacebookにつぶやいた所, 思ったより
ソフトウェア開発の生産性を阻害する「気軽に聞けない」ことの考察と対策 - メソッド屋のブログ
マイクロソフトの DevOps テクニカルエバンジェリストになる前から、ずっと不思議だったことがあります。 それは、「アメリカのエンジニアの生産性の高さ」です。素晴らしいサービスは大抵彼らから生まれていますし、彼らを見ているとアウトカムも生産性も非常に高く感じます。 私は個人的にこの秘密を解く旅の途中にいます。私はインターナショナルチームに所属しているのですが、同僚と一緒に働いたり、ハッカソンをしたりして気づいた１つの仮説について共有したいと思います。 気軽に「聞けないこと」が生産性を阻害しているのでは？ 以前私は「米国のエンジニアはコンピュータサイエンスを専攻している人が多くすごく優秀で、さらに英語が出来るので、技術収集するのも楽だから相当アドバンテージがある」と思っていました。 英語に関してはそうだと思いますが、彼らの個々の人がそんなに優秀かというとそうでもないことに気づきました。それ
採用プロセスを真剣に考えろという話
人材流動性の高まりを日々感じているみなさんこんにちは。 最近いろんな会社にお呼ばれしていて、その中でエンジニアの採用の話になることがとても多いのでちょっと整理しておきます。 ポイント▼「面白いプロダクトもないし、仕事内容は面白いとは思えないし、よい給与は払えないし、仕事環境にも自由はないけど、良い人雇いたいんだけど、どうしたらよいですか？」悪いが諦めろ。良い人は当然のことながら複数の会社が興味をもつことになるし、働く場所を自分で選択します。Pros/Consを見極めて選ぶことになるので、Prosがない場所で働く理由がありません…だとあまりに冷たいので、もしあなたが次に転職するとして、それでも今の会社に入るのであればあなたを惹きつける理由が何かあるはずで、それをアピールしよう▼「入社してから期待値にあっていないことが分かる、ってことが多いんだけどどうしたらよいですか？」期待値を明文化している
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
エンジニア組織のスケールに伴う社内勉強会のTry&Error #infrapre / 20170805
“エンジニア35才定年説に挑戦する” 開発チームのマネジメント
