「もったいない」マインドが逆に効率を悪くする。フロー効率とリソース効率から考えるチームで仕事をする理由チーム開発プロジェクト管理マネジメント はじめに 前回、なぜ、ソフトウェアプロジェクトは人数を増やしても上手くいかないのかの記事において、プロジェクト型の人員規模を柔軟に変化させる開発スタイルに関して、理論的なスケジュール削減の限界について考察しました。その際に、チーム型開発や組織とソフトウェアの紐付けについても示唆しました。 今回は、チームでソフトウェアを開発することに関して、「フロー効率」と「リソース効率」という観点から考察し、なぜ私たちはチームで開発するのか、あるいはなぜプロジェクト型を採用するのかについての考え方を深めていきたいと思います。 そして、組織における効率性の価値観が異なると、新しい効率性に関して理解をする前に「もったいない」と感じてしまい、新しい文化を取り入れづらくして

関さんが以前「デジタル庁が立ち上がる今だからこそ、UK GDSの失速について語ろう」という非常によい記事を書いておられましたが、いい機会なので別の角度から：アメリカのUSDSが立ち上がった時のリクルーティングについて、語っておきます。 デジタル庁とは日本政府が公開した「デジタル社会の実現に向けた改革の基本方針（案）」によると、デジタル庁は、「デジタル社会の形成に関する司令塔として、強力な総合調整機能（勧告権等）を有する組織とし、基本方針を策定するなどの企画立案や、国、地方公共団体、準公共部門等の情報システムの統括・監理を行うととともに、重要なシステムについては自ら整備し、行政サービスを抜本的に向上させる」とのこと。素晴らしい。 背景として、『今般の新型コロナウイルス感染症対応において、マイナンバーシステムをはじめ行政の情報システムが国民が安心して簡単に利用する視点で十分に構築されていなかっ

この度、自分が所属するHRBrainという会社で カジュアル面談をした100名の方に1万円、合計100万円をプレゼントキャンペーンをはじめました！ 社長と相談した結果、 カジュアル面談した100名の方に現金1万円、総額100万円をプレゼントすることになりました！！ - DMでスキルや経歴が分かるものを送って下さい - スカウトを送りたい方にカジュアル面談の招待をお送りします - 面談実施後にその場で1万円お渡しします DMお待ちしてます！ pic.twitter.com/iJuZtpGlVF — 川田浩史∈HRBrain (@ssossan) February 20, 2020 何故こんなことを始めたのか、背景を伝えるためにこの記事を書きました。 採用って想像以上にお金がかかる前職ではバックエンドのエンジニアとして開発をしていたので、採用には全く関わったことがありませんでした。 2018年

こんにちは、HRBrain VPoE川田です。 部屋とYシャツと私の「飲みすぎて帰っても 3日酔いまでは許すけど」って良い歌詞ですよね。許して欲しいです。 もうこれ以上部屋とYシャツと私の話は出てきません、悪しからず。 さて、本日はEngineering Manager Advent Calendar 2020の記事です。 エンジニアの評価と給与とグレードの話をします。 想定読者は、もちろんエンジニアリングマネージャーの仲間たちです。 ちなみに今回の内容は「これが俺の考えた最強の制度だ！」と言うつもりは全くなく、みなさんと同じようにずっと悩み続けている中で今現時点での考え方をスナップショット的に記したものなので、数ある考え方のうちの1つと捉えていただけたら嬉しいです。 この記事から「こうした方がより良いのでは？」等、議論が生まれてくれればなお嬉しいです。 エンジニアの給与決めるの難しい問題

こんにちは、ZOZOテクノロジーズで執行役員CTOをしている @kyunsです。 本記事はCTOA Advent Calendar2020の 16日目の記事となります。 この記事ではZOZOでの2年半を振り返り、テックカンパニーを目指す中でCTOとしてどのようなことに取組み、結果としてどういう変化が起きたかについて紹介したいと思います。 同じような立場のCTOやこれからエンジニアリング組織を強化していきたい方々の参考に少しでもなればと思います。 自己紹介と背景 私はヤフーに2006年に新卒で入社し、3年働いた後に当時一緒に働いていた金山と一緒にVASILYというスタートアップを創業し、受託アプリ開発や「IQON」というサービスを開発していました。 何度かの資金調達などを経て、最終的に2017年にZOZOへ売却し、ZOZOの完全子会社となりました。その後、2018年の4月には当時のスタートト

ざっくり年収1,000万円のエンジニアが10名いる会社では、年間1億円の技術投資がなされているわけですが（地代家賃、ライセンスフィー、PC代など含めるともっと）、年間1億円を正しく詳細に把握して、投資をコントロールできている会社は少ないと思います。会社が創業期であれば、最低限作らなければならない機能などは分かりやすく見えていたりするのでまだしも、そのプロダクトでしっかりとした収益が成り立ち、上場企業となるようなレベル感のプロダクトに対する技術投資となると、一部の大きなプロジェクトは把握していても、細かな投資ポートフォリオを常に把握することは難しいのではないでしょうか？今回はこの部分に一石を投じてみたいと思います。 技術投資量を見える化する 投資の最適化とは言いますが、最適化というのは「To Be」の話ですので、まずは「As Is」を知らなければ話になりません。その、まず「As Is」を知る

話したネタ DECって会社は何をやっていた？ IBMと7人の小人達 メインフレームに対するアンチテーゼ、ミニコンピューター NEC PC-9801が大流行した時代 この時代の日本のIT企業は何をしていたのか？ 通産省とのタッグ 富士通、日立、NEC、日本IBMで市場を分け合っていた時代 ソフトウェアはハードウェアのおまけだった SIerという名前が生まれてきた背景 当初は何と何をインテグレーションしていたのか？ トークンリングとイーサネット 90年代の日本の技術者は、どのような開発をしていた？ ユニコードがない時代なので、国際化は大変な仕事だった IT業界の下請け構造はどの時期から発生しはじめたのか？ Unixがのるワークステーション vs Windowsがのるパーソナルコンピューター デヴィッド・カトラー Windows95のこの時代もUXが優れていたのはAppleだった、ただこの頃のM

ITエンジニア35歳定年説。今でも時折語られるワードですが、文脈としては「35歳定年説なんて嘘だよね」という形で使われがちです。現在LIGで年齢制限無しで採用活動をしていることもあり、改めて市場を調査中です。私自身も38歳で転職してきたので、今回は35歳以上のミドル層、主にエンジニアがどこで活躍しているのかついてお話します。今はまだ20代で怖いものなしの方にも加齢は不可避な事情であるため、現在のミドルの状況は知っておいて損はないでしょう。また、30代未経験エンジニアの方々についても触れていきますので参考になれば幸いです。 ITエンジニア35歳定年説とは何だったのか　この話が出てくる度に少し調べてみるのですが、この説は詠み人知らずなようです。IT業界の黎明期から言われていたとも言われています。 次に出版物について調べてみたところ、2005年に2冊ほど見つかりました。いずれも著者自身の経験が書

こんにちは、元テックリード、この10月からVPoT（Vice President of Technology）に就任した、Classiの丸山（id:nkgt_chkonk）です。 前回の記事では、前CTO（現VPoE＝Vice President of Engineer）の佐々木が「Classiで発生した2つの問題を繰り返さないために我々が取り組んでいること」というタイトルで、社内体制を変更したことをお伝えしました。 今回はわたしから、組織体制の変更の背景や、現在どのような体制で、どのような課題に取り組んでいるのかをさらに詳しくお伝えしたいと思います。 4月~5月にかけての2つの問題の原因となった「甘え」 前回の記事でお伝えしたとおり、2020年の4月〜5月にかけて、Classiは外部の攻撃者による不正アクセスおよびデータの漏洩という大きなセキュリティインシデントと、アクセス増による大規模

新型コロナウィルスの影響も長引いてますが、皆さま無事お過ごしでしょうか。私は幸い無事です。 日ごろチームでソフトウェア開発をしているのですが、近年社内ではペアプログラミングやモブプログラミングが流行しています。 私のいるチームでもここ二年ほどモブプログラミング（ないし類似のプラクティス）に取り組んできました。 モブプログラミングについて正確にどのようなものかは以下の記事などをご参照いただければと思います。 簡単にまとめると、要求分析やコーディング等幅広い開発作業を、同じ場所に集まったチームの共同作業でこなしていくというものです。 このご時世ですので、最近はオンラインのミーティングルームに集合する形式でしたけど。 www.agilealliance.org ここから先は、非常にパーソナルな、私に限定された体験になります。 どの人・チームにも適用できる話ではありません。ではありますが、どの人・

スマートキャンプの郷田です。 ​ 先日、本年度のpmconfに参加させていただきました。 pmconfとは、2016年から年に1度開催されるプロダクトマネジメントに携わる人たちが学び・切磋琢磨する場が提供されるカンファレンスです。 https://2020.pmconf.jp/ 私は昨年のpmconf2019から参加させていただいているのですが、昨年のカンファレンスで得た知見を実際にこの1年実践してきたものを紹介したいと思います。​ pmconf2019への参加まで 岡田 康豊さん：“失敗事例で学ぶ” 失敗しないプロダクトマネジメント - PMの必須スキルと、自走する組織のつくりかた - 小城 久美子さん：プロダクトの強い軸を作るプロダクトマネジメントフレームワーク 二木 祥平さん：LINEにおけるお金とユーザーのジレンマ 全セッションを通して その後の変化：社内でのPM認知 最後に ​

アンドパッドのRailsエンジニアの @KanechikaAyumu です！ 10/27にForkwell主催の「Forkwell Open Sesame! ｜SaaS企業のリードエンジニア同士でお悩み相談会」に登壇しました！ forkwell.connpass.com SaaS企業３社（株式会社LegalForce、株式会社アンドパッド、メドピア株式会社）とファシリテーターのwillnetさんと困りごとを持ち寄り、企業同士ならではの開発課題をお互いに質問し合いました。 私は「継続的Gemアップデートどうしていますか？」という質問に対して 「Rails 継続的Gemアップデートの 仕組みを」というタイトルで発表しました。 発表した内容について 創業時から開発を続けてきたRailsアプリが５年程経ち、徐々に大きくなり（コードの行数は３０万行程度）、Gemのバージョンが古いなど、色々と課題を抱

まえがき コードレビューの目的 大目的 小目的 チェックリスト 優先度高（大きな損失を生む問題・後からの修正が困難な問題） 優先度中 優先度低（システムに大きな影響を与えない問題・後からの修正が容易な問題） レビューを負担にしないために レビューサイズのコントロール 誰がレビューをするか 議論をどうまとめるか 批判と個人攻撃 レビュワー向けアドバイス Code author向けアドバイス 参考文献 まえがき コードレビューの有効性が説かれるようになって久しい。しかし、コードレビューをするべきという観念ばかりが先立ってしまい、何のためにコードレビューをするのか、どのような点をレビューするべきなのかといった、目的や進め方に対する意識が曖昧なケースも数多くあるように思われる[6]。コードレビューの目的を理解せずに惰性でレビューしているだけでは、いずれレビューそのものが形骸化し、単に承認のハンコを

こんにちはBASE株式会社取締役EVP of Developmentのえふしん( @fshin2000 ）です。 今回は、年末の給与改定から運用を開始する評価グレード制導入のお話を書いてみたいと思います。 これまで人材採用時の給与決定や社員の評価時には、マネージャ間で相談し役員承認の上で給与を決めていましたが、その基準や空気感は詳しく社内のメンバーに共有できていませんでした。理由として、中途主体の採用だとどうしても前職給与に影響され、人によって給与にばらつきがでてしまうため、体系だった形に整える機会がなかったのですが、今度、社内に評価グレード制というものを導入することになり、各給与レンジの方に求めるスキルや意識についてまとめたのでこちらで公開いたします。 評価グレード制というのは、一般的に等級と呼ばれるもので、一定サイズ以上の会社のご経験がある方なら、類する制度はどこでもあると思いますので

コンテンツブロックが有効であることを検知しました。 このサイトを利用するには、コンテンツブロック機能（広告ブロック機能を持つ拡張機能等）を無効にしてページを再読み込みしてください。 ✕

この記事は、私が責任者を務める事業のエンジニアが、転職を考えていたのでその転職活動がうまくいくよう相談にのり、無事希望する転職ができて喜びあった、という体験談です。 自社の社員の転職を支援するという経験が、個人としてとても貴重な体験だったことと、支援をしながら、もしかしてこれは新しいマネージャーとメンバーの関係なのかもしれない、と感じることがあったので、どんな意図で進めていたのか書き出してみようと思います。 メンバーの退職と向き合うのは、マネージャーにとって重くて大事な仕事だと思います。マネジメントに携わる人にとって、私の経験がお役に立てたら嬉しいです。 自己紹介が遅れました。株式会社groovesで Forkwell 事業の責任者を務めている赤川と申します（私のポートフォリオ）。#InfraStudy や #DataEngineeringStudy の主催をしておりますので、そこで知って

単純に仕事の用事なのですが、俗に言う経営層と言える立場の方々にヒアリングする機会が増えたことで、とあるセリフを頻繁に耳にするようになりました。 「事業の話ができるエンジニアがいないんだよね。本当に困りますよ」です。 これは僕が事業の話をできるとかそういうことを言いたいのではなくて、各社の経営層の切実な想いであり１つや２つの組織で聞いた発言ではなく、あらゆる組織で耳にする強烈なペインであると言いたいんです。 本当に、文字通り、全ての組織でこの発言を聞きました。 僕個人としては、「え？そうなんですか？結構いると思いますが」って当初反応してたんですよね。何故なら、自分の周りには幸い「技術にだけ興味があるエンジニア」が少ないからでして、彼らがそこまでの切実さで何を求めているのかはっきりとわかっていませんでした。ただ、僕も諸事情あって彼らと似たような視点を持たなければいけない状況になり、この発言の理

サンフランシスコベイエリアでのITエンジニアの給料は東京より高いが、税金や物価も高いと言われている *1 。ではどちらに住む方がより多くの金が手元に残るのだろうか。 僕がベイエリアに移住してからちょうど1年が経ったので、僕が東京とベイエリアそれぞれにいた頃の出費やタイトルでどのくらい家の収支に差が出るのかということをまとめてみる。なお、この記事を書いている時点で 105.60 円/ドル なので、ドル円の変換をする際はこのレートを用いる *2 。 収入 基本給 ベイエリア 東京 $153,600 913万円 GitLabは同社の世界各地での待遇計算基準を 公開 しており、地域間の差異を公平に計算するには割とよくできたベンチマークなのでここの年収をそのまま使う。計算に使われる location_factors.yml では、日本の給与はサンフランシスコの 56.3% になっている。 Calcu