この文章は、セプテーニ・オリジナルに所属する企画者・エンジニアの指針となるよう、現在の我々の目指すところ/我々が取っている行動の理由/我々が求める姿勢、を文章化したものです。我々は“高速高品質”を目指すシステム開発は機を逸さないために開発速度が重要です。いって品質を顧みなさすぎても不幸を生み出します。我々は高速に高品質なシステムを開発できる状態を目指します。初回リリース最速を目指すことは意味しません。初期に作成する部分は最も下地となる部分であり、土台です。土台が腐ると、その上位レイヤーも腐ります。取り返しも付かないことが多いので丁寧に作成しましょう。我々は保守性のあるコードを高速に生産する“品質”と一口に言っても国際規格が存在するくらい複雑ですが、我々は品質の中でも“保守性”を重要視します。保守性の低いコードを保守しようとすると、開発者の肉体や精神の不健康を招き、酷くなると休職・離職に繋がります。ビジネス面においてもフットワークは悪くなり、徐々に貢献できなくなってくるどころか、障害による損失・運用でカバーの多発によりマイナス影響を与えることも起こりえます。低い保守性のコードは追記された部分も悪くなりがちなうえ、前例に従うつもりでコピペされることも多いので、いつの間にか増殖します。後から改善することも困難です。早めに対応しましょう。採用活動にも影響があります。良いコードを書いていればPRになりますが、悪いコードが蔓延していると好んで劣悪な環境に入りたがる人は居ないため、人材の確保が難しくなります。いずれも会社の存続にも影響する問題であることから、我々はまずは保守性があり、それを保てるコードを高速に生産できる状態を目指します。具体的に何をするのか高速高品質を目指すため、効率が良い道具とプロセスを選び、良い状態を作れるよう努力をして、良い状態を作り、それを保ちます。第一の選択肢としてScalaの利用を積極的に検討しますScalaを使う理由は気軽に品質を維持するためです。我々はScalaを積極的に使用します。Scalaは表現力に富み、手慣れた状態であれば労力少なく意図する機構を記述することができます。型がありIDEも発展していることから、リファクタリングを行いやすく品質維持の労力が少ない言語です。学習コストは小さくありませんが、何ヶ月もかかるものではありません。Javaの資産を活かせる点も実用的です。現時点では意識の高い人材との出会いを増やす効能もあります。Scalaを利用しない場合バッチなど、小さなプログラム、もしくは完全な使い捨てなプログラムを作成する場合、Scalaは利用しません。BashなりPythonなりPHPなり、状況に応じて使いやすい物を利用します。ユーザーに配布する必要がある、といった事情でフットプリントを大きく出来ない場合も利用しません。VBAなどユーザー利便性と開発効率・保守性を天秤にかけて利用言語を選定します。iOS開発や古いシステムの保守、目的とする環境でScalaが利用できない場合も他の言語を利用します。目的のライブラリが特定言語の物しかない、といった場合であればマイクロサービス化して分離を試みる、ラッパーを開発する、といった手法を検討する余地があります。マイクロサービスを導入する場合、試行のしやすさを目的にレンダリング部分だけPHPに担当させるといったことも選択に入ります。こだわることはありません。目的を鑑み、より優れた言語が登場した場合は、それに乗り換えることが推奨されます。スクラムを採用する理由は現状を把握し、早く適切な判断をするため我々は、スクラムを積極的に採用します。変化の激しい市場において、我々は価値の高いプロダクトを提供し続ける必要があります。スクラムでは、バックログや各セレモニーによって適切かつ継続的なフィードバックサイクルを実現できます。Scrumの原則と価値に従いながら、現状に合ったプラクティスを模索し続けます。スクラム以外を使う場合スクラムが適さないと判断した場合は、スクラム以外の開発手法を選択します。“適さない”とは、チームの維持期間が3ヶ月より短い場合、またプロダクトの状態が単純である場合が該当します。その他スクラムチームで適切な開発手法と判断し、スクラムマスター定例で同意を得た場合も別の開発手法を採用します。スクラムマスターはスクラムの理解と成立に責任を持っており、スクラム自体に固執してはいけません。スクラム以外の開発手法も学習し、チームを適切に導かなければなりません。DDDを採用するのはチーム全員で要件の芯を捉え続けるため我々はドメイン駆動設計を積極的に採用します。ドメイン駆動設計はユビキタス言語という言葉と実装を一致させる言語を用いてビジネス要件の芯を設計の中核におく手法です。「エンジニア以外にも翻訳不要で伝えることができる」「設計と実装に対する価値観が共有できる」という特徴があり、チーム全員で要件の芯を捉える助けになることを期待しています。具体的には、やらねばならないことのコストをプロダクトオーナーが認識しやすくなる/レビューや仕様検討時に、言葉と実装が一致しているか、というチェックを行えるようになる/設計や概念がまずい場合、言葉にすると自然と大仰に成り危険な感じになる、といった効能を期待しています。“レイヤードアーキテクチャを採用する”ではないため、上記効能を維持出来るアーキテクチャであればどの手法でも構いません。小さなプログラム、もしくは完全な使い捨てのプログラムの場合、DDDは採用しません。マイクロサービスにおいては、特定サービスの内部だけ採用しない、といった選択もあり得ます。既存コードへの改修や、フレームワークなど開発環境の仕様が特殊である、など導入に無理が出過ぎる場合も採用しないか、崩すことを検討します。プロトタイプ作成時にも採用しません。プロトタイプは全てを割り切って高速に具現化することに価値があり、丁寧に設計することは目的と反します。セクションを参照してください。ユニットテストを書く理由はリファクタリングをし続けるため我々はユニットテストを書きます。改修を続けるシステムにおいて、仕様変更に伴い既存コードがベストな設計で無くなる場面が発生します。この際、保守性を維持するためには既存コードも理想と思える設計に書き換える—リファクタリングをする必要が有ります。テストがあれば“書き換えたが動かしたことが無い”領域が減り、安心度が高まります。テストが無い場合、只の作り直しであるためリスクが大きく既存コードの改修は憚られる場合が発生します。これが積み重なると設計の歪みが大きくなり、保守性の大幅な低下を招きます。ユニットテストは頻繁に動作確認ができる作業台としての役割も期待します。E2EテストやF5(再読込)駆動開発では全てを結合しなければ動作確認ができませんし、場合分けをカバーしきるのは難しいですが、ユニットテストであればメソッド単位で確認を行うことができます。細かな場合分けにも対応できます。我々はTDDを標準とはしませんが、その心は参考にし、ある程度小さいまとまりでテストを動かしましょう。テストを書くことで自分の書いたコードの最初の利用者が自分となりましょう。使い勝手の改善や、不具合検出の助けとなります。テストを書く=遅い、という思い込みを止めようテストもコードを書く以上、時間を消費するのは確かですが、作業台として活用をすれば確認効率も高まるので、慣れ次第ではF5駆動開発より素早く開発できるかもしれません。仕様変更を行ったときの確認項目の削減効果も大きいので、長期的に見て速度を落とさないための手段、と考えても良いでしょう。カバレッジ100%を目指す、といったテストを書きすぎる方向に陥ると本当に遅くなるので注意しましょう。テストの密度や品質は保守性の維持を念頭に置きつつ、適度に省きましょう。他のテストにより安心できる部分は省くことが推奨されます。テストはよりカバー率の高くなる下位層—レイヤードアーキテクチャであればDomain層/Infra層、の方を充実させましょう。テストを書かない場合バッチなど小さなプログラム、もしくは完全に使い捨てであることが確定しているプログラム、にはテストを書かなくても十分な場合が多いでしょう。プロトタイプに対しても前述の理由でテストは書くべきではありません。レビューを行うのは意識を保ち続けるため我々はコードレビューを行います。一人で綺麗な設計・コードを書き続けるのは難しく、他人の目と意見があってこそ行うことが出来ます。鉄の自制心を持ったメンバーでチームを固めているわけでもなければ、レビュー無しに品質を保ち続けるのは困難でしょう。レビューを行い続けるため、属人性を高めない一人開発、もしくはサーバをいじれる人一人・クライアントをいじれる人一人、というようにスキルセットで担当分けをすると相互にレビューをすることが難しくなります。このような属人性を高める体制は避けるべきです。可能であればサーバ側2名・クライアント2名、もしくはサーバとクライアントを両方扱える者1名を混ぜる体制にしてレビュー品質の確保を組織レベルで心がけましょう。それでも1名〜2名で始めざるを得ない場合は発生しますが、この状態を長引かせると属人性が高まりすぎてしまい、健全なレビュー体制に戻せなくなります。早めにタスクローテーションを行う、もしくは二人でサーバを作ってから二人でクライアントを作成する、等の工夫で属人性が高まらないよう注意をしましょう。レビューを行わない場合よほどの緊急事態でなければ、レビューを行わない理由はありません。そもそも一人開発である、専門性が高く自分しか見ることが出来ない、等の問題でレビューを行えない場合は有ります。これは組織の問題なので、組織(あるいはチーム)で解決を図ることになります。具体的には単独開発にならないアサインをする・専門家を育てる、といった策になります。課題に対する解決案や得られる成果の大きさが不明確な案件に対してリスクの低減を目的としたプロトタイプを作成することがあります。プロトタイプでは保守性より素早さが求められるため、1人で開発したり、ユニットテストやレビューを実施しないことがあります。一方で、プロトタイプと称して保守性を考えず作成されたプロダクトが使われ続け、保守に苦しむ事態が過去に何度も発生していました。保守性の低いプロダクトを保守することによる苦しみを避けるために、プロトタイプでは次の制約を設けます。制約を満たさないプロトタイプは速やかに廃棄します。ここでは、システム・サービスの停止がなされ利用不可能でコストが発生しない状況を廃棄と定義します。事前に明文化されていること。満たした場合には、本格開発物にリプレイスされるまで、プロトタイプを維持するために最小限の運用を複数名で可能な状態を評価終了後3ヶ月以内に構築すること。本開発に移行する際には、コードの作り変えも含めて検討し、長期の運用保守が可能な状態を構築すること。プロトタイプは評価終了後から1年以内に廃棄すること。技術指針の適用除外についてやむをえない事情で技術指針(プロトタイプを含む)の遵守が難しい場合、または遵守が得策でないと考えられる場合、以下の手続きにより技術指針を適用除外とすることができます。技術指針の付録文書として適用除外の理由/期間や条件を記載した文章を作成する。おわりにこの文章に記載されている具体的技術(言語・設計手法等)はすぐに陳腐化すると予想されるため、拘り続ける意味はありません。この文章に記載されている考え方は時間が経っても大きくは変わらないと思われます。常に心に留め、研鑽を積みましょう。Original,Inc.。