ぼくの大切な友人でもある優秀なエンジニアが、マネージャーを引き受けることになったと聞きました。いろんな事情がありなかなか大変な決断だったらしいのですが、どうせやるならがんばってほしい、うまくいってほしいという老婆心を(おっさんなのに)発揮して、ぼくが初めてマネージャーになったときのことを思い出しつつ、勝手にアドバイス的なことを書こうと思います。

自社でWebサービスを運営する会社の開発チームのマネージャー、という前提で書いています。

読むといい本

はじめての課題に挑むとき、賢い人は先達の知恵が詰まった「書籍」による知のショートカットを試みます。読んでおいて損はない2冊を紹介します。

新版 はじめての課長の教科書

ベタなタイトルですが、「マネージャーになるとはどういうことか」を一般論で語ってくれるわかりやすい本です。まずは読んでおいて、会社や環境に合わせて理解を修正していくとよいでしょう。


チームが機能するとはどういうことか

「チーミング」「プロセス知識スペクトル」「心理的安全性」という重要ワードが出てくる本です。チームで問題解決をするのが主なミッションであるソフトウェア開発において、避けて通れない考え方が紹介されています。


こころがまえ

よく居酒屋のトイレに貼ってある小言的なやつです。老婆心を燃料に、いままでいろいろ考えてきたことを要約してみます。

マネージャー最大の仕事はメンバーの給料を引き上げることだ

マネージャーの仕事につく細かいラベルは無限に存在しますが、源流まで遡るとここに行き着きます。メンバーに成果を出させ、それを交渉材料にメンバーの給与を引き上げること。このゴールがブレると、メンバーもマネージャーも不幸なことになることが多いように思います。

チームのミッションを説明し、それぞれのメンバーに期待する役割と成果を設定し、それを達成できるようサポートする。メンバーがあげた成果を可視化し、給与を決定する場での説得材料を作る。これらがマネージャーの仕事です。

メンバーの給料を引き上げられるマネージャーであれば、自らの評価も押し上げていくことができるでしょう。

自分を守れるのは自分だけ

マネージャーになるとつい張り切って「メンバーを守るのがぼくの仕事や!!!!!」などとなりがちです。もちろんリーダーとしてメンバーを外圧や理不尽から守るのは大切な仕事ですが、そこが行き過ぎて保護者マインドを持ってしまうとお互い不幸になります。

メンバーを守るのが仕事ではなく、自分を守れるメンバーを育て、メンバーが自分を守るのをサポートするのがほんとうのマネージャーの仕事です。期待する役割と成果をきちんと伝え、それを達成するためにサポートする意思があることを伝えたら、あとはメンバーが頑張り、問題や困難に出会ったら自分で判断する。メンバー自身では解決できないことを補助し、一緒に解決に導く立場としてのマネージャーであるべきです。

そして、マネージャー自身を守るのもマネージャーの仕事です。チームだけではなく自身の負荷を把握しコントロールできることが求められます。さらに言うと、せっかくモチベーションを持ってマネージメントに取り組もうとする新任マネージャー(きみのことだ)が自重で潰れていくのは、マネージャー自身にとっても会社にとっても大きな損失なのです。

メンバーには「自分で自分を守る」という意識を持ってもらう。マネージャー自身も「自分で自分を守る」という意識を持つ。これがマネージャーとして重要な仕事であり、強いチームに必要なマインドセットでもあります。

期限があるタスクを持つと死

これはぼくの経験から思ったことであり、うまくマルチタスクとオーバーワークを回せるマネージャーには当てはまらないかもしれません。

プロジェクトにたくさんのタスクがあり、見積もりをすると現存戦力では期限に間に合わない。そんなとき「プレイングマネージャー」という言葉を思い出し、マネージャー自身がタスクを自分にアサインしてしまうことがあります。しかし、たいていの場合これは悪手となります。

見積もりが溢れた分を現実的な見積もりで自分がカバーする。不慮の事態がこれ以上発生しなければ、それは妥当な判断と言えるでしょう。しかし、マネージャーのタスク消化をアテにしなければならないようなプロジェクトの場合、第二第三の「不慮の事態」は高い確率で発生します。そのとき、マネージャーが目の前のタスク消化で手一杯だったら、いったい誰が次の「不慮の事態」を捌くのでしょう?

マネージャーには「自分のリソースはボーナスだと思う」スキルが要求されます。最前線に乗り込むのは最後の手段としてとっておきましょう。

まとめ

ソフトウェア開発チームのマネージメントという仕事は、大変で、重要で、そして面白い仕事でもあります。マネージャーになる・ならないの選択肢が提示された状況で「なる」ことを選んだのは、その理解と覚悟があったんじゃないかな、と思います。

がんばってね。困ったことがあったら、いつでも呼んでね。

マストドンの流行とfriends.nicoと超会議

2017年4月、日本で分散型SNS「Mastodon」のムーブメントが勃発しました。ASCII.jpの記事の記事と、それに触発された日本語インスタンス「mstdn.jpの設立をきっかけに、企業や個人のインスタンスが次々と立ち、関連するイベントが次々と開催され、あっという間に書籍まで発売されました。

身の回りでも、「friends.nico」の立ち上げとともにどったんばったんの大騒ぎが勃発。ニコニコ超会議にブースを出したり、ステッカー出して配ったり、mstdn.jpの管理人ぬるかるの入社が決まったり…と、4月の後半はひたすらばたばたしていたのでした。

その超会議では「超技術書典」という技術系同人誌の即売会が併催されました。その中の「ライブ同人誌執筆」という企画に急遽著者としてアサインされたので、この顛末をまとめた薄い本を執筆・即売してきました。プリントしたぶんは完売御礼なので、PDFを販売できないか検討しています。


マストドン開発者Eugen Rochko氏とマストドンイベント

5月になって騒動はやや沈静化し、超会議も終わってやっと一息…というタイミングで、新たなミッションが発生しました。

「マストドン開発者Eugen Rochko氏を、Interop Tokyo 2017「マストドン」ブリーフィング基調講演とマストドン会議3に登壇させよ!」というもの。

諸事情により来日してもらうのはかなわず、Skypeでのオンライン登壇となったのですが、氏とイベント主催者の調整をひととおり回していたため、僕の5月はひきつづきどったんばったんしていたのでした。

イベントそのものは盛況で、開発者の声を直接聞くことでマストドンの思想的な面や今後の展望などへの理解も得られ、有意義なものになったと言えるでしょう。

ちなみに日本語の記事では「オイゲン・ロッコ」と記述されることが多いですが、事前のSkypeミーティングで聞いたところ、実際の読みは「ロチコ」もしくは「ラチコ」の方が正しいようでした。

新橋.beer

と、ここまでマストドンに関わってしまったのに、自分でやってみない手はないだろう。そう思い立ち、早速立ててみることにしました。

(さらに…)

10/8(土)、forkwellが主催するイベント「Forkwell Meetup – この先生きのこるエンジニアとは」というイベントで、ゲストトークとして「ロックスターになれないエンジニアたちに贈る生存戦略」というお話をしてきました。

スライド

(さらに…)

…というのに行ってきたのでメモを晒します。社内共有用に書いたんだけど、秘匿情報もないのでほぼそのまま公開します。乱文かつ文中敬称略にて失礼。

~マネジメントに悩める全てのエンジニアにささげる~ 伊藤直也の1人CTO Night |転職ならDODA(デューダ)

開発組織マネジメントのコツ

  • 対象 : 50 – 100人ぐらいのWeb / 受託会社
  • CTO or VP of Engineering
    • 海外ではCTO : テックリードのイメージが強い
    • マネジメントをするのはVPofEが多い
      • CTOがマネジメントしたくなければVPofEを雇うのもあり
  • スコープ
    • チームマネジメント
    • ヒューマンマネジメント
  • (さらに…)

Hiromu Shioyaさん(@kwappa)が投稿した写真

ござ先輩から著書「独習Python入門 1日でプログラミングに強くなる」をご恵贈いただきました。

Pythonはほとんど未経験だったので、サンプルコードは全部写経してみつつ、感想を書いてみました。コードと一緒にGitHubにてご覧ください。

kwappa/gothe_python


ソフトウェアエンジニアのあいだで人気が高まっているチャットサービス「Slack」。みなさんはもうお使いですか?

洗練されたUI、柔軟な他サービスとの連携、オープンなAPIなど、エンジニアにとってはグッとくる特徴を備えています。僕の周囲でも他サービスからSlackに乗り換える会社が多く、プライベートなコミュニティがSlack上に構築されることも増えてきました。

そんな盛り上がりを見せているSlackに、待望の入門書が出版されました!それがこの「Slack入門 ChatOpsによるチーム開発の効率化」です。著者の@matsukazさんからご恵贈いただいたので、書評させていただきます。

(さらに…)

4/25、ITスタッフィングさんのご依頼で、「エンジニアとして生きのこるためのスキルをキャッチアップする技術を学べるセミナー」というお題でしゃべってきました。LTより長くしゃべるのはずいぶんひさしぶりです。

講演資料


講演の対象はITスタッフィングの登録者がメイン。お弁当が出て僕の著書がプレゼントされるという太っ腹なイベントでした。


しゃべってきたこと

「派遣エンジニアが収入を上げていくにはコミュ力をあげるかスキルを磨くしかないよね」という主催者の仮説に基づき、先月開かれた「コミュ力を上げるセミナー」に続いての第2回として、日々のどんな取り組みがスキルアップにつながるかを話してね?というオーダーでした。

そこでキーワードとして…

(さらに…)

ニコニコ動画とAWS

ニコニコ動画のインフラ、というと巨大なオンプレミス環境というイメージをお持ちの方が多いようです。実際ほとんどのサービスはオンプレミス環境で動いており、一時期は「日本のインターネットトラフィックの10%を占めている」などと言われたりもしました。

ところが今年に入って、弊社ではAWSの利用が急増してきました。AWS Summit 2015では「ドワンゴが AWS を使ってみた」というセッション(レポート / スライド / 動画)で、LDRの事例を紹介しています。

また、10月にリリースされた「ニコナレ」や「ニコルン」といった新サービスも、オンプレミス上の基盤システムをAWS上のサービスから利用する、という形で構築されています。特に「ニコナレ」のバックエンドで稼働しているメディアストレージはマネージドサービスを多用しており、スピーディなリリースに寄与しています(詳細 : RubyとAWSでつくるメディアストレージ基盤 – Qiita)。

このようにAWS活用の流れは加速しており、来年以降も事例は増えていく見通しです。

「実践 = 仕事」でAWSに入門するために

しかし、AWSの利用経験は乏しかった弊社、インフラ担当のエンジニア陣は試行錯誤の連続でした。僕が見ていた「ニコナレ」チームでも悪戦苦闘し、なんとかリリースにこぎつけたころ、「Amazon Web Services 実践入門」という本が出版されたのです。


(さらに…)

めりくり〜〜〜。これはドワンゴ Advent Calendar 2015の最終日の記事です。みなさんはいい子にしてましたか?サンタはきましたか?

なんとまあ、この記事はKwappa研究開発室1年ぶりのエントリーとなってしまいました。どんだけさぼっていたんだ…。

今年の仕事

さて。

今年の主な仕事は、教育事業に関連する開発チームのマネージャーという立場でした。自分でプロダクトコードを書くとボトルネックになってしまう、という(高い授業料を払った)過去の学びから、ひたすら裏方に徹しています。打ち合わせやTODOの数も多く、マネージャーに対してのマネジメントが切実に必要でした。

プロダクトコードを書かないマネージャーであっても、ソフトウェアエンジニアたるもの「ないものは作るしかない」。というわけで、仕事の合間にちまちまとSlack Botを導入し、必要なプラグインを作っていました。

kwappa/kinoco

それがこのkwappa/kinocor7kamura/rubotyに機能を詰め込んでだものです。いくつか自前のプラグインも開発したので、それらを紹介していきます。

kinoco

(さらに…)

この記事はドワンゴ Advent Calendar 2014 – Qiita 12/25の記事です。まだ12/25ですよ!セフセフ!!

なお、この記事はドワンゴ所属のエンジニアが書いたものですが、あくまでも個人の見解であり、ドワンゴという会社やその関係者とは無関係です。

TL;DR

エンジニアの可視化

日本の未来、明るいかも

先日、とある採用イベントに参加してきました。プログラミング経験のある就活中の学生さんが、新卒を採用するIT系の企業20数社と交流する、というイベント。ブースでは企業ごとにプレゼン + 質疑応答、フリースペースでは「高専出身」「プロコン」「データサイエンティスト志望」などのテーマごとにたまり場で交流、というものでした。1枠20分が12枠あり、プレゼンと交流を6枠ずつ担当しました。

フリースペースのテーマの中に「作ってきたもの見せます」というコーナーがありました。「とりあえず話しましょう」とか「今日から就活開始」みたいなカジュアルなテーマに比べると人の集まりは少なかったけれど、予想よりずっとたくさんの学生さんが集まってくれたのには驚きました。スマホアプリ、Webサービス、Unityのゲーム。動画見せてくれた子もいたし、CSVのデータから正規化されたスキーマを返す、なんていうめっちゃ業務なプロダクトの説明もありました。

密かに少子化とスマホの普及、ゲームの高度化による「プログラミング人口の減少」を危惧しているおっさんとしては、いろんなものを手を動かしてコード書いて作ってきた学生さんが思いのほかたくさんいたので、日本の未来も捨てたもんじゃないな、と見直す気持ちになりました(老害発言)。

個人的には、いろいろ作ってみること、それを見える形で公開することは、ソフトウェアエンジニアとして楽しく生き、腕を磨くための大事な行動だと思っています。特に、ある程度時間が取りやすい学生時代にそういう習慣をつけておくと、そのあとのエンジニアライフがより充実したものになるのではないでしょうか。

「技術アピール」お待ちしています

(さらに…)