ここで多くの人が、いきなりクラウド（＝要するに、ネットの向こうにあるデータの倉庫）につなごうとします。私もそうしかけました。

でも、それをやると高い確率でこうなります。接続設定のエラーで画面すら出ないまま、休日が半日溶ける。動くアプリを一度も見られないまま、やる気だけ先に死ぬ。

なので、逆をやりました。ネットには一切つながず、スマホの中だけで動く「中身が空っぽの版」を先に完成させた。

前回まで

コードが一行も書けない会社員が、AIに日本語でお願いして家族用アプリ「ごはんいる？」を作っています。

第2回では、いきなり作らせずに「何を作るか」だけを先に決めました。1ユーザー＝1家族、最大7人、お弁当と昼食は別々に数える、Androidのみ、直接配布。ここまでが設計図です。

今回から、やっと手を動かします。ただし、ネットにはつなぎません。

なぜ、いきなりクラウドにつながないのか

作りたい気持ちは分かります。でも最初は、クラウドを後回しにしたほうがいい。理由は3つあります。

1. 接続の設定でつまずくと、画面すら見られないまま時間が溶ける。一番モチベーションが下がる詰まり方です

2. 見た目と使い勝手を先に固められる。ここが、あとで一番作り直しが多い場所です

3. お金がかからない。無料枠すら消費しません

この「中身が空っぽの版」を、開発ではモックと呼びます。＝要するに、ニセのデータで動く練習版です。本物のデータはどこにもない。でも、画面はちゃんと動く。

繰り返します。クラウドは、後回しでいい。 まずスマホの中だけで完成させる。

料理でいえば、いきなり本番の食材を切り始めるのではなく、先に段取りとお皿の並べ方だけ決めておくようなものです。

1つのアプリに、2つのアプリを入れた

やったことを具体的に書きます。同じアプリの中に、データの置き場所が違う2つのモードを用意しました。

・モック版：データの置き場所はスマホの中のファイル1つ。開発中の画面確認に使う
・本番版：データの置き場所はクラウド（Firebase）。家族が実際に使う版

最初はモック版だけで作り込む。見た目と使い勝手が固まったら、データの置き場所をクラウドに差し替えるだけで本番版になる。そういう作りにしておきました。

これが結果的に大正解でした。第5回でクラウド接続の山場が来て派手に詰まるのですが、そのときもモック版は普通に動くので、開発が止まらなかった。逃げ場を先に作っておいた、というわけです。

段取りだけ、二重に用意しておいた。

この時点で、もうアプリは触れた

モック版で、この4つの画面を作りました。

・ログイン画面（ダミーの家族7人から選ぶだけ）
・ホーム画面（今日の食事の人数集計）
・カレンダー
・予定の登録画面

中身は空っぽのニセデータです。でも、タップすれば反応するし、人数もちゃんと集計される。この時点で、もうアプリとして指で触れる。 ここまで来ると、開発は一気に楽しくなります。

登録前と登録後で、ホーム画面がどう変わるか。並べるとこうです。

ネットにつながっていないのに、ここまで動く。作った本人が一番びっくりしました。

つまずきポイント

順調そうに見えますよね。しっかり3回つまずいています。

つまずき1：開発の準備が、作るより面倒だった。

コードを書き始める前に、道具をそろえる必要がありました。Java（開発の土台）、Androidの開発キット、Android Studio（開発用アプリ）、それからスマホの代わりに画面を映す「エミュレータ」。

手順はAIが全部やってくれます。ただ一度、「ライセンスに同意しますか？」の画面で処理が止まりました。AIがどれだけ自動で進めようとしても、この「同意しますか？」の対話だけは、勝手には越えられない。

教訓は単純です。AIが黙って止まったら、「今なにを待ってるの？」と聞く。だいたい、こっちの返事を待っています。

つまずき2：ホームボタンを押しても、ホームに戻らない。

登録が終わったあと、下のホームボタンを押しても、最初の画面に帰ってこない。自分で触っていて気づいた不具合です。

原因は、アプリが前回開いていた画面を覚えていたこと。よかれと思った気の利かせ方が、裏目に出ていました。「ホームを押したら必ず最初に戻る」よう直しました。

これ、地味に大事な話です。AIが書いたコードも、完璧ではない。 そして、実際に自分で触ってみるまで、この手のバグは見つからない。配る前に自分で踏んでおいてよかった、と心から思いました。

つまずき3：欲しい機能は、使ってから出てくる。

最初は「今日の食事」しか表示していませんでした。でも自分で使ってみると、すぐ思うわけです。「明日と明後日も見たい」。買い物の計画に要るので。

そこで、今日／明日／明後日の切り替えボタンを足しました。当たり前のことなんですが、使ってみないと、必要な機能は分からない。設計図をどれだけ眺めても、この気づきは出てきませんでした。

地味だけど、あとで一番効いた：自動テスト

この段階で、もうひとつ入れておいたものがあります。自動テスト。＝要するに、「ちゃんと動いてるか」を機械が勝手に確認してくれる仕組みです。

・家族3人が「お弁当いる」と登録したら、集計はちゃんと3になるか
・締切を過ぎた変更を、きちんと検知できるか

こういうチェックを、最終的に22件、機械が自動で通してくれるようにしました。

これがあると、あとで機能を足したとき、どこかが壊れていないか一瞬で分かる。実際この連載の最後（v1.3.0）まで、機能を足すたびにこのテストで安全確認をしています。

派手さはゼロですが、いま思うと、この回で一番賢い判断でした。

この回の学び

・クラウドは後回し。 まずスマホの中だけで動くものを完成させる。画面すら見られずに時間が溶ける事故を防げる
・早く触れるようにすると、必要な機能が見えてくる。 「明日も見たい」は使って初めて分かった
・AIが作ったものにも不具合はある。 自分で触って確かめるまで見つからない（ホームボタン問題）
・自動テストは早めに入れる。 あとで機能を足すのがずっと楽になる

――――――――――

📮 「その頼み方」をそのまま真似したい方へ

モック版から作らせる指示、自動テストを入れさせる指示——この連載で実際にAIへ送った指示文を10個、読者特典にまとめてあります。コピペして使える汎用版つき。

――――――――――

今すぐ登録する

次回予告

ここまで0円です。無料枠すら使っていないので当然ですが。

ところが次回、通知機能を作ろうとして、クレジットカードの登録を求められかけます。0円を守るために、通知のしくみごと設計を作り直した判断を書きます。

クラウドは、後回しでいい。でも、いつかは向き合う日が来る。その第一歩が、次回の「お金」の話です。

配信は火曜と金曜、全8回。あと5回です。

私もそう思っていました。実際、そう言いかけました。

でも、その一行を送っていたら、たぶんこのアプリは完成していません。

できたのは「思ってたのと違うもの」。直して、また違って、また直して。そのうち面倒になって、スマホのメモ帳に戻る——そういう未来がかなり濃厚でした。

実際にやったことは逆です。コードを1行も書かせず、先に「何を作るか」だけを決めた。

しかもその要件定義（＝要するに、何を作るかの取り決め）、私は仕様書なんて書いていません。AIの質問に答えただけです。

今回はその手順を全部開きます。連載で一番地味で、一番真似する価値のある回です。

前回まで

コードが一行も書けない会社員が、AIに日本語でお願いし続けて、家族用アプリ「ごはんいる？」を作りました。

いま家族5人のスマホに入っていて、毎日使われています。そして「かわいくない」と言われています。詳しくは第1回で。

やってしまいがちな頼み方

まず、私がやりかけたダメなほうから見せます。

「ごはんいる？っていう家族向けアプリを作って。夕飯の出欠がわかるやつ」

一見、ちゃんとした依頼に見えますよね。要望は伝わっている。AIも「わかりました」と言って、元気に作り始めてくれます。

問題はそこじゃないんです。

このお願い、決まっていないことが多すぎる。

・家族グループは1世帯に1つ？　複数の家をまたぐ？
・何人まで使う想定？
・お弁当と、家で食べる昼ごはんは、同じ「昼」で1回に数える？
・Androidだけ？　iPhoneも？
・そもそも、できたアプリをどうやって家族に配る？

ここを決めずに「作って」と言うと、AIは止まってくれません。

分からないところを勝手に決めて、それっぽく作り始めます。しかも、わりと自信満々に。

で、できあがってから「あ、そこ、そういう意味じゃなかった」が発覚する。

作り直し。また別のところが違う。また作り直し。

第1回で「ごはんを作ってから『今日いらない』が発覚するのが一番つらい」と書きました。開発もまったく同じでした。できてから間違いに気づくのが、一番高くつく。

ごはんも設計も、戻せないんです。

実際にやった頼み方

やったことは逆でした。

最初のフェーズでは、コードを1行も書かせない。

AIに最初に伝えたのは、アプリの中身ではなく「進め方」です。

この順番で進めてください。フェーズ1では設計だけ。コードはまだ1行も書かないで。

全体は5つのフェーズに分けました。

・フェーズ1：何を作るか決める（コードは1行も書かない）
・フェーズ2：見た目だけ動く試作版を作る（ネットにはつながない）
・フェーズ3：家族・招待・権限のしくみ（まだクラウドは使わない）
・フェーズ4：クラウド連携・LINEログイン
・フェーズ5：テスト・家族に配布

なぜ分けるのか。理由はひとつです。

一気に作らせると、どこで間違えたか分からなくなるから。

段階ごとに「ここまではOK」と確認できれば、事故っても直前まで戻ればいい。全部まとめて作らせて全部間違っていたら、どこから直せばいいのか誰にも分かりません。

作った本人にも、です。

最初に出した4つの指示

進め方と一緒に、”お願いの前提”も先に固定しました。効いた順に4つ。

1.「フェーズ1では成果物だけ。コードは書かないで」

設計に集中させます。すぐ手を動かしたがるAIを、いったん座らせるイメージです。

2.「分からないことは勝手に決めず、日本語で質問して」

これが一番効きました。すぐ後で詳しく書きます。

3.「嘘の情報（架空のURLやキー）は作らないで」

AIは分からないと、”それっぽい嘘”を堂々と作ることがあります。先に禁止です。

4.「秘密の情報はスマホの中に置かないで」

セキュリティの方針は、作り始める前に決めておく。この一言は、あとで効いてきます（第5回）。

一番効いたのは「AIに質問させた」こと

2番の指示は、想像以上の働きをしました。

作らせるつもりだったのに、逆に質問攻めにあったんです。返ってきた質問がこれ。

・家族グループは1世帯に1つでいいですか
・何人まで想定しますか
・お弁当と、家で食べる昼食は、別々に数えますか
・Androidのバージョンはどこまで対象にしますか
・アプリはどうやって配りますか

3つ目で手が止まりました。

お弁当と昼食を、分けるかどうか。考えたことすらなかった。

でも言われてみれば当たり前なんです。お弁当を作る手間と、家で昼を出す手間は、全然違う。ここを「昼1回」でまとめていたら、集計の意味が半分なくなっていました。

自分では絶対に気づかない抜け漏れを、作り始める前に潰してもらえる。

これが実は、最大の時短でした。

質問に答えていくうちに、仕様は勝手に固まりました。

・1ユーザー＝1家族グループ
・家族は最大7人
・お弁当と「家で食べる昼食」は別々に数える
・対象はAndroidのみ
・アプリストアを通さず、直接配布

繰り返しますが、私は仕様書を書いていません。質問に答えただけです。

つまずきポイント

ここまで順調そうに見えますが、しっかり2回つまずいています。

つまずき1：質問が、どこに出ているのか分からなかった。

AIが日本語で質問を返してくれた——のに、それが画面のどこに表示されているのか分からない。

私が最初にAIにした質問は、これでした。

「質問は何処で確認できる」

質問に、質問で返した。役割が逆転したうえに、こちらの初動がこれです。

でも正直に書いておきます。ここ、たぶん多くの人が同じ場所で固まります。恥ずかしがらずに聞いていいところです。

つまずき2：「これ実行していいですか？」が多すぎた。

AIは作業のたびに「この操作を実行していいですか？」と許可を求めてきます。

丁寧なんです。丁寧なんですが、一歩進むたびに止まる。なかなか進まない。

そこで「できるだけ許可なく進めてください」と伝えて、確認の頻度を下げました。

ただし、危ないこと（データを消す・外部に公開する）は必ず止める設定だけは残しました。

この「どこまで自動で任せて、どこは必ず止めるか」の線引きは、AI開発で最初に決めるべきことだと思います。

全部確認は、遅すぎる。全部お任せは、危なすぎる。ちょうどいい場所は、自分で決めるしかありません。

地味だけど、一番効いた設計判断

要件を決める中で、コードと関係ない「考え方」の判断もありました。ひとつだけ紹介します。

「未登録」と「未定」を、別物として扱う。

・未登録＝まだ答えていない人。催促していい
・未定＝「まだ分からない」と意思表示した人。催促しなくていい

この2つを一緒にすると、「ちゃんと答えたのに催促される」というストレスが生まれます。

そして人は、この手の小さい理不尽で、静かに怒ります。

アプリの使い心地はこういう細かい区別で決まる——というのは、家族に配ってから何度も思い知ることになります（第7回）。

この回の学び

・いきなり作らせない。フェーズを分けて、1つずつ「ここまでOK」を確認する
・AIに質問させる。自分の抜け漏れを、作り始める前に潰せる（お弁当と昼食問題）
・どこまで任せるかを最初に決める。全部確認は遅く、全部お任せは危険
・細かい設計判断（未登録と未定を分ける等）が、あとで使い心地を左右する

――――――――――

📮 この回で出した「4つの指示」を、そのまま使いたい方へ

本文で紹介した指示は、実際に私がAIに送った文章そのものです。連載で効いた指示文を10個まとめた読者特典に、コピペで使える汎用版と一緒に入れてあります。

――――――――――

今すぐ登録する

次回予告

次回は、いよいよ手を動かします。

といっても、ネットにはつなぎません。まず「見た目だけ動くけど、中身は空っぽの版」を作りました。

いきなりクラウドにつながないほうがいい理由を、痛い目の一歩手前で書きます。

配信は火曜と金曜、全8回。あと6回おつきあいください。

わが家で毎日発射されるこのLINE、返事が返ってくるのは3人。しかも「いる」「昼はいらない（聞いてない）」。

耐えかねて、アプリを作りました。コードは一行も書けないのに。

「今日、夕飯いる人？」問題

家族のいる家なら、たぶんどこでも起きているやつです。

• 夕飯の出欠をLINEで聞く。返事はバラバラの時間に、バラバラの精度で返ってくる

• お弁当が何個必要か、当日の朝になっても確定しない

• 誰かの「今日いらない」を、作る人だけが知らない

一番つらいのは、作ってから「あ、今日いらないんだった」が発覚する瞬間です。ごはんは戻せません。

この状態を放置すると何が起きるかというと、毎日です。毎日この小さいストレスが、この先ずっと続く。夕飯は明日も明後日も来るので。

……という話をAIにしたら、アプリができました。順を追って説明します。

先に完成品をお見せします（信じてもらえないので）

アプリ名は「ごはんいる？」。ひねりゼロですが、家族向けアプリに必要なのはカッコよさではなく、おばあちゃんが読めることです。

やってくれることはこれだけです。

• 家族それぞれが「朝・昼（お弁当か家か）・夕」の予定を登録する

• ホーム画面に「お弁当◯人分・夕ごはん◯人分・まだの人◯人」が勝手に集計されて出る

• 今日／明日／明後日はワンタップ切り替え

• ごはんを作る人（管理者）は、カレンダーで3週間分をまとめて見られる

• 締切前に「まだ登録してないよ」とスマホに通知が飛ぶ

• 家族の招待はコードを送るだけ。ログインはいつものLINEアカウント

つまり、あの「今日いる？」のLINEを、二度と送らなくていい。

そしてこれがスマホのホーム画面です。ChromeやGmailに混ざって、右下にしれっと自作アプリが並んでいます。湯気の立った茶碗のアイコンが「ごはんいる？」です。

「作ってみた」ではありません。家族5人のスマホに入っていて、毎日使われています。ここ、この連載の一番の自慢ポイントなので、太字にさせてください。家族5人が、毎日使っています。

作った本人のスペックを公開します

私の開発者としてのスペックです。強い数字と弱い数字が混在しています。

• プログラミング経験：なし（書けない。読めない。エラー文は呪文に見える）

• 開発費用：0円（クレジットカード登録すらしていない）

• 運用費用：0円（Firebaseの無料枠内）

• 実際の利用者：家族5人が毎日利用中

• バージョン：0.2.0 → 1.3.0（アップデート8回以上）

• アプリのサイズ：約7.5MB

• 自動テスト：43件が自動で通る

やったことは、AI——具体的にはClaude Code（＝要するに、日本語で指示するとコードを書いて実行までやってくれるAIツール）に、日本語でお願いし続けただけです。本当にそれだけかというと、それだけではなかったので連載が8回あります。

正直に書いておきたいのが費用の話です。「0円」は「完全無料のサービスだから」ではありません。Firebase（＝要するに、アプリの裏側を丸ごと引き受けてくれるGoogleのサービス）の無料枠に収まるように設計したから0円なのです。使う人が増えれば有料になる可能性はあります。というか実際、開発の途中で課金一歩手前まで行って、慌てて設計を作り直しています。この攻防は第4回でやります。

家族は、優しくなかった

個人開発は普通、作って満足して終わります。私も危なかった。

でも家族に配ると、終われないんです。なぜならユーザーが食卓にいるので。

配って返ってきた声の一部をご紹介します。

• 「文字が小さい」

• 「かわいくない」

• 「メモの例文が消えないんだけど」

• 「毎日同じ内容を入れるのが面倒」

「かわいくない」は効きました。機能の話ですらない。でも、直しました。見た目を作り直し、例文のバグを直し、”基本情報のコピー”機能を足しました。配ってからの5回のアップデートは、全部この容赦ない家族レビューが原動力です。

世界一距離の近いユーザーテスト、おすすめです。逃げ場はありません。

難しかったのは、コードじゃなくて「決めること」

連載の結論を先に書いてしまいます。

「AIに作らせる」の本当の難しさは、コードではなく”決めること”にある。

AIはコードを書いてくれます。エラーも（だいたい）直してくれます。でも——

• 何を作るか

• どこまで作るか

• 有料と無料の分かれ道で、どっちを取るか

• 家族の「使いにくい」のうち、どれを直してどれをスルーするか

これは全部、人間の仕事として残りました。この連載では、その判断を全部公開します。

判断だけでなく、事故も全部書きます。予告編としていくつか——

• Firebaseにパッケージ名を打ち間違えたまま登録して、直せなくなりました。最終的に、アプリ側の名前を間違いに合わせるという力技で解決しています。引っ越せないので表札を書き換えたようなものです（第5回）

• 完成したアプリを家族のスマホに入れようとしたら、Androidに「危険なアプリ」としてブロックされました。作った本人の目の前で、です（第6回）

• 通知機能をLINEで作ろうとしたら、クレジットカード登録が必要になりかけました。0円死守のため、通知の仕組みごと設計変更（第4回）

この連載で全部書きます（全8回）

1. 「今日、夕飯いる人？」に疲れた会社員が、コードを一行も書けないままアプリを作って家族に配った話（この記事）

2. 「何を作るか」をAIと決める：いきなりコードを書かせない

3. まず”動くけど中身がない版”を作る：ネットにつながずUIを完成させた話

4. 有料になりかけたので設計を変えた：LINE通知をやめて0円を守った判断

5. 一番苦しかった山場：LINEログインとクラウド接続、実機だけで出たエラー

6. 家族のスマホに配る：アプリに署名し、「危険なアプリ」警告と戦う

7. 使われてからが本番：家族の「使いにくい」で5回作り直した話

8. 総括：AIで開発して分かったこと、かかったお金、次にやるなら

この回の学び

• AIはコードを書いてくれる。でも「何を作るか・どこまでやるか・何を直すか」を決めるのは自分

• 「作った」より「使われ続けている」の方が何倍も難しく、何倍も面白い

• 0円は偶然ではなく、無料枠に収まるように設計した結果（詳細は第4回）

――――――――――

📮 読者特典を、まだ受け取っていない方へ

この連載で実際にAIへ送った指示文を、10個まとめて配っています。コードは一行も書きません。効くのは”頼み方”です。

https://rustynail48.substack.com/p/ai10

――――――――――

今すぐ登録する

次回予告

第2回は「何を作るか」をAIと決めた話です。最初にやったのは「アプリ作って」とお願いすること——ではありませんでした。コードが書けない人間の要件定義（＝要するに、何を作るかの取り決め）、次回書きます。

配信は火曜と金曜、全8回。最終回まで4週間おつきあいください。

プログラミング未経験の会社員が、AIに日本語で指示するだけで、LINEログイン・クラウド同期つきのAndroidアプリを作り、家族に配るまで。

この特典では、その開発で私が実際にAIへ送った指示文（プロンプト）の中から、「これが効いた」「ここが転機になった」もの10個を、そのまま真似できる形で公開します。

各プロンプトには、 ・実際に送った文（少しだけ整えています） ・コピペで使える汎用版（あなたのプロジェクトに置き換えるだけ） ・何のための指示か／なぜ効いたか をつけました。コードの知識はいりません。効くのは「何を・どう頼むか」です。

さらに巻末に、連載本文で名前を出した指示文を5本、追補として足してあります（第3回・第5回・第6回で触れたもの）。

⚠️ この特典に、鍵やパスワード、APIキー、メールアドレスなどの機密は一切含めていません。あなたが真似するときも、そうした情報はAIに渡さないでください。

この特典の使い方（3ステップ）

登録は無料・ワンタップです。

ラス | SAPの町医者

SAP BASIS 20年。DB屋あがりのシステム屋です。現場で見てきたリスクを言語化します。AIで武装しながら、SAPの町医者を目指しています。

この特典は、連載「AIだけで家族アプリを作った話」の読者向けにまとめたものです。

情シスの仕事をしていると、「勉強する時間がない」という感覚が慢性化する。

障害対応、ベンダー折衝、ユーザーからの問い合わせ。
気がつくと1日が終わっている。

本当は、セキュリティも、クラウドも、マネジメントも、もう少し勉強したい。
でも、机に向かって本を開く気力が残っていない。

ぼくもずっとそうだった。

でも、あるとき気づいて、ちょっと悔しくなった。

時間がないんじゃない。
「耳」を捨てていただけだった。

目と手は塞がっていても、耳は空いていることが多い。

ここに気づくと、情シスの毎日は少し変わる。

情シスに「耳のすき間時間」が多い理由

情シスの仕事をよく観察すると、こういう時間が毎日ある。

通勤・移動中
電車・車・徒歩。
スマホを見る気力がなくても、イヤホンは刺せる。

片道30分なら、往復で1時間。
週5日で月20時間。

「月20時間の勉強時間を作れ」と言われると無理に見える。
でも、通勤中に聴くだけなら現実的だ。

サーバルームでの作業待ち
バックアップ完了待ち。
パッチ適用中。
再起動待ち。

画面の進捗バーを見つめながら、「早く終われ」と思っている時間がある。
その時間、手は動かせない。
でも耳は空いている。

障害対応の待機中
ログを眺めながら、ベンダー回答や別チームの確認を待つ時間。
もちろん集中が必要な局面では聴かない。

ただ、切り分けが一段落して「待ち」に入った瞬間はある。
その15分に、軽めのビジネス書を1章だけ聴く。
これだけでも、SNSを眺めるよりは前に進む。

昼食・休憩時間
食堂でスマホを開く。
気づいたらニュースとSNSで20分溶けている。

ここをAudibleに変えるだけで、1日1章は進む。

こう考えると、情シスには毎日1〜2時間の「耳のすき間時間」がある。

なぜポッドキャストではなくAudibleなのか

無料のポッドキャストでも、耳学習はできる。

だから、ただ「耳で聴ける」だけならAudibleである必要はない。

Audibleを使う理由は、別にある。

1. 本1冊を、プロのナレーションで聴ける

ポッドキャストは情報の断片になりやすい。
Audibleは本1冊なので、著者の考えを最初から最後まで追える。

情シスの仕事は、断片知識だけでは弱い。
「何を優先するか」「どう判断するか」という考え方まで入れたい。
その意味で、本を丸ごと聴けるのは強い。

2. 聴き放題だから、途中でやめやすい

買った本だと「最後まで読まないともったいない」と思う。
でもAudibleなら、合わなければ別の本に移れる。

これが地味に大きい。

忙しい情シスに必要なのは、根性で読み切ることではない。
今の自分に刺さる本を、早く見つけることだ。

3. オフライン再生が現場と相性いい

地下鉄。
電波の弱い建物。
サーバルーム周辺。

情シスの行動範囲には、通信が安定しない場所が意外とある。

Audibleは事前にダウンロードしておける。
前日の夜に1冊入れておけば、翌日の移動や待ち時間でそのまま聴ける。

4. 章単位で進めやすい

1章10〜20分の本が多い。

朝の通勤で1章。
昼休みに1章。
帰りの電車で1章。

これだけで、1日3章進む。
「まとまった時間がないと読めない」という思い込みが消える。

まず何を聴けばいいか

最初の1冊で迷うなら、重たい技術書より「行動が変わる本」がおすすめだ。

1冊目：夢をかなえるゾウ（水野敬也 著）

ぼくが最初にすすめたいのはこれ。

自己啓発っぽいタイトルだけど、中身はかなり実務的だ。
大きな夢を語る本ではなく、「靴を磨く」「人を笑わせる」みたいな小さな行動を積み重ねる話。

情シスは、毎日トラブルや調整に追われる。
だからこそ、「今日ひとつ行動を変える」という感覚を取り戻すのに向いている。

👉 Audible版「夢をかなえるゾウ」

2冊目：神さまとのおしゃべり（さとうみつろう 著）

情シスの仕事をしていると、「それが常識だから」で片づく場面が多い。

この手順でやるもの。
この順番で承認を取るもの。
前任者もそうしていたもの。

でも、障害や非効率の原因は、意外とその「当たり前」の中にある。

この本は、「自分の常識を疑う」きっかけになる。
堅いビジネス書ではないので、通勤中にも聴きやすい。
疲れている日に流しても、頭に入りやすい1冊だ。

👉 Audible版「神さまとのおしゃべり」

30日間、無料で試せる

Audibleは最初の30日間、無料体験ができる。

まず1ヶ月、通勤時間だけでいい。
いきなり休日を潰して勉強しなくていい。
朝と帰りの電車で、1冊流してみる。

それだけでたぶん気づく。

「耳が空いている時間、こんなにあったのか」と。

👇 Audible 30日間無料体験はこちら
【無料体験はこちら】

無料期間が終わった後は月額1,500円。
ビジネス書1冊分くらいの値段で、対象作品が聴き放題になる。

合わなければ無料期間中にやめればいい。
まずは「通勤だけ」で試すのがいちばん軽い。

最後に

「勉強する時間を作る」のは難しい。

でも「耳のすき間時間を使う」のは、意識を変えるだけでいい。

情シスは忙しい。
だからこそ、耳を使う。

移動時間。
待機時間。
作業待ち。

毎日こぼれていた時間が、1年後の自分をつくる。

今日の帰り道、まず1冊だけ流してみてほしい。

この記事にはアフィリエイトリンクが含まれています。

情シスの仕事をしていると、「勉強する時間がない」という感覚が慢性化する。

障害対応、ベンダー折衝、ユーザーからの問い合わせ。 気がつくと1日が終わっている。

でも、あるとき気づいた。

「目と手は塞がっていても、耳は空いていることが多い」

情シスに「耳のすき間時間」が多い理由

情シスの仕事をよく観察すると、こういう時間が毎日ある。

通勤・移動中 電車・車・徒歩。スマホを見る気力がなくても、イヤホンは刺せる。 片道30分なら、往復で1時間。週5日で月20時間。

サーバルームでの作業待ち バックアップ完了待ち、パッチ適用中、再起動待ち。 「何かが終わるのを待っている」時間は、耳が完全に空いている。

障害対応の待機中 ログを眺めながら次の手を待つ時間。 画面は見ているが、思考は半分空いていることが多い。

昼食・休憩時間 スマホSNSを眺めるより、イヤホンで聴く方が圧倒的に学びになる。

これだけで、毎日2〜3時間の「耳のすき間時間」が存在している。

Audibleで「耳のすき間時間」を使い倒す方法

① 再生速度を1.5〜2倍にする

最初は違和感があるが、3日で慣れる。 2倍速にすれば、1冊8時間の本が4時間で聴ける。 移動時間だけで週1冊のペースは現実的に達成できる。

② 「ながら聴き」専用のジャンルを決める

集中が必要な本（技術書・数字が多い本）は、作業しながら聴くのには向かない。 すき間時間には「考え方・思想・エッセイ系」を充てると定着しやすい。 技術的な内容は、座って画面を見られるときに聴く。

③ 同じ本を2〜3回聴く

紙の本と違い、Audibleは「繰り返し」が容易。 1回目は全体把握、2回目は気になる部分だけ。 移動のたびに同じ本をかけ流すだけで、内容が自然に染み込む。

④ 章ごとに区切って聴く

1章10〜20分の本が多い。 通勤1往復で1〜2章。これを積み重ねると、1週間で1冊終わる計算になる。 「まとまった時間がないと読めない」という思い込みが消える。

⑤ 移動前にダウンロードしておく

オフライン再生ができるので、電波のないサーバルームや地下鉄でも聴ける。 前日夜に次の本をダウンロードしておくだけでいい。

30日間、無料で試せる

Audibleは最初の30日間、無料体験ができる。

まず1ヶ月、通勤時間だけ使ってみてほしい。 「耳が空いている時間がこんなにあったのか」と気づくはずだ。

👇 30日間無料体験はこちら

月額1,500円で聴き放題。 ビジネス書1冊分の値段で、毎月何冊でも聴ける。

最後に

「勉強する時間を作る」のは難しい。

でも「耳のすき間時間を使う」のは、意識を変えるだけでいい。

情シスは忙しい。だからこそ、耳を使う。

移動時間・待機時間・作業待ち。 毎日積み重なるその時間が、1年後の自分をつくる。

※この記事にはアフィリエイトリンクが含まれています。

正直に言います。

ぼくは本を読むのが苦手でした。

SAPのエンジニアとして20年。

毎日、障害対応・ログ解析・夜間の電話対応。

「本を読もう」と思っても、家に帰れば疲れ果てていて、気づけば積ん読の山だけが増えていく。

そんなぼくが変わったのは、Audible（オーディブル）を使い始めてからです。

====

「読む」をやめて「聴く」にした

通勤電車の中。

ぼくはスマホを開く代わりに、イヤホンをつけました。

流したのは「夢をかなえるゾウ」（水野敬也 著）。

正直、最初は半信半疑でした。

「自己啓発書なんて、どうせ耳障りのいいことしか言わないだろう」と思っていた。

ところが、主人公のセリフが刺さりすぎた。

「変わりたい、変わりたいって言うけど、お前は昨日と何か変えたか？」

ガネーシャ（ゾウの神様）に、ぼくは心の中でぶん殴られた。

「変わりたい」と思いながら、何年も変えてこなかった。

それがぼくの現実だったから。

====

この本がすごいのは「地味な行動」しか教えないこと

自己啓発書にありがちなのが「意識を変えよう」「マインドセットを変えよう」という話。

でも夢をかなえるゾウは違う。

ガネーシャが課す「課題」は全部、地味です。

• 靴を磨く

• 募金する

• 人を笑わせる

「えっ、これだけ？」と思うはず。

でもこれが、機能する。

結局ぼくたちは「大きな変化」を求めすぎて、何も動けなくなっている。

小さな行動の積み重ねが、確実に人を変える。

それをガネーシャは知っている。

====

「聴く」からこそ気づいた

本で読んでいたら、ぼくはたぶん3日で積ん読にしていた。

でも耳で聴くと、電車の中でも、歩きながらでも、止まらない。

ガネーシャの語り口が面白すぎて、勝手に続きを聴きたくなる。

Amazonレビューで15,000件以上、評価4.8。

数字が全部を語っています。

====

30日無料で全部聴ける

Audibleは今なら30日間無料体験ができます。

「夢をかなえるゾウ」はその聴き放題対象。

登録した日から、すぐ再生できます。

解約もワンクリックで完了。

気に入らなければ、お金は一切かかりません。

「変わりたいけど何から始めればいいかわからない」という人に、最初の1冊として迷わず薦めます。

👉 [Audible 30日無料体験はこちら]→https://amzn.to/4fgsIdo

===

最後に

ぼくは技術者です。

感情論が嫌いで、数字と根拠でしか動かないタイプの人間。

でもこの本だけは「理屈じゃなく刺さった」と素直に言えます。

「変わりたい」という気持ちを、もう先送りにしないでほしい。

今日、イヤホンをつけて、通勤中に流してみてください。

それだけで、少し何かが変わります。

Rusty｜SAP BASIS 20年 / SAPの町医者

SAPが急に止まると、まるで天災のように感じる。

でも20年近くSAPのインフラを見てきた私の経験では、

「完全に予告なし」の停止はかなり少ない。

よくある前兆パターンを3つ紹介する。

① レスポンスが「じわじわ」遅くなる

朝は普通に動いているのに、夕方になると画面の遷移が重い。

月初・締め処理の時期だけ遅い、というわけでもない。

こういう「説明のつかない遅さ」が慢性化しているとき、

DBの領域不足やバッファの枯渇が進行していることが多い。

「まあ気のせいかな」で放置されがちなサインだ。

② ショートダンプが「たまに」発生している

SAPにはST22という画面があって、異常終了した処理の記録が残る。

月に数回、ほとんど同じエラーが出ているのに誰も調べていない

そういう職場は非常に多い。

ショートダンプは「予告編」だ。本編（本格停止）の前に必ずここに証拠が残っている。

③ バッチ処理の終了時刻が少しずつ後ろにズレている

毎朝6時に終わっていたバッチが、気づいたら6時半になっている。

半年前は5時台だった。こういう「ジリジリしたズレ」は、

データ量増加やDBの統計情報劣化を示すサインのことが多い。

この3つは、専用ツールを使わなくても「SAPの標準機能だけ」で確認できる。

でも情シス担当が複数システムを兼任しているような現場では、

誰もそこに目を向ける余裕がない。

問題は、停止が起きてから初めて「あのとき気づいていれば…」となることだ。

まとめ

まずST22を開いて、直近1ヶ月のショートダンプを眺めてみてほしい。

そこに「次の障害の予告」が静かに積み上がっているかもしれない。

何かが壊れたとき。 システムが落ちたとき。 誰かがパスワードを忘れたとき。

必ず呼ばれます。

「ちょっといいですか」 「情シスさん、急ぎで」 「今すぐ来てもらえますか」

ぼくはそういう連絡が来るたびに、複雑な気持ちになる情シス担当者を何人も見てきました。

「また自分だ」と思いながら、それでも走っていく人たちです。

====

でも、何も起きていないとき。

静かな一日。システムが正常稼働している月曜日。 バックアップが粛々と完了している夜。 パッチ適用が予定どおり終わった週末。

そのとき、情シスは「存在を忘れられます」。

廊下ですれ違っても誰も声をかけません。 会議に呼ばれることもありません。 「最近どう？」と聞かれることもない。

当たり前です。 「何も起きていない」というのは、情シスが仕事をした結果です。

でもその結果は、誰の目にも見えません。

====

これが、情シスという仕事の本質的な矛盾です。

うまくいっていると「いなくてもいい人」に見える。 失敗すると「なぜ防げなかったんだ」と責められる。

貢献が見えにくく、失敗だけが可視化される。

これほど理不尽な評価構造は、なかなかありません。

ぼくは正直に言います。

この構造の中で「やりがい」を見出すのは、相当な精神力が必要です。

====

では、どうすればいいのか。

ひとつ言えることがあります。

「何も起きていない」状態を、自分で言語化することです。

「今月、こういうリスクに気づいて、こういう対応をした」 「このまま放置していたら、半年後にこうなっていた」 「パッチを当てたことで、この脆弱性が塞がれた」

静かな貢献を、自分の言葉にする。

誰かに報告するためではなく、まず自分のために。

自分がやってきたことを、自分で認識する。

それが、消耗せずにこの仕事を続けるための、最初の一歩だと思います。

====

情シスの仕事は、目に見えない防波堤を作り続けることです。

波が来なければ「いらない」と言われる。 波が来たら「なぜ止められなかった」と言われる。

でも、防波堤がなかったら、街は沈んでいます。

あなたがいるから、何も起きていないのです。

それだけは、忘れないでください。

SAP BASIS を20年やってきました。 専門はDB——性能問題や障害調査が一番長い現場です。

難しいことをやってきたわけじゃありません。 導入プロジェクトも、大規模移行も、経験ゼロです。

でも、「何かおかしい」を嗅ぎ取ることは、誰よりも得意だと思っています。

このニュースレターでは、こんなことを書いていきます。

• SAPの裏側で起きていること（DBレベルの話）

• 現場で見てきた「静かに進む劣化」の話

• 情シス担当者が知っておくと助かること

対象は、SAPを使っている中小企業の情シス担当者や IT責任者です。 難しい専門用語より、「あ、うちの話だ」と思ってもらえる発信を心がけます。

目指しているのは**「SAPの町医者」**。

大病院じゃなくていい。 何かあったとき、まず相談できる人間になりたい。

毎朝散歩しながら、そんなことを考えています。

読んでくれてありがとうございます。これからよろしくお願いします。

ラス

でも正直に言います。毎日残業後に分厚い技術書を開く気力は、もうありません。

そこで数年前から取り入れたのが「耳学習」です。今日はその話をします。

エンジニアこそ「耳」が空いている

エンジニアの仕事は「目を使う」時間が圧倒的に長い。画面を見る、ドキュメントを読む、ログを追う……

だからこそ、通勤・移動・家事の時間は「耳」が空いています。

ここを学習時間に変えると、1日30分でも月15時間の勉強時間が生まれます。私はこの習慣を続けて、副業・フリーランスに踏み出す決意ができました。

私がAudibleで聴いているジャンル

エンジニアのキャリアに効く本

• 「エッセンシャル思考」→ 無駄を削り、本質に集中する考え方

• 「嫌われる勇気」→ 副業・独立に踏み出す勇気をくれた一冊

ビジネス・交渉力を上げる本

• 「超影響力～歴史を変えたインフルエンサーに学ぶ人の動かし方」→ 提案や見積もりが通りやすくなる心理学

• 「マネジャーの最も大切な仕事」→ チームマネジメントの視点が身につく

【速報】本屋大賞2026受賞作もAudibleで聴ける

2026年4月9日、本屋大賞2026に朝井リョウさんの「イン・ザ・メガチャーチ」が選ばれました。

この作品、受賞当日からAudibleで配信開始・聴き放題対象に入っています。

「推し活」と現代のファンダム経済をテーマにした話題作。技術書に疲れたとき、こういう旬の小説を耳で楽しめるのもAudibleの魅力です。

勉強だけでなく、教養・娯楽も月額1本でカバーできる。これが私がAudibleをすすめる一番の理由かもしれません。

Audibleのコスパ、正直に言います

• **月額1,500円（税込）**で対象作品が聴き放題

• スマホアプリ1つで完結。倍速再生で時間効率もアップ

• 「イン・ザ・メガチャーチ」など話題作も随時追加

今使えるお得なキャンペーン

登録画面にアクセスすると、以下のどちらかが表示されます。

① 30日間無料体験 1ヶ月間、完全無料でお試しできます。気に入らなければ無料期間中に解約すれば料金は一切かかりません。

② 3ヶ月間 月額99円キャンペーン（期間限定） 通常1,500円/月のところ、3ヶ月間は月99円（合計297円）で利用できます。4ヶ月目以降は通常料金に戻ります。

どちらが表示されるかは人によって異なります。登録画面を開いて、自分に表示されているお得な方を選んでください。

👉 Audible 30日間無料体験はこちら

技術力を上げることも大事ですが、エンジニアが副業・独立で成功するにはビジネス思考と自己投資の習慣が必要です。

移動時間が、あなたのスキルアップ時間に変わります。まずは無料期間中に、好きな1冊を聴いてみてください。

本記事はAmazonアソシエイト・プログラムに参加しており、商品リンクを含みます。リンクを経由して登録いただいた場合、筆者に一定の報酬が発生することがあります。

これは、20年間ぼくが現場で感じてきた、正直な気持ちです。

---

今日は、中小企業の「情シス1人体制」について書きます。

この記事を読んでいる方の中に、1人で社内のシステムを全部担当している方がいると思います。

あるいは、「情シスって何してるの？」と思っている経営者の方もいるかもしれません。

どちらにも、読んでほしい内容です。

---

まず、現実から話します。

日本の中小企業の多くで、情報システムの担当者は1人です。

サーバーの管理、PCのセットアップ、メールの設定、社員からの問い合わせ対応。

それに加えて、SAPのような基幹システムの管理まで担う。

これを、1人でやっています。

---

ぼくが現場でよく見てきたのは、こういう状況です。

情シスのAさんは、毎朝30分早く来ます。

昨夜のバッチが正常に終わっているか確認するためです。

昼休みも、メールを確認しながら食べます。

「システムが止まったら、すぐ対応しなければ」という感覚が抜けないからです。

有給を取ると、スマホを手放せません。

「休んでいる間に何かあったら」と思うからです。

これが、1人体制の現実です。

---

でも、このAさんが問題なのではありません。

問題は、「1人でなんとかなっている」という状況が、リスクを見えにくくしていることです。

Aさんがいる間は、なんとかなります。

でも、Aさんが急に入院したら。

Aさんが転職したら。

「Aさんがいないとシステムがわからない」という状況が、多くの現場で起きています。

これを、ぼくは「属人化リスク」と呼んでいます。

---

もう1つ、見えにくいリスクがあります。

1人体制では、「自分のシステムが本当に大丈夫かどうか」を確認できないということです。

毎日近くで見ていると、少しずつ変化に気づかなくなります。

「昔より遅い気がするけど、こんなものかな」

「たまにエラーが出るけど、再実行すれば動くから大丈夫」

この「大丈夫かな」が積み重なっていくのが、静的劣化です。

外から見ると一目でわかることが、中から見るとわかりません。

---

ぼくが「かかりつけSAP医」を始めた理由の一つは、これです。

1人で抱えているAさんに、外の目を持ってほしかった。

「先生、これって普通ですか？」と気軽に聞ける存在が、近くにいてほしかった。

---

かかりつけ医が何をするか、考えてみてください。

毎回、大きな検査はしません。

聴診器を当てて、「最近どうですか」と聞いて、「これ少し気になりますね、様子を見ましょう」と言う。

それだけです。

でも、その「少し気になる」を早めに拾うことで、大きな病気を防ぎます。

SAPも同じです。

月に1回、外の目で見るだけで、防げる障害があります。

---

1人体制で頑張っている方に、伝えたいことがあります。

あなたが1人で守り続けていることは、すごいことです。

でも、1人で全部抱えなくていいです。

「外に相談する」という選択肢を、持っておいてください。

困ってから探すのではなく、困る前に「話せる人」を1人作っておく。

それだけで、あなたの仕事は少し楽になります。

---

もし「うちのSAP、大丈夫かな」と思ったら、ぼくに声をかけてください。

答えが出るかどうかはわかりません。

でも、一緒に考えることはできます。

情シス1人体制の現場を、ぼくは20年見てきました。

あなたの状況は、きっとわかります。

---

AIは賢いです。

でも、使う側が賢くないと、意味がありません。

これが、3ヶ月格闘して学んだ、一番大事なことです。

---

今日から「AIとの格闘記」シリーズを始めます。

ぼくがClaudeと格闘しながら学んだことを、失敗も含めて全部書きます。

「AIを使いたいけど、うまくいかない」という方に、特に読んでほしい内容です。

---

最初に、正直に言います。

ぼくはAIが得意ではありません。

最初の1ヶ月、ほとんどうまくいきませんでした。

「こんな感じで要約して」と書いたら、全然違う要約が返ってきました。

「もっと簡潔に」と言ったら、今度は短すぎて意味がわかりませんでした。

「プロっぽい文章で」と書いたら、やたら堅い文章が出てきました。

毎回やり直し。

時間だけが過ぎていく。

これが、ぼくの最初の1ヶ月でした。

---

転機は、ある先輩の一言でした。

「AIに『何をしてほしいか』じゃなくて、『何者として動いてほしいか』を伝えてみ」

意味がわかりませんでした。

でも、試してみました。

「あなたはSAPのベテランコンサルタントです。以下のログを解析してください」

同じ質問が、全然違う答えになりました。

具体的で、的確で、現場で使える内容でした。

---

これが、プロンプトの最初の壁です。

AIは、役割を与えると変わります。

「誰として答えるか」を決めることで、回答の質が上がります。

---

ぼくが今使っている、基本の型を紹介します。

**型1：役割を与える**

「あなたは◯◯の専門家です」から始める。

例：「あなたはSAPのデータベース専門家です」
例：「あなたは中小企業向けのIT顧問です」
例：「あなたは読みやすい文章を書くライターです」

これだけで、回答のトーンと精度が変わります。

**型2：目的を明確にする**

「目的は◯◯です」を1行で書く。

曖昧な指示の例：「この文章を直してください」
明確な指示の例：「目的は、情シス担当者が5分で読めるレポートにすることです」

目的を書くと、AIが何を優先すべきかを判断できます。

**型3：出力形式を指定する**

「◯◯の形式で出力してください」を必ず入れる。

例：「箇条書き3点で」
例：「200字以内で」
例：「見出し→本文の構成で」

これがないと、AIは自分が「適切だと思う」形式で出してきます。

それがぼくの求めていた形式かどうかは、運次第です。

---

この3つを組み合わせると、こうなります。

「あなたはSAPのデータベース専門家です。目的は、情シス担当者が経営層に説明できるリスクレポートを作ることです。以下のデータをもとに、リスクを3点、箇条書きで出力してください」

同じデータを貼り付けても、この指示があるときとないときでは、まったく別の回答になります。

ぼくは、この違いを体感するまで3ヶ月かかりました。

---

でも、型を覚えれば終わりではありません。

ここからが、本当の格闘です。

AIには「癖」があります。

何度やっても、同じ言い回しが混じります。

「次に重要なのは〜」「さらに〜」「また〜」

これを消すのが、ぼくの仕事です。

「癖のある言葉を使わないでください」と指示を加える。

それでも出てくる。

「以下の言葉は使用禁止です：次に重要、さらに、また」と書く。

ようやく消える。

AIは、言わないとやりません。

細かく指示するほど、精度が上がります。

---

もう1つ、大事なことがあります。

AIの回答を、そのまま人に送ってはいけません。

必ず1回、自分の目で読み直してください。

AIは自信満々に、間違えます。

数字が違う、事実が違う、文脈が違う。

それでも自信満々に出してくる。

最終確認は、人間の仕事です。

これだけは、絶対に省略しないでください。

---

最後に、格闘を始めようとしている方へ。

最初の1ヶ月は、うまくいかなくて当然です。

ぼくもそうでした。

うまくいかないことが、学びです。

「どこが悪かったのか」を考えながら使い続けると、3ヶ月目に急に視界が開けます。

ぼくはそれを体験しました。

続けてください。

---

障害は、突然やってきません。

必ず予兆があります。

ぼくが20年で学んだ、一番重要なことはこれです。

---

今日は、SAPの現場で実際に起きていることを書きます。

技術的な話ですが、IT担当者でなくても読めるように書きます。

「うちのSAPって大丈夫なのかな」と思ったことがある方に、特に読んでほしい内容です。

---

まず、1つ質問させてください。

あなたの会社のSAPシステム、「健康」ですか。

「動いているから大丈夫」と答えた方。

それは、答えになっていません。

動いていることと、健康であることは、別の話です。

---

たとえば、こういうことが起きます。

ある朝、経理部のAさんが月次の締め処理を実行しました。

いつもなら30分で終わります。

その日は2時間かかりました。

「遅いな」と思いながら、Aさんは待ちました。

翌月も、2時間半かかりました。

その翌月、締め処理が途中で止まりました。

システムダウンです。

月末の、一番忙しい日に。

---

このとき、ITの担当者は言います。

「突然止まりました」

でも、ぼくに言わせると、突然ではありません。

2時間、2時間半、と、毎月サインが出ていました。

ただ、誰も「サイン」として読めていなかった。

これが、SAPの静的劣化です。

---

静的劣化には、主に3つのパターンがあります。

**パターン1：データベースの肥大化**

SAPは毎日、膨大なデータを記録します。

受注データ、在庫データ、会計データ。

これらは蓄積され続けます。

削除されることは、ほとんどありません。

データが増えると、処理に時間がかかります。

最初はわずかな差です。

1年、2年、3年と、差は積み重なっていきます。

ぼくが見てきた現場では、3年運用したSAPのデータベースが、当初の設計容量の2倍になっていたケースがあります。

そのシステムは、毎月夜間処理が延滞していました。

「昔より遅くなった気がする」と言われ続けて、2年が経っていました。

**パターン2：夜間処理の肥大化**

SAPには、夜間に自動実行される処理があります。

在庫の集計、売上の締め、請求書の発行。

業務が増えると、夜間処理も増えます。

3年前は夜中の2時間で終わっていた夜間処理が、今は朝7時まで走り続けている。

でも、誰も気づいていない。

なぜなら、朝7時には「終わっている」からです。

ただし、ギリギリで。

その「ギリギリ」が毎月少しずつ広がっていくことを、誰も記録していない。

これが、静的劣化の怖さです。

**パターン3：運用知識の劣化**

一番厄介なのは、これです。

システムを知っている人が、会社を去っていく。

「あの人に聞けばわかった」という人が、10年でいなくなります。

残された人は、ドキュメントを見て運用します。

でも、ドキュメントは5年前に書かれたものです。

その後の変更は、誰かの頭の中にしかない。

こういう現場が、本当に多いです。

---

では、これをどうやって見つけるのか。

ぼくが「静的劣化診断」で見ているのは、3つだけです。

- データベースの空き率と増加速度
- 夜間処理の完了時間の推移
- 運用ドキュメントの最終更新日

この3つを見るだけで、システムの状態が9割わかります。

難しい技術は、使いません。

見方を知っているかどうかの差です。

---

最後に、1つお願いがあります。

今日、自社のSAPの夜間処理の完了時間を、1ヶ月前と比べてみてください。

延びていたら、黄色信号です。

3ヶ月連続で延びていたら、赤信号です。

それだけで、半年先の障害を防げる可能性があります。

「見方がわからない」「誰に聞けばいいかわからない」という方は、ぼくに連絡してください。

まず話を聞くだけでも、構いません。

---

前回の記事を読んでくれた方から、こんな反応をもらいました。

「52歳で副業を始めるの、すごいですね」

「でも、今さらじゃないですか？」

両方、正直な感想だと思います。

今日は、この「今さら」という言葉に、ちゃんと答えようと思います。

---

結論から言います。

ぼくが52歳で看板を出したのは、「今さら」だからではなく、「今しかない」からです。

---

少し、昔の話をします。

20年前、ぼくはSAPのシステム管理者になりました。

当時は「SAPが動き続けること」だけが仕事でした。

データベースの使用率を毎朝確認して、バッチが終わっているか確認して、障害が起きたら夜中でも対応する。

地味な仕事です。

でも、ぼくはこれが好きでした。

システムが静かに動いている朝、ちょっとした達成感がありました。

誰にも褒められないけれど、これがないと会社が止まる。

そういう仕事です。

---

ところが、20年経って、気づいたことがあります。

ぼくは、会社の外では「何者でもない」ということです。

名刺には会社の名前があります。

でも、名刺がなくなったとき、ぼくには何が残るのか。

52歳のある朝、そう考えました。

答えが、出ませんでした。

---

同じ頃、ChatGPTが出てきました。

最初は「なんだこれ」と思いました。

試しにSAPのエラーログを貼り付けて、「これ何が原因ですか」と聞きました。

30秒で、まともな仮説が3つ出てきました。

ぼくなら15分かかる作業です。

正直、ゾッとしました。

---

でも、その夜、もう一度考えました。

AIが出てきたことは、ぼくにとって「脅威」なのか。

それとも「武器」なのか。

ぼくの結論は、「武器」です。

理由は1つです。

AIには、20年分の現場経験がないからです。

---

AIはログを解析できます。

でも「このお客さんは3ヶ月後に大規模パッチ適用を控えているから、今の段階では軽微な対処で様子を見るべきだ」という判断はできません。

AIはSQLのチューニング案を出せます。

でも「この会社の情シス担当者は1人で、残業できない状況だから、長期間かかる改善案は提案すべきではない」という空気は読めません。

現場の「人間の事情」を読む力。

これはぼくの20年が作ったものです。

AIには、まだできません。

---

では、なぜ「今」なのか。

3つ理由があります。

**1つ目。会社員の安定は、もう保証されていないからです。**

ぼくは今も会社員です。

でも、50代の先輩たちを見ていると、早期退職の打診が来た人、部署ごとなくなった人、それなりにいます。

「定年まで安泰」という時代ではありません。

外に出たとき、ぼくには何があるのか。

今から準備しないと、間に合わないと感じました。

**2つ目。AIという増幅器が、初めて手に入ったからです。**

ぼくが副業を始めようとしたとき、いつも壁になったのが「時間」でした。

週10〜15時間しか使えない。

それで何ができるのか。

でも今は、Claudeがいます。

診断レポートの下書きを作る、提案書の構成を考える、議事録を整理する。

これらが、以前の3倍のスピードでできるようになりました。

時間の制約が、AIで崩れました。

**3つ目。52歳は、遅すぎない。でも、60歳は遅すぎるからです。**

これは正直な話です。

60歳から新しいことを始めるのは、できます。

でも、体力・気力・学習速度を考えると、今から始める方が明らかにいい。

8年後に「あのとき始めておけばよかった」と言いたくありません。

---

「今さら」という言葉は、たいてい、言っている側の言い訳です。

やらない自分を正当化するために、始めようとしている誰かに投げかける言葉です。

ぼくも、かつてそちら側にいました。

だから、気持ちはわかります。

でも、ぼくはもう、その言葉を受け取りません。

---

看板を出すと決めた夜、ぼくは1つだけ条件を自分に課しました。

「手を動かす仕事はしない」

夜間対応はしない。

実作業の代行はしない。

代わりに、頭を貸す。

判断を助ける。

予防を届ける。

これなら52歳のぼくでも、10年続けられます。

---

「かかりつけSAP医」という看板は、この考えから生まれました。

大病院ではありません。

派手な導入プロジェクトも、大規模なリプレイスも、ぼくの仕事ではありません。

町医者です。

月に1回、定期点検をして、何かあれば相談に乗る。

静かに、長く、信頼される存在。

それがぼくの目指す形です。

---

最後に、同世代の方へ。

50代で「今さら」と思っている人が、この記事を読んでいるとしたら、伝えたいことが1つあります。

「遅い」という感覚は、始める前にしか存在しません。

始めたあとは、「今日が一番早い日だった」になります。

ぼくは、始めました。

あなたはどうしますか。

---

（次回は「SAPが静かに劣化するとき、現場では何が起きているのか」について書きます。月曜の朝に届きます）

---

こんにちは、SAPの町医者｜ラスと申します。

52歳です。

SAP BASISという、裏方の裏方みたいな仕事を20年やってきました。

今日から、ここで書きはじめます。

最初に、結論から言います。

ぼくは、Claudeというアメリカの会社が作ったAIに、自分の仕事を半分以上奪われました。

そして、歓迎しています。

むしろ、もっと奪ってくれと思っています。

「は？」

と、思ったかもしれません。

普通、52歳の会社員が「AIに仕事を奪われた」と言ったら、その次に続くのは泣き言です。

「もう自分の時代は終わった」 「若い世代にはついていけない」 「退職金のことだけ考えています」

みたいな話です。

ぼくは、全部逆です。

AIに仕事を奪われたおかげで、52歳にしてやっと、自分の看板を出す決心がつきました。

その看板が、これです。

「AIで武装した、SAPの町医者」

少し、説明させてください。

ぼくの本業は、SAP BASISというものです。

SAPをご存じない方のために言うと、世界中の大企業が使っている、一番お堅い業務システムです。

トヨタも使っています。ソニーも使っています。日本の上場企業の多くが、SAPの上で在庫管理と会計をまわしています。

そのSAPには、表側（業務を動かす部分）と、裏側（システムの基盤）があります。

ぼくがずっと触ってきたのは、裏側の、さらに裏側です。

データベース。

システムが「重い」「止まった」「遅い」と言われたときに、呼ばれる役目です。

地味です。

夜中に電話が鳴ります。

誰にも褒められません。

でも、20年やってきたら、だいぶ詳しくなりました。

ところが、です。

去年あたりから、風向きが完全に変わりました。

ChatGPTが出てきて、Claudeが出てきて、Geminiが出てきて。

ぼくの仕事の、かなりの部分をAIが肩代わりしはじめたのです。

例えば、ログ解析。

20年前のぼくなら、エラーログを1行ずつ目で追って、パターンを探していました。

今のぼくは、Claudeに全部放り込みます。

10分で、原因の仮説が3つ出てきます。

例えば、SQL文のチューニング。

昔は分厚い本をめくりながら、試行錯誤していました。

今は、Claudeが「このインデックスが効いていません」と瞬時に指摘します。

正直、ゾッとしました。

52歳で、仕事がなくなる、と思いました。

でも、よく見ていくと、AIにもできないことがあるのです。

それは、「その現場の事情」を判断することです。

例えばAIは、SQLのチューニング案を提示できます。

けれど「このお客さんの夜間バッチは朝7時に絶対終わっていないといけない。だから、この改善は今夜やってはいけない」という判断はできません。

例えばAIは、ログから障害原因を推定できます。

けれど「この情シス担当者さんは、ここ3ヶ月で3回障害を起こしていて、もう上司の信用がない。だから、報告の仕方を変えないと、また怒られる」という空気は読めません。

現場の「人間の事情」を読む仕事は、まだAIにはできないのです。

それを20年、ぼくはやってきました。

ここまで整理して、ぼくは決めました。

AIと戦うのではなく、AIを武器にして、現場に入り直そう、と。

具体的には、2つやります。

ひとつ目。

SAPの劣化を「静的に」診断するサービスを作ります。

システムを止めずに、レポートだけで「この会社のSAPは、あと何年で障害を起こすか」を予測します。

これは、ぼく一人では時間がかかっていた作業です。

AIを使うと、3日で終わります。

ふたつ目。

「かかりつけSAP医」という立ち位置を作ります。

大病院ではありません。

町医者です。

月に1回、定期点検をして、何かあったら電話一本で相談できる存在。

手は動かしません。頭だけ貸します。

夜間対応はしません。日中の一次相談だけ受けます。

これなら、52歳のぼくでも、体力的に続けられます。

このSubstackでは、その過程を全部書いていきます。

上手くいったことだけではなく、失敗もです。

Claudeとの格闘記も書きます。

「今日はこのプロンプトで、こう返ってきて、全然ダメだった」 「このPythonスクリプトをClaudeに書いてもらったら、1時間かかった仕事が3分で終わった」

そういう話を、赤裸々に書きます。

なぜなら、同世代の人たちに「ぼくにもできた」と伝えたいからです。

ぼくより若い人には「50代でもこう戦えるのか」と知ってほしいからです。

そして、SAPのお客さんには「この人なら話が通じそうだ」と思ってもらいたいからです。

最後に、お願いがあります。

購読（無料）を、ぜひお願いします。

毎週1本、月曜の朝に、ぼくの「AIと格闘する記録」が届きます。

途中で「飽きたな」と思ったら、いつでも解除できます。

そのかわり、面白いと思ったら、周りの人に教えてあげてください。

52歳、SAP20年、AI格闘1年。

これから、ぼくの町医者としての旅がはじまります。

よろしくお願いします。

追伸。

近いうちに、「SAP劣化診断チェックリスト」を出す予定です。

SAPの現場で働いている情シスの方向けに、「自分のSAPがあと何年もつか」を自分でチェックできるリストです。

それまでは、ここで週1本、ずっと書き続けます。

楽しみにしていてください。

結果は、芳しくありませんでした。

====

SAP BASIS（SAPというシステムの基盤を支える技術領域）に携わって、約20年です。

大規模システムの障害調査、性能劣化の診断、データベースの深い部分。

その経験は、確かに積み上げてきたものだと自負しています。

だからこそ「発信すれば読まれるはずだ」と思っていました。

でも、現実は違いました。

20本書いても、反応はほぼゼロ。

「やっぱり自分には無理だったのかな」

正直、そう思いかけていました。

====

転機は、ある動画との出会いでした。

イケハヤ氏のマーケティング教材「明鏡」の中の、一本のレッスン。

「イケハヤ脳でコンテンツを制作する方法」

この動画を見て、ぼくは気づきました。

「コンテンツの量が足りないのではない。やり方が間違っていた。」

====

動画の内容を、ここで詳しくは書きません。

でも、一番刺さったエッセンスはこれです。

「専門知識をそのまま出しても読まれない。読者の言葉に変換して、はじめてコンテンツになる。」

ぼくは20年分の「SAPの知識」を書いていました。

でも読者が求めているのは「自分の仕事が楽になる情報」だったのです。

完全に、ズレていました。

====

それからぼくは、やり方を変えました。

Claude（AIアシスタント）を使い、自分専用の「イケハヤ脳エージェント」を構築しました。

イケハヤ氏の思考パターン、文体ルール、マーケティング哲学を学習させた、ぼくだけのAIアドバイザーです。

「読者視点で、専門知識を言語化する」

この一点を徹底するために、AIを相棒にしました。

====

だから今日、宣言します。

「Substackで100投稿チャレンジを始めます。」

Noteの20本は、失敗でした。でも、必要な失敗でした。

「何が間違っていたか」が分かった上での、再スタートです。

今度は「読者の言葉で書く」という軸だけをブラさずに、続けます。

====

これを読んでいるあなたに、一つ聞かせてください。

専門知識はあるのに、発信がうまくいっていませんか？

「書いても読まれない」「何が間違っているか分からない」

そのまま諦める前に、一度立ち止まって考えてみてください。

問題は「知識の量」ではないはずです。

ぼくも100投稿を通じて、その答えを探し続けます。

一緒に見届けてください。

====

【参考】ぼくが「やり方の間違い」に気づいたきっかけの教材

イケハヤ氏のマーケティング教材「明鏡」の中に、この動画があります。

「専門家の知識をAIでコンテンツに変換する方法」が、具体的に解説されています。

もし同じような壁を感じているなら、チェックする価値があります。

→ https://brmk.io/wu56BZ

※アフィリエイトリンクを含みます

====

次回は、「SAPシステムが”静かに壊れていく”パターン――20年の現場で見てきたこと」を書く予定です。

フォローして、続きを待っていてください。

====
#明鏡 #Substack #100投稿チャレンジ #副業 #情報発信 #AI活用 #コンテンツ制作 #SAP #専門家 #副業エンジニア