システム作りの新しい風に！ | #9th creative クリエイティブ

まず「進行シナリオ表」を作ることから始める。

▲

システムは、ユーザや管理者の操作によって動くもの。
その操作内容とそれに対して想定しているシステムの動きを表にまとめて書いていく。
デイリーなどの定期処理もあれば、それも含めて作る。

ポイント！

「ページを開く」とか「画面を表示する」とか、普通の言葉で書く。

普通の言葉のほうが、考えやすいし、ユーザの視点で考えられる。

ウラ側の実装はなんとなくイメージはしつつも、あまりふれない。

実装の方法を固定化しないようにしておいて、シナリオを書きながら、自由に解釈できる余地があったほうが、いろいろ決めやすい。

こうやって、作る前に、ユーザの操作とそれに対する動きを、書けるだけ書いていきます。作ってみないとわかんないなぁってことは、あとから書き足してもいいので、ざっくりで。あくまで、動くときに、いろいろ決めておいて、迷いを減らすことが目的ですから。

「進行シナリオ表」が「実装テスト表」になる！

▲

「進行シナリオ表」には、操作に対する反応が並んでいます。ということは、この表を辿れば、実装のテストができるということ。つまり、表ができた瞬間に、「全部の項目がバツ」のテストがすでに始まっているということです。
システム作りは、これを「全部の項目がマル」になるようにする作業を進めていくことだけを考えればいいことになります。
気になることは、あとからでも、どんどんシナリオ表に追加して、それから作業をして、バツをマルにしていくだけ。
全部マルになったら、完成！　システム作りは無事終了！

最後に勝手にギモン解決！

▲

Ｑ

こんな面倒なことしなくても、普通に作ればいいし、手間ばっかりかかってムダなんじゃないの？

自分自身が、プログラミングというか、コンピュータそのものと向き合うと、何するんだったか、とか、どこで区切りをつけたらいいか、すぐ、わかんなくなっちゃうので、個人的には、先に全部決まってたほうが動きやすいし、動くときの発想も膨らみやすいと感じています。

Ｑ

実装については、なにも触れていないんだけど、どうしたらいいの？

実装については、思い思いに好きなようにすればいいと思っています。何をどう作っても、最終的にテストをするので、作るときに、不具合が残ったらどうしようとか、そんなことは考えなくても大丈夫！　そう思えるように準備しておくことが大切だと思います。