どうも。つじけ（tsujikenzo）です。このシリーズでは、2021年5月から始まりました「ノンプロ研GAS中級講座5期」について、全8回でお届けします。もう8回目で最終回なのですが、最終回を、3回に分けてお送りしています。今日は最終回の3回目です。
前回のおさらい
前回は、「プロの開発を知ろう」 をお届けしました。
今回は、「ノンプログラマーによる開発」 をお届けします。
ノンプログラマーによる開発
では、プロによる開発から学べる、ノンプログラマーでも利用できるような開発手法を、まとめてみましょう。
ノンプログラマーの開発工程
ノンプログラマーであっても、開発工程にプロとの差はあまりありません。
それぞれ見ていきましょう。
ノンプログラマーの要件定義
仕事とは、「もの」を始めの状態から終わりの状態に変える「こと」です。
そこには必ず、要（かなめ）の変化があり、それ以外は肉付けに過ぎません。
要件定義の肝は、現状からムダを省くことではなく、本質はなにかをとらえることです。
発注者は業務の最前線にいますので、要望としてありとあらゆる情報を提供してきます。（情報が足りない場合は、こちらから引き出す作業も必要です）
5W1Hのようなフレームワークもありますが、情報の洗い出しはメモ帳でもかまわないと思います。
まずは散らばった情報から、「もの」と「こと」の分析をおこない、本質をとらえる練習をしてみましょう。
最終的に「要件定義書」を作成して、次の工程に進みます。
ノンプログラマーの外部設計（基本設計）
要件定義が固まると、次は、外部設計でした。業務アプリケーションの機能、見た目、構造を設計する工程です。
むずかしそうですが、
1. 要件定義で要の変化がきまったら、ユーザー目線でどう実現するかを設計する
2. 外部設計は、次の工程の内部設計のためにあるんだな
と、理解しましょう。
要件定義に長けている人は、要件定義の段階で、発注者の要件を「何を使って」「どのような工程で」「どのようなシステムを」作るのかを固める場合もあります。
今回は、要件定義書がなくても、あくまで「要の変化」が見えた程度を想定します。（要件定義書をつくらないと外部設計ができないというのは、ノンプログラマーにとって少々ハードルが上がるからです）
外部設計はプロ同様にやろうとすると大量のドキュメントを作成しなれければなりませんが、今回は肝となる4つを選んでみました。
業務フロー
業務の流れを可視化し、発注者と認識の統一をはかります。
業務フローを使い、開発の前後を比較すると、業務分析にも役立つでしょう。
機能一覧
「機能」とは、業務アプリケーションで自動化される処理です。
機能のかんたんな一覧表を作成しましょう。漏れがあっても構いません。気付いたことがあれば更新していきましょう。
ER図
小規模な業務アプリケーションでは、「データベースを使うほどではない」、「データは発生するが流用しない」という理由で、データベースを意識せずにコーディングすることが多いです。
しかし、「データベース」は、今後、とても重要な、本当に重要な項目になっていきますので（しつこいですね、すみません。でも本当です。）、ぜひ、この機会に仲良くなっていきましょう。
ER図は、実世界の「もの」と「こと」を記号化することからはじまります。（これを概念モデルと呼びます。本来は要件定義のときに作成します）
「もの」と「こと」に「なに」を足した、おおむね3種類の記号で実世界を表します。
– もの・・・エンティティ、実体
– こと・・・リレーション、関連
– なに・・・アトリビューション、属性
時間の都合で、詳細は割愛します（別途ブログに書きます）が、さきほどの業務フローを眺めながら作成するのもいいでしょう。
最終的に、データベースのテーブルとして使える状態のER図を作成します。（これを論理モデルと呼びます。）
ER図の詳しい解説は、別の連載でお届けしたいと思います。
テーブル定義書
ER図ができたら、テーブル定義書を作成します。
基本的に1テーブルにつき、1シートですが、テーブルは増えたり減ったり、カラムも常にコロコロ変わるので、設計段階であまり深く考えないことをオススメします。
ざっくりテーブルを把握できたら、次の工程に進んでかまわないと思います。
問題を見つけたり、よりよいデータベース案があればER図やテーブル定義書を書き直せばよいでしょう。
最終的に「外部設計書」を作成して、次の工程に進みます。
ノンプログラマーの内部設計（詳細設計）
外部設計が固まると、次は、内部設計でした。主に 業務アプリケーションの内部を設計する工程 です。
やはり専門的でむずかしそうですが、
1. 外部設計できまった仕様を、プログラマー向けの詳細に落とし込む
2. 「詳細設計書」を見れば、いつでも、誰でも、どこでも、コーディングに参加できるんだな
と、理解しましょう。
外部設計と同様に、プロのようなすべての詳細設計書が必要なわけではありません。
誰（未来の自分も含む）でもわかる、プログラミングをするための詳細設計書 が存在していることが望ましいです。
詳細設計書に記載される主な設計
– ユーザーマニュアル
– 画面詳細設計書
– クラス図
– ユースケース図
– データベース物理設計書（DBMS設定定義書）
時間の都合で、詳細設計の1つ1つの設計書のご紹介はできませんでした。
また、機会を見つけてお届けできればと思います。
ノンプログラマーのテスト
業務アプリケーションは、動いたらおわりではなく、設定した課題を正しく解決できているか、評価したほうが良いでしょう。人事部の査定や周りからの評価につながる可能性があります。
そのためにまず、要件定義以降の工程を、コーディングを底とした「V字モデル」構造にします。
それぞれの設計で決めたことに対して、正しく解決できているかテストします。
テストは、底（コーディング）から近い順に、ミニマムデータなどを用いて行います。
– 内部設計→単体テスト
– 外部設計→結合テスト
– 要件定義→総合テスト
GASを書くさいは、関数などを作成し、実際に動くかどうか確認しながら作業を進めますので、無意識に「単体テスト」を行っていると言えます。
くわえて、GAS開発モデルでは、上流工程の設計書やドキュメントが残っているはずなので、「要件定義書に書かれている要件はクリアしているか」 などのチェック表を作成するとよいでしょう。
まとめ
以上で、「ノンプログラマーによる開発」 をお送りしました。
プロとノンプログラマーでは、開発の規模が違うことは目に見えています。
参考資料が示す通り、プロでさえ 開発の解像度が高くなればなるほど、ドキュメントが増える というジレンマを抱えています。
社会も技術も変化していく中で、統一したソフトウェア開発モデルを策定することはとてもむずかしいでしょう。
その解決策の1つとして、プロは 「機能要件の合意形成を目指す」 というロジックを試みているようでした。
わたしたちノンプログラマーにとっても、「開発モデルを作ってみよう」 という試みが、意義のあるものになれば幸いです。
今後の展開
タイトルを 「ノンプログラマーによるGAS開発モデル」 としたのは、まだ続きがあるからです。
GASによる業務アプリケーションの開発には、GASならではのアドバンテージがたくさんあります。
– すでにGWSがクラスとして提供されていること
– GWSにスケジューリングやタスク管理サービスが同梱されていること
– プログラミングやデプロイの環境構築が不要なこと
– データベースとしてスプレッドシートやGCPを活用すること
などが挙げられます。他にもキリがありません。
少なくとも、中級以降のGASの開発と保守は、できる限り どうやって開発を始めるのか、開発を進めたのかを可視化 したほうが良さそうです。
いったん、このシリーズは完結しますが、次回以降のシリーズでは 「GASならではの開発」 もお届けできればと思います。
このシリーズの目次
- [ノンプロ研]GAS中級講座5期 事前課題
- [ノンプロ研]GAS中級講座5期Day1 スコープと関数
- [ノンプロ研]GAS中級講座5期Day2 クラス・ライブラリ
- [ノンプロ研]GAS中級講座5期Day3 組み込みオブジェクト
- [ノンプロ研]GAS中級講座5期Day4 ScriptServices1
- [ノンプロ研]GAS中級講座5期Day5 ScriptServices2
- [ノンプロ研]GAS中級講座5期Day6 HTTP通信・API
- [ノンプロ研]GAS中級講座5期卒業LT ノンプログラマーによるGAS開発モデルとは
- [ノンプロ研]GAS中級講座5期卒業LT プロの開発を知ろう
- [ノンプロ研]GAS中級講座5期卒業LT ノンプログラマーによる開発
参考資料
『発注者ビューガイドラインの活用と拡張 機能要件の合意形成を目指して』 IPA
『もの・こと分析で成功する シンプルな仕事の構想法』中村善太郎 日刊工業新聞社
Special Thanks
GAS中級講座3期卒業LT こはたさん
GAS中級講座4期卒業LT SWDさん
VBA初級講座4期卒業LT かにみそさん
ノンプロ研アプリ制作 カワムラさん
