みなさん、こんにちは！
タカハシ(@ntakahashi0505)です。
「ノンプログラマーのためのスキルアップ研究会」は、ノンプログラマーがプログラミングをはじめとするITスキルを学び合うコミュニティです。
先日の定例会のテーマは、なんと「ドメイン駆動設計」！
…おそらく、ノンプログラマーで耳にしたことがある方は少ないかも知れません…
しかし、私がこの「哲学」に出会ったとき、ビビビ！と来たんです。ノンプログラマーにとても向いているのでは？と。
ということで、今回からシリーズで「ノンプログラマーのためのドメイン駆動設計超入門」のレポートをお送りします。
「超入門」ということで、なるべくノンプログラマーの誰もがわかるようにお伝えできるよう努力しますので、ご安心ください。
初回の今回は、ノンプログラマー向けにウォーターフォールの設計とアジャイルの設計について詳しく解説しますよ！
ちなみに当日の様子は以下、Togetterのツイートまとめもご覧くださいませ。
では、行ってみましょう！
設計とは
ドメイン駆動設計とあるとおり、これは「設計」の一種なんですね。デザインです。
まずは、この「設計」とは何かについて明らかにしていきましょう。
ソフトウェア開発というと、どうしてもコードを書く「実装」の工程のイメージが強く出ますが、実はいくつもの工程が必要です。
以下の図のようなかたちです。
大きく分けると以下の4つの工程で、設計とテストはさらに細かく分かれることがあります。
- 要件定義
- 設計
- 実装
- テスト
基本はこの工程どおりなのですが、開発の進め方でいうと、これを1回だけ行ってソフトウェアを完成させるウォーターフォールと、何度も繰り返しながらソフトウェアを改善していくアジャイルと、2種類の進め方があります。
開発の各工程（ウォーターフォールの場合）
ウォーターフォールは、日本の伝統的企業の大規模なソフトウェア開発でよく採用されている手法で、各工程を完全に完了してから次の工程に進みます。
このウォーターフォールを例に、各工程をより細かく見ていきましょう。
要件定義
要件定義では、クライアントが求めるソフトウェアについてヒアリングして、その目的（Why）や、何をつくるか（What）を確認する段階です。
それを、「要件定義書」という形でまとめて、承認が得られれば次の段階に進みます。
設計
設計はどうやって作るのか（How）を決める段階です。
たとえば、基本設計では、システム構成、UIとその画面遷移、データベースなどシステム全体や外から見える部分についてどのようにするかを決めて、「基本設計書」を作成し、クライアントのコンセンサスを得ます。
一方で、詳細設計では、ソフトウェアの内部をどういうパートに分けて構成するかといったことを決め、これを「詳細設計書」に落とします。
実装
ウォーターフォールでは、基本設計書や詳細設計書がありますから、それを用いて、分担してコーディングを進めます。
これが実装の段階です。
テスト
次の実装したソフトウェアが正しく動作するかを確認するテストの段階があります。
ここで、単体テストは、設計の段階で作成した「詳細設計書」が答え合わせ用の資料となります。
それをクリアすると、次のシステムテストに進みますが、そこでは「基本設計書」が答え合わせの資料として用いられます。
そして、クライアントにわたす段階の受け入れテストでは、要件定義の際に作成した「要件定義書」が答え合わせの資料となるのです。
このように開発工程の各工程が、テスト工程の各工程に対応している対称性から、V字モデルとよばれているのです。
「設計書」が設計のアウトプット
このように、ウォーターフォールでは、設計の段階でソフトウェアをどう作るかを決めて、そのアウトプットである設計書をもとに、後の工程の実装を進めます。
また、テストの段階では、正しく動作をしているか付け合せをする資料として、またその設計書が用いられます。
つまり、ウォーターフォールの場合、設計はソフトウェア開発で必要なドキュメントをつくること、とも言いかえることができます。
それがあるからこそ、別の企業に実装やテストの工程を分業すること、またその品質を担保できるというわけです。
ウォーターフォールの課題
しかし、ウォーターフォールには課題もあります。
まず、ウォーターフォールでは一切後戻りができないということです。
たとえば、要件定義で、エンドユーザーがまったく望まない見当違いのソフトウェアが描かれてしまったとしても、後の工程のすべての関係者は、それにフィードバックをすることもできずに、粛々とドキュメントどおりの作業を進めるしかありません。
後の工程で形になってから見える改善点も出てくるかも知れませんが、それもフィードバックはできません。
また、すべての工程が完了し、リリースするのに、とても時間がかかりますが、その間に世の中の変化があったとしても対応することができません。
つまり、まとめると以下のような課題です。
- 後の工程から前の工程にフィードバックができない
- 柔軟にソフトウェアの変更ができない
今はとくにニーズが多様化し、変化のスピードが速くなっていますから、そのデメリットは大きくなっています。
アジャイル
それに対してアジャイルでは、要件定義、設計、実装、テストを小さな単位で行います。
まず、リリースできるところでリリースしてしまいます。
その各工程で、もしくはリリース後に改善点が見受けられれば、それを再度要件定義し、設計し、実装し、テストし、リリースをするのです。
これを何回も繰り返して、すばやく改善をしていくのがアジャイル開発です。
アジャイルの「難しさ」
とても今の時代にマッチした開発手法に見えますが、いくつかの条件があります。
すべての工程を素早く行う必要があるので、すべての工程を担当するメンバーが密にコミュニケーションをする必要があります。同じチームがずっと担当することになり、さらにクライアントもそのコミュニケーションに入る必要もあるでしょう。
また、「終わり」がないので、予算や人員の計画が立てづらいという問題があります。変化に応じて、調整する必要があります。
さらに、ソフトウェア開発でも、何をどうつくるのか、どう変更を加えてえいくのかを素早く判断する必要があり、先々の変更のしやすさなども意識しておかなければいけません。
まとめるとこうです。
- コミュニケーションを常にする必要がある
- 計画を立てづらい
- 柔軟に判断、対応をしなければいけない
つまり、都度都度の判断が必要になり、ソフトウェア開発やプロジェクト管理の難易度が高くなります。
アジャイルの設計
さて、ここでアジャイルの設計に目を向けましょう。
反復を高速に回転させる必要がありますから、ウォーターフォールのように、きちんとしたドキュメントを残し、それを実装のための指示書にし、テストのための答え合わせにする、などは現実的ではありません。
では、アジャイルにおける「設計」とは、具体的に何をすることでしょうか？
なんとなくふわふわして進めていいものでしょうか。
いや、しかし、何度も変更をすることを考えると、変更がしやすいような作り方をする必要があります。
この問いについては、次回以降の記事で明らかにしていきたいと思います。
ノンプログラマーの開発ではどうか
さて、ノンプログラマーの開発では、クライアントからの依頼というよりは、自らやチームが望む小規模なツールを作るという機会が多いでしょう。
ほとんどの場合、分業は不要ですから、指示書としてまたクオリティ担保のためのドキュメントは、マストではありません。
実際に、何かあれば自分が直せればいいかな…という方も多いでしょう。
つまり、変化には都度対応できます。
ということで、ノンプログラマーの開発は、規模は小さいにしても、タイプとしてはアジャイルに近いのです。
まとめ
以上、今回はノンプログラマー向けにウォーターフォールの設計とアジャイルの設計について詳しく解説しました。
このような工程があるというのはあまり意識してないノンプログラマーが多いかと思いますが、次回以降、「設計」の重要性について理解いただけるはず…！
次は「オブジェクト指向」についてお伝えします。
どうぞお楽しみに！
