CTOA Advent Calendar 1日目のバトンを受け取りましたので、1日目となる今回は、CTOに求められる役割の変化について、自分のこれまでの振り返りを兼ねて記事を書いてみようと思います。ちなみに今週はマガジンの連載をこちらの記事に代えさせていただければと。 普段はこちらのマガジンでソフトウェアと経営についてつらつらと書いています。ご興味ある方、年末の時間のあるときにでもご一読いただければ幸いです。 はじめにこの10年、エンジニアとしてのキャリアをスタートして今に至るまで、一桁人のスタートアップから1000人近い規模の開発組織を抱えた大企業まで様々な規模の組織のCTOを経験してきました。おおよその流れとしては、学生時代に小さなスタートアップを3社、その後Gunosyにて一桁人から60人前後の開発組織、現在はDMMのグループにて合計1000人弱の開発組織にてCTOをしています。 C

フロントエンドのパラダイムを参考にバックエンド開発を再考する / TypeScript による GraphQL バックエンド開発

今やどんなビジネスでもITが関係している。ITを支えているのはソフトウェアだ。あらゆるものがソフトウェアで実現される時代になった。そんな事業や生活に密接に関わるソフトウェアだが、その開発について知られていないことも多い。 とくに経営者がプログラミング経験がないことで、ソフトウェア開発のリーダーシップをとるときに的外れなマネジメントをしてしまうことがある。あまねく経営者がプログラミング経験があれば良いのかもしれないが、それは現実的ではない。 プログラミング経験がなくても、せめてソフトウェア開発の特性について知っておくと良さそうなこともあると思い、なるべく専門用語を使わずに本稿を書いた。 プログラミングは製造ではなく、設計である いまだにソフトウェア開発を、ビルや家屋の建築に喩える人がいるし、工場でモノを製造するようにプログラムが作られると思っている人もいる。 ここが間違いのもとだ。ハードウェ

You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session. Dismiss alert

エンジニアリングマネージャーたちのパネルディスカッション 織田晃弘氏（以下、織田）：では、さっそく始めたいと思います。「エンジニアリングマネージャー・パネルディスカッション」とのことで、さっそくですが、登壇者の紹介に入りたいと思います。 まず、本日モデレーターを務めさせていただきます、織田と申します。 私自身もエンジニアリングマネージャーをやらせていただいておりまして、社内では「エンジニア組織を開発していく」というテーマで集まっている「エンジニアタスクフォース」という委員会活動のようなものの責任者として、委員長をさせていただいております。 では、お一人ずつマイクで自己紹介をしていただければと思います。 及川卓也氏（以下、及川）：おはようございます。及川卓也と言います。今年のはじめから法人を作りまして、「Tably（テーブリー）」と発音するんですけれども、そこの創業者・代表をしております。

はじめに ソフトウェアエンジニアリングマネージャ（以下、EM）に求められる責務は、多岐にわたっています。 流動性が高いITの業態である一方、日本型メンバーシップ雇用と米国型のJD型雇用との隙間にあって、責務と権限の曖昧な状況の中に置かれることも少なくないように思われます。 このような状況下で、メンバーからも経営からも双方にそれぞれの考える理想的なマネージャであることを求められることもしばしばあるようです。結果として、マネージャの休職など精神的なストレスも高さが問題になっています。 また、ソフトウェアエンジニアにとって、プログラミングにおけるスキルとくらべ、マネジメントに対するそれのモビリティ（会社を変えても有効であると思える程度）が低く見えると言ったことから、ソフトウェアエンジニアにとってキャリア形成に効きづらいのではないかと考えてしまうことも自然なことです。 その結果、ソフトウェアエンジ

こんにちは。開発部門HR（技術人事）のOKANOです。 前回は、それまで勉強会文化がなかったぐるなび社内に、学びの文化が芽吹くまで についてご紹介しました。 今回はこの話の「それから」についてお伝えしたいと思います。 とりあえずスタートを切った！けどこれからどうしよう、という方 社内の文化づくりに奮闘されている方 こんな皆様のご参考になれば幸いです。 「勉強会プロジェクト（以下、勉強会PRJ）の芽生え」は、「0を1にするお話」でした。この中でもそれなりにもがいてはいたのですが、成長期（1を5に増やすお話）に移る過程の今回のお話でも、かなりもがいてきました。 未だ努力の最中であり、完結はしていない事をご承知おきください。 運営体制の甘さが発覚 まずは行動を起こすこと！ が「芽生え」フェーズでの行動指針になっていたこともあり、なかば勢い（だけ）で運営していたところがありました。 具体的には、

先日とあるベンチャー企業を辞めた。 ベンチャーの失敗はよくある話だしツイッターでもよく見かけるが、実際に自分の目の前でベンチャーが死んでいく様子を見た。 ----- 僕が働いていたその会社は、入社当時は社員数は数十人くらいの規模、創業してまだ数年ほどのいわゆるベンチャー企業だった。 数年前からのとあるブームの波に乗り「最先端領域のベンチャー」というラベルが付いた会社だった。 僕の入社当時は非常に勢いがあった時で、仕事の引き合いも多くきていたし、市場の成長と共に会社が伸びていっている空気を感じていた。 そんな勢いに乗っていた状況だったが、社長を始めメンバーのほとんどはエンジニアで、ビジネスをつくれるセンスと能力のある人がいないことが課題だった。当時の会社の経営状況がどんなだったか詳細は知らないが、潤沢に利益があるわけではなかったと思う。VCから調達した資金を消費しながらムーンショットを狙って

心理的安全性の高いチームを作るためにサーバントマネージャーに徹する話などを聞くことがありますが、なんか大変そうだなーと考えてたら、これは組織設計の課題だと思ったわけです。 サーバントマネージャーは過渡期と割り切って、本来の仕事である課題解決に時間を使えるようにしていったほうがいいです。 心理的安全性とは他者の反応に怯えたり羞恥心を感じることなく、自然体の自分を曝け出すことのできる環境や雰囲気のことを指します。 だそうです。失敗するかも…と早めに言えることはアジャイルな組織には必須です。 心理的安全性は1人のメンバーが日常的にコミュニケーションする相手との視座、視野、視点が近いと高くなると仮説を立ててみました。 視座、視野、視点の図 https://tech.drecom.co.jp/viewpoint-of-being-leader/視座が離れてる例：リーダーが超ベテランでメンバーが超若い

こんにちは、ゆのん(id:yunon_phys)です。この記事は Akatsuki Advent Calendar 2018 の22日目の記事です。 前日は@kackytwさんのDQNの学習速度を改善するでした。 Engineering Managerのjob descriptionを共有する流れ 近年、Engineering Manager(EM)業界が賑わってきています。特に2018年は非常に活発化した年でした。書籍としては、エンジニアリング組織論への招待とエンジニアのためのマネジメントキャリアパスという名著が生まれました。また、Engineering Manager Meetupが3回開催され、Slack workspaceでは12/22時点で268人となっています。EMのためのPodcast EM.FMも誕生し、総再生回数が10,000回を突破するなど、多くの方から注目を集めていま

機械学習チームの林田(@chie8842)です。好きなスポーツはテニスとスノボです。 システムは、その当時の最新の技術で作ったとしても必ずレガシー化します。 機械学習システムも他システムと同様、一度デプロイしたら終わりではなく、継続的なメンテナンスが必要です。昨今機械学習は、特に技術の進歩が目覚ましいため、レガシー化するのも早い分野といえます。本稿ではレガシー化した機械学習アプリケーションのメンテナンスと、それに伴うGPU環境からCPU環境への移行によって、大幅にシステムの運用コストを削減した例をご紹介します。 機械学習アプリケーションにおけるコスト課題 クックパッドにおける最初の大きな機械学習プロジェクトである料理きろくがリリースされたのは、2年前のことです。それ以来、様々な機械学習アプリケーションがデプロイされ、現在では大小含めて30を超える機械学習アプリケーションが運用されています。

エンジニア歴17年の俺が、事業系の開発タスクをバンバン投げてくる非エンジニアに、保守の必要性を死ぬほど分かりやすく説明する。 [Ateam Lifestyle x cyma Advent Calendar 2018]の5日目は、株式会社エイチームライフスタイルの@gonjyu121が担当します。 はじめに最近のWEBサービス運営チームというと、事業運営や企画営業のチームと、エンジニアチームが一緒になって働く事が多いですよね。 そんな時、多くのエンジニアが、 「品質保持やリファクタリング、改善系のissue（タスク）の優先度がなかなか上がらず、着手できない・・・・・・」 といった悩みを抱えがちです。これなんですが、非エンジニアの皆さんからすると、 「エンジニアがすごいのは分かるんだけど、何をやってるか、なんでこんな時間がかかるのか、正直分からないんだよなー」 と思っていたりします。こんな話、

日本では「ブロックチェーン」は過度な期待、「DevOps」は幻滅期、「ビッグデータ」は陳腐化へ。ガートナーが「日本におけるテクノロジのハイプサイクル」2018年版発表 調査会社のガートナーは毎年、先進テクノロジーに関する「ハイプサイクル」を発表しています。 ハイプサイクルとは技術の登場から安定までを5つのステージに分けて説明したもので、黎明期から過度な期待を経て幻滅、啓蒙、安定へと移行する途上のどこにその技術が位置しているかを示しています。 米ガートナーは2018年8月に「Hype Cycle for Emerging Technologies, 2018」として今年のハイプサイクルを発表し、汎用AIは黎明期、バイオチップやディープラーニングは過度な期待、複合現実は幻滅期などと位置付けています。 同社の日本法人であるガートナー・ジャパンも10月11日付けで、「日本におけるテクノロジのハイプ