どうも。つじけ（tsujikenzo）です。このシリーズでは、2021年9月から始まりました「ノンプロ研GAS中級講座6期」について、全7回でお届けします。今日は7回目で最終回です。最終回は、なんと5回に渡ってお送りいたします。
前回のおさらい
前回は、「HTTP通信・API」をお届けしました。
今回は、卒業LT大会で発表しました 「オブジェクト指向によるGAS開発のススメ」 をお届けします。
卒業LTのアジェンダ
- 要件定義
- 外部設計
- 内部設計・コーディング・テスト
- クラス設計のコツ
- シートクラス
はじめに
前回（GAS中級講座5期）の、卒業LTでは 「ノンプログラマーによるGAS開発モデル」 という、内容をお届けしました。
プロの開発手法をまなび、ノンプログラマーにも取り入れられる要素はないか、という考察をしたものです。
今回のシリーズでは、その進化版で、オブジェクト指向のエッセンスを取り入れたGAS開発を、お届けします。（ノンプログラマーのわたしが、個人的に学んだことをアウトプットしますので、間違いなどはご容赦ください）
オブジェクト指向のエッセンス
流行り廃りもありますが、プログラムの開発・保守・運用を楽にする手法の1つが、オブジェクト指向プログラミングです。
わたしも、勉強をはじめたばっかりで、少しずつブログ化しています。
オブジェクト指向とは、実世界のヒト・こと・モノを「オブジェクト」という単位でとらえ、ソースコードに反映させることです。
GAS開発を楽にしてくれる手法だと信じていますので、興味のあるかたはぜひ、一緒に学びましょう。
今日、第1回目は、「要件定義」から始めていきます。
ユースケース図
要件定義をするときに便利なツールが、ユースケース図です。
今回は、「スプレッドシートで日報を作成し、マネージャーにPDFをメールする」という、業務アプリケーションを作成したいと思います。
ユースケース図を書こう
ユースケース図は、「そのシステムでユーザーがなにをできるのか」を可視化したものです。
あまりむずかしく考えずに、直感で書いてみましょう。
まず、システムを真ん中に置いてみます。 
こと
次に、やりたいこと（○○する）を並べてみます。ここで、「将来的に使うかもしれない」という機能は、記入しないことをオススメします。（たとえばGoogleドライブに保存する、とかSlackに通知を飛ばすなど）
本当に必要な、コアな部分に集中しましょう。
とくに、スプレッドシートにレコードを追加するばあいなどは、「フォームから入力させたい」と考えるかもしれません。
しかし、現段階では「スプレッドシートを開いて、1行追加する」と考えましょう。
フォームから入力などは、あとで機能を追加すればいいのです。
ヒト
システムを操作するヒトが必ずいると思いますので、ヒトを記入します。
この段階では、ヒトは、それぞれの処理を実行できると考えていいでしょう。 
いずれは、処理はすべて連携され、「日報を入力するだけで、メールが送信される業務アプリケーション」にしたいかもしれません。
しかし、まずは、個別に処理を実行できるという考え方が大事です。
トリガーなどは、あとで機能を追加すればいいのです。
モノ
ヒトが処理することに対して、アイコンなどをおいて、なにを操作するのかイメージを固めましょう。
とくに、とりあつかうものが、スプレッドシートなのか、PDFなのか、メールなのか、など、具体的なアイコンがあるとわかりやすいです。 
このシステムと連携するものとして、日報を管理する人事部のシステムがあるかもしれません。
しかし、今後連携するシステムのモノまで考える必要はありません。別のシステムとは、APIで連携させていきます。
API連携などは、あとで機能を追加すればいいのです。（システムをAPIで連携したものを、マイクロサービスと呼びます。）
完成図
実際に使用するシートなどが決まっていたり、定義できるばあいは、ユースケース図に書き込んでしまいます。
完成したユースケース図はこちらです。 
まとめ
以上で、「要件定義」をお送りしました。
ウォーターフォール開発のように、ガチガチに要件定義をして、仕様を細かく決めるのではなく、ユースケース図をざっくりと書くのがコツです。
ガチガチに書いても、あとで変更は必ず発生します。なにごとも「ざっくり」でいきましょう。
申し遅れましたが、開発にはMURALやJamboardといったホワイトボードツールがオススメです。
次回は、 「外部設計」 をお届けします。
参考資料
このシリーズの目次
[GAS]オブジェクト指向によるGAS開発のススメ
