どうも。つじけ（tsujikenzo）です。このシリーズでは「Google Apps Scriptとドメイン駆動設計」についてお届けします。
全部で何章のシリーズになるかわかりません。少しずつ更新します。
第1章は、「オブジェクト指向とはなにか」 で全3回でお送りします。
今日は、第1章の第1回目で「はじめに」をお届けします。
前回のおさらい
前回、「ドメインとはなにか」というシリーズをお届けしました。
プログラミング学習の中級以降、規模の大きな開発をする機会が増えます。
わたしたちノンプログラマーの開発を楽にする方法が、ドメイン駆動設計という開発手法です。
ドメイン駆動設計は、オブジェクト指向がベースになっています。
まずは、オブジェクト指向やクラスについて、紹介していきたいと思います。
今日のアジェンダ
- 中級の壁
- パソコンと人間の共通言語
- このシリーズのゴール
中級の壁
わたしは、Google Apps Script（以降、GAS）の勉強をしている、ノンプログラマー（プログラミングで生計を立てるプロのエンジニアではありません）です。
普段、業務効率化を行うアプリケーションなどのプログラミングをしていますが、学習が進むにつれて、ソースコードの規模が大きくなってきました。
書いたコードを管理するために、設計書や仕様書をマニュアルとしてまとめるタスクも増えてきました。
コードは書いて動いたら終わりではありません。むしろ、コードは後で読まれる時間の方が長いです。
しかしながら、後で読む気が起きない仕様書や、どうせ誰にも読まれないマニュアル作りに、大切な時間をさこうと思えません。
この八方ふさがり、どうしたらいいのでしょうか。
ノンプログラマーのプログラミングスタイル
図は、プログラミングスキルとソースコードの規模における、プログラミングスタイルを分析したものです。 
プロは、ソースコードの規模によって、プログラミングのスタイルを選択できるでしょう。
しかし、ノンプログラマーは、ソースコードを処理のまとまりで書く、というスキルがないため、ソースコードの規模が大きくなればなるほど、沼にハマっていきます。
ソースコードの実装（動くものをつくること）はもちろんですが、作ったあとの仕様変更やバグに対する処理も、大変なコストがかかってきます。
もしかしたら、「むしろプログラミングを作らない方がよかった」と感じてしまう瞬間もあるかもしれません。
期待する変化
ほんの数行ですむソースコードは、頭で考える手続き通りの順序で書いてしまってかまいません。（図の左上、左下のエリア）
着目したいのは、図の右下のエリアの変化です。 
ソースコードが大きくなるにつれて、運用コストが上がっていきますが、その分、学習コストも跳ね上がっていきます。
その学習コストを少しでも下げて、ソースコードを処理のまとまりで書く、というスキルを手に入れることはできないのでしょうか。
このシリーズは、そんなノンプログラマーの悩みを解決する試みです。（現在進行形の学習分野です）
パソコンと人間の共通言語
パソコンの歴史は古いです。半導体なんかない大昔は、真空管や紙テープを使って、演算処理（プログラミング）をやってました。
今では電源を入れて、キーボードやマウスを操作するだけで、プログラミングができます。
そんな便利な時代になって、非常に高性能になりましたが、パソコンはまだ人間ではありません。
パソコンでプログラミングするときは、パソコンがわかる言葉で命令する必要があります。
ここに、ひとつ、落とし穴があります。
プログラミング学習の順番
どんな書籍でも、プログラミング学習を始めるときは、Hello Worldの出力から始まり、四則演算や基礎構文を学びます。
それは、パソコンがわかる言葉を、わたしたちも学ぶ必要があるからです。
そのように、パソコンがわかる言葉を学んでいくと、ソースコードも自然と手続き型プログラミングになります。
厳密には手続き型プログラミングの定義は違いますが、イメージをお伝えするとこのような流れです。（※イメージです） 
業務アプリケーションを作るさいは、処理の流れがわかるように、業務フロー（図中央）を作成することもあると思います。
コードは、業務フローにそって、上から下にプログラミングしていきます。
このようにプログラミングすることは、自然なことです。なにもおかしな点はありません。
プログラミングが上達していくと、共通する処理を関数にして切り分ける、サブルーチンや、モジュール化というテクニックも使うでしょう。
そして、規模の大きな業務アプリケーションを開発したり、複雑な処理を行い始めて、冒頭でご紹介した壁（書けば書くほど運用コストがあがる）にぶち当たります。
命令型プログラミング
その問題を解決するプログラミング手法のひとつが、「オブジェクト指向」です。
オブジェクト指向とは、実世界のヒト・こと・モノを「オブジェクト」という単位でとらえ、ソースコードに反映させることです。
手続き型とは異なり、それぞれのオブジェクトが命令（メッセージ）をやりとりしながら、処理を実行していきます。
命令型プログラミングで書くときは、クラスが重要なテクニックになっていきます。 
ドメイン駆動設計でいこう
ドメイン駆動設計とは、オブジェクト指向をさらに発展させた、プログラミング手法のひとつです。
ドメイン（業務、知識、ルールの領域）とソースコードを一致させよう、というアプローチです。
とてもむずかしい分野の学習ですが、業務におけるプログラミングが楽になる、という結果が得られるのなら（わたしはそう信じています）、チャレンジしてみたいと思います。
まとめ
以上で、第1章「オブジェクト指向とはなにか」の「はじめに」をお届けしました。
プログラミング初心者が、四則演算や基礎構文を習うのは、「まずプログラミングに慣れる」という目的があるんだと思います。
その流れで、書くソースコードが手続き型プログラミングになるのも、自然です。
プログラミングを行うことで、だんだん複雑な処理が大量にできるようになりますが、同時に、コードを書けば書くほど運用コストがあがります。
これは、プロであれ、ノンプログラマーであれ、関係ありません。
ドメイン駆動設計は、このトレードオフに立ち向かえそうな気がして、とてもワクワクしています。
時間はかかりますが、ゆっくりやっていきましょう。
次回は、 「オブジェクトとはなにか」 をお届けします。
参考資料
手続き型プログラミング フリー百科事典『ウィキペディア（Wikipedia）』
このシリーズの目次
Google Apps Scriptとドメイン駆動設計
