にたまごほうれん草ブログ

はてなダイアリーから移行したブログ。以前のはこちら→http://d.hatena.ne.jp/emergent/

アラフォーからベンチャーのプログラマーに転職して2年経ったけど、正直な感想書いてみる。

以前こんな記事があった。タイトルはそれを少しもじった形。より正確に書くなら、「アラフォーでベンチャー企業のエンジニアに転職して2年経ったけど、〜」となるかな。

shimasei.hatenablog.com

そこにこんなブコメを書いたらいくつかスターをいただいたので、少し時間が経ってしまったけど書いてみることにします。

未経験じゃなくて、PM系キャリアからアラフォーでPG@ベンチャーに転身した話なら書けるけど需要ある?

現在の会社に転職したのが2018年9月なので2年とちょっと経過したことになる。未経験からの転職エントリはよくはてブ人気エントリーに上がっているけど、私のようなパターンの人の転職エントリってあんまり見たことないので。

以下に該当するような人にはひょっとしたら役立つかもしれない。

  • ある程度、情報系のバックグラウンドがある
  • 就職してからは、仕様作って外注する立場だったり、プロマネ職で開発よりリソース調整が業務のメインだったりする
  • でもやっぱり自分の手でコードを書いてプロダクトを作る職に転職したい

書いてたらめちゃくちゃ長くなったので先に謝っとく、ごめん。

前職までは何をしていたか

私自身について簡単に書いておく。→簡単にならなかった。4年コーディング、9年企画&マネジメント職、ということを書いている。あとは飛ばしてもよい。

現職は3社目。大学は電気・情報系(5類)に入学したが、別に小さい頃から電子工作に興味があったとかパソコンをバリバリ使ってたなんてことはなく、入学してから初めてコンピューターに触れた。家電メーカーで開発していた父親に憧れて、どちらかというと電気電子工学を学ぶつもりだったけれど、2000年あたりのインターネット常時接続時代到来とともにネットワークにどっぷりハマり、進路は情報系に転換。そのままソフトウェア開発者志望で最初の某家電メーカーに就職した。

最初の家電メーカーでは、最初の4年間ぐらいは組み込み向けLinux上のソフトウェアをCでコーディングするようなお仕事をしたり特許を書いたりしていたが、その後入ったプロジェクト(緊プロ)で電子書籍サービスの事業立ち上げチームになり、どちらかというと企画メインで、ソフトウェア開発やコンテンツ製作そのものは開発パートナー企業に委託して、パートナー企業と自社の間を行ったり来たり打ち合わせの連続するような仕事だった。まだまだ未熟だったのでものすごく非効率な仕事の仕方をしていたかもしれない。

その後、サービスインすると、協業先とのジョイントベンチャーに出向してオンライン書店の運営をしたり、解体後は自社にもどって営業に近いことをしていたり、と徐々に開発職ですらなくなっていったのであった。

そこで最初の転職をしようとするが、開発職は自分でコーディングするような会社はどこも落ちた。実績でいうと「◯◯の開発をしました」だったり「△△サービスを作りました」だったりとアピールできるものの、実際は自分でコードを書いてないのでコーディング試験で落ちる。プロマネというほどきっちりとした開発プロセスを学んでもいないので開発リーダー職も落ちる。

そんな折に、電子書籍サービスの開発でお世話になったパートナー企業からお声がかかってそちらに転職した。そこでは、受託開発もやっているが、独自技術を使っての製品を大企業に提案して、そのライセンシングと合わせて開発委託業務をもらうようなことを主にやっている会社だった。ここでも、自分でコードは書かないが、最初はアプリ仕様やその後の運用を提案しながら仕事をもらえて結構楽しかった。

その後、同じ顧客の案件で炎上していたプロジェクトがあったのでそこに入り、なんとか頑張ってこなしたら同じアプリ案件をずっと担当することになりそのまま開発リーダーになっていた。その仕事で、顧客や対向サーバー開発担当の某SIerと折衝や自社内のリソース管理を通して、開発プロセスや品質の考え方を学ぶことができた。オフショア開発は安易に手を出すと死ぬということも学んだ。

終電どころかタクシーで帰宅して朝10時に出社するような生活がちょくちょくあって疲弊したというのもあるが、やっぱり自分でコードを書いて開発したいという思いは捨てきれなかった。このとき37歳。

現在どういう会社にいるか

リンク先ブログの書き方に倣うと、情報通信サービス系の自社開発企業、ではあるんだけど、音声処理技術をメインとしたフェアリーデバイセズという会社にいる。社長がゴリゴリのエンジニアで、プロダクトの多くは社長自身が開発したものであった。

入社当時社員20名程度という小規模な会社だが、研究チームと開発チームがあり、私はそこの開発チームに入った。

年齢層は高いかどうかよくわからないが平均年齢35ぐらいといった感じ。社長は私より年齢が一個下だがめちゃくちゃ頭が切れるタイプである。

会社全体の文化としては、企業というより大学の研究室に近い感じで、フレックスでもあるが遅くまで残業することは推奨されておらずのんびりとした雰囲気であった。コロナ以前ですら就業規則にリモートワークが組み込まれていたので、埼玉県から通っている私には非常に働きやすい環境である。

会社としての仕組みは現在でもまだまだ整備中だが、社員の働きやすさを第一に考えて整備されてきているので、規模が大きくなってきても堅苦しいところは少なく、よい会社であると感じている。

どうやって入社したのか

さて、なぜこういう技術オリエンテッドな会社に、私のような「典型的な技術職ではない」人間が「技術職として」入社できたのか。私自身の想像では、10%が実績、20%がハッタリ、残りはタイミング(運に近いかも)だと思う。

私は、長らくコーディング職から遠のいていたとはいえ、ITプロダクトや事業の開発には身を置いていたので、職務経歴書にはそれなりのプロダクト開発経験が並びはする。なので、書類選考は通ることが多い。ただ、1回目の転職活動時は、上述の通りスキルが合わないため、スキルも見合うように半年程度は業務時間外でプログラミング学習をしてきた。

と言ったことをやってきた。

それでも、本職プログラマーの人に対しては技術的な優位性はそこまでアピールできない。しかし、前述の経験から「プロダクト開発をゴールまで導く」「開発チーム作りができる」というポイントをメインでアピールしつつ、その中で自分もコードを書いていくんだ、という気概を面接の場ではアピールした。

最終面接では、社長の矢継ぎ早の質問や議論にかなり苦戦した。正直ここまで頭も口も回る人間がいるもんかと感じたけど、答えられる質問には即答し、わからない質問にはわからないと即答し、プロダクト開発のディスカッションに対しては経験を活かしていくつかのパターンで提案する。結果的に、これで内定を得ることができた。ただし、これは後述するが、マネジメント経験があるメンバーを会社が欲していたというところによるところが大きい、と入社後に知ることになる。なので「残りはタイミング」と書いた。

ちょうど今日、たまたまはてブ人気エントリーに上がっていた以下の記事を読んだが、スタートアップの成長過程で「2. 若い社員を増やしたがる」で書かれている「マネージャー不足」に陥る(あるいは陥らないようにしようと考えている)時期が来るはずである。なので、そのような企業とマッチングすることができれば、プログラマー職から離れている人でもプログラマー職に返り咲くパスを作ることはできると思う。

anond.hatelabo.jp

ちなみに、面接に関する余談。私は面接の場で「C言語をやってきたので(プロダクトのメイン開発言語である)C++にはすぐ追従できます」と口走ったが、これはとんでもない誤りであった。この時点で落とされなかったのはラッキーとしか言いようがない。

入社して何をやってきたか

なんだかんだ2年経ったので色々やったが、最初の半年ぐらいのことを思い出しながら書いてみる。

入社して、開発チームに1エンジニアとして配属された。最初はチームリーダーから、ちょっとした機能開発のテーマをもらって、まずは1週間ぐらいでそれを対応した。開発対象のソースコードリポジトリ自体はGitHubのプライベートリポジトリにあったが、開発を始めてからリリースまでの間にすぐに課題が山積されていることに気づいた。

  • リポジトリが大量にあるが、どれが何のリポジトリで何の機能を持つものか一切ドキュメントがない
  • Redmineは形だけはあったがほぼ運用されておらず、タスク管理されていない
  • タスク管理されていないので、誰が何をやっている(やってきた)か、メンバー同士が把握していない。週に一度、今週は何やったよーという報告を各自がするだけである
  • 顧客からの要望や不具合指摘が営業チームから入ってくるが、誰もアサインされないので /dev/null に消える。催促されたら誰かが急いで対応するのできっちり検討されてないプロダクトができあがる。
  • 商用サービスをリリースする手順も共有されていないので、日中にえいやとサーバーが再起動されていた(チーム内にちゃんとできない人がいないわけではなかった)
  • テストがろくにされていないので、デグレる→直す、が頻発する
  • それらの課題がわかっていても「やらなきゃなー」で再び /dev/null

要は、チームとしての体を成していないのであった。なので、まずは当たり前の開発体制を1から作ることを始めた。

  • 開発チーム内の体制づくり
    • タスク管理や、レビューなど、使うツールを全部定める。機能面で過不足が今後でるかもしれないがとりあえず使い始める
    • チーム外からの対応要望(期限のあるもの)と、チーム内の内部課題(放置されているバグや、リファクタリング課題など)をわかる限りで全部洗い出してタスクチケット化する
    • タスクチケット化したものから半年分の対応計画をおおまかに作成
    • 対応計画から、メンバーと相談しながら主担当をアサインしていった
    • 開発着手からリリースまでのプロセスをメンバーみんなと共有し、コードレビューを必須とした
    • 現在のシステム構成やデプロイ時の手順などを、メンバーに聞いて回り自分でドキュメント化していった
  • 開発チーム外とのやりとり
    • 社長や営業チームと話し、会社としていつまでに何を作りたいか、計画が必要なものをヒアリングして回り、上記の計画に反映していった
    • 開発チームへの要望や指摘を入れるルートを一本化した(基本的には私がフロントで受け、タスクチケット化し、対応時期と担当者を決めて連絡する)

とまぁ、書き出してみると色々大変そうだが、誰もやりたがらなかったことなので裁量を持って対応でき、当時は私含め6人のチームなので業務時間の三分の一程度でそれらをやりながら残りは自分に開発タスクをアサインしてコードを書く仕事を進めることができた。ちょうど、商用サービスが開始したばっかりで大きな顧客がまだいなかったというのもラッキーだった(当時の状況では大きな顧客がつくこともなかったかもしれないが)。

そこから半年かからずにそれなりに軌道に乗るようになったので、チームで1on1という名の個人面談を勝手に始めて各人の状況や感想を聞くようにしたり、足りないスキルを補うために採用活動をしたり…としてたら、入社後1年ぐらいしてマネージャーに昇格し、今に至るという感じである。

マネージャーになってからは会議の時間が激増して一時期はほとんどコードを書けなくなったけど、今度は自分のタイムマネジメントをしながら死んでもコードを書く、という形でやってたら(途中をめっちゃ端折るけど)「実践Rustプログラミング入門」を出版していた。

前職までとの違い

冒頭のブログ主さんは中学校教員とプログラマー職で比較しているけど、私の場合は業界自体は変わらないので「それなりの規模の会社」と「小規模のベンチャー企業」という観点で比較してみる。

生活の安定に関して

いい年した大企業経験者からすると、小規模のベンチャーへの転職で懸念になるのは収入面であろうと思うが、技術者であるところを鑑みられているからか、特に不満のない収入を得られている。これは当社だけでなく、転職活動時に別で内定を頂いたスタートアップ企業も同程度の年収提示をしてもらえたので業界的にそうなのであろう。(そうでないと得られないスキル領域であるのかもしれない)

あとは、自分の裁量で仕事量と就業時間をコントロールできるので、家族との時間もそれなりにとれている(少なくとも前職よりは)と思っている。どうだろう。こればっかりは妻に聞いてみないとわからない。子供はいない。いたらまた違うのだろうが、当社の子持ちの人は9時〜18時のような時間で勤務していたりするし、子育てしながら時短勤務のプログラマーもいるので、柔軟な働き方ができる就業環境にはなっていると思う。

精神の安定について

大企業だと自分のコントロールできないところで色々決まったり、受託開発だと顧客都合で頻繁に連絡があったり、と心が乱されることが多かった。これは、プロマネをやっててもそうだし、プログラマーであっても同じだろう。

現在は基本的に顧客のフロントに立つことはなく、技術的なやりとりのために自分がフロントに立つ時は電話での連絡をさせない・不定期な緊急会議をしないということを意識することで非常に安定するようになった。顧客が何度も会議を求めてくるようなときは、だいたい開発状況がつかめなくて不安になっているときなので、極力一発で黙らせるように心がけている。

黙らせる、というと言葉が悪いが、要するに、

  1. 相手が何の情報が欲しいのかを事前にヒアリングし、
  2. 準備して過不足なく情報提供し、
  3. ついでに電話をかけてくる担当者のその先にいる上司にどう報告すればいいのか・何を調整してくればいいのか、も教えてあげる

ということである。

コントロールできる範囲

仕事上の裁量は大きいし、プログラマーとしての成長は自分次第だし、で、コントロールできる範囲については文句なしで現在の方が大きい。「こんなの作ってどうするの???」という話には遠慮なくNoと言えるのは大きい。

リモートワーク

これは、前職まででも勝手にやっていた(ルールとしてOKだったわけではないが…)ので特に変わった感じはしない。今ならコロナ禍で大企業でも整備されてきたのではないだろうか。

技術イベントや勉強会への参加

前職までも、技術イベントへの参加はできたが、事前申請や事後レポートが必要だったりで多少面倒であった。今は、ある程度事前に経営陣と「こんなこと話すよ」と合意しておけば勝手に行って話をしてもよいので自由である。むしろ、個人としてのプレゼンスを外で発揮してこいというのが会社の方針なのでまだまだ足りないと思っている。もちろん、これはマネージャーである私の特権でもなんでもなく、技術メンバー全員に推奨していることである。

コミュニケーション

ロジカルなコミュニケーションが必要なのはもちろん前職まででも変わらないが、社交辞令や謎マナーを強要してくる人がいないのがとても居心地がよい。

求められる能力

これに関しては、冒頭のリンク先のブログに書かれているのがその通りなのでそのまま引用する

コミュニケーション力

チームの中で溶け込んでやっていける能力、というか態度・姿勢。

といっても普通に話せる能力があれば大丈夫だと思う。

説明力

自分の考えを他者に正確かつわかりやすく伝えられる能力。これが一番大事な気がする。

自走力

質問すればすぐに誰かが答えてくれるような環境ではあるが、当然ながら業務もあるわけで、一から手取り足取り教えてくれることを期待してはいけない。

すぐに「教えてくれ」ではなく、まずはいろいろ自分で問題解決のトライをしてみる、という態度が必要とされる。

一点追加で書くが、マネージャー視点から欲しい能力としては、「報連相ができること」(特に相談)である。

自分としては、悩みを吸い上げやすい環境を作ろうとしているし、悩んでいそうな人にはこちらからアプローチするが、プログラマーの特性として、課題にぶち当たるとそのまま永久に帰ってこれない渦に飲み込まれて悩んでしまう人が一定数いる。メンバーの仕事に道筋をつけるのもマネジメントのうちなので、渦に飲み込まれてしまう前に、自分の取り組もうとしていることがこれでいいのか、これしかないのかを相談すること、相談のタイミングを見極めることも能力のうちであると考える。

周囲のメンバーにはそういうことを言ってはいるが、プログラマーとしての自分はまだ発展途上だし、同じ成長課題を抱えているのである。自分のことを客観視しながら仕事をしないといけない。

転職の年齢について

元ブログでは「ほとんど関係ない」と書いているが、アラフォーともなると、20代のときのような体力もなく身体的な衰えが感じられたりするので、「転職後10年ガッツリ働く」ことを考えているなら40になる前に転職するのがいいのではと思っている。というか私はその焦りがあったので37で転職を決意した。

現在の、人を採用する側の観点でも書くと、アラフォー以降となるとプログラマーとしてはよっぽど尖っている人でないと少なくともチームマネジメントなどのコーディング以外の要素を求めてしまう。50を超えた人であれば、引退が近いことも想定して「数年間の採用でもメリットがあるか」を観点に含めてしまう。あと、大企業の人であれば、だいたいそのぐらいの年齢だと管理職になっていて、プログラマーやってると言われると逆にコミュニケーションに難があるのでは?と勘ぐってしまうこともある。傾向として。

あとは、年齢が高くなりすぎると、それまでの経験を活かすというよりは、大上段に構えて自分の知見をひけらかすタイプの人がいたりするので、素直な人が多い技術者の中にそういう人を放り込むのはリスキーだろう。

おお、それはまさに、こんなブログを書いている私のことではないか。みんな、私の言うことなんて聞いてはいけない。

(おわり)

私だって『実践Rustプログラミング入門』を書きました

8月22日に『実践Rustプログラミング入門』を発売してからすでに1か月弱経ってしまいましたが、共著者の1人として参加するという貴重な経験をしましたので、私もブログにしたためておこうと思います。書かずにいる間に増刷が決まっていました。ありがとうございます!

他の共著者の方々のブログ記事

執筆のきっかけや感想など

2019年のクリスマス、フォルシアの松本さん(id:matsu7874)からのメールでRust本執筆にお誘いいただいたのがきっかけでした。その後、年が明けてから共著者陣で集まりテーマをブレストし、大まかな方向性が決まったと記憶しています。しかし、3月ぐらいまでは皆なかなか筆が進まず…という状況で、4月に入るか入らないかあたりでみなさんエンジンがかかったような気がしています。

最初のブレストの際におおまかな章立てと分担は決めたものの、少し書き始めたところで全体を俯瞰すると「あれも足りないこれも追加したい」と色々意見が出てボリュームが増えていきました。校正に出すタイミングでは、時期的にフルリモートワークのときでしたが、日中に会社の仕事をやってから間髪入れずに執筆・レビュー作業に突入していて、本業なんだっけ状態に陥りつつも、非常に充実した日々でした。ちなみに私は、4章と、11章の「FFI」「Rustを仕事で使う」、3章のFutureを書きました。

それにしても、7人も執筆者が集まると、自分の知らないRustのネタや知識がたくさんあるということを思い知らされました。メンバーの中でプログラマーとして一番未熟な私にとっては、執筆やレビュー自体がとても勉強になり、ますますRustのことを好きになることができました。

現状の自分の立場にも恵まれ、Rustを趣味だけではなく業務で実戦投入することができたことは、これからもRustを使い続ける口実にはなるでしょう。Rustを使ったソフトウェアプロダクトの開発は、いいことが多いので、これからもどんどん発見・発信していけたらと思います。

私とRust

ここから先は、ほぼ自分語りです。

私がRustを本格的に勉強し始めたのは、2019年の初頭だったと思います。新卒で就職した2005年から、数年のソフトウェア開発者(家電のソフトウェアをC言語で書いていた)だった期間を経て、それ以降は長らく開発の上流工程やプロマネ的な立場でばかり仕事してきました。ここでいう上流工程とは、企画や基本設計ぐらいの領域を言っています。つまり、プロダクトのコードを触ることはほとんどなく、業務の合間にちょっとしたスクリプトを作成する程度。それなのに、40歳まで後2年というところでやっぱりコードを書く仕事をしたいと思い、現在の会社に転職しました。当然選考を受けている時点ではソフトウェア開発者としての期待値はそんなに高くなかったと想像していますが、チームマネジメントをすることを期待されて(だと思っています)採用してもらえました。そのときは自分含め6名だけの開発チームだったので、チーム環境の整備しつつ、既存のC++プロダクトをベースに機能追加やバグ修正を積極的にやっていきました。

しかし、入社当初持っていた「C言語をやっていたからC++もすぐ習得できるだろう」という考えは甘く、やればやるほどC++は難しい…と実感することになります。既存プロダクトの多くはC++で書かれていて非同期処理も多用されていました。ロジックが難しいということもありましたが、C++をメンテナンスできる人は限られる一方、非同期処理由来のバグはどんどん見つかって増えていく→自分ほか数名でバグを直さないといけない、という悩みがありました。そんな経緯もあって「もっと別の言語で安全に作り直せないだろうか」と考え始めたのでした。

そんな中で、いろいろ調べているうちにRustを知ることとなり、半年ほどの自分の勉強期間を経て、新規に作成するサブシステムを、自らRustで開発して商用ローンチまで持っていくことができたのでした。言語仕様やコンパイラの動作を実際に試していくうちに、Rustは非常にプロダクト開発向きだという思いがどんどん大きくなっていったのを覚えています。開発に着手するまでに「Rustはすごく良い!なぜならば〜(省略)。だからこれは私がRustで作る!」と社長やチームメンバーにアピールしまくっていました。今思うと、半ばゴリ押しだったな、と。

プロダクトがWebサーバーであり、ちょうどactix-webのバージョンが1.0.0になったばかりだったのはいいタイミングだったと思えます。着手タイミングあたりで、マネージャー(管理職)になったのもあって、「日中はマネージャーのお仕事、それ以外の時間は全部コード書く時間」みたいな生活をしてたような気がします。帰宅してからも土日もずっとRustでコード書いていた(か、試行錯誤していた)ような気がします。

そのときは、まだFutureを知ったばかりで、サンプルコードを読んで動かして、関係しそうなクレートのコードを読んで試行錯誤して…と、あまりスマートじゃないやり方でしたが、徐々に馴染んでくると、「コンパイラに怒られて直して、動かすとちゃんと動く」というRustの開発体験が非常に心地よく感じるようになってきました。怒られ続けて丸二日、みたいなときもありましたが…。

そのような日々を経て、バックエンドでプロダクトをローンチできたときは、感激もひとしおでした。そんなこんなの体験談をShinjuku.rsに投下していたら、松本さんに執筆のお声がけをいただけたので、これはもう是非!という形で引き受けていました。その後は冒頭に書いた通りです。

おわりに

『実践Rustプログラミング入門』は、発売後すぐに非常に好評をいただき、2週間経たずに増刷が決まりました。これには、Rustや競プロ界隈で名を知られた共著者の方々のおかげによるところが大きいですが、私も仕事での立場上、他社の人と関わることも多いので、この本を持ってRustを世の中の企業にもっと広めていければいいなと思います。

iPad Proを買いました

今まではカフェに入ってMBPを開いてiPhoneテザリングして…とやっていたのだけど、席についてiPadを開くだけでもうそこにほぼMac相当の環境があるってのは結構すごくないですか。(SIM入れられるやつなので)

プログラミングするには環境構築が結構大変そうだけど、何か見たり文章を書いたり、だと全然問題ない感じ。画面がiPhoneに比べて大きいから目の前にMacBookがあるような感覚でとてもよい。

しばらくヘビーに使ってしまいそうな予感。

Rust LT #7 発表資料まとめ

話を聞く側で参加してきました。懇親会には出られなかったのでブログでまとめとく。 rust.connpass.com

冒頭κeenさんのPCに合うコネクタがなくて発表順が変わったりしましたけど、プロジェクターへの出力はよくトラブルが起こるところですね。私のMBPも、Forciaさんとこで発表するときは何故か画面出力できない。ChromeCastとか使うと解決できるかもしれない。

話題のGUIツールキットOrbtkを読む

redox-osに組み込まれているGUIツールキットだそうな。Pure Rustだからブラウザでも見られるんですよー!と言われてコマンド一発でブラウザに表示してたのが本筋ではないながら一番びっくりした。

cargo-nodeってやつだそうで。こういう便利cargoコマンドもっと知りたい。

github.com

RustでJVMを作成してみた

JVMの仕様書って公開されてるんですね。ってわかってても実際に作っちゃうのはすごいです。

Rust for neuRo-simulation

自分がよく知らない分野の研究でRustが活用されている話だったので用語とかも興味深かった。口頭では淡々と話しつつ、スライドがコミカルでアニメーションしたりするのは面白いやり方。

rustfmtの中の人の発表(タイトル失念)

github.com

2019年の活動の振り返りと今後について話されていた。Rustのコードを書くときはもはや空気のように使っているツール。いつもお世話になっております。

そういえば最初の発表者のrchaser53さんもrustfmtの結構なコントリビューター。そういう人たちに会えるこういうイベントはいいやね。

Rustで作るTUIアプリケーション

資料見当たらず。

先月のShinjuku.rsでもターミナルアプリケーションの発表があったけど(tui-rsを使ってたかどうかは失念した)、GUIアプリケーション開発に馴染みが少ない(勝手なイメージ)Rustならではの面白いアプローチですね。

DNN CompilerをRustで書く

AI将棋とかR1に出たり、とかアクティブかつ話慣れてらっしゃる方だなぁと思った。

それはさておき、DNN推論するのにRustでPyTorchを上回れるってなにげにすごいのでは。理論力と実装力が両方必要そう。

Rustによる類似画像検索

RustにそもそもImageクレートなんてものがあることを知らなかった無知な私です。類似画像検索ってのは今まであまり必要になったことはないけど、大量の猫画像を整理するのに便利かもしれない。

同社内の営業からの金にならない仕事依頼への対策案

そもそもの背景

飲んでたときに同席者(とある企業の研究者)が、「営業が金にならない仕事を丸投げしてきて対応するのがつらい」とこぼしていたので、対策を考えていました。こういう、部門をまたいだ面倒事は管理職がちゃんと交通整理して然るべきですが、十分機能してなさそうなのでボトムアップで提案してみれば、と書いてみました。

というわけで以下が本文。

用語定義

以下では、営業部門で顧客からの仕事を投げてくる人を「営業」、受ける側の人を「研究者」と記載します。

営業側の困った振る舞い

  • 大企業相手の営業で、重要案件をゲットするための関係維持の口実とかで、何かしら細かい調査とかを振ってくる
  • その仕事で顧客からお金をとろうとしない

研究者が困っていること

  • 営業の顧客関係維持に役立っているだけで、技術的蓄積もあまりなく、研究者側の大した成果にもならない
  • 研究者側は営業から軽視されていると感じている
  • 結果、モチベーションもあがらない

想定される営業側の言い分

  • 最終的には会社全体の売上につながる
  • 研究者も実務に貢献できるしいいだろう
  • 顧客とは保守契約を締結していてその工数の範囲内だ
    • 結んでるかもしれないし結んでないかもしれない
    • 研究者側は、そういうことあんまり教えてもらえないよね

困った営業への対策

オススメの運用

メールなどで作業依頼が降ってきたら、「では、まず見積りしますね〜」と返す。見積りするのにかかりそうな時間は、このときに伝えておく。(明日まで、とか出張が入るので来週月曜日に出します、とか)

見積りを作成したら、次項の※1で洗い出したデータや仕様とともに提示。「これこれのデータをもらって内容を○日で確認したら、着手できる日をお伝えしますね」と一旦返信。着手したら何日でできるか、は見積りに含めておく。

作った見積りは、チーム内でリストにして管理しておきましょう。

具体的な内容は次項以降に記載します。

仕事が降ってきたら、まず見積りをしよう。

「○○なデータの傾向分析」だと仮定

  • タスクを細分化する
    • データの受け取り&内容不備の確認
    • プロジェクトの作成(管理用ディレクトリやリポジトリなど)
    • データの前処理
    • 実装
    • 学習、チューニング・・・etc
  • 見積りする中で、とある工程の作業に必要なデータを全部洗い出す(※1)
  • 各工程の工数と、労務単価をExcel等で整理し費用としてわかるようにして提出

個別の見積りを行ったら、チームで「外からの仕事の依頼」に対する見積りをリスト化する。

  • 基本事項:案件名、工数労務単価、原価(工数労務単価)
  • 一緒にまとめておくといいもの
    • 作業の難易度(研究者での作業が必要か、他の人でもできるか)
    • 依頼された作業によって得られるもの(ないならない、と書いておく)
    • 作業の支障になったこと(必要なデータの提供遅れ、営業側の動きが悪くて期限前に詰めた、など)

見積りをする運用にすると何がいいのか

  • 詳細に見積りをする中で(※1で)、あらかじめ先方からもらっておくデータや仕様を明確にすることで、着手してからあれくれこれくれと言わなくても済む
  • 少なくとも即日着手というのはできなくなるので、依頼する側も余裕を持って依頼するようになる(はず)
  • 営業側に「その作業依頼で、実質○○円分の稼働がかかってんだぞ」を可視化できるようになる
  • いずれはそれを元に営業部門と交渉する材料になる
    • 営業とその先の顧客に「○○円分の価値」を提供しているということを明示することで、営業に金をよこせ(金をもらってこい)と言える
    • 余計な作業を振るな、とも言える
    • 営業へのメリットもある
      • 作業リストは、もし営業が顧客と保守契約を結んでいるのであれば、顧客への保守費用上乗せの材料になる
      • 研究者に依頼する必要がある仕事とそうでない仕事がだいたいわかるようになる(業務委託PGを一人雇っておけば解決できるとか)
      • (研究者にとっての)定型業務をシステム化することで効率化する、という社内案件も作れるだろ

実際のチーム運用への適用

チーム内で合意をとろう

いきなりひとりだけでやり始めても、営業から上長にクレームが来るだけなので、最初のステップはチーム内で合意を得る必要がある。ここは慎重に。

チーム内打ち合わせの場が定期的にあるなら、「こういう営業に困ってて、それへの対策を考えてきた」と提案してみる。

見積り作業という手間が増えるので、反対する人も出るかもしれない。だけど、それすらやれない人はそもそも仕事ができないとか云々言う。スキルが属人化の懸念とかもある。

提案者自身が一番困っている立場であれば、上長(できれば管理職)に「自分が困ってるのでこうしたい。営業から文句言われたらかばってほしい」と味方につけておこう。上長・管理職以外で反対する人がいたら「てめえらが困ってねぇってだけで反対するな。俺が困ってるんだから助けろ。」と強引に進めるのもあり。ただし、最初に管理職を味方につけようね。

合意がとれたら営業に伝えよう

短期間にポコポコと営業から依頼が振ってくる状況であれば、合意がとれた次の依頼から以下のように返してみよう。

「チームの方針で、細かな依頼でも、見積りを作成することになりました。つきましては、まず見積りしますので○日ください」

てな感じで。で、上記の「オススメの運用」の内容を進めていく。

力こそパワー

上長よりもっともっと偉い人とも仲良くなっておきましょう。周りが敵だらけになったら、上長ごと力でねじ伏せてくれます。

技術書典7に参加してきました(機械学習の炊いたん2)

Twitterにいろいろ書いてしまったので引用しながら手抜きしますごめんなさい。

技術書典7は終わりましたが、Boothで引き続き購入できます。

tomo-makes.booth.pm

戦利品、他のサークルの書籍の感想など

おまけ

こつこつとコードを書き続けるためのプログラミング問題集

はじめに

半年ほど前に転職してから、ソフトウェアエンジニアとしてコードも書く立場となったのですが、やはり、長年コードを書き続けていた人とブランクのある私では、コーディングスピードが圧倒的に違ってきます。

もちろん、業務のバックグラウンドの知識の差もありますが、「コードを書くスキル」に関しては、ある程度は「どれだけの量、書いて動かしたか」だと思っていますので、極力毎日少しでもコードを書くようにしています。(書かないと覚えられないタイプ)

ただ、毎日とれる時間のばらつきや、ネタ切れなどありますので、手軽に書ける問題がたくさんあるサイトがあると重宝します。本記事では、私のよく使うサイトを紹介します。

Project Euler

projecteuler.net

コンピュータで解く数学の問題集サイト。アーカイブの最初は割と簡単なところから始まり、徐々に難易度が上がっていく。

私は50問を過ぎたぐらいから解くのに時間がかかるようになってしまい、別の言語で同じ問題を解く横展開ばかりしてしまって解答数の進捗が停滞気味…。

ただ、新しい言語を覚えるときは、ざっと言語仕様を眺めたあとは、実際に手を動かすために問題を解くというのが、最近の自分のお決まり手段になっているのでやってみるのがいいと思います。

上手くアルゴリズムを書ければ、1分以内には解けるように問題ができてる、と一応書いてある。

言語処理 100本ノック

www.cl.ecei.tohoku.ac.jp

言語処理、文字列処理に関する課題がステップ・バイ・ステップで列挙されています。私はまだ20問ほどしか解いていないですが、Project Eulerに疲れたら合間に言語処理100本ノックを、みたいな感じで少しずつ解いています。

AtCoder過去問

AtCoderの過去問を解くのもよいと思います。

非公式ですが、過去問をまとめているサイトや、最初に解くべき問題のリストをまとめてくれている人がいるので、参考にさせてもらっています。

ちなみに、筆者も何回かAtCoderに参戦したことはあるのですが、制限時間に追われて問題を解くのは苦手のようで、ズタボロでした。しかしそろそろ、半年ぶりぐらいにやってみてもいいかも。

qiita.com

今後やってみたいもの

画像処理100本ノック

GitHub - yoyoyo-yo/Gasyori100knock: 画像処理100本ノックして画像処理を画像処理して画像処理するためのもの For Japanese, English and Chinese

画像処理もあまりやったことがないので、体系的に経験できるといいなーと思っています。あと、音声処理もほしい(自分で作れ)。

Modern C++チャンレンジ

タイトルはC++ですが、Rustでもやってみたいと思います。

Modern C++チャレンジ ―C++17プログラミング力を鍛える100問

Modern C++チャレンジ ―C++17プログラミング力を鍛える100問

ディープラーニング∞本ノック!!(2019/05/12追記)

教えてもらいました。

github.com

おわりに

できる人はこういう問題集も一気にやっちゃうんだと思うのですが、最初はできなくても少し経ってから再度解くとわかるようになっていたり、てなことも多々ありますので、こつこつと忘れずに続けていくのが肝要です。

モチベーション維持のために私がやっているのは、進捗を見えるように、解いた分をスプレッドシートに記録していく、というものです。毎日一個ずつマルを付けていくと、だんだんマルの部分が増えていくのが楽しみになります。

さいごに、こういうのもあるよ、という問題集サイトの情報をお持ちの方がいらっしゃいましたら、情報いただければ小躍りします。