portal shit!

新しくウェブ系のシステムを開発するときにやったことがいいことを書いておきます。コードを書くスキルとはちょっと別なのでこういうのは経験がないと身につかないけど超重要です。

1. システム構成図を描く

どんなシステムがあってどんな流れで処理が進むのかを絵に描く。かっちょいい設計書じゃなくてもいい。手書きの雑なやつでもいい。一個一個の処理に「〇〇君」のような名前を付けていくといい。「JSON書き出し君」みたいな感じ。

2. 誰が何をやるかを明確に

タスクを洗い出すだけではなく、誰がどこまでやるかを明確にする。1で描いた絵に担当をアサインしていくと漏れがない。

3. リリース日を決める

リリース日を決めずに開発を始めるとパリッとしない。リリース日を決めて、アプリの申請、 QA の予定などを埋めていくと、何日までに開発を終わらせておかなければならないかが逆算的にわかる。間に合わなそうであればリリース日を動かして調整する。

4. 確認環境・デモ環境を作る

ローカルではなく、本番と似た環境で動作確認できる環境をまず作る。ローカルで動いたけど本番で動かないをなくす。本番サイトを非公開にできるならリリース前からガンガンデプロイしてもいい。CSSが当たってなかったり、APIがモックでもいい。動くものを関係者間で共有し、早い段階でイメージのズレを補正することが超重要。

CI/CD の仕組みまで初期に整えておけるとなおいい。

5. リスクの高いところから開発する

システムの処理の中で重要かつ難易度が高い、もしくは実現できるかわからない（不確実性が高い）部分から開発する。簡単なところから先にやって不確実性（リスク）の解消を先送りにするのは超危険。

6. APIのJSONのフォーマットを先に決める

こうしておくことでバックエンドとフロントエンドがパラレルで開発できるようになる。誰かの作業が進まないと他の人の作業が進まないというような依存関係を作らない。

7. コードはこまめにリポジトリにプッシュ

他の人が作業状況をわかるようにする。小さくプルリクエストを作ってマージしていくとかは今更言わなくても常識ですよね？

8. 朝会か夕会をやる

超ラフにコミュニケーションしてお互いの進捗を共有する。可能ならオフラインで話す。一緒に寿司を食べるのも効果的。

---

↑は作るものが決まってからの話なので、作るものが合ってるか（正しいか）はまた別の話（プロダクトマネジメント）。

今年は転職して働く環境が変わり、自分のエンジニアとしての能力が足りないと痛感させられることが何度もあった。しかしそれは技術力が足りないというよりも、もっとほかのもののように思えた。良いエンジニアとは何なのかについて、今年一年で考えたことを書いてみたい。

良いエンジニアとは何だろうか。技術力が高ければ当然に良いエンジニアと言えるのだろうか。そもそもエンジニアに必要なスキルとは何だろうか。技術力がまず挙げられるだろう。良いエンジニアは当然に高い技術力を持っていて生産性が高いはずだ。

技術力に加えて、プロジェクトマネジメントのスキル（以下プロマネ力と省略）も必要なのではないだろうか。これまでの自分の経験を振り返るに、技術的に秀でたエンジニアはプロマネ力も兼ね備えていることが多いと感じる。技術力が高いエンジニアはプログラミングの能力が高いので、組織や開発体制を「プログラム」する能力が培われるのかもしれないが、技術的に秀でた人が必ずプロマネ力が高いわけではない。技術力さえ磨けば良いエンジニアになれると誤解してしまいがちだが、技術力だけ磨いてもみんなから求められる良いエンジニアにはなれないだろう。

ではなぜ技術力に加えてプロマネ力が必要なのだろうか。

一般に、コードを書かずに問題を解決できるならその方がよい。相手に言われるままにコードを書くよりも、コードを書かずに問題を解決できた方が時間も金もかからずみんなハッピーだろう。もしコードを書くとしても最小限の変更に抑えられるのが良いエンジニアなはずだ。技術力が高いだけではこういう発想は出てこないだろうし、真の問題が何なのかを見極め、解決策を考える能力が求められる。

良いエンジニアには先を見通す力も必要だろう。依頼された機能を開発するためにはどんな作業が必要か、どのくらい時間がかかりそうか、誰と調整しないといけないか。

関係者に働きかけ、周りを動かす力も必要だろう。理不尽な依頼が振ってきたときに、その依頼に対して反論し、相手を説得して実現可能なやり方を受け入れてもらわないといけない。

誰かに指示されるのを待たず、自ら動くことが出来る力も必要だろう。仮にプロパーのプロジェクトマネージャーがいたとして、プロマネの指示ばかり待ってコーディングしかしないようでは良いエンジニアとは言えないだろう。

このような、プロジェクトをコントロールし推進する力が良いエンジニアには必要なのではないかと思う。

そんなに何でも出来る人はいないのだから、スクラムをやれば良いのでは、という意見もあるだろう。確かに並エンジニアの集団ではスクラムが有効そうに思える。卓越したエンジニア一人で開発するよりも、数人の並エンジニアによるチームで難しい問題に立ち向かうストーリーの方がおもしろいだろうし個人的には好きだ。

しかしそうやって並エンジニアを寄せ集めても、そこから良いエンジニアは育たないのではないかと感じる。

スクラムチームでエンジニアは、スクラムマスターとスプリント計画、プロダクトオーナーとの「合意」により保護される。自分一人で問題に向き合い、問題を解決する能力がつきにくい。

一方でスクラムを採用していない荒野のような環境では、エンジニアはチームに頼れず、自力で要件を定め、関係者の合意を取り、自らプロジェクトを推進していく必要がある。そのような厳しい環境に身を置くことで、上に挙げたようなプロマネ力が身についていくのではないかと感じる。

これまでの自分のキャリアを振り返るに、以前勤めていた職場はまさに「荒野」といえるような環境だった。誰も何を作るかはっきり分かっていないんじゃないか、いきなり一人で工数見積もりやれといわれても出来るわけないだろう、こんなウォーターフォール開発はやめてアジャイル開発がしたい、こんなクソ会社辞めたい、といつも思っていた。

しかしつらかったのは自分にプロマネ力がなかっただけなのでは、と最近思うようになった。その後入った職場では、つらいこともありはしたものの、スクラム開発のおかげで個人が一人で抱え込んで苦んだりすることなく、チームで協力して開発することが出来た。その中で自分は自分自身の能力を過信したのかもしれない。実際には大してエンジニアとしての力は身についておらず、チーム開発やスクラムをやらない組織で働くことになったときに、自分の能力のなさを思い知らされたのだった。

本題に戻る。自分が良いエンジニアになるためには、技術力も当然足りていないと思うのだけど、プロマネ力を上げていかなければならないと思っている。来年の目標はそのあたりに置きたい。

Shut the fuck up and write some code.

はい。