2018年4月17日、明日の開発カンファレンス実行委員会が主催する、開発リーダーのためのイベント「明日の開発カンファレンス 2018」が開催されました。開発の効率化に取り組むリーダーたちが一堂に会して、現場で学んだ知見を共有する本イベント。第2回となる今回も、さまざまな経験を積んだエキスパート達がプレゼンテーションを行いました。トークセッション「クラウド労務サービス『SmartHR』を支える開発チームの作り方」では、株式会社SmartHRのVP of Engineeringである芹澤雅人氏が登場。急成長を続けるSmartHRの開発の舞台裏を語ります。 面倒な労務管理の現状 芹澤雅人氏：あらためまして、私は芹澤雅人と申します。SmartHRという会社で「SmartHR」というサービスを作っております。前職で社会人になって以来、ずっとWebエンジニアとしてのキャリアを歩んでおります。 2015

あるコミュニティの後、習慣的に飲みに行く。中堅どころや若手エンジニアもいるのでその層のエンジニアが何を考えているのかを聞ければいいと思っている。実際は中堅も後半のエンジニアやシニア層のエンジニアが組織に対する愚痴や自分の不甲斐なさを自虐的に吐露し始める。 多分、誰でも同じなのだろうが、仕事が思うように上手くいかなかったり、評価をされなかったりして不満の一つや二つはあってもおかしくはないだろう。今ここにもっともらしく書いている自分だって、この年齢になっても「なんだかな」と思うことは組織に対してもあるし、仕事にだってある。 愚痴は何も進まない。 それを聞いた周りは気分は聞き流していたとしても聞く前よりは気持ちのレベルは下がるし、それを話す当人はスッキリするわけがない。嫌なことを言語化することで自分の気持ちを可視化できるようにしてしまうのだから。 でも、悩みを聞いてもらうのであればそれはいいと思

週次でミーティングを持っている。いわゆる進捗会議ではなく、プロジェクトの付帯的な活動やその他の活動の状況を聞く。ああ、活動状況を聞いているのだから進捗会議と同じではないか。ただ、違うのはマネージャからの周知のようなものは極力しない。そういったものはchatツールで済ませてしまう。そのほうがログが残るのでメンバが忘れていても遡れて良い。何より、メンバを集めて1時間使うなら、メンバが使った方が良い。 ある回で、シニアのエンジニアが今日は2件話したいと言った。ちょっと言い方がいつもと違うな、と感じた。自分の意見を持っているし実力もあるエンジニアだが、周りに合わせる柔軟性も持っている。そのエンジニアが、である。 実は、その回の前日にそのエンジニアが他組織と某案件で場を持つことを知っていた。更に言えば、前日にその他組織の担当と会話をしていて、担当が案件をどう考えているかを知っていた。まあ、人が悪いと

近頃お会いする方々から採用意欲が以前より高いと感じている。どこかしこもwe are hiring!なう、である。某社においては採用は全方位で、と言い切る創業者も少なくない。 採用意欲は年収にも現れている。某社では4桁は出すとか、4桁には満たないが稼働日が少ないとか条件は様々だ。 付き合いのあったり、面識のあるエンジニアの方も、理由は様々だが市場価値を自ら確かめに出向いたり、条件が合えば新しい職場に移る決断をしているケースが目立ってきた。 もちろん、採用する側としての期待する貢献と応募するエンジニア側が決断する諸条件が折り合えば、エンジニアの流動が決まるわけだ。 もともと、どちらかと言えばいきなり外の組織に移ることを考える前に、まずは組織の中で担当する事業を移ることを考えた方がいいと思っている派である。なぜなら、組織をまたがる異動で（場合によっては）技術転換や求められるロールが変わることに対

今では、もう10年も前のことになってしまうが、某部署に異動していくつかのプロマネをした後がどれも技術的に未経験のソリューションで、若干の助走期間があったがプロジェクトが始まってしまえば助走期間でやったことは大して役に立たなかった。 そうしたソリューションの中で、あるエンジニアが考えた手法があった。ただ、その手法は机上でしかなく、考えた本人も実践でその手法が機能するかどうかは確かめたことがなかった。 一般的なシステム開発手法であるウォーターフォールでの局面間の割り当てから言えば、データ設計などが上流により過ぎている感を覚えるような構成なのだが、これは適用するパッケージの導入と構成の制約も考慮した上での仕立てになってた。 顧客から見れば、システム要件を話す時点で、どうしてデータ項目まで言及するのか戸惑うかもしれなかったが、それはそれで後工程が楽になるのとより早い段階から顧客が当事者意識を持つよ

某社の役員と話をしてたら、何となくキャリアの話まで及んで、さらに立ち上げた事業の経緯を赤裸々に聞くことになった。それがまた面白くて自然と前のめりになるような引き込まれ方になっているのに気づいた自分に何か大事なことを聞いているのではないかと問い掛けをしようと思いかけたが、それではその何か大事な話の続きを失ってしまいそうで脇に起きつつ話を続けた。 氏曰く、 「人生で大事なことは○○から学んだ」 のだそうだ。○○と伏せているのは、まあ、大人の事情だということで。 そういったことを思い出して、さて自分はエンジニアとして、何から大事なことを学んだのだろうと問いかけをしてみたが○○を埋められる言葉がさっと出てこない。 何だろうなと思案しつつ、まあ、プロジェクトマネジメントだよな、と。苦笑しつつもエンジニアの専門として選んだ仕事、職種なのだから当然すぎて面白くない。 ○○に当たるところは、活動する目的や

また、人と歓談した際の気づきである。ある役員にインタビュー形式でその方のキャリアを聞いているとき、途中でこんなことを口にされた。 「自分が言ったことをやる、ということは大変だった」 実際にはその大変だったこと実現されて、分掌が変わったときに代替わりをしたので肩の荷が下りたらしい。世代交代もどうしたものかと思っていたら、部下から手が挙がったのが嬉しかった、と。 「自分が言ったことをやる」ことについて、自分自身を振り返ってみると、やはり出来ていないことの方が多い。あれこれしようと思っていてもそのとおりになっていない。仕事は大見得を切ることはないので淡々とこなしているが、思い通りにならないのは仕事以外のことばかりだ。 あれこれやりたいと思っても出来ること、やらなければならないことを優先してしまうので、もう少し新しいことなり、基礎力的なところをやろうとするとついつい後回しになってしまう。 「言った

プロジェクトでは納期があり、ウォーターフォールなら開発線表でリリース日を設定したり、見積もり可能な仕様かどうかで工程を分けて契約をしたりする。アジャイル開発であればイテレーションごとにリリースする。 何れにしてもプログラムはどこかのマイルストーンでリリースされる。 あるプロジェクトでとても優秀なエンジニアがjoinしていた。joinしていたと言うよりは、プロジェクトの目標を達成するためのプロジェクトチームとしてのスキルセットの重要なポジションを担うために引っ張ってきた。 このエンジニアが作ったプロダクトがあり、多分、50代のとあるクラスタなら誰もが知っているのではないかと思う。 ついつい、このエンジニアに難易度の高い開発テーマがを寄せてしまい、進捗がやばくなってTOCとアサイメントの見直しで乗り切ったプロジェクトがあったことは以前のエントリで書いた。 このエンジニアの凄さはなんとなく伝わっ

元メンバの人とメッセであれこれと会話していたとき、 「エンジニアとして自信が持てるようになるまでどのような不安を抱えていたか」 と言うことを尋ねてみた。 まぁ、なぜこんなことを聞いてみようと思ったか、その背景は簡単に説明した方が良いかもしれない。 もう、50代も数年経験しているとすっかり自分の仕事の仕方が出来上がっていて、担当している仕事で不安になることはリカバリができないくらい失敗らなければそうそう体感することがない。別の表現をするなら、仕事はコントロールできる範疇にある、若しくは体裁を整えるくらいにはキャッチできる。 門外漢だったとしても、入門編でも読んで、友人関係から知っている人を探して飲みながらでもレクチャーを受けて落とし込んでいけばいいというパターンを持っているから、それこそ、まーなんとかなるかなと高を括っている。どこかで痛い目にあうんだろうがそのくらい冷や汗を書くくらいこととは

厄介なことにソフトウェアは形がないため、定規で測ることもできないし、重量を計測することもできない。第一、そうした単位を持たせて設計することができない。 現実的にできそうなものはプログラムのコード、ステップ数やバイナリのサイズがあることにはあるが、作り方により変動するので基準値を決めることができない。 やはり、ソフトウェアはハードウェアのように計測して品質を確かめることはできない。 ソフトウェアは業務要件を実現するシステム要件のほかに非機能要件の性質を持つ。業務要件は業務そのものであり、その一部分若しくは全ての業務をITに置き換える。どのように置き換えるかはIT要件であり、IT要件を実現するのがシステム要件である。 機能そのものの働きではなく、機能全体としての動きは非機能要件として様々な切り口で要求される。 とするとき、ソフトウェアの品質を確かめるにはどうしたら良いのだろうか。 ついつい現場

あるメンバがいて、処理能力は高いのだがもう少し考えながら仕事をした方が良いんじゃないか、と。そう思ったし、何度か伝えたのだがどうもそのメンバの仕方として染み付いているようでこれはこれで困ったものだ、と。 実際は、自分は困らないが、件のメンバは困るのだ。処理能力が高いとは仕事に落としこんでさえいれば、である。その仕事に落とし込むところができないと処理能力を活かすことはできない。 故に、そのメンバは仕事に落とし込むところを開拓しなければならないのに、処理する仕事と同じように仕事を落とし込む作業を処理しようとしてしまう。これはアウトプットの形のないところから進め方を含め作り上げていくような場合に要件を持っている人と衝突してしまう。 なぜなら、処理能力を発揮するパターンと同じように仕様を決めることを持ち出すからだ。ところが今やりたいのは処理能力を活かすことではない。その前段階である。 要件を実現す

これまで何度か仕事上でお詫びをしたことがある。主に、障害報告とか部下の不祥事だと思う。 障害報告だからとか、不祥事だからと特別な服装をしたことはないが、とにかく往訪した目的を果たさなければ楽しくない仕事をしに行った意味はない。 障害報告でも不祥事でも、わざわざ出向いて説明するのは、起きたインシデントに対する事実の確認と事後対処について共有する必要があるステークホルダの立場だからだ。 謝罪の基本 先方はこちらが起こしたことについて利害関係がある為、（多くは不利益を被っていることについて）事後対処の同意と不利益についての要求がないことの確認をしなければならない。 経験から言えば、次のコンテンツが必要だ。 お詫び 事象と経緯 原因 暫定策（恒久策まで時間を要する場合） 恒久策 ただし、こうした内容はステークホルダである当事者間で行われる内容であり、第三者に公表するようなものではない。 第三者へ公

「ちょっと聞いてください」 「ちょっと待って、このメール出したら…ではよろしくお願いいたします…と。それで」 「さっき、上司に呼ばれて」 「やらかしたか」 「まだやってません」 「やるのか」 「先のことはわかりません。やるかもしれませんけど」 「よくない話なんだろう。フラグでも立ったか」 「そんなところです」 「…」 「それで、あるプロジェクトの応援に行くことになりました」 「…」 「しばらくお昼は一緒に行けなくなりました」 「そうか」 「そうです」 「それで」 「あまりいい感じのプロジェクトじゃないみたいです」 「だよなぁ」 「ですよね…。それでどうしましょう」 「いつものようにやるしかないんじゃない」 「すばらく様子見してきます」 「そんな余裕があるといいな」 「こんにちは」 「あれ以来だな。どう、あっちは」 「今晩、空いてますか」 「空いているの前提だな」 「そんなことありません。よ

この、googleの最高のマネージャの8つの習慣ってネタのエントリを見たの、何度目だろうという気がするのだが。 じゃあ、放置すればいいじゃないと思わないこともないのだが、あーこれ自分は成れんなと思ったので最高でない、アンチパターン的なマネージャとしての自分を分析してみよう。自分は素材だからな。 lightworks-blog.com 習慣1　よいコーチであれ。 具体的で、建設的なフィードバックをする。 ネガティブフィードバックとポジティブフィードバックをバランスよく行う。 定期的に1対1の対話をし、部下の強みに合わせた問題の解決方法を示す。 引用　全て上記サイトから。 良いコーチの良いとはなんだ。詳細を読まなければわからんな。曖昧で非建設的な指摘をするマネージャだと最高でないのだろう。 確かに。 でもな、具体的過ぎるとマイクロマネジメントぽくならないか。具体的過ぎるとメンバの仕事を実質やっ

なんだろうと思って読んみでみたら随分前に読んだ物のような気がするのだが、果たして記憶違いだろうか。 デスマーチが起きる理由 - ３つの指標 · GitHub ちょうど、過去に作成したスライドを探していて見つけられず、諦めた後、ひょんなことからスライドを見つけられたのでそれをまじまじと眺め直してみた。 そのスライドは、冒頭でリンクを貼ったデスマを書いたものではないのだが、スライドに書いたプロジェクトも立て直しに入らずに、あのまま進行していたらです待っていたのかもしれない。少なくともあのプロマネは持たなかっただろう。 リンクの先のエントリの最後に書いていあるのはこれからの抜粋だと思うのだが、そりゃ色々とリソースが半減だったらデスマになるのはほぼ確実だろう。ほぼと書いたのは、見積もりが甘くて1.5倍以上の予算が確保できていれば、まあどんなプロジェクトでも収まるからだ。 世の中にはQCDSと言う考

過日、こんなことを呟いた。 減らすのと、足すのどちらが簡単か。減らすためには目的を理解できなければ減らしていいかの判断がつかないし、知識がなければ足すことはできないし。 — ふみさん (@finayama) 2018年5月4日 これは、こんなことを考えていた。 facebookで 開発プロセスのテーラリングは、オーバーオールに体系化された項目から不要な項目を削除するよりは、本質として外せない最小限の体系に必要な項目を足す方が楽だ。 と言う考えを見かけたからだ。 それを読んで、そうかな、と感覚的にそんなことないよ、と思った。感覚的に反応するのもアレ（自分の思慮の浅さ）となってしまうのも自分自身に対して如何と言う感じなのと自分の考えの正誤を確かめたく、表に整理した。 表の項目を分ける条件は次の項目である。1つは体系化された項目から削る、足すと言う振る舞い。もう一つはそれらとの組み合わせとなる別

まあ、脈略もなくエントリを書いていると、もう少し体系的に整理した上でコンテンツを書いた方が良いに越したことがないのだが、ついつい習慣で書きたいネタを探してその日のエントリを拵えてしまう。 拵えるという言葉は美術の先生がよく使っていた。一度自宅に遊びに行ったことがあって、乾燥させて砕いた餅を揚げ餅にして出してくれたのが印象に残っている。今思えば、あの間取りはアトリエも兼ねていたんだと思い出す。 大型連休はのんびりとリフレッシュすることもなく、日々の習慣のことを続ける一方、連休明けのスライドづくりも休み初日から手をつける。なんでも形にしていく確実な方法は、やろうと決めた最初の日に手をつけ、実績を１ページでも残すことが肝要だ。これをしておくだけで、随分と気が楽になる。初日に手を付けないと翌日から自分にストレスを感じるだけだ。 切り口を変えて見せる 資料を作るとき、よく言われることに切り口を考えた

もう20年くらい前だったか、大規模プロジェクトにアサイメントされた。担当は、プロジェクト内で使用するエンジニアが使用する情報共有システムだった。サーバのセットアップ（聞いてなかった）から、パッケージの導入をさせられて（製品担当のエンジニアのオンサイトサポートがあったかもしれない）、あとはプロジェクトに合わせてカスタマイズするというやつだ。 当時のカウンタのリーダが部長級の人で、プロジェクトの中で使わせるのでマニュアルを作れという。じゃあと、作ってみたら速攻でリジェクトされた。もう一度トライしたらこれも速攻でリジェクト。 そのとき、優しく言われたのが 「目次からね。作って」 ああそうなんですね、くらいしか思いもしなかった。言われたことの意味が理解できていなかったのだ。 だからだろう、３回目もリジェクト。 わかってないので解決策が突破できずに悩むこと一日。今から思えば悠長なことだ。今だったら、

SES（システムエンジニアリングサービス契約）の意味を一度確認してみよう。 SES契約は労働法規などでは業務請負の一種とみなされる。このため、労務管理や指揮命令系統などが発注元企業から独立している必要がある点が、発注元企業による指揮命令の下で業務を行う派遣契約との大きな違いである。賃金は技術者の労働力に対して支払われ、システムの完成は支払い要件には含まれない。 民法での典型契約が委任であっても、下請法における取引が「情報成果物作成委託」や「役務提供委託」であっても、労働者派遣法や職業安定法の区分基準では「業務請負」であり[1]、違法派遣や偽装請負に該当しないように注意が必要である。 システムエンジニアリングサービス契約 - Wikipedia 要約すると「自社の指揮命令の下で労働力を提供する」ということだ。興味深いのは民法と労働者派遣法及び職業安定法の区分基準が違う点である。 さて、なぜS