はじめに
こんにちは。電子契約サービスであるクラウドサインの開発に携わっている神達です。 社内で運用されている DesignDoc の作成・レビューを行えるようになるため、1 年間ほど取り組んだ内容をまとめてみました。 弊社に入社してからはじめて触れた概念だったため、最初はなにを意識すればいいのか非常に戸惑いました。 知識や観点の不足を補い、迷いを減らすための取り組みを行ったので参考にしていただければ幸いです。
DesignDocとは
DesignDoc は、機能開発のプロジェクトを始める前に、その機能全体の設計を文書にしたものです。 背景・目的・検討した案・方針などと一緒に資料化します。 プロジェクトの性質・ボリュームによって表現すべき内容・粒度が変わります。
抽象度の高い設計について記載するものであり、実装に踏み込むような詳細な内容は記載しません。 このような資料を作成することで、事前に全体像を整理して開発するうえでの見通しを良くしたり、テックリードなどチーム外からのフィードバックを早い段階で受けることにより手戻りを減らすことが出来ます。
課題への直面
DesignDoc のテンプレートや基本方針は社内で整備されており、その点は特に困っていませんでした。 ただ、いくつか DesignDoc の作成やレビューをしてみた結果、自身の課題に直面しました。 具体的に感じていた課題は以下のとおりです。
- 設計の知識と実践が全般的に足りていない
- AWS の知識が足りていない
- 時間確保が難しい
この課題を克服し、DesignDoc の作成やレビューが「できる」と言えるためにはどうなれば良いのか。 抽象的ではありますが、以下の水準を満たせれば最低限は「できる」とみなしました。
- 作成 ... 設計内容以前になにをどう書くべきかで大きく迷わないこと
- レビュー ... いくつかはフィードバックが出てくること、何を見れば良いか分からず途方にくれないこと
克服に向けた計画
社内で質問した
以下のとおりゆるく質問したところ先輩の方々からいろいろ教えていただけたので、それを参考にして克服に向けた取り組みを計画しました。
【緩募】漠然とした質問なんですが、みなさんがDesignDocの作成・レビューするときに意識していることや参考になる資料や書籍などあれば教えていただけませんか？ 個人的には設計能力自体、非機能要件の知識、インフラの知識あたりが弱いなーと思ってます。それ以外もなんでもいただければ嬉しいです。
参考になる書籍やサイト、社内資料や資格について教えていただけました。
取り組みたいことを整理した
自身の課題と先輩の方々からの意見を踏まえ、以下のとおり取り組むことを整理・計画しました。
- システム設計・インフラ・AWS の知識を身につける
- 業務を調整して時間を捻出する
- 場数を踏む
- 慣れる
- 観点を知る
具体的に取り組んだこと
実際に 1 年間ほど取り組んだ内容と結果を紹介します。
技術系の書籍を読んだ
以下の書籍を読んで知識を増やしました。 システムの設計・運用に必要な観点はかなり広いと感じました。 他の人と輪読会形式にすることで安定して読み進めました。
- 入門 監視
- Web システムではリリース後の運用まで考える必要がある
- 本書では監視の種類、見るべき指標、領域ごとの具体的な実現手段を知ることができる
- アラートによる異常検知だけでなく、改善していくための計測も含まれる
- システム設計の面接試験
- 配色や図解で非常に分かりやすく構成されている
- よくある構成のパターン、要件ごとに必要な観点がいくつも紹介されている
- タイトル通り面接試験で答えられるように、論理的にシステム設計する流れになっていて実用的
- サーバ/インフラを支える技術
- 古めなのでオンプレ寄りな内容ではあるが、今でも通じる基礎を学べる
- 具体的な設定例も多く出てくるため、最初は細かく読み込まずに手法や概念を知るぐらいのつもりで流し読みでも良さそう
- 3分間ネットワーク基礎講座
- 初学者でも非常に分かりやすい表現とボリュームになっている
- ネットワークを雰囲気で流してきた人にはちょうどいい
- マイクロサービスパターン
- 商用サービスであれば高い確率で選択肢に入ってくるマイクロサービスについて解説している
- マイクロサービスパターンのメリット・デメリット、根底にある技術、実現パターンについて細かく触れている
- かなり細かく扱っていて勉強になるが、ボリュームがあって全部読むのはしんどいので、つまみ食いで読むと良さそう
- 情報セキュリティの敗北史
- 勉強というよりは読み物
- なんとなくで曖昧に捉えていたセキュリティという概念について、歴史を踏まえてどう捉えるべきか新たな観点をもらえた
AWSの資格を取得した
弊社では AWS を多く使っているので、当然 DesignDoc などの全体設計でも大きな立ち位置を占めます。 勉強のために AWS Certified Solutions Architect - Associate (SAA-C03) を受験して合格しました。 AWS の設計をするためにサービスの理解、要件ごとの適切な構成を学びました。 クラウドインフラですが、前提としてある程度オンプレにも共通するインフラの知識はあったほうが良いと感じました。 30〜40 時間ほど勉強しました。
業務量を調整した
当たり前ですが、時間がないとレビュー・作成は難しいです。 DesignDoc のレビューは結構時間がかかります。 まずプロジェクト全体の要件・方針を確認して、それが現在の設計にどう落とし込まれているかを確認、さらにより良い実現方法の検討と提案など、ボリュームのあるステップを踏む必要があるからです。
以前は自身の開発業務で余裕がないからと DesignDoc のレビューを避けている部分があったのですが、今回はしっかり取り組むために自身の業務量を調整するように動きました。 そもそも開発の作業予定をぎちぎちに詰めるのは DesignDoc に関係なく問題が起こりやすいので避けたほうが良いです。 必要であれば開発チーム内に DesignDoc のレビューをしたいので少し作業を減らす旨を伝えていました。
DesignDocのレビューを行った
習うより慣れろという言葉もあるとおり、やってみなければ進まない部分もあります。 ということでレビュー依頼が出た DesignDoc は基本全部レビューするようにしていました。 少しだけ手が回らなかったものもありましたが、そういったものも一通り目は通していました。
以下のような効果を得られました。
- DesignDoc の雰囲気に詳しくなった
- DesignDoc のレビューでどういったフィードバックがされるのか実例を見て学べた
- DesignDoc の観点の幅が広がった
- 以前よりレビュー作業に慣れた
DesignDocの作成を行った
こちらも実践が大事ですね。 レビューも大事ですが作成も大事です。 ということで実際に自身が携わった開発で 2 つの DesignDoc を作成しました。 ベテランの人であれば一人で書き上げたほうが早かったりもしますが、私はそうでないので同じ開発チームのメンバーと一緒に DesignDoc を作成しました。 ペアプロ・モブプロの設計バージョンのイメージです。
作成してみると理解の曖昧だった部分が明確になっていきます。 また他の人と会話しながら作成することで知識の相互補完や壁打ち、相互レビューの効果があって進めやすかったです。
ガイドラインを整備した
DesignDoc は開発の最初に行うため、幅広く扱う必要があり、成果物の資料の着地点も読みにくいです。 それでもより円滑に作成を行えるようにしたいと思い、実践の中で気付いたことをベースに自身の開発チーム向けにガイドラインを整備しました。 作成時の迷いを減らし、複数のメンバーが同じ方向を向いて進める助けになると感じています。
具体的な例をいくつか挙げてみます。
- 判断材料になる事実は積極的に明確にする
- ある要素によって方針が変わりうる場合、その要素が事実としてどうなっているか明確にすることで無駄な議論や迷いを減らすことができる
- 有識者を積極的に巻き込む
- 困ったらテックリードに相談する動きを円滑にする
- 作成後、テックリードにレビューしてもらう流れになっているが、根本から誤った方向に進んでいると手戻りが大きくなる
- 不安な要素があれば作成途中で軽くでも認識を合わせておくと軌道修正がしやすい
- リソース効率よりフロー効率を重視する
- DesignDoc 作成が開発プロジェクトにおけるクリティカルパスになる
- 抽象的な作業のため多くの知見や観点が求められる
- 見えてない可能性について無理に決めようとしない
- すぐにはまとまらないが全体に大きく影響するほどでない問題は、とりあえずで決めて前に進む
- 必要がないものは設計しない
まとめ
以前より理解が広がった実感はあります。 計画的に取り組んだので振り返りもしやすくてよかったです。 ただ身につけるべき知識は無限にありますし、今後もやっていく中でより慣れていく部分が大いにあるのも感じます。 引き続き学習と実践のループを回していけるように意識していきたいです。
