エンジニアの業務ガイド

これは何？

プラハでエンジニアとして働く方に向けたガイドです。意識すると良い考え方や行動を会社のみんなで書いていくことで、より質の高い開発を行える組織を目指そうぜ

あくまでガイドなので従う必要はありません。状況に応じてガイドに記載された内容が不正解になることもあります。役立つ時だけ使ってください。

目的

各々が無意識に行なっていることを言語化することで組織全体の学習を促進する
社内のエンジニアの根本思想を近づけることで、議論に時間を割きすぎることなく大事なことを迅速に決められるようにする
近い思想を持つエンジニアに興味を持ってもらいたい。あわよくば応募して欲しいなぁ...！

メンテナンス方法

社内のメンバーであれば誰でもPRを投げてください。加筆でも更新でも削除でも構いません。管理者を設けるとその人の思想にドキュメントが依存してしまうため、PR提出者以外の誰か1名がapproveしたらいつでもマージして OK です。会社全体の意向をできるだけ反映したドキュメントにしていきましょう！

書くべきことの基準

ひとまず基準は設けていません。ルールを定めておいた方が良いかなと悩んだのですが、まずは積極的にこのドキュメントが更新されることを優先したいので！

ガイド

ガイドに記載する内容は

メンテナンスを最小限に留められる
異なる環境やプロジェクトでも活かしやすい

ことを重視しているため、ちょっと一般論的や心構え的な話が増える傾向にあります。ご容赦くださいませ

技術寄りの話

頻繁にデプロイする

この辺はLeanとDevOpsを一度読んでおくと良いかも (opens in a new tab)

定期的に技術負債を返済する

技術負債が蓄積すると手を出せなくなってしまうので定期的に返済する必要がある。「手が空いたらやろう」「次の機能開発が落ち着いたらやろう」と考えていると一生手をつけなくなるので、毎週金曜日の午後を負債返済に充てる、など決まった時間枠を設けた方が良い

自分を頭の良いエンジニアだと思わない

自分の仕事に自信を持ちすぎず「絶対に他にもっと良い解決方法があるはず」と考えることで、正解を探したり、人に聞く習慣につながる

常に複数案を考える

最初に思いついた解決策に飛びつくのを堪えて他の案も考えてみると、考慮漏れに気づいたり、より良い案に繋がることがある

学習するときは頭と手を同時に動かす

本を読むだけだと理解したつもりに陥りやすい。理解を確認するために手を動かしてみると学習が捗る。特に抽象度の高い概念を学んでいる時ほど抽象と具体を行き来するのが大切。

情報をインプットしたら自分なりの仮説を作る

新しい情報を読んでもあまり身につかない時がある。「今学んだことが正しいとしたら、こうなるはずだ」と自分なりの仮説を作って検証してみたり、「この知識が成立するには隠れた前提条件があるはずだ」と前提条件を探してみると、理解が深まることが多い (opens in a new tab)

コードを書く時間より読む時間を優先する

書く時間を短縮するために読みづらいコードを書いてはいけない。コードを書く時間より、そのコードが誰かに読まれる時間の方が圧倒的に多い。自分の作業時間を数分~数時間を削減するために他人に苦痛を強いてはいけない

機械に仕事を押し付ける

人間は必ずミスをするのでアテにならない。人間の仕事はどんどん自動化していこう。型を使ってコンパイラに仕事を押し付けることで実行時例外を減らしたり、面倒な検査はE2Eテストで自動化したり。目安として3回実施する可能性がある作業は自動化する方法を模索してみよう

消す前提で機能を作る

この辺で詳しく解説してみた (opens in a new tab)

ドメインを理解する

自分が作るサービスのドメインを理解するほど以下のメリットが得られる：

適切にモデリングができるため最小限の手戻りで変更容易性が高いコードを書ける(それによるセキュリティ面のメリットも (opens in a new tab))
サービスに求められるアーキテクチャ特性を見極められる (opens in a new tab)(例えばHFTを行う金融サービスを作る場合、サービスの特性を理解しておけばパフォーマンスが設計上の重要項目になることに気付ける)
開発チーム外のメンバーと円滑に会話できるため、組織全体から信頼される

新しい技術を学ぶときは、解決したい課題を理解する

「磯野〜GraphQLはイケてるってXXが言ってたから使おうぜ〜」みたいな技術選定はちょっとダサいので、その技術がどのような課題を解決するために生まれたのか、その課題が生まれた背景、その課題が重視され始めた理由、などを理解した上で採用した方が良い意思決定に繋がりやすい。不可逆な意思決定 (opens in a new tab)ほど解決したい課題を理解してから取り組んだ方が良い

新しい技術に触れる

新しい技術のなかには、従来と次元の異なる生産性を叩き出したり根本からパラダイムシフトを引き起こすものがある。どんどん学習していこう！審美眼が養われるはず (opens in a new tab)

細い幹から太い枝は生えない

日々新しい技術に触れていくうえで、新しい技術が自分にとって必要なものかどうか/業界で流行するかどうかなどを見極めるための基礎的な知識は不可欠。ライブラリやフレームワークに依存しない、もっといえば言語にも依存しないような知識・哲学・原理原則も学ぶと吉。たとえば、設計やアーキテクチャ、UNIX的な考え方など。

周りと円滑に働く

コードレビュー

コードレビューは重要ですが、作業のボトルネックになりがちです。コードレビューで重要なのは簡潔に意図を伝えること。やりとりが何度も往復するコードレビューは避けましょう！

簡潔に意図を伝えるため、コードレビューをする際は以下の点を工夫してみると良いかもしれません:

実装イメージを提案する
suggested changeを使う
情報源を共有する
prefixで重要度を伝える
完結かつ優しく

実装イメージを提案する

文章で意図を伝えるより成果物（コード）で意図を伝える方がスムーズです

例： show the code

suggested changeを使う

suggested changeにしておけばレビュワーはボタンをポチるだけなのでとっても楽です！

例： use suggested changes when possible

情報源を共有する

同じ情報を共有できていた方が議論がスムーズです。自分の意見の根拠となっている情報源があれば、積極的に共有しましょう

例：

prefixで重要度を伝える

nitsとかimoとかmustとか、コメントの重要性を伝えるprefixを添えると相手が対応を判断しやすくなります

完結かつ優しく

簡潔かつ優しいコメントを心がけましょう！自分にとって一番大切な人にコメントしている気持ちで書くとちょうど良いかも

徹底的な明文化

思考を明文化する習慣が身につくと様々なメリットが得られる。

周囲と協働しやすい(認識が共有できるため)
後から見返した時に当時の意思決定や根拠を思い出せる
周囲から指摘を受けてブラッシュアップされる(技術ブログなどに公開するとより効果が高まる)
考えているように見えて悩んでるだけのことがある。書くと考えることを強制される

方法：ADRを書き残す、試行錯誤の履歴をslackのtimes、scrapbox、zennのscrapなどに残す、清書した内容を技術記事として公開するなど

人間は感情で動く生き物だと理解する

この辺はカルチャーガイドも参考にしてみると良いかもしれない

結論から話す (opens in a new tab)

そのほうが業務連絡が早く終わって雑談したり、一緒にゲームする暇ができるので。

…真面目に書くと、結論から話さないと相手の集中力が途切れて話を聞いてくれなくなるので、正しく情報が伝達できなくなる。

全てはトレードオフだと考える

要はバランスおじさんは馬鹿にされるので、全てはトレードオフお兄さんが登場。

現実に完璧な回答は存在しない。必ず何かがトレードオフになっている。自分の案が何をトレードオフにしているのか、常に意識しよう

全く欠点のない完璧な回答を探すのではなく、今の状況で妥協できること・妥協できないことを見極めて各案のメリットデメリットと照らし合わせる方が効率的に動ける

事業状況を理解した上で決める

事業状況を全く知らずに下した意思決定は、下手をすると自己満足なオーバーエンジニアリングになりかねません。事業のことも学び、考えた上で意思決定していくことが大切です。

良い例

粟田さんのコメント (opens in a new tab)
- このサービスは、いくらの売上を生み出す見込みなのだろう（事業状況の理解）
- じゃあこれぐらいのコストまでは許容範囲内だな（状況から逆算した目標設定）
- こういう技術構成でいこう（技術者としての決定）

コードを書くことだけが解決手段だと思わない

コードを書いて問題を解決するのはエンジニアの仕事だが、ふりかかってくる困難を「なんとかする」のも仕事の1つ。アプリケーションにどんな機能が必要か（不必要か）を考えたり、コードを書くための環境を整えたりすることが問題解決のために必要であれば、やろう。

ミーティングそのものを嫌がらない

不必要なミーティングは開催しないほうがいいし非効率なミーティングは改善すべき。だが、コーディングだけしていたいなどの理由でミーティングそのものを嫌がって参加しない姿勢でいると、必要な情報が共有されなかったり重要な意思決定に参加できなかったりしてかえって非効率な結果を招いてしまうことがある。エンジニアとして積極的にミーティングに参加して、情報収集や問題解決の提案をしよう。

周りと楽しく働く

一緒に学ぶ仲間を探す

一人で学習を続けるとモチベーションが続かないし、理解を完全に間違えることもある。一人でも良いので仲間をみつけて取り組むと捗る。プラハには知的好奇心が強い人が集まっているのですぐ見つかるはず！

伝え方が9割

遠慮はいらないけど配慮は大事。伝え方に気をつけよう。

ユーモアを交えると大体うまくいく(ただしスベるリスクを抱える。ここにもトレードオフが存在する)
否定系のコメントは全部肯定系に変換できる(お前のコードクソだな→こうしたらもっと良いコードになるかもよ)
emojiを入れるだけで少し和む。:chipmunk: とか :dolphin: とか動物を入れてみよう

1日1回小さな親切

心地よいチームは日々のメンテナンスから生まれる。どれだけ小さくても、相手に気づかれなくても構わないので、一日一回は誰かに親切をする意識を持つと毎日楽しく働ける

カジュアル面談