エンジニアとして働くことについて思い返すことがあったので、まとめておこう。あとは、自分自信は無能な分類なのであるが、なんとかして頑張って仕事をするために頑張っていること、をまとめようと思う。

要素としてあるのは、おそらく以下の3つ。

仕事を達成すること
サイクルを回すということ、
大人になること

色々なところから学んだが、これを振り返ろうと思ったのは、『Engineers in VOYAGE』の「Zucks」の章で、どういう人が欲しいのかという語りと、フルサイクルエンジニアとはに関する説明から、ああ、これだこれ、となることがあった。

前半ではzucksの記事でのフルサイクル開発者に関して、後半では、自分の失敗と、無能なりにどうやって2人の開発部から10人規模に至るまでで得られた知見(？)

留意点

自分の失敗と、今進めいる挑戦に冠しては、生存者バイアスがかなりある。

zucks

求人票で語りたかったことにある「エンジニアリングは事業を成功に導くための手段だ」という明確な認識は素晴らしい

full cycle

求人票には次のようなことが書いてある。

『以下のようなシステム開発のライフサイクルを一貫して行うことがほとんどです。

ヒアリング、調査
意思決定
実装、テスト
デプロイ
モニタリング
改善

』

これは次のNetflixのフルサイクル開発者の考えと一致している

Netflix

Netflixにおけるフルサイクル開発者―開発したものが運用するには、開発部の組織構成に関する今後の目標となるものや、組織の一員である個人としてどういうことを意識して活動していくのがよいかについて描かれている。

気になったところをいくつかピックアップしていこう。

『ソフトウェアライフサイクルの目的はtime to valueの最適化、つまり効果的にアイディアを実際のプロダクトやサービスに変換すること

ソフトウェアサービスを開発し運用することは一連の責任から構成:

Design
Develop
Test
Deploy
Operate
Support

』

『サイロを解体しフルソフトウェアライフサイクルの共同所有を奨励することで、学習とフィードバックを最適化

責任を外部化するのではなく開発チームに与えることで、ダイレクトなフィードバックループと共通のインセンティブを持つことができる』

『驚くべき開発ツールを持ち、設計、開発、テスト、デプロイ、運用、サポートといったフルソフトウェアライフサイクルへの責任を持つ開発チーム』

『フルサイクル開発者の"本当の仕事"はライフサイクル全てにわたる問題を解決することだ。フルサイクル開発者はSWE(Software Engineer)としてもSDET(Software Development Engineer in Test)としてもSREとしても振る舞うのだ。あるときはビジネスの課題を解決するソフトウェアを開発し、またあるときはテストケースを書き、そしてまたあるときはシステム運用の自動化を行う。』

『このモデルを成功させるためには、チームはそれが価値あるものになるよう真剣に取り組む必要があるし、コストについても意識的でなければならない』

仕事の進め方

求人票で、以下のことを明確に書いているのは本当にすごいと思う。

『私たちの仕事は「不確実なものを減らして実現したいモノ・コトに向かう」こと

具体的には以下のようなことを考えながら、その時々において最良な意思決定を行い、それをメンバと共有して、プロダクトやサービス・事業を成長させることを目指しています

この開発は影響が大きいので、既存のものと並行稼動させて結果を比較するようにし、安全に入れ替えていこう
既存のコードがあまりよろしくないので、まずはリファクタリングをして修正箇所を限定できるようにしてから新しい機能を追加していこう
とりあえず新しい機能を試したいので、本番トラフィックを扱える環境に展開して様子を見てみよう

その判断軸となる基本的な考え方は以下です。

システムを安定運用させるには
新たな課題を見つけ、改善策をデザインするには
問題が発生したときに素早く検知できるようにデザインするには
問題が発生したときに速やかに安定していた状態に戻せるようにデザインするには
上記のようなことを顧客満足と収益のバランスを取りながら優先順位を付け実施するには

』

言われれば当たり前、だけど、明文化すると、これを取り上げたということは、他の事よりもよりこれらを重視しているのだ、とアナウンスしていることがわかる。

my case

1つの仕事に集中できることが必要。その仕事をちゃんと “DONE” という状態に持っていく責任を持って、サイクルを回していかねばならない。

失敗したこと

失敗したことの要点としては以下の2つである。

やり遂げることよりも、効率よくやることを優先したほうが良かった
最後まで持っていくことを意識せずに、ビジネス的な旨味を最初に確認していなかった

具体的な反省事項は次の4つ。

夜遅く、翌日の3時まで、仕事をやる。
自分での勉強する時間を設けず、成長しづらい期間を過ごした。
自分の責任を増やしすぎた。
“Fail Fast” というのを実践することができなかった

これらを踏まえて、どう改善していったかを見よう。

自分のクオリティをコントロールする

まずは失敗のその1

夜遅く、翌日の3時まで、仕事をやる。

実際に困ったこととしては、長時間労働をしたり、神経を使う仕事を息抜きなしでやったり、睡眠時間が少なかったりして、胃腸が知覚過敏を起こした。ひどいときは、一口食べただけでお腹いっぱいになった。(一日百食みたいな感じになった) 一ヶ月もかからず、治ったけれど、未だになお少食である。

ここで、休むことやできないことはやらないことの重要性を実感した。ただ、それでもなお、休む人が怖い人のために、念の為に、言い訳を2つ提示しておこう。

言い訳1: 全知全能の神だって、6日間働いて、1日は休んだんだぞ？
言い訳2: キリストだって、会衆が押し寄せて、朝早いうちに弟子とともに逃げ出すとかやってたんだぞ？

この失敗を受けて私がやったこと:

寝る時間を確保する。
前日に翌日の予定を立てる。
- 午前中は集中を要するもの、午後は比較的集中力を要しないもの
午後に紅茶を飲む

失敗を早く

失敗その4の

“Fail Fast” というのを実践することができなかった

についても、ここでのクオリティーコントロールと同じ流れで対処できた。

小さな単位でどんどん仕事をやって(もちろん順序は重要である)、それで早く結果が得られる状況にしていくほうがいい、ということに気づき、

比較的粒度を細かくタスクを区切り、
想定した時間どおりに仕事ができたかを確認

というのを一日の小さな時間のなかで失敗に気付けるようにしたり、また適切なものを顧客にすばやく届けられるように

実装前、
実装中、
実装後、

と各段階において、人と話して、大きな変更が必要になるより早くに失敗に気づけるようにするようにした。

自分の勉強時間

次の失敗

自分での勉強する時間を設けず、成長しづらい期間を過ごした。

これに対してやったことは:

朝の時間は大事にした。
- 意識的に、朝は自分の興味のあることをやった。
  - というのも、人間は起きたあとのほうが集中力があり、疲れていない。どうせ残業したりして時間が確保できなかったり、帰って疲れて勉強できないことが多いのだから。
業務時間中に業務に関連することについて勉強する。
- 30分くらいいいだろう。さらに、もしそれが咎められるようだったら辞めたほうがいい、と考えて、振り切った。

仕事の進め方もよくなったと思う。

仕事における自分の領域を確保する

次の失敗。

自分の責任を増やしすぎた。

自分の何が向いているかはよくわからないから、とりあえず誰もしないことをやる、誰かの仕事を譲渡してもらう。特に、チームや部署、組織をスケールするのに役立つような役割を確保しよう。

他人に仕事と権限を与える。自分をスケールするためには必要。自分の責任を減らすために、CTOを探したりした。これについては、その人の能力や性格をよく考慮しないといけないので、上司と相談してやっていきましょう。

増やしまくった結果得たもの

ただ、増やして悪いことばかりが起きたわけではなく、得られたものもある。

誰もやらないけれど、誰かやらないと、会社が死ぬから、とりあえずやって、とお願いされることが多くあった。

テスト仕様書作成、テスト計画書作成、テスト実行手順作成
技術コンサル
社外のBizの人間との協議
Partnerとの英語での技術に関する会議

おかげで自分が不得意と思っていたものも、実はそうではないと木付ける容認合った。

「大人になろう」

次に、自分をちゃんとエンジニアとして働くためにやろうとしたことがある。それは、大人になること。(cf: 20201031log, 20201102log)

「大人になろうよ」という言葉をもらい、それを時々思い出し、大人になるってどういうことだろうかと考えたり、本を読んで学んだり、していった。この反省、思考、学習が、今のエンジニアリングマネージャーの仕事にも活かせる経験を生んでくれた。

大人になるというのは具体的にどういうことなのか、謙虚、尊敬、信頼という人間関係における重要な3要素は除くとして、特に実践したのは次の2つであろう。

約束を少なく

1つのタスクに集中できないと、結局大きな損失を得る。たくさん約束するな。

人の話を聞く

自分では自分のことはほとんど見えない。

人の話を聞くだけならタダなので。見当違いだと思っても、ログはとっておき、あとで参照可能にしていれば、調査しやすくなる。

楽をできるようにする

自分の仕事の責任を減らすということにおいて、自分から横に流すだけだったら改善はできない。自分だけではなく、部の全体として楽になってきたが、具体的に何が変わったのか。

学習に関して:

会社で勉強した結果を発表できる場所を用意して、そこで発表したり、発表を聞く

仕事の内容に関して:

自動化をしたり、検索しやすくしたりする。

開発部以外との交流に関して、とにかく相手からの心象をよくする

人にお願いするときは、お願いする相手より目線を低くしたり、
面白くない冗談に笑ったりする。
ただし、仕事に関することは絶対文章にして、相手と共有して、証拠を残す

部内での関係

上司を自分で選ぶ。
- 運が良いことに、会社がCTOを探すタイミングで、自分の知り合いを紹介し、採用でき、今では信頼のおける素晴らしい上司である。
自分よりできる人を採用して、その人に仕事を渡す。

プロダクト:

マイクロサービス化を進める。
モノリスの地獄を抜け、自分の盆栽に引きこもりやすくする。

会社のチームに持っていく

VOYAGE GROUPの記事と、自分の失敗を受けて、じゃあ、会社で活かそう、となった。

文化

VOYAGE GROUPの捉え方はすごくよく、これを是非会社にも持ち込みたかった。そして、ちょうどいいことに、会社が採用で重視しているという文化というのが公開されたので、まずは部内限定で、会社の文化と関連付ける形で、開発部の文化として3つを導入した。全くもって、VOYAGE GROUPのものと一致しているが、それについてはご容赦願いたい。

本質を探し続け、柔軟に考える
小さく挑戦、すばやく失敗
フィードバックし、継続的に成長する

これらについて、私は自分の言葉で、この会社にあって、どうあって欲しいか、という注釈を付け加えていった。(注釈をつけるにあたっては『Team Geek』を読んだ体験がよく活きたと思う。)

これらについて、開発部のProjectにはMergeされた、そして、次は浸透・定着させることに挑戦させている。

失敗の共有

失敗を記録し、記憶し、それにどう対処していったか、というのは、同様に困った状況に面している人にはとても助けになる。

1on1では折りに触れ、「困っていることはあるか」、「一緒に検討したいことはあるか」と尋ね、発話を促し、相手に質問し、相手の持っている手札を明らかにし、対策案を探すという協力をしている。

これから

これからやっていくことについて

自分において

なによりも知識が重要である。

いろいろな本を読んで、手数を増やし、使えるものを使うべき場面で使い、知見を蓄え、共有し、チームをよりよくしていこうと思う。

技術よりも人間に関する問題が好きなのは確かであるが、私が相手をするのは、技術を扱う人間なのであるから、その扱う技術に関してちゃんと知識をもっておかないと困る。

会社において

チーム文化について

浸透させていく。

なぜ、浸透させないといけないのか、というと、人間は記憶をするのが不得意であるが、なにかと関連付けておくと、思い出しやすくなる。

チーム文化の3つを繰り返し伝え、
チーム文化と関連付けて仕事のやり方や改善点を伝え、
それでなんとか少しずつ定着していける、

あとやることとしては、部内のレベルから、社内のレベルに持っていくことである。これについては、開発部のチーム文化について、『Team Geek』の要約の発表と合わせてやろうと思う。「開発部にはこういう文化があります、みんな知っておいてね。あと、この手の人間関係の知識や技術は、当たり前かもしれないけれど、改めて抑えておいて損はないよね」

技術評価

技術評価、というのが、まだ不十分である。制度という形がまだあまく、というのも、開発部のチームがまだ少ないので、目が届くから、いいよね、という甘えがある。

いずれ、会社を大きくし、チームが増えたら、これに挑戦しなければならない。

技術評価においては、会社もコンピテンシーを導入したり、透明化を図っているところなので、それに向けてやっていこう。