GUIDELINES技術指針

  1. TOP
  2. 環境
  3. 技術指針

序文

この文章は、セプテーニ・オリジナルに所属する企画者・エンジニアの指針となるよう、現在の我々の目指すところ/我々が取っている行動の理由/我々が求める姿勢、を文章化したものです。

我々は“高速高品質”を目指す

システム開発は機を逸さないために開発速度が重要です。かといって品質を顧みなさすぎても不幸を生み出します。我々は高速に高品質なシステムを開発できる状態を目指します。
初回リリース最速を目指すことは意味しません。初期に作成する部分は最も下地となる部分であり、土台です。土台が腐ると、その上位レイヤーも腐ります。取り返しも付かないことが多いので丁寧に作成しましょう。

我々は保守性のあるコードを高速に生産する

“品質”と一口に言っても国際規格が存在するくらい複雑ですが、我々は品質の中でも“保守性”を重要視します。

保守性の低いコードを保守しようとすると、開発者の肉体や精神の不健康を招き、酷くなると休職・離職に繋がります。ビジネス面においてもフットワークは悪くなり、徐々に貢献できなくなってくるどころか、障害による損失・運用でカバーの多発によりマイナス影響を与えることも起こりえます。低い保守性のコードは追記された部分も悪くなりがちなうえ、前例に従うつもりでコピペされることも多いので、いつの間にか増殖します。後から改善することも困難です。早めに対応しましょう。
採用活動にも影響があります。良いコードを書いていればPRになりますが、悪いコードが蔓延していると好んで劣悪な環境に入りたがる人は居ないため、人材の確保が難しくなります。
いずれも会社の存続にも影響する問題であることから、我々はまずは保守性があり、それを保てるコードを高速に生産できる状態を目指します。

具体的に何をするのか

高速高品質を目指すため、効率が良い道具とプロセスを選び、良い状態を作れるよう努力をして、良い状態を作り、それを保ちます。

Scalaの利用を積極的に検討します

Scalaを使う理由は気軽に品質を維持するためです。

我々はScalaを積極的に使用します。Scalaは表現力に富み、手慣れた状態であれば労力少なく意図する機構を記述することができます。また型がありIDEも発展していることから、リファクタリングを行いやすく品質維持の労力が少ない言語です。
学習コストは小さくありませんが、何ヶ月もかかるものではありません。Javaの資産を活かせる点も実用的です。現時点では意識の高い人材との出会いを増やす効能もあります。

Scalaを利用しない場合

バッチなど、小さなプログラム、もしくは完全な使い捨てなプログラムを作成する場合、Scalaは利用しません。BashなりPythonなりPHPなり、状況に応じて使いやすい物を利用します。またユーザーに配布する必要がある、といった事情でフットプリントを大きく出来ない場合も利用しません。GoやC#、Excel VBAなどユーザー利便性と開発効率・保守性を天秤にかけて利用言語を選定します。
iOS開発や古いシステムの保守、目的とする環境でScalaが利用できない場合も他の言語を利用します。ただし、目的のライブラリが特定言語の物しかない、といった場合であればマイクロサービス化して分離を試みる、ラッパーを開発する、といった手法を検討する余地があります。
マイクロサービスを導入する場合、試行のしやすさを目的にレンダリング部分だけPHPに担当させるといったことも選択に入ります。
その他、他言語を利用することが合理的な場合には Scala にこだわることはありません。なお目的を鑑み、より優れた言語が登場した場合は、それに乗り換えることが推奨されます。

スクラムを採用する理由は現状を把握し、早く適切な判断をするため

我々は、スクラムを積極的に採用します。

変化の激しい市場において、我々は価値の高いプロダクトを提供し続ける必要があります。スクラムでは、バックログや各セレモニーによって適切かつ継続的なフィードバックサイクルを実現できます。Core Scrumの原則と価値に従いながら、現状に合ったプラクティスを模索し続けます。

スクラム以外を使う場合

スクラムが適さないと判断した場合は、スクラム以外の開発手法を選択します。
“適さない”とは、チームの維持期間が3ヶ月より短い場合、またプロダクトの状態が単純である場合が該当します。その他スクラムチームで適切な開発手法と判断し、スクラムマスター定例で同意を得た場合も別の開発手法を採用します。
スクラムマスターはスクラムの理解と成立に責任を持っており、スクラム自体に固執してはいけません。スクラム以外の開発手法も学習し、チームを適切に導かなければなりません。

DDDを採用するのはチーム全員で要件の芯を捉え続けるため

我々はドメイン駆動設計を積極的に採用します。

ドメイン駆動設計はユビキタス言語という言葉と実装を一致させる言語を用いてビジネス要件の芯を設計の中核におく手法です。「エンジニア以外にも翻訳不要で伝えることができる」「設計と実装に対する価値観が共有できる」という特徴があり、チーム全員で要件の芯を捉える助けになることを期待しています。具体的には、やらねばならないことのコストをプロダクトオーナーが認識しやすくなる/レビューや仕様検討時に、言葉と実装が一致しているか、というチェックを行えるようになる/設計や概念がまずい場合、言葉にすると自然と大仰に成り危険な感じになる、といった効能を期待しています。
なお、“レイヤードアーキテクチャを採用する”ではないため、上記効能を維持出来るアーキテクチャであればどの手法でも構いません。

DDDを採用しない場合・崩す場合

小さなプログラム、もしくは完全な使い捨てのプログラムの場合、DDDは採用しません。マイクロサービスにおいては、特定サービスの内部だけ採用しない、といった選択もあり得ます。
既存コードへの改修や、フレームワークなど開発環境の仕様が特殊である、など導入に無理が出過ぎる場合も採用しないか、崩すことを検討します。プロトタイプ作成時にも採用しません。プロトタイプは全てを割り切って高速に具現化することに価値があり、丁寧に設計することは目的と反します。なお、この文章におけるプロトタイプの定義は プロトタイプの定義 セクションを参照してください。

テストはバグの少ないシステムを速く作り続けるため

我々はテストを怠りません。テストが無いシステムを書き換えるのは恐ろしいものです。テストの存在により、確信を持って変更できます。

小さい単位で、再現性があり、変更が容易で、実行の速い、自動化されたテストを我々は好みます。これらの性質をもつテストは、問題点を速く正確に特定でき、テスト対象とテストが共に素早く変更でき、回帰テストの繰り返し実行に耐えられるからです。ただし必要に応じて、これらの性質を持たないテストも併用します。例えば、ユーザーストーリーの受け入れテストは内容が複雑かつ広範に渡ることがありますし、探索的テストの自動化は難しいでしょう。

データ基盤や機械学習アプリケーションなど、自動テストが難しい、あるいは、十分な効果が期待しづらい領域があります。これらの領域では、テスト可能性を高めるトライをすると共に、監視を中心としたアプローチで問題を早期に発見する仕組みを充実させます。 

テストを書かないとき

変更する想定の無い書き捨てのプログラムを書く場合には、回帰テストを目的としたテストは書きません。

確認したいことが不明瞭なテストや、型などの他の仕組みにより担保されていることを確認するテストは、品質にも速度にも寄与しないため書きません。

レビューを行うのは意識を保ち続けるため

我々はコードレビューを行います。

一人で綺麗な設計・コードを書き続けるのは難しく、他人の目と意見があってこそ行うことが出来ます。鉄の自制心を持ったメンバーでチームを固めているわけでもなければ、レビュー無しに品質を保ち続けるのは困難でしょう。

レビューを行い続けるため、属人性を高めない

一人開発、もしくはサーバをいじれる人一人・クライアントをいじれる人一人、というようにスキルセットで担当分けをすると相互にレビューをすることが難しくなります。このような属人性を高める体制は避けるべきです。可能であればサーバ側2名・クライアント2名、もしくはサーバとクライアントを両方扱える者1名を混ぜる体制にしてレビュー品質の確保を組織レベルで心がけましょう。
それでも1名〜2名で始めざるを得ない場合は発生しますが、この状態を長引かせると属人性が高まりすぎてしまい、健全なレビュー体制に戻せなくなります。早めにタスクローテーションを行う、もしくは二人でサーバを作ってから二人でクライアントを作成する、等の工夫で属人性が高まらないよう注意をしましょう。

レビューを行わない場合

よほどの緊急事態でなければ、レビューを行わない理由はありません。そもそも一人開発である、専門性が高く自分しか見ることが出来ない、等の問題でレビューを行えない場合は有ります。これは組織の問題なので、組織(あるいはチーム)で解決を図ることになります。具体的には単独開発にならないアサインをする・専門家を育てる、といった策になります。

プロトタイプの定義

課題に対する解決案や得られる成果の大きさが不明確な案件に対してリスクの低減を目的としたプロトタイプを作成することがあります。プロトタイプでは保守性より素早さが求められるため、1人で開発したり、ユニットテストやレビューを実施しないことがあります。
一方で、プロトタイプと称して保守性を考えず作成されたプロダクトが使われ続け、保守に苦しむ事態が過去に何度も発生していました。保守性の低いプロダクトを保守することによる苦しみを避けるために、プロトタイプでは次の制約を設けます。制約を満たさないプロトタイプは速やかに廃棄します。
ここでは、システム・サービスの停止がなされ利用不可能でコストが発生しない状況を廃棄と定義します。ただし、ソースコードについてはその後の参考のため残すものとし、廃棄されたプロトタイプであることがわかるよう明記することとします。

開発前

  • 開発・評価期間、評価基準が事前に明文化されていること。
  • 開発・評価期間は合わせて3ヶ月以内であること。

開発・評価終了後

  • 評価基準を満たした場合には、本格開発物にリプレイスされるまで、プロトタイプを維持するために最小限の運用を複数名で可能な状態を評価終了後3ヶ月以内に構築すること。
  • 本開発に移行する際には、コードの作り変えも含めて検討し、長期の運用保守が可能な状態を構築すること。
  • プロトタイプは評価終了後から1年以内に廃棄すること。

技術指針の適用除外について

やむをえない事情で技術指針(プロトタイプを含む)の遵守が難しい場合、または遵守が得策でないと考えられる場合、以下の手続きにより技術指針を適用除外とすることができます。

  • 技術指針の付録文書として適用除外の理由/期間や条件を記載した文章を作成する。
  • 作成した文章について開発定例会議参加者全員の承認を得る。

おわりに

この文章に記載されている具体的技術(言語・設計手法等)はすぐに陳腐化すると予想されるため、拘り続ける意味はありません。しかし、この文章に記載されている考え方は時間が経っても大きくは変わらないと思われます。常に心に留め、研鑽を積みましょう。

2020年3月 更新