📏バリューとポリシー

toggle holdingsで働くすべてのエンジニアが発揮するべきバリューと、遵守するべきポリシーです。働きやすく成果を挙げやすい環境を維持発展させるために、エンジニアが具体的にどのように振舞うべきかということを記載しています。

前提

toggle holdingsにはクレドがあり、これはエンジニア職に限らずあらゆるメンバーに対して求められる行動指針です。組織全体としてはこの考え方をベースに仕事に取り組んでいただくことになりますが、それを踏まえて特にエンジニア組織の中で「具体的にこのように考えて行動してほしい」ということを言語化したものです。

バリュー

チームの成果 ＞ 個人の成果

エンジニア組織においては「トラブルシューティングに積極的に参加して問題解決に貢献した者」「他のメンバーのPull Requestの品質を上げることに貢献した者」「積極的に業務改善し、組織全体の生産性向上に寄与する行いをした者」が評価されます。但し「問題解決できるから」「品質が向上するから」といって攻撃的と受け止められるような表現を使う者はチームワークを損なうため、容認されません。公正な評価のため、GitHub上での活動を可視化するダッシュボードを作成し、全員が見られるようにしています。ダッシュボードツールにはFindy Team+を利用しており、様々な角度からアクティビティを見ることができます。

開発者生産性向上の徹底

あらゆるプロダクトは、新規開発者のオンボーディング期間を限りなくゼロ近づけなければなりません。具体的には、開発環境のセットアップを行い、最初のPull Requestを出せるようになるまで7時間以内でなければならないという指標を設けています。これを超える場合は新規メンバーの増員よりも先に開発環境の改善を行わなければなりません。また、開発者生産性を向上させるツールについては積極的に取り入れていきます。GitHub Codespaces, GitHub Copilot, ChatGPTなど、活用できるものは徹底的に使い倒し、そのノウハウを組織にフィードバックすることが推奨されます。

積極的にフィードバックを受ける

プロダクト開発はチームで行うものであり、また不確定要素も多いものです。チームで問題解決をするために、課題解決アプローチを決めるところから途中経過まで、あらゆる状況において他者にフィードバックを求める姿勢を重視します。また、他のメンバーからフィードバックを求められた者はどのような粒度であれフィードバックを返すことが必要です。フィードバックは社内だけで受けるものではなく、積極的にユーザーの情報も取得しましょう。単独で進めた仕事よりも、他者と協力して進めた仕事の方が質が高いということを我々は信じています。

----

これらの行動特性を最大限発揮してもらうために、以下のポリシーを徹底します。

ポリシー

まずIssueを作り、開発途中でもPull Requestを送る

常にフィードバックを求めることができる状態で仕事を進めてください。

どのような些細なことであっても、まずはIssueに起こしましょう。可視化されないものは存在しないものとみなされます。Issueを作れば、その内容に対してコメントを受けることができますし、今知らないことでも、知っている人から知識引き出すために利用できます。

また、開発途中であってもフィードバックを受けるためにドラフトのPull Requestを出すことが推奨されます。そしてフィードバックを受けながら内容を磨き上げてください。ドラフトのPull Requestは、指定されたレビュワー以外であっても内容を磨くためのコメントを付けることが推奨されます。レビュワーのApproveが得られたらドラフトを外してマージすることが可能になります。

開発環境とツールの集約

開発環境はGitHub、コミュニケーションはSlackに集約しなければなりません。

開発・運用のあらゆる情報はGitHub Repo, Projects, Wikiの中にあることを前提とします。開発者生産性向上のため、GitHub Codespacesを用いて開発を行います。GitHub Codespacesでの開発基盤整備や、プロジェクト情報管理の観点から、モノレポ構成が原則です。開発環境を改善したい場合は、GitHub Codespaceの構築内容に対してPull Requestを送ってください。技術検証などでローカル環境を構築することは自由ですが、最終的にGitHub上で何らかの形で可視化されないものについては評価の対象になりませんし、仕事をしたと認められることもありません。

コミュニケーションは同期・非同期を場合によって使い分けることが望ましく、かつオープンであることが求められます。コミュニケーションはSlackとプロジェクトごとのチャンネルを活用し、同期的な会話が必要な場合はHuddleとVSCode Live Shareを使います。秘匿されるべき情報（例：パスワードやアクセストークン）をやり取りする必要がある場合にはDMを用いても構いません。

新しいツールを提案することは問題ありませんが、その場合は既存のツールのうち2つ以上を減らせるものであること（我々はこれを「1 in 2 out原則」呼んでいます）を意識してください。

IaCによるインフラ構築

インフラ構築はIaCツールを使うことが必須です。

IaCツールを用いないでインフラ構築を行うと、後から加入したメンバーは何が展開されていてどのような関係にあるかを知ることが難しくなり、開発参加を困難にします。また、そうした経緯が暗黙の知識≒既得権益化することは組織利益とは相反します。更に、操作履歴等も残らず何が正かがわからなくなるため、うかつにリソース削除などもできなくなり、インフラコストをいたずらに増加させます。これを踏まえて、IaCツールを用いないインフラ構築を行う場合は、その理由を明瞭かつ全員がわかるところに、誰の責任で行ったかわかる形で記録してください。