Geolonia のソフトウエア開発

オープンソースについて

私たちのソフトウエア開発における大きな特徴の一つが「オープンソース」です。

では、なぜ私たちはオープンソースを活用するのでしょうか。目的は以下の通りです：

モチベーションが高く優秀なエンジニアの採用に結びつけるため
プロダクトに対する良質なフィードバックを集めるため
プロダクトがプロダクトを売る仕組みづくりのため
私たちが依存する様々なオープンソースプロジェクトに対するギブバック

私たちは、オープンソースが社会を変えるための大きな力となる可能性を秘めていると考えていますが、「無料」という言葉だけが先行して評価されることもたくさんあります。

GAFAMに代表される欧米のプラットフォーマーたちの多くが「オープンソース企業」を標榜している通り、私たちにとってのオープンソースは、ビジネス上の様々な課題を解決するための合理的なワークフローです。

私たちは、オープンソースのワークフローやエコシステムを活用しながら、民間企業として期待される社会貢献を果たしていくことを目指します。

理念

私たちが開発において重視していくべき理念は以下の通りです：

顧客（またはユーザー）の課題を解決します。開発者としての自身のための課題の解決と、顧客のための課題の解決はかならずしも一致しません。私たちは顧客の課題を解決することを優先します。
バザール方式を採用し、「小さくリリース、しょっちゅうリリース」を実践します。
「Decisions, not options」の考え方に基づき、ユーザーに対して安易に選択肢を増やさず、ベストな方法を模索して決断していきます。
ボーカルマイノリティ - 声が大きい少数派やニッチケースに惑わされないようにします。
「期限」や「予定」はそれ自体もソフトウエアの品質の一つとして捉えます。
実現するにあたっての問題点を考えるのではなく、どう実現するかを考えることを重視します。

以下は、Facebookが上場した際の申請書からの抜粋です：

The Hacker Wayは継続的な改良と反復による構築のアプローチです。技術者は、何事も常に改良することができ、それに終わりがないということを信じています。彼らは問題を直します。たとえ、人々がそれを不可能だと言ったり、現状に満足していてもです。

技術者は、すべてを一度に正しく実行しようとするのではなく、小さな反復からすばやくリリースして学習することにより、長期的に最高のサービスを構築しようとします。これをサポートするために、Facebookの何千ものバージョンをいつでも試すことができるテストフレームワークを構築しました。私たちは、常に"完了することは完璧よりも優れている"ことを思い出すために、壁にその言葉を刻みました。

[Mark Zuckerbergの2012年のFacebook IPO前の投資家向けレターより]

開発者に求めるスキル

ハードスキルとソフトスキル

ハードスキルとは？

私たちはハードスキルを、コーディング技術や専門知識など、専門書を読んだり訓練を積むことで習得可能なスキルと定義しています。

多くの場合、ハードスキルは試験によって計測可能であり、後述するソフトスキルに比べて習得することが比較的容易です。

ソフトスキルとは？

私たちは、学習意欲やコミュニケーション能力など、チームとして大きな価値を創造していく際に求められる能力をソフトスキルと考えています。多くの場合、ハードスキルに比べて後から身につけることが困難なスキルです。

主なソフトスキルとして以下が挙げられます： 1. コミュニケーション能力 2. 問題解決能力 3. リーダーシップ 4. タイムマネジメント 5. 創造性 6. 学習意欲 7. EQ

私たちは、ハードスキルの多くがAIによって代替されていくことは容易に予測できると考えており、ソフトスキルの重要度は今後非常に高まっていくと考えています。

スキルレベル

私たちは、開発者のスキルを以下の5種類のレベルに分類しています（名称は別途考えます）。

ルーキー - コードを書くことはできますが、タスクとして与えられた機能をどのように実装すべきかの判断はできません。関数の入力と戻り値、どの外部モジュールを使うべきかなどの指示に加えて、書かれたコードに対する詳細なレビューも必要です。
若手 - 関数の入力と戻り値を指示すれば、残りはわずかなコミュニケーションだけで実装を行うことができます。ただし、どのような関数を実装するべきかなど、要件に対する具体的な設計はできません。テストさえパスしていれば、コードに対する詳細なレビューは不要です。
準レギュラー - ソフトウエアの全体的な設計に対して、どのような関数を実装するべきかなどの実装上必要な設計ができます。ただし、ルーキーや若手に対して指示を出すスキルはありません。またソフトウエアに潜む潜在的な課題を自主的に改善するスキルもありません。この段階まではハードスキルのみが期待されており、ほぼすべてのエンジニアを育成可能です。
レギュラー - ソフトウエアの全体的な設計に対して、どのような関数を実装するべきかなどの設計を行うスキルがあり、ルーキーや若手、準レギュラーとともに、チームとして価値を創造していくことができます。また、ソフトウエアのパフォーマンスや信頼性、UXなどの課題を自主的に解決するスキルがあります。
エース - レギュラーのスキルに加えて、与えられた課題（またはビジネスロジック）から、ソフトウエアの全体的な設計を行うことができ、継続的に改善のサイクルを回すことができます。

私たちは、エンジニアのスキルをバックエンド、フロントエンドなどのスキルセットでも分類できると考えていますが、個々のエンジニアは、与えられたロールに応じて評価される必要があります。

たとえばフロントエンドエンジニアが、データベースの設計をできないからといって永遠にルーキーであるとは言えません。

スキル分けの目的

私たちは、開発者のレベルを上げることももちろん重要ですが、ルーキーや若手が貢献できる状態をつくることが、もっとも重要な課題であると位置づけています。

ルーキーや若手が貢献できる状態をつくるには、たとえば以下のような「指示の出し方」などの仕組み化が必要です。

レギュラーまたはエースが、空の関数及びユニットテストを記述します
ルーキー及び若手がそのテストをパスするようにコードを記述します

私たちは、レギュラーまたはエースが記述するテスト（または指示）では、以下が明確になっているべきだと考えています。

関数の入力（引数及びそれぞれのデータ型）
戻り値及びエラー処理（たとえばエラーがthrowされるべきか、それとも普通の変数であるべきかなども含めて）

相手のスキルによっては、入力と戻り値だけを指示すれば十分な場合もあります。

コーチングと20%ルール

私たちは、このようなワークフローを検討する場合の課題として、本人の認識と違う評価や誤った評価をしてしまうことによるモチベーションの低下があると考えています。

これには、コーチングと、Googleが採用しているような20%ルールを採用していくことで解決していきます。