ITエンジニアの世界にようこそ。あなたはこれからエンジニアとして、様々なシステム、アプリケーション、サービスの構築や運用に関わっていくことになります。というか、この文書は、そんな皆さんに向けて書かれています。
もうちょっと想定読者を絞り込みましょうか。以下の想定読者にぴったりマッチしない方は、自分がそういう立場だと想像して読んでいくことにしてください。
あなたは2024年にピカピカの新人としてシステム開発を生業とする会社の一員となりました。最初の仕事としてお客様の社内向けのそこそこの規模のWebアプリケーション開発のプロジェクトにアサインされたものの、いったいシステムというのはどうやったら出来上がるのかさっぱりわかりません。
そもそも、Webアプリケーションってどういう構成要素があって、どういう順番で、どうやって作ったらいいんでしょうか。そこにはどういう道具や技術が必要なのでしょうか。
この質問には驚くべきことがいろいろあります。
驚くべきことの1つ目は、この質問の答えにいわゆる「プログラミング」が関わることはホンのちょっぴりだということです。世の中の多くの人が、「アプリを作るにはプログラミングが出来ないとダメだ」と思っています。間違ってはいません。誰もプログラムを書かないのなら、アプリは出来上がりません。
しかし、例えば、マンガ雑誌、例えば週刊少年ジャンプを1号作ることを考えて下さい。間違いなく10人以上の漫画家さんがマンガを描かないとジャンプは発売できません。しかし、マンガの原稿が出来るまでにも、原稿が紙の雑誌になるまでにも、およそたくさんの工程があり、たくさんの人が関わっています。その中でマンガが描ける人の割合はごくわずかだと思います。しかし、「ジャンプはどうやって読者の手に届くのか」という工程を白紙の原稿用紙からコンビニの雑誌コーナーに運ばれるまで正しく理解している人は何倍もいるはずです。それを正しく理解したプロの共同作業でジャンプが毎週届けられています。
あるいは、フランス料理店に素敵なディナーを楽しみにいったとしましょう。あなたがオーダーをするためのメニューを書くところから、最後にお会計をするところまで、シェフではない、料理を作らない多くの人が関わっていることでしょう。しかしおそらく、フランス料理店で働くプロフェッショナル達はみんな、あなたのオーダーがどうやってあなたのテーブルに運ばれ、同時に大事な伝票が記載されるのかのプロセスを理解しています。そうでないと、協力して働くことが難しいからです。
同じように、あなたが参加したプロジェクトでも、エディター上のコードがどうにかしてユーザーが使っているWebの画面になり、ユーザーの操作がどうにかしてどこかに届いて、期待する答えを送り返しているハズです。あなたは、その工程を正しく理解したプロフェッショナルになり、多くのプロジェクトメンバーと共同作業することが期待されています。あなたがこの期待に応えられるようにするための一部を担うのが本書です。
2つ目の驚くべきことは、Webアプリケーションではこの一連の工程をあなたは自分のパソコン上で1人で全部やることが出来るということです。これは本当に驚くべきことです。偉大なフランス料理のシェフは、自ら食材を仕入れ、メニューを書き、オーダーを取り、調理をし、給仕をし、伝票を書き、会計をすることができるでしょう。とはいえ、いささかの設備が最低限必要ですし、実際に食材を買う出費はかかるでしょう。
しかし、あなたは自分のパソコンの上だけで、なんの特別な支出なしにアプリケーションを作って動かすことが出来てしまいます。ITが虚業だと言われても、否定しきれません。
実のところ、システム開発でも全てがパソコンの上で済むようになったのは最近のことです。ほんの30年前にはまともなアプリケーションを作るのには何百万円、何千万円もする特別なコンピューターやソフトウェアが必要でした。パソコンが高性能化してなんでも動かせるようになり、動かすソフトウェアも多くが無償で提供されるものが増えたのは本当に凄いことです。30年前はDIYが趣味のお父さんが無駄に高性能のマキタの工具を買うのと同じく、ちょっとしたツールを作るのが楽しみの日曜プログラマですら何万円もする開発キットを買ってキッチンタイマーを自作して喜んだりしていました。まったく、今はなんて素晴らしい時代なんでしょうか。
もうひとつだけ、驚くべきことを追加しておきましょう。システム開発の現場でバリバリ働いているプロフェッショナルは、もちろんアプリケーションがどうやって作られるかの工程を理解しています。しかし、この工程すべてを1台のパソコンの上で実行出来るにも関わらず、この全てを実際にやってみたことがある人は驚くほど少ないです。
しかし、それはジャンプの出版に関わっている人のほとんどが同人誌を作ったことがないのと同じです。別に大まかに知っていれば、あとは自分の担当のところだけちゃんと理解しておけば仕事は出来ます。さらに言えば、IT業界は他の業界に比べて変化が激しいです。大まかは変わらなくても細かいツールや手順はバンバン変わります。いちいち細かいところまでとても追いかけていられないよという人がほとんどでしょう。本書で紹介するツールも、おそらくは10年後には古臭いやり方になっているでしょう。ひょっとしたらなくなってしまうものもあるかも知れません。ここに示したのはあくまで2024年版だというのは注意してください。もちろん、ちゃんと手を動かして理解した皆さんは、すぐに最新にキャッチアップ出来ますからご心配なく。一度ちゃんと理解することが大事です。
なお、きっちりとモダンな工程とツールを理解した皆さんは、プロジェクトでひょっとしたら「えっ？そんなのツール使えばすぐ出来るのに」だとか「本で読んだ手順と違う・・・無駄じゃない？」というような場面に遭遇するかもしれません。しかたないです。大まかの部分も変わってしまうことがあり、それについていけてない残念な人もいます。「最近はこういうのもあるみたいですよ」と教えてあげてください。ただし、本書の範囲はホントに基本で、むしろちょっと保守的な選択なのでよっぽどそんなことはないと思います。
あなたがフランス料理を独学で学ぼうとした場合、どうするでしょうか。一番近い大型書店の料理本のコーナーを目指すのは悪くない方法でしょう。この世の多くのことが書籍から学べます。コンピューターの分野も例外ではありません。計算機科学の名著はたくさんあります。私も紹介したい本がたくさんあります。
ところが、Webアプリケーションの開発に使うツールの使い方は、すべてWeb上にあります。Web上にあるものが原本で、正統で、最新です。これはやはり少々特殊な分野と言えそうですが、Webに関するツールを作る人がWebで情報を提供するのは、自然なことだからです。
問題は、Web上にはあまりにたくさんの情報があり、どれをどの順番に読めば体系的に学べるのかがさっぱりわからないことです。同じようなツールが複数あったり、よく似たバージョンがたくさんあったり、わけがわかりません。そこで、本書では、何について学ぶ必要があり、どの文書を読めばよいのかをお伝えします。
その前に、インターネット上のドキュメントを探すときの注意点をいくつか紹介しておきましょう
ソフトウェアやツールを使おうとしてわからないことがあった場合、みなさんGoogleで検索すると思います。様々なサイトがヒットして、その中から皆さん初心者向けのわかりやすそうなところをチョイスして読んでいるんじゃないでしょうか。
しかし、初心者向けのわかりやすそうな記事は誰が何のために書いているんでしょうか。何のためかは、ページビューを稼ぐためです。それ自体が悪いことではありませんが、ページビューを稼ぐためには必ずしも正しいことを書く必要はありません。間違っているといろいろなところから怒られるとは思いますが、実はちょっと怒られるぐらいの方が見てもらえたりします。
それよりも、正しい情報を伝えようとしている人が書いているものを読んで下さい。正しい情報を伝えようとしている人は、その情報が伝わらないと困る人です。つまり、そのソフトウェアやツールの作者です。作者は正しく伝わる良いドキュメントを書くモチベーションがあります。なぜなら、書かないとせっかく作ったツールが使ってもらえなかったり、使った人からやたらと問い合わせが来たりするからです。なので、そのソフトウェアやツールを作った人が書いたドキュメントを探して読んで下さい。これを「1次資料を読む」と言います。
ただし、読みやすいドキュメントを書くのは大変な仕事ですし、能力も必要です。1次資料が読みにくかったり、よく躓くポイントには誰か別の人がフォローの文書を書いてくれていたりします。このようなドキュメントは大変に価値があるものですし、あなたも「誰かが書いておくべきだ」と感じたら自ら書いて公開しましょう。誰かの助けになるかもしれません。しかし、あくまでこれらは1次資料の次に読む資料です。まずは1次資料を読むことを心がけてください。
ただ、多くの1次資料は英語です。英語が苦手な人は、1次資料を読むのが大変かもしれません。しかしまあ、今ではよい翻訳ツールもあるし、AIに読むのを手伝ってもらってもいいし、いろんな助けを得てなんとか頑張りましょう。あ、AIに翻訳してもらったり要約してもらったりしてもいいですが、わからないことをAIに聞くのは止めましょう。AIに聞いていいのは自分があってるか間違っているか判断できることだけです。
インターネットが使われるようになって30年。今ではだいぶ資料も蓄積されてきました。迂闊に検索をすると、非常に古い情報が引っかかってしまう恐れがあります。特に長く使われているソフトウェアやツールの場合、使われ始めた頃に持っていた欠点や、もはや時代に合わなくなった特徴などが大きく変更されて、もはや全然違うものになっちゃっていたりします。
例えば、プログラミング言語は使い方を覚えるために頑張らなければいけないイメージがあるせいか、「古くなったから、別の新しいのを作ろう」とはならず、少しずつ改善していこうとする傾向があります。今でもよく使われているJava、JavaScript、PHPはどれも90年代に作られた言語ですが、30年に渡って改良が重ねられた結果、今では当時の教科書がまったく役に立たないレベルで変わっています。しかし、うっかり2000年代のブログ記事などを見つけてしまった場合、今ではまったく推奨されないやり方が書いてあったり、もっとひどい場合には今ではセキュリティ的に非推奨なやり方が紹介されていたりする可能性があります。
これを避けるためには、そのソフトウェアやツールの大まかな歴史を知っていることが大事です。そうすると、いつ以降の記事なら参考にしていいのかの目安がつけられます。
しかし、歴史的な話というのは、あまり多く語られることがありません。本書では皆さんが資料を探すときの足がかりになるような歴史的なトピックをときどき紹介していきます。
ドキュメントを読めというのはよく言われるアドバイスだと思います。1次資料を頑張って読むのは大事なことです。ですが、1次資料にはそのソフトウェアについて必要となるすべてのことが書いてあります。初めてそのソフトウェアを使う人向けのチュートリアル記事から、そのソフトウェアを改造して使いたいと思っているコワモテ開発者向けの内部構造の資料まで、いろいろなドキュメントが用意されているケースがあります。明らかに全部読む必要はなさそうです。それはたぶん、皆さんもわかっとるわいと思ってることでしょう。
問題は、どれが自分に必要なドキュメントなのかがわからないということです。わからないのは当然です。慣れてくれば飛ばし読みしたり、必要なところを検索かけて読んだりしているうちに全体像がわかってきますが初心者のうちは難しいでしょう。こういう場合に一番簡単なのは、どこを読むべきか誰かに教えてもらうことです。「〇〇というソフトウェアで××をしたいのですが、どうすればいいか教えてもらえますか？」という質問に答えるのは面倒です。相手の知識レベルによってどう説明すれば良いかが変わります。しかし、「〇〇というソフトウェアで××をしたいのですが、どのドキュメントのどの辺りを読むべきですか？」という質問は答えやすいです。これならAI Chatに尋ねてムチャクチャな回答が返ってきても被害は少ないですから、ChatGPTに聞いちゃうのもオススメです。
本書では各パートで、「ドキュメントのこの部分を読んで試してね。ここは飛ばしてね」という説明を入れるようにしますので、参考にしてください。
本書では、試しに作ってみるWebアプリとして、読んだ本の感想を書くSNSもどきを作成します。どんなアプリでも構わなかったのですが、イメージしやすく、画像なども扱い、典型的なデータの保存・読み出しがあるものとして考えました。
今回はこれをJavaで作成します。WebアプリケーションフレームワークとしてはSpring Bootを採用します。これは、社内向けお仕事アプリの典型としてよく使われていそうなものとして選択しました。それを元に開発プロセスに使うツール群も定番のものをチョイスするように心がけました。ただし、動的言語にも触れて欲しかったのでGroovyをテストに使います。定番のJUnitではなくSpockを使いますが、使ったことがないJavaプログラマーはぜひGroovy/Spockによるテストを試してみてください。
では、さっそく、まっさらからのアプリ開発を試していきましょう。しかし、Javaのコードを書くのは当分先です。まずは環境づくりと開発現場で使うツールの理解からです。長い旅路になりますが、すべて開発の現場で使われているものたちです。ひとつずつ観光地を巡っていくような気持ちで楽しんでください。
それでは良い旅を！