はじめに

Hello World😊東京都中野区在住の中野です😃

前回の転職から約2年経過し今回はやりたいことをやったので転職することになりました。当時の転職テーマは 「私が働き続けたいと思える組織を作る」 でした。

今回はそのテーマを軸になんの会社でエンジニアとして何をしてたのかについて簡単に書いていきます。

何してたのか

Edtech(教育系)の会社で変化を起こす人をやってました。

そもそもどんな状態だったのか

名ばかりのワンチーム

私がジョインした当時はお世辞にも組織と言えるものではなく個人商店の集まりがチームと呼ばれていました。ウォータフォールモデルでマネージャーに言われたことだけをやるような状態で閉鎖的な環境でした。だいたいできてないことは笑って誤魔化され、できない言い訳ばかり聞くことになります。

隠蔽された情報

情報は分断化されており、プロダクトやプロジェクトに関わる人間全員が必要な情報にアクセスできずに、マネージャーからの情報の共有を得て全体像を少しずつ知っていく状態でした。意図してか意図せずか情報は隠蔽されており、何かをやるにもマネージャーから話を聞かなければならない状態でした。

ドキュメント等は更新されておらず、必要な資料や情報が存在しません。何かをやるにも現行の仕様を崩さないように手探りの状態でした。またドキュメントを作ってナレッジを共有したりすることができていませんでした。

最悪の開発体験

過去のバージョンは全てサーバ上に乗っかっており、ユーザのアプリのバージョンによって見に行ってるサーバのアプリケーションが異なりメンテナンスコストが非常に高くなっていました。また作ることが正義になっており、現行のシステムを改修する文化はなく常にユーザからバグの報告が上がっている状態です。そこに「とりあえず動けばOK」のコードたちが追加されていきます。想像通りにカオスでした。

以前CTOに「設計ってどうしてるんですか？」と質問したら「設計なんていらないですよ。」と言われて戦慄したのでも今ではいい思い出です。

そして全て 俺たちが考えた最強のルール で業務上のルールが作られていました。

学習に消極的

学生の学習をサポートしている事業なのにエンジニアの学ぶ姿勢が消極的でした。これはエンジニアだけではなくマネージャーも含めて同じことが言える状態でした。新しい技術に手法に概念に触れることをせずに手持ちの武器だけで戦おうとする姿勢を感じました。

リリースは一大イベント

サービスのリリースは業界の繁忙期に依存していており、必然的にビックバンリリースとなっていました。ジョインしたタイミングでLaravelをLTSに更新しておきました。と共有もらいました。気になってテストコードを実行したらオールレッドでした。これは壮絶な戦いになる予感。

どんな状態になったのか

名ばかりのワンチームからスクラムなワンチームへ

ウォータフォールモデルを採用し個人商店のような開発モデルからスクラムを導入し移行していきました。それに合わせてタスク管理としてjiraを採用しています。今まで会社からの情報共有の場として週に1日開発部内で会議がありましたが、デイリースクラムを導入して毎日チーム内でコミュニケーションを取る場と情報を共有する場を設けるようにしました。今まではCTOのなんとなく見積もりからチームメンバーで見積もりを(プランニングポーカー)行うようになり、言われたことをやるのではなくチームとしてなんの仕事をやるのかを決めるようにしました。結果的にベロシティを見てスプリントプランニングを行えるようになりました。そして、スプリントレビューを開催しレビューをもらえるようにしていきました。また、各々が抱えていた課題等はKPTを導入し、チームメンバー全員に共有し一緒に考え対策を行っていくようになりました。以前はできない言い訳ばかりだったのが、どうやってやるのかを議論できるようになりました。

隠蔽された情報から公開された情報へ

タスクを遂行するのに必要な情報をマネージャーに先に資料化してもらい、資料化できたら取り組むようにしていました。言った言ってないの不毛なやり取りを駆逐するため、口頭ベースでのやりとりは必ずエビデンスが残すようにしました。またタスクを遂行する中で得た知見や発見に共有する必要がある情報は必ず資料化するようにしました。

これで必要な情報は必ず資料化されている状態になりました。

最悪の開発体験からモダンな開発体験へ

開発部としてユーザファーストを指針として定め共通認識として定義しました。

しかし、ユーザファーストを謳っても障害対応などや技術的負債の返済に心理的安全性が担保されてない環境下での業務遂行は精神をすり減らしていくためDX(デベロッパーエクスペリエンス)の向上が私の中で急務だと感じました。

開発する上でオレオレルールを廃止し、メンテされてないgitlabからgithubに載せ替えコードレビューを必須化し、CircleCIを採用しCI/CDの仕組みを作りDevOps化を推進していきました。

また組織化する上で技術間の結合度を落とす必要性があり、システムのアーキテクチャを再定義しました。結果的に設計の勉強会を行う必要があり、設計が何故大切なのかを理解し設計に関心を持ってもらい業務に活かしてもらえるようにしていきました。特にCTOに納得してもらいすすめる必要があり、ほぼ再教育みたいな形になってました。

そしてフロントエンドとバックエンドが密結合していたので分離することを提案しプロジェクト化しました。その際に、フロントエンド技術は採用等も考えVue.jsを採用するようにしました。複雑だったバックエンドのバージョンは常に最新版のみをデプロイするように変更し、古いバージョンのバックエンドを駆逐していきました。シンプルに最新版のみをメンテすればいいだけになるのでこれで運用コストが以前に比べて落ちました。

そして、今まではIDEの購入を個人がしていましたが採用面も考慮し、Phpstormを会社負担でライセンスを用意してもらえるようにお願いしました。今ジョインすれば無料でPhpstorm使えます。

学習に消極的から学習に積極的に

ジョイン当時、勉強会に参加することにいい印象を持ってもらえてなかったように感じました。そして、社内には学ぶための環境が整備されていませんでした。また、業務の時間を使ってまでそれに参加する必要性があると思われていなかったのかもしれません。何度も説明し実際に勉強会に参加し、その学びを社内でフィードバックしていきました。そうした甲斐があり、すこしずつ勉強会に参加することが認められはじめました。その後は、社内のエンジニアは気になった勉強会に参加して学びを社内に還元するようにしました。

合わせて同時期に社内勉強会を開催し約1年半の間、最近のメンバーがジョインするまでほぼ私一人の孤独なLTが行われていました。社内勉強会をなんとしても文化として後に残さなければならないと思いほぼ休みなく毎週LTしてました。結果として、LTは部署を跨いで文化として今はしっかりと根を張って浸透しています。

あとは社内図書制度として必要な技術書や読みたい技術書は会社負担で購入してもらえるようにしました。そして、技術書は社内にある状態になったので、輪読会を定期開催できるようになりました。必要な書籍などを輪読しお互いに意見や考えを交換共有できるようになりました。

リリースは一大イベントから習慣へ

ビックバンリリースになる原因は業界の繁忙期に合わせてのリリースになっていたのが原因だったので、アプリケーションのリリースサイクルが業界の繁忙期に依存する必要がないという話をしました。ビジネスの特性上にはPDCAをまわすサイクルが年に数回しかないのは承知の上ですが、アプリケーションがそこに引っ張られて依存していい理由にはならないので、毎週リリースすることを目標に動いていきました。

開発で何をしたのか

基本的には新規アプリケーションの設計・実装を担当しており、社内の新規APIのほぼ全てを担当してました。具体的なことは書けませんが国案件のアサインが私一人だったのはさすがに笑いました。 DBをAurora化したりDBに保存された画像情報をS3にreplaceしていったりバックエンドやフロントエンドの技術選定を担当したりしていました。他には開発フローの定義やツールの選定にサービスの選定まで行っていました。また、この先事業のスケールにあわせてDDDのエッセンスを導入したりアーキテクチャーの選定を行ったりもしていました。ここが大変でした。将来的にはマイクロサービス化することは考えてはいて、しかし今どこまでやるべきかなどは要検討しました。ここは私一人でやるのではなく優秀な方が来た時に泥臭い作業をしないで動けるようにすることを第一に考えて展開していきました。

そういえば、ジョインしてすぐにやった仕事は開発環境が公式のBoxを使っているわけではなくどこの誰が作ったかわからないBoxを使っていたり、アプリケーションがBoxの環境に依存していたり、複数のプロダクトに依存していたりしてた部分を分離しシェルスクリプトのリバースエンジニアリングを行ったりしていました。それらをHomestead環境で動作するよう標準化を推し進めました。

会社組織について

ナレッジは所有ではなくシェアへ

ドキュメントツールはいくつか選択肢がありましたが、全社的に採用するのでメインの機能がシンプルで誰でもわかり、バージョン管理ができ、共同編集も可能でお引越しが可能という点で最終的にはesa.ioを採用しました。まずは、情報を残して共有するということを浸透させ、社内の情報にアクセスするための共通の入り口とするようにしています。そこから各部ごとに切り出すかどうかなど柔軟に対応できそうだったのが決めてです。もともと、組織的にマークアップを書く基盤があったのと足りてない分は補助する形で導入しました。

DMとプライベートとSlack警察

slackを無料枠で使っていたため独自のルールが存在しAPIを利用することもできずに不便だったので有料化してもらうためにslackの有料で使うべき話をマネージャーと進めました。

また独自ルールのために大量に作られたプライベートチャンネルが情報を断片化している原因になっているため全てのチャンネルをパブリック化していきました。またDMのやりとりが非常に多く水面下で派閥があることが容易に想定できました。が、分かる範囲で社内警察してルール違反者は次々に逮捕していきました。

同じようなチャンネルが複数あり、チャンネルの定義が不十分だったチャンネルたちを各部から協力者を集いチャンネルを整理し、プロダクトやプロジェクトに関するチャンネルの運用を再定義しました。

開発部について

民主化の風

当時を思い返すとCTOの発言に物申す人が一人もいなかったです。出された答えを受け入れる文句は言わないみたいな雰囲気でした。それは完璧な答えだから何も言わないのかということではなく、第三者の視点で見てみると知識や経験が足りなく論破されるかもしれないから何も言わない言えない。そんな風に映っていました。

意思決定に必要なカードをCTOに全員渡せているのか？というとそんなことはなく、CTOは常に正しい判断を下せているのかというとそう思えるわけでもなく、どうもしっくりこなかったので何度もチームで話し合い意見をいう場を民主化していきました。

これにより意思決定に必要なカードはメンバーからCTOに渡るようにし、認識の齟齬がおきてない状態で腹落ちした意思決定をしてもらえるようになりました。無論メンバーも意思決定に腹落ちしています。

完璧症候群とルールと私達

完璧主義それは病のように静かに私達を蝕んでいました。何かルールを作る時や仕組みを作る時に完璧であろうとするあまり身動きが取れない状態になっていました。これは小さな話でも大きな話でもそうです。しかし、必要なのは完璧ではなく柔軟ではないでしょうか。そしてルールとは私達を縛り付けることではなく、私達が気持ちよく働くためにあるべきではないでしょうか。その視点が抜けたルールは形骸化されやすくルールに合わせて私達が動く必要があり働くことがストレスになります。私達に合わせてルールが変わるべきだと思っており、一度作ったルールや仕組みを変えてはいけないルールなんて存在しないはずなんです。存在しないはずなんですが、完璧症候群になっているとルールが絶対に見えるんですよね。これが非常にやっかいで答えなんてないものに完璧な答えを見出そうとします。時間の無駄なのでもっと本質にフォーカスする必要があります。そもそもルールは変わるものであり、変えるものであること理解してもらい、とりあえずやってみてPDCAを回して次のアクションを考えることを前提に少しずつ完璧症候群を駆逐していきました。

次は何するのか

サーバサイドエンジニアでB社の事業にコミットします。既存アプリケーションのリプレイスを担当することになっています(たぶん)。引き続き世の中の商談をよりよくできるように技術者として貢献していきたいと思います。技術力の向上とビシネスの理解を今まで以上に深めて新しいValuを提供していけるよう尽力します。

さいごに

書き出したらたくさんあるのですが長くなってしまいました。他にも書けることは恐らくたくさんあるので気が向いたら追記していこうかと思います。

転職のテーマだった 「私が働き続けたいと思える組織を作る」 ですが、色々と挑戦でき形にすることができて非常にチャレンジしてみてよかったと思っています。結果として私自身次のチャレンジに進みますが、ジョインした当時よりも随分働きやすくなったかなと思ってます。

欲しいものリストです。期待してます。