Kaizen Platform, Inc. エンジニア行動指針
Engineering Teamの Akira MAEDA です。 今回はKaizen Platform, Inc.社内にあるエンジニア行動指針を紹介したいと思います。
このエンジニア行動指針は創業間もない頃に技術顧問のNaoya Itoが中心になって作成し、今から2年半ほど前にオフィスに遊びに行った私に、CTOのToshimasa Ishibashi、Naoya Itoの二人がKaizen Platformの実現しようとしている未来とともに熱心に説明してくれ、私のKaizen Platformへの転職のきっかけになったことを今でも思い出します。
以下内容
— -
Kaizen Platform, Inc. エンジニア行動指針
Message from CEO (Kenji Sudo)
・ 我々はクラウドソーシングで新しい働き方を作り出していく集団なんだから、我々自身も新しい組織のあり方に挑戦すること
・フルタイムの社員は、会社の真の競争力の源泉となる仕組みをつくることにフォーカスしよう
・ 様々な国や地域で多くの人が前向きに協力したくなるようなオープンな組織や事業でいよう
Kaizen Platform エンジニアの哲学と行動指針
価値観
- Kaizen spirits
・マーケットへのGrowthの提供 / 外部への価値提供的な / More Growth, Less resource / 外部志向 / パートナー的な / 相談してもらえる
・外部に対して役立つという意識（信頼される、頼られる） - 新しい働き方・組織のあり方
・働く場所、働く時間、休む頻度は問題にしない。達成した価値の大きさに責任を持つ
・∴ チームワーク重要
・個人が働いていて楽しく幸せ / 自分が働きたい会社をつくる - オープン & 共有
・話しづらいことほどテーブルに乗せる - 外的刺激 (Extrinsic Motivation) よりも内発的動機 (Intrinsic Motivation)
・お金や評価ではなく「自分がそれを作りたい」と思う情熱を優先する - 怠惰・傲慢・短気
- 怠惰（Laziness）： 全体の労力を減らすために手間を惜しまない気質。この気質の持ち主は、役立つプログラムを書いてみんなの苦労を減らしたり、同じ質問に何度も答えなくてもいいように文書を書いたりする。よって、プログラマーの第一の美徳である。
- 短気（Impatience）：コンピューターが怠慢な時に感じる怒り。この怒りの持ち主は、今ある問題に対応するプログラムにとどまらず、今後起こりうる問題を想定したプログラムを書く。少なくともそうしようとする。よって、プログラマーの第二の美徳である。
- 傲慢（Hubris）：神罰が下るほどの過剰な自尊心。または人様に対して恥ずかしくないプログラムを書き、また保守しようとする気質。よって、プログラマーの第三の美徳である。
行動哲学
謙虚 (Humility)
世界の中心は君ではない。君は全知全能ではないし、絶対に正しいわけでもない。常に自分を改善していこう尊敬 (Respect)
一緒に働く人のことを心から思いやろう。相手を1人の人間として扱い、その能力や功績を高く評価しよう信頼 (Trust)
自分以外の人は有能であり、正しいことをすると信じよう。そうすれば、仕事を任せることができるこの3つを合わせて HRT と呼びたい。読み方は「ハート」だ。
refs Team Geek
- 自律的に動く
- 暗黙知を作らない
- 許可を求めるな謝罪せよ
- 官僚的にならない
・×「○○さんの許可を得ないとできません」 - 技術的な間違いは躊躇せず指摘
- 3度同じ事を繰り返す時は自動化
働き方
- リモートワークを妥協しない
- 非同期に働く。フロー状態の同僚を邪魔しない
- KPT: 定期的に自分たちのやり方をアップデートする
オープンさ
- 自らの仕事 (プロセス・成果) をオープンに
- 情報は閉じ込めてはいけない
- どこにあるかわからない/誰も読んでないドキュメントには価値はない
設計と実装
- 12 Factor App
- KISS and YAGNI: 過剰に設計しない
- Dirty Hack より中長期的に維持可能なシンプルな仕組み
・コピペせず時間をかけて堅牢なコードを書け
・複雑なコード、Dirty Hack の積み重ねは時間と共に周囲の人間のモチベーションを蝕む - DRY
振る舞い
- いじりにくいならリファクタリング
- チケット・Issue はストーリーで語る
- テストは自動化
- ミーティングはアジェンダを用意、終わり次第議事録を共有
・Markdown で書いて Qiita:Team に貼る - コミットするコードにコメントアウトはできるだけ入れない
・コメントアウトする場合は他ディベロッパがわかるように必ず理由を書く
Pull Request
- “WIP” Pull Request : 作業過程をオープンに
- まめに git push
- 一行の変更でも Pull Request で
- 適宜masterからmergeしてConflictを最小限にする
- コミットヒストリーは他人がわかりやすいように奇麗にする
・TopicブランチやPush前のブランチでは`git squash`を使い、typoの修正など無駄なコミットログを残さない
・TopicブランチやPush前のブランチでは`git merge`よりも`git rebase`を使う - レビューする人のために有用な情報を書く
・実装の参考にしたサイトのリンク
・関連するIssueやPull Requestのリンク
・UI関連の修正は修正前後のスクリーンショット - コメントに遊び心を忘れずに
・LGTMは画像を使おう
・emojiを使おう
コードレビュー
- コードレビューをする・される
- レビュワーがレビューしやすい Pull Request への心がけ
・概要に背景 (why)、解決したいこと、要求仕様を書く
・巨大になりすぎないうちにレビューを依頼
・必要に応じて履歴を整理
・レビュー前にリファクタリング
大切なこと
- 家族を大切にする。同僚を大切にする
