日々常々

ふつうのプログラマがあたりまえにしたいこと。

作って学ぶ Spring Boot入門

@suke_masa さんの書かれた「作って学ぶ Spring Boot入門」を頂きまして。

AIだのなんだので激動の昨今ですが、新しくシステム開発業界に入られる方がいなくなるわけでもなく、「入門」は必要です。 ある程度時間の流れに耐える入門書もあるにはあるのでしょうが、変化の激しいなかで「これ大方合ってるんだけどこの辺りは古いんだよね」のようなものは一部の入門者を大いに混乱させます。

情報を探せば検索エンジンをAIが使ってそれっぽいものを生成してはくれますが、初心者が自己学習に使用するには流石にまだまだ厳しい。 そんな現代において、SpringBoot4.0、Java25というほとんど最新と言える条件で、一人の著者が書ききった入門書は代えがたいものなんじゃないかな、と思ったり。

読み方にあれこれあるMavenにふりがなが振られるコンテキスト

さて内容の方はといいますと……

  • JavaやIDEのインストールからはじめ
  • ライブラリやJavaの軽いフォローをし
  • Springの話
  • DB、トランザクション
  • ブラウザでのUIとバリデーション
  • WEB API
  • 認証認可

という感じになっています。気になる方は目次をご覧ください。

説明はそこそこにコード主体、作って動かしながら学ぶ感じ。 写経しながら「ここ変えたらどうなるんだろう」と試すのが苦にならない方に向いている系の本です。

説明はそこそこと書きましたが、トランザクションのreadonlyやブラウザアプリケーションでのPRGパターンなど、単に「動かす」だけだと出てきづらいものの業務でやるなら知っておきたいところも触れていたりするのが面白いところ。

こういう構成図を使って「今動かしてるのここですよ」と示してくれるので、「動かしつつ構造で把握する」という学び方をする人は理解しやすいと思います。私はそのタイプなので、こういう図がない本だと自分で描いてたり。

図にある「単体テスト」とかその他諸々コンテキストによってまちまちな言葉も出てきますが、「この本ではこういう使い方をしている」というのは揃っているのが本の良いところだなと。

決して「一冊で即戦力に!」というような本ではありませんが、コードや図が多いので通し切るのにかかる時間はそこまでかからないと思います。 スタートダッシュを一貫したコンテキストで走り切って、そこから着実に身に着けていく。そんな位置にある本でしょうか。

私の方はAI使って「せっかくだから」とあまり馴染みのない言語/フレームワークを使ったりしてるんだけど、出てくる実装や情報の一貫性のなさにあわあわしてる今日このごろ。これはこれで面白いんだけど、初心者の学び方ではねーやね、と。

「検算」と「選択」

AIと開発者の付き合い方について現時点で思ってることのメモ。

AIのパワフルさは今更いうまでもない。 そしてこの手の話には必ず「AIがあれば人間の開発者は不要」みたいな話がついてくる。 ある面では正しいが、そういう主張をする人は自分の答えを持っている(これ自体は悪いことではない)し、面倒なのでそういう主張からは距離を置いている。

将来的に「現時点で開発者の仕事と思われているもの」の多くがなくなるのはそうだと思う。 遠い将来ではなく、今この瞬間もなくなっている(本当に消滅したということではなく「なくなったと言って良い状態」になっていること)ことだろう。 そういう仕事がなくなるとかいう方向の話は別でやるとして。

現時点での開発者(およびAIを使用する多くの仕事)の仕事はなんなのか。 それを言葉にするなら「検算」と「選択」になるかなと言うのが本稿の趣旨。

AIに答えを求めるとそれっぽい答えが出てくる。 この答えが妥当なのかを調べる必要があるのがAIを使っていくなかで必要なことで、「コンピューターは正確だが柔軟性がない」というひと昔前のイメージの真逆である。 正確な振る舞いはコンピューターが得意とするところなので、「答えが合っているか」をコンピューターに調べさせるのは当然の活動。ハーネスとか言ってるのがこの辺なんだろかってふわっと思ってる。

検証を無邪気にAIに任せてるのがしばしば行われるが、これがイマイチなのは「正確でない答えを正確でない方法で検証しても正確でないまま」という単純な話になるので効果は限定的である。 「正確でない人間の仕事を正確でない人間がチェックする」というのはダブルチェックなどで行われることであるが、限界があるのは知っての通り。

つまり、AIの仕事の結果を検証する方法は正確である必要がある。「正確な方法を使った検証」を実行するのはAIでよい。この辺りの構造を認識したり設計したりできるかがAIを使うものに必要なスキルである。が、そういう組み合わせとかもAIができるようになっている。

では人間がやるべき仕事ってないのでは?となるのだが、ここで「検算」と「選択」という言葉を用いる。

検算は別の方法で確かめること。 その方法を選択するのが人間の仕事で、選ばれる方法は「(その答えに関わる)人間が扱えるもの」でなくてはいけない。 関わる人間が理解不能なロジックでしか検算できないものは「検算不能」として捨てるのが、人間の仕事じゃないかなって。 「検算」は「伝えたい相手に伝わる言葉での説明」である。伝えたい相手はステークホルダーと呼ばれる人かもしれないし、対象プロダクトをメンテしていく開発者かもしれない。

AIはしばしば人類には理解不能な答えを出してくる。 それはひとめ「間違っている」と映ることもあるが、よくよく確かめると正しいこともなくはない。 唯一無二の答えならそれを選ぶしかないが、多くの場合、答えは一つではない。 ゆえにいくら正しくとも「選ばない選択」をするのが、人間の仕事じゃないかなって。

人間に合った答えを選び、人間が扱える方法を選んで検算する。 人間に合っていない答えは選ばない、人間が扱えない方法での検算は採用しない。

って感じ。

昔からある構造

AI関連で色々と「今までとは違う!」って話はでるのだけど「構造は変わってないなぁ」と思うことはよくある。 今回の話も技術差のある現場では昔からよくある話だったりする。

技術差があると技術上位者による「他のメンバーが理解できないが正しい答え」はしばしば持ち込まれるが、それをそのままにするとスケールしなかったり、オーパーツ化して痛い目にあったりする。そこで「メンバーのスキルをあげる」のと「メンバーがわかる(あるいは将来的にわかるようになる)レベルの答えを選択する」などの方法を組み合わせて対応してきた。AIでも同様のことが必要ってだけの話。

なので別に新しい考え方でもなんでもない。

のだけど、「メンバーがわかるようになる」は答えを出したのが「言うても同じコンテキストに同席した人間」条件下だったのである程度期待してもよかった(酷なこともあるが)。しかしながらAIとなると「人間にAIと同じレベルになれ」を要求するのは流石に無理がある領域もある。その辺は差分かもしれない。

プロの投手で160km/hのボールを投げられる人がいて。同じプロの投手でトレーニングにより投げられる人がいるのを期待するのは自然。 でもピッチングマシーンが300km/hのボールを投げるからといって、人に投げられるようになるのを期待するのは違うよねって。

おまけ

「検算」は 京都総合法律事務所のメルマガ2026年4月号 から編集後記から。

決定の遅延と添木の設計

設計してますか?

ぶっちゃけ「設計 is 何」ってよくわからないんだけど、設計はしてます。 で、その設計なんだけど、今の何かを満たすものだけでなく未来に備える系があるなと思った。 私の中では「決定の遅延」と「添木」と呼んでるものです。

決定の遅延

決定を遅延させるために行う設計があります。

現実はいろんなことが起こり、未来がどうなるかはわかりません。 少し待てば情報が増えることがわかっていることはあります。でもどのような情報が来るかは分かりません。

「すべての情報が揃ってから動けばいい」という選択もあり、これはこれで一理あります。 ですがそのようにしていると期限に間に合わないこともしばしばあります。 時間は融通が効かないので、他で融通を効かせる必要があります。

そういう時に「決定を遅延させる設計」を使うことがあります。 決まっている部分を進めて、決まっていない部分を後回しにするという当たり前のような手段ですが、往々にして決まっていることと決まっていないことはないまぜになっています。

そういう時にいろんな整理をします。

  • 決まっていることと決まっていないことを分ける
  • 決まっていない度合いで濃淡をつける
  • 決まる時に取られうる選択肢を限定する
  • ...

かたい部分はハードパーツって呼んだりするもののこともある。

(直接ここで書いているものとイコールではないが。)

あの手この手で決め難いところを柔らかく包み込んで、決定を遅らせることが可能なようにする。 単なる先送りではなく、重要な部分を決めるための時間を稼ぎ、決まった時に憂いなく取り組めるようにする準備を整える。 そんな感じ。

添木

プロジェクトの期間中に決定が訪れるものであり、それが待つ価値のあるものであれば、可能な限り遅延させられるようにして進めます。 それはそれとして決定が訪れないものもそれなりにあります。

「将来こうなるかもしれない」と考えるのは重要ではあるものの、なっていないことを前提に作るのはYAGNIと言われるアンチパターンです。(作るコストがAIで劇的に下がってるので「作っちゃえばいいじゃん」って話もありはしますが、本稿の趣旨ではないのでそれはそれとしてください。) でも考えるのはいいことなんです。 前提にした対応はしない、でも方向づけはする。 そういう設計を「添木」と呼んでいます。

具体例はうまく伝わるかわかんないのですが、構造や名前は添木の側面を持ちます。

たとえばパッケージ構造はクラスの増え方を方向づけします。 新規プロダクトで序盤に用意したどこからか借りてきたパッケージ構造が邪魔くさく感じたことはないでしょうか。 それはおそらく借りてくる元のコンテキストでは「その方向に進んでほしくない」というものです。意図的であれ結果的であれ。 そのコンテキストを踏襲するなら「邪魔くさい」と感じたのは何かしらアーキテクチャのルールに違反しているからでしょう。

たとえば名前は他の名前に影響を与えます。 「添木」という言葉があれば「鉢」とか「枝」とかが連想されるものです。 システム開発での名前選びは、今後の他の名前に何かしらの制約を与えます。具体例?触ったことあるシステムのクラス名とかを思い返して、新しいクラスを追加しようとしたらそれに引っ張られますよね。それです。

「添木」は存在を認識されないなど、伝わらないこともしばしばです。 実際の植物でも添木を無視して成長してることもままあるものですし、まぁ仕方ない。 「そうはならんやろ」と思うような方向に成長することも稀によくある。

添木で物足りないなら周りをしっかり囲いましょう。 ニュアンスや文化で伝えるのではなく、規約やルールでしっかり固めましょう。 どちらがいいかなーというのもまちまちだと思うんだけど、AIを前提にすると添木は主張が弱すぎて役に立たない気もしなくはない。

speakerdeck.com

ルールや規約の話を出してしまったので「添木」がその系に読み取れなくもない気はするけど、あくまで「成長に方向性を与える」という設計パターンです。 「"今は決めない"と決めたもの」でも「成長するならこっち方向かなー」という意図を込める。そんな設計ってのもあるよなぁと。伝わるかなー。

補足: 仮止め

私の中で「仮止め」と呼んでいる設計パターンもあるので触れておく。

「仮止め」は家具を組み立てる時とかにネジを軽く締めておく、キツく締める前にやっておくあれです。 永続的ではなく一時的にその状態で固定して全体のバランスを調整したり、場合によってはやめたりするのだけど、とにかくそこを固定しないと他のことを考えようにも空中分解してしまうようなことはそれなりにあります。 「一旦これで決めて次に進めよう」という感じで決定はしているので、「決定の遅延」とは区別しています。

なおADRなどの軽量ドキュメントによる「取り消し可能な決定」も「仮止め」に近いけれど、そのままにする可能性があるのが「取り消し可能な決定」です。「仮止め」はその場所で固定するにしても「ちゃんと締める」は必須になる点が違ったりする。

しめ

どんな設計でも動けばいい。それはそう。動くのはいいこと。動かないのは話にならない。 とは言えコンピューターの発達に伴い、「動く」を満たした上で取れる選択肢も非常に広くなっている。 「こういう作りをしないとそもそも動くと言えない」のような制約は縮小し、超富豪的プログラミングも十分成立してしまう今日この頃。 そんな制約が少ない中での設計の考え方ってのもあるわけで。

決められるなら決めてしまえばいいことも多いのだけど、決めない方がいいこともそれなりにありはします。 そういう時に「決定を遅延」させられるようにし、さらに決めないまま方向性を主張する「添木」を配置する。 そんな感じの考え方をすることがなくはないなぁ、という話でした。