Aiming 開発者クレド

コードの重視・ アウトプット重視

ソフトウェア受託開発の大規模な連鎖の中で、プロジェクトが失敗したりエンジニアが割を食ったりするというのは、日本ではよくある話です。

ふくれあがるコミュニケーションのオーバーヘッドに対応するために、いろいろな工程に投入される「プログラミングのできない設計者」もしくは「単なる仕切り屋と化すプログラマ」。
設計者と実装者と管理者を完全に分けてしまってケンカになるのは、みんなにとっての不幸です。
料理を作れない人がレシピを書いていたり、料理人が号令だけかけていては、おいしい料理は作れないでしょう。

アウトプット重視の開発

Aiming 制作風景

採用や組織編成など、業務のあらゆるところでソースコード重視、アウトプット重視のポリシーを置いています。

作業は工程で分担するのではなく、一人のエンジニアがある機能が完成するまでのすべてをおこないます。この方が責任も明確ですし、作る実感も湧きます。

また、GitHubを使ったコードレビューもおこなっています。コードレビューは、品質保障の点と技術者としての成長の点という2つの点で重視しています。

アウトプット重視の採用

採用においては、あなたが世の中に何を公開しているか、あなたが個人の興味によって何を作ったかを常に評価します。
どこの大学を出てどんな資格を取った、どの会社で何のプロジェクトに参加したといったことよりも、GitHubのコードや、オープンソースへのコミット、オープンでなくても個人的に作ったオレオレツールやスクリプト、作りかけの dog food、ブログや SNS などを見ます。

これは、所属した組織ではなく「あなたが実際に生み出した価値は何か」に興味があるからです(もちろん、今まで会社の中で価値を出してきた人もいるので、すべての人をこの軸で評価するというわけではありません)。

また、自分で作った何かを公開していることは、小さくても世に出して評価される勇気を持っていることの証明です。これは非常に立派なことです。

孔子の言葉に「子曰く、これを知る者はこれを好むものに如かず。これを好むものはこれを楽しむ者に如かず。」というものがあります。
「知るひとは好いている人に、好いている人も楽しんでいる人には及ばない」という意味です。
個人のアウトプットは、あなたが何を好きで、何を楽しんでいるのかを如実に表しています。
何を考えて、何を作ったのかを話してください。
そして我々と一緒に好きを追求し、エンジニアリングを楽しみませんか?

チーム対問題の原則とツッコミビリティ