システムを作ろうとした時に、まずはサービスとしての立ち上げを優先するあまり、それ以外の事は時間ができたらと後回しにする事はよくあります。
しかし、規模が大きくなってサービスが軌道に乗ってくると色々とあの時やっておけばよかったとか、もう一度作り直したいという状況に追い込まれるのはよくある事です。
そんな事にならないように、初めからある程度考慮しておいたほうが良い事を書いてみたいと思います。
システム開発に関すること
1. フレームワークを利用する
一からシステムを組む際は、何らかの著名なフレームワークを最初から導入した方が効率的に進められます。
全てを手作りしたい衝動やフレームワークを導入する際の教育などのコストだけを見ていると、あとあと後悔する羽目になったりします。
それは規模が大きくなるにつれ、保守性がやたらと落ちたり、独自の構造から他のエンジニアがそれを使うのに習得するコストがフレームワークを使う場合のそれを上回る時がきたり、（その独自システムを作った人の自己満足が多く含まれる故に）そもそもそれを使ったところでエンジニアとして何もスキルアップ出来ない状況となったり、技術がレガシー化してサービスが対応出来ないといった課題が出てきたりするからです。
2. ログは残しておく
ログというのは思った以上に大事で、何も開発時のバグの発見やサポート時の状況調査に使われるだけではありません。
サービスのアクセス状況や行動履歴から有用な情報を得たりする事ができます。
前者は開発上どうしても必要となるため、ある程度目が向けられたりしますが、一定の期間があれば十分ということでその後捨てられ、後者の要件が満たせないということになったりします。
これは、ログサーバーの構築やバックアップの構成に影響してきます。
5年前のサービスインの時と今の状況を比較したいというような効果分析をしたいのなら最初から考慮すべき事となってきます。
3. 開発環境を整備する
規模が大きくなってくると多くのエンジニアが携わる事になりますから、個々のPCに入れるツールや開発サーバーの用意も必要になってきます。
規模が小さい場合、開発サーバーは別れているもののリリース前に確認するステージング環境と本番が設定分けているだけで同一サーバーだ、なんてのをよく見たりもします。
しかし、こういう状況は大きなリスクを負いますし、何よりもサービスを拡張していく上で足枷となってしまいます。
また、開発者が利用するPCやIDE等々の環境も整備しておいた方が良いでしょう。
これはエンジニアの能力を高めるだけでなく、環境の差から生まれる問題に頭をなやされるといった無駄な時間を解消してくれます。
4. スタンダードで実装する
フレームワークの件でも書きましたが、独自の実装を進めると大抵の場合はあとあとボロがでてきます。
世の中には先人たちが築き上げたベストプラクティスが幾つもあり、そして標準化された技術や高機能のライブラリも多数用意されていますので、それを使わない手はありません。
そういったものは、息の長い技術になってきますし、Tipsも多いためエンジニアの手助けをしてくれ、そしてスキルアップを助けてくれますし、何より変化に柔軟です。
世の中にないものを自分たちで作ろうとしない限りは車輪の再発明をするのはやめた方がよいでしょう。
システム保守・運用に関すること
5. 資料のアップデートを続ける
システム運用に関する資料は、設計書や操作マニュアル、障害時のリカバリ対応方法をまとめたものや、運用の体制からフローを定義したものなど多岐に渡ります。
開発当初はこまめにアップデートしてもリリース時点で既に整合性が取れてない資料がゴロゴロあるというのも珍しくありません。
これらの資料の作成やアップデートは優先度が引くなりがちですし、常に参照するわけでもないので、作業者のモチベーションもあがりません。
ただ、いざという時には必要なものになりますし、他のエンジニアへの引継ぎや教育などでは一から説明するよりは体系的に纏められたドキュメントがあった方が便利です。
この問題を解決するために、ドキュメントの管理方法やwikiを使うなどオンラインで手軽に使うためのツールやルールの整備も必要になってきます。
使わない資料を作るほど無駄の事はありませんし、誰が管理すると決められていてはなかなかアップデートも出来ないので、チームでそれを補う仕組みがあったほうがよいでしょう。
6. バージョン管理をすること
保守フェーズに入ってくると様々な機能の拡張や変更が行われます。
これはサービスの発展のためには仕方のないことですが、そのスピードが上がるにつれ内部仕様は複雑さを増し、問題もまた増えてきます。
プログラムのバージョン管理ができていないと、誰が行った作業かやいつから仕様が変わったのか、バグがどの時点で混入したのかの調査が難しくなります。
保守フェーズにおいて、この作業にかける時間は馬鹿になりません。
また、バージョン管理はバックアップにも大いに役立ちます。
バージョン管理の扱いは多少扱いが難しいかもしれませんが、よくある直近のソースの状態をコピーしてから作業するといった事を続けるより遥かに多くのメリットをもたらせてくれます。
プログラムだけでなくコンテンツやドキュメントもバージョン管理の対象に含めておいた方がよいでしょう。
うっかり上書きしてしまったのであの時のドキュメントに戻したいとか、昔のデザインと見比べたいといった場合でも、瞬時に取り出せることで無駄な時間と労力を使わなくても済むようになります。
7. 自動化する
運用というのは作ってる過程ではおざなりになりがちで、よく「それは運用でカバーする」なんて言葉も聞かれます。
しかし、実際に運用が始まると苦労するのは担当者で、その後の施策の中で数多くの運用改善のプロジェクトが立ち上がり、その時間で本来のサービス拡張に手が付けられないという事態もでてきます。
また、手作業や人ありきの運用をしていると、サービスが大きくなるにつれ、その部分がボトルネックになり上手く回らなかったり、エンジニアもスキルが身につかなかったり属人化するリスクもでてきます。
運用のとこまで視点を広げ、 人の手をなるべく介さない業務作りも必要になってくるでしょう。
システム運営に関すること
8. 資産や契約を管理する
資産というのは機器だけでなくライセンスなども含まれてきます。
また、契約はそれに紐づくもので保守や請負に関する事など多岐に、そして複雑に絡んできます。
これをなぜ管理しないといけないかというと、まだ余剰で使えるものに無用な投資をする事を避けたり、契約期間が過ぎて保守が受けられなくなるというリスクを回避したり、それに伴う契約期間を考慮する事でシステムのライフサイクルやマイルストンを設定する事ができるからです。
システムはこの手の問題がつきまとい、構築当初は遠い未来のようでも、やがてEOS（End Of Support）を迎えるために次のリプレイスを検討しなくてはいけない時期がやってきます。
そういったリスクへの舵取りをうまくするためにも資産管理をしておく必要があります。
9. 役割を決め、専門職に任せること
サービスを作るには多くの役割とその担当者が出てきます。
そして、その道のプロも数多く携わるわけで、その人たちの成果物や意見に対して、素人は意見を挟んだり手を加えない方が良いでしょう。
デザインはデザイナーに任せた方が良いですし、サービスに対するイメージというのは上手く伝える必要はありますが、細かな色使いやレイアウトに意見することで本来の良さが消えることの方が多かったりします。
その意見は大抵、個人の意見だけが含まれた感覚的なものですので、広く受け入れられるとは限りませんから、その一言で本来の良さが消えてしまうどころか、そのままの状態で長く運用で引きずる羽目になってしまいます。
そして、その仕様に対して責任を取ってくれることはありませんし、次のリプレイス時には、口出しした人は恐らくいないでしょう。
10. 前に進めること
エンジニアは、ある程度の規模に成長したシステムを見て、小さな綻びがやたら気になり出したりします。
エンジニアの作り直したい病 でしょうか。
ここに書いたことを例えうまく見越していても何かの理由を付けて一から作り直したい衝動に駆られるものです。
しかし、大事なのはサービスとしての計画を一歩ずつ前に進めることです。
例えそれが後で問題がでるとしてもサービスを大きくすることを優先させなくてはならないことはあります。
同じ機能のために作り直す事はナンセンスで、それによる進化を盛り込まなくてはなりません。
後悔やモヤモヤとした感情を甘受することもまた必要な事となってきます。
まとめ
これらのことは、後々後悔することが多くありますが、その全てを見越すことは難しいことです。
わかっていても予算やスケジュールの都合で出来ないということもありますし、最後に書いたように後悔すると分かっていても優先度的に前へ進めなければならないこともあります。
ただ、初めからわかっていることと突っ走ってしまって後悔するのとでは大きく結果も違ってきます。
何が何時の時点で問題になるのか、後で何をすればいいのかということを分かっていれば、そのリスクをうまくコントロールすることも出来るでしょう。