はじめに
こんにちは！ソフトウェアエンジニアの種岡です。
皆さん、システム設計に取り組んでいますか？
設計は、プロジェクト成功への道筋を描く、航海の羅針盤です。
目的地を見据え、それに向かって進むための確かな指針となります。
設計の質がしっかりしていれば、開発という大海原でも迷わず進むことができます。
設計はプロジェクトの土台を築く、創造的かつ重要なプロセスです。
夢を描き、それを形にする試行錯誤の楽しさ、これこそが設計の魅力だと思います。
この記事は秋の技術特集 2024の11記事目です。
この記事 is 何？
この記事では、設計図を描く際の心構えと、誰でも見やすい設計図を作成するためのテクニックについてお話しします。
なぜ設計図を書くのか？
- 図は複雑な情報を視覚的に整理し直感的な理解を推進することができるため
- チーム内外での共通理解を促進し、コミュニケーションを円滑にするため
- 予測可能なリスクを最小限に抑え、品質の高い成果物を確保するため
チーム開発の現場では、設計図がこれらの要素を支えてくれる重要な役割を果たします。
「仕様書やソースコードがあれば十分なのでは？」、「設計図に時間をかけるよりも、早くコードを書いてユーザーに価値を届けたい」と考える方もいるかもしれません。
しかし、限られた時間だからこそ、設計図を作成することがプロジェクトの成功に繋がるのです。
設計図はみんなで育てる
設計図は最初から完璧である必要はありません。
プロジェクトの初期段階で 「たたき台」 として設計図を共有し、チーム全体で議論を重ねながら成長させていくことが大切です。
多くの場合、設計図の作成は一人で行うことが多いでしょう。
その結果、大きな変更が発生し、レビュアーに負担をかけたり、理解がうまく伝わらなかったりすることがあります。
私自身もそうした経験を経て、1日の作業分程度の小さな粒度で設計を共有する改善を行いました。
その結果、以下のような効果を得られました。
- 説明することで、自分自身の理解が深まる
- 他のエンジニアの知見が自然と設計に反映される
- 設計変更の差分が小さくなり、チーム全員が理解しやすくなる
細かな設計ミーティングを繰り返し行い、チーム全体の理解度を高め、設計図を成長させていく好循環を生み出すことが重要だと感じています。
以下は実際に社内の開発プロジェクトで書いた設計図です。
上記のプロセスを繰り返し行い、チーム全体で設計図を育てていくことで、最終的には見やすく理解しやすい設計図が完成しました。
設計初期
最終形
設計図を書く
draw.ioとは
設計図の作成には、ブラウザ版のdraw.ioを使っています。
draw.ioは無料の作図ツールで、直感的な操作で設計図を作成でき、初心者でも綺麗な製図ができます。
ブラウザ版の便利な点は、 作業環境に依存せず、同時編集が行えるため、 「みんなで育てる」 ための環境が簡単に用意できるところです。
設計初期における心構え
- チームに共有して、フィードバックもらえる最小単位を素早く作る
- 見た目よりも、議論に必要な要素が揃っていることを意識する
draw.ioを使う準備
白紙ファイルを選択し共有ドライブに保存しておく
・設計初期はブレスト的な段階であることが多いので、目的の図が決まっていなければ白紙ファイルで作成しておく ・いつでもチームに共有してフィードバックを貰えるよう共有ドライブに保存する
「その他の図形」から利用する図形をインポートしておく
よく利用するAWSやGoogle Cloudのアイコンは、テンプレートとして用意されているので非常に助かってます。
たたき台に対してフィードバックをもらう
ある程度輪郭が見えて来た段階でチームに共有してフィードバックをもらいましょう。
フィードバックは、付箋や矢印、色をうまく活用するのが良いです。
「フィードバックを受ける」 ⇔ 「設計図の修正」
をある程度繰り返すとどんどん全体の解像度が上がってきます。
とくに、設計初期フェーズはフィードバックによって大きく設計図の更新が発生することが多いです。
そのため、この段階ではきれいに整理するよりも議論に必要な情報が揃っているかの観点で図を修正することを心がけます。
きれいに整理する
設計図に大きな変更が入らなくなったり、登場するコンポーネントが多くなって視認性が悪くなってきたらそろそろ整理する頃合いです。
レイヤー機能の活用で、編集作業をスマートに
図面が複雑になると、アイコンの配置を少し変更したいだけでも、背景やコメントまで一緒に動いてしまい、思わぬ手間がかかることがあります。
そんなときに役立つのがレイヤー機能です。
レイヤー機能を使えば、要素ごとに異なるレイヤーを作成し、個別に編集が可能です。
レイヤーは、メニューの「表示」→「レイヤー」で利用可能になります。
自分は2種類のレイヤーで図を書き始めることが多いです。
アイコンを並べるコンポーネント用レイヤー、そのアイコンのまとまりを示す背景用レイヤー。そして、設計の複雑さに応じて、3つ目のコメント用レイヤーを使います。
グリッドを意識する
マス目の水平・垂直方向に合わせて図形を並べるだけでも自然ときれいに見えます。
複数の図がある場合、片方の図を移動させると補助線が出てくるので合わせて有効利用します。
プレモーテムで活用する
プレモーテムは、プロジェクトや計画が失敗する前に、その失敗要因を事前に予測し、対策を立てるためのフレームワークです。
チームで集まり、「もしこのプロジェクトが失敗するとしたら、その原因は何か？」をあえて考えるセッションを行います。
設計図を活用したプレモーテムはプロジェクトの品質向上にとても役立ちます。
図を用いることでシステム間の依存関係が視覚化されるため、見落としがちなリスクを洗い出すことができ、リリースに自信を持てます。
また、チーム全体の運用知識が向上し、安心してプロジェクトを進められるのも大きな利点です。
この図の紫色の付箋は、プレモーテムでチームがリスクを感じた箇所を示しています。
とくに付箋が集まっている部分は、メンバー全員が共通して不安を抱いているポイントです。
一方で、付箋が少ない場所でも他のメンバーの視点から新たなリスクが見つかることがあります。
設計図を用いてプレモーテムすることで、こうした視点の違いから新たな気づきを得ることができるのでオススメです。
おわりに
設計図はプロジェクトの成功に向けた強力なツールです。
しっかりとした設計図を作成することで、チーム全体の理解を深め、コミュニケーションを円滑にし、開発の進行をスムーズにできます。
一方で、設計に100％の正解はありません。
運用を始めてから新たに気づくことも多々あります。
それでも、限られた時間の中で、その時点での最適解にたどり着くことが重要です。
そのため、設計図をチームで育てていくこと、いつでも誰でも簡単に改善が可能な状態にしておくことが大切です。
