バリューとポリシー
toggle holdingsで働くすべてのエンジニアが発揮するべきバリューと、遵守するべきポリシーです。働きやすく成果を挙げやすい環境を維持発展させるために、エンジニアが具体的にどのように振舞うべきかということを記載しています。
最終更新
toggle holdingsで働くすべてのエンジニアが発揮するべきバリューと、遵守するべきポリシーです。働きやすく成果を挙げやすい環境を維持発展させるために、エンジニアが具体的にどのように振舞うべきかということを記載しています。
最終更新
toggle holdingsにはがあり、これはエンジニア職に限らずあらゆるメンバーに対して求められる行動指針です。組織全体としてはこの考え方をベースに仕事に取り組んでいただくことになりますが、それを踏まえて特にエンジニア組織の中で「具体的にこのように考えて行動してほしい」ということを言語化したものです。
エンジニア組織では、個人のスキルだけでなく、チームの集合知とAIの能力を最大限に活用し、組織全体の成果を最大化することが重要な基本原則です。具体的には「トラブルシューティングにおいて積極的に問題解決に貢献した者」「チームのAI活用を支援し、アウトプットの質・量の向上に貢献した者」「AIを駆使して業務プロセスを抜本的に改善し、組織全体の生産性を飛躍させた者」が高く評価されます。ただし、いかに優れた成果であっても、他者への敬意を欠く、攻撃的と受け取られかねない表現は容認されません。建設的な協働を追求します。
あらゆる開発において、新規開発者のオンボーディング環境は（自動構築、AIによる関連ドキュメントの動的生成、Q&Aボット等）を活用し、限りなくゼロに近づけることを目指します。最初のPull Requestを出すまでの7時間以内という指標は最低基準であり、これを達成できない場合は、開発環境のAI支援強化を最優先で実施します。また、人員の増員を検討したくなった場合はまず「そのワークロードをAIに任せられるようにできないか」という問いを持って改善することが必要です、人間が介在しなくてもできることを常に探索し、人間が発揮すべき価値に集中しましょう。GitHub Copilot, Cursorをはじめとする最先端のAI開発支援ツールを手足として使いこなし、その効果を最大化するプロンプトエンジニアリングや活用ノウハウを組織全体で共有・進化させることは、全エンジニアの責務です。
プロダクト開発は、不確実性の中でチーム（人間とAIを含む）が一丸となって進めるものです。課題設定から実装、レビューに至るまで、あらゆる段階で人間とAI双方からのフィードバックを積極的に求め、活用する姿勢を極めて重視します。他のメンバーやフィードバックを求められた際は、迅速かつ建設的に応答することが求められます。そのためにAIを積極的に活用し、フィードバックの質と速度を高めましょう。社内だけでなく、ユーザーの声も積極的に取り入れます。我々は、人間とAIが協働し、多様なフィードバックを取り入れた仕事こそが、単独で進めるよりも圧倒的に高い品質を生み出すと確信しています。
----
これらの行動特性を最大限発揮してもらうために、以下のポリシーを徹底します。
どのような些細なことであっても、まずはIssueに起こしましょう。可視化することで、今知らないことでも人間とAI双方からのフィードバックを引き出すことができるようになります。
また、開発途中であってもフィードバックを受けるためにドラフトのPull Requestを出すことが推奨されます。AIによるレビュー支援（コード解析、コメント提案等）も活用しながら、人間とAI双方の視点を取り入れて内容を磨き上げます。レビュワーは指定された者以外でも、内容向上のためのコメントやAIによる改善提案を行うことが推奨されます。
AI支援を最大限に受けられる環境とツールを選択し、あるいは入れ替え続けましょう。開発・運用のあらゆる情報はAIが学習・分析可能な形式で記録されることを前提とします。プロジェクト情報管理の観点から、モノレポ構成が原則です。常にAI支援開発に最適化された状態を維持しましょう。
コミュニケーションは同期・非同期を場合によって使い分けることが望ましく、かつオープンであることが求められます。並行してAIによる議事録作成、翻訳、情報検索支援なども積極的に活用しましょう。コミュニケーションはSlackとプロジェクトごとのチャンネルを活用し、同期的な会話が必要な場合はHuddleとVSCode Live Shareを使います。秘匿されるべき情報（例：パスワードやアクセストークン）をやり取りする必要がある場合にはDMを用いても構いません。
新しいツールを提案することは問題ありませんが、その場合は既存のツールのうち2つ以上を減らせるものであること（我々はこれを「1 in 2 out原則」呼んでいます）を意識してください。
IaCツールを用いないでインフラ構築を行うと、後から加入したメンバーは何が展開されていてどのような関係にあるかを知ることが難しくなり、開発参加を困難にします。また、そうした経緯が暗黙の知識≒既得権益化することは組織利益とは相反します。更に、操作履歴等も残らず何が正かがわからなくなるため、うかつにリソース削除などもできなくなり、インフラコストをいたずらに増加させます。これを踏まえて、IaCツールを用いないインフラ構築を行う場合は、その理由を明瞭かつ全員がわかるところに、誰の責任で行ったかわかる形で記録してください。