Webサイト制作の個人史やWebサイト制作の個人史２で書きましたように、私はAutomate the Boring Stuff with Pythonを読んで感動し、自分の仕事に生かしてきました。
2025年の中頃に第3版が著者ページAutomate the Boring Stuff with Pythonで公開されたので、日本の読者に広めるために、また自分の参照用として、この本を本腰を入れて訳そうと決意しました。
なるべく早く完成させたいと思っております。
浅野直樹の学習日記
この画面は、簡易表示です
私のLLMとの付き合い方
ChatGPTに代表されるLLMが数年前から急速に普及し、もはや生活の一部になったと言っても過言ではないでしょう。
私はITエンジニアやプログラミングスクール講師としてLLMに触れる機会が多いです。
情報がまとまった書籍もいくつか出版されてきたのでそれらを読み、自分なりのLLMとの付き合い方が見えてきたので、ここにまとめます。
１．LLMをどう捉えるか
（１）教科書的な説明
AIに関しては楽観論から悲観論まで幅広い意見が分布していますが、LLMの実像を正確に捉えることが何よりも重要です。
LLMは、コンテンツを生み出すAIである生成AIのうち、言語に特化したものです。
LLMを含むAIは、魔法のように推論や創造をしているように見えますが、コンピュータによる計算結果です。
およそどのLLMの解説本にも書いていますように、LLMは、インターネット上のテキストを学習して、与えられた単語（トークン）の次にはどの単語（トークン）が続きやすいかを確率的に判断して文章を生成します。
「吾輩は」と来たら「猫である」と続く確率が高いといった判断です。
LLMはこれに尽きます。
LLMは記号接地しておらずサールの中国語の部屋のようであるという、記号接地問題 ～AIは言葉の意味を理解できるのか？～ ｜NTS Journalで示唆されている見解に私も賛同します。
（２）私個人の捉え方
個人的には、LLMを、インターネット上の知識を備えたワープロのようなものだと捉えています。
ワープロが出始めた頃に活字の価値が急速に下がった違和感と、LLMが出始めた頃に流暢な文章の価値が急速に下がった違和感が似ているからです。
ワープロ登場以前の活字といえばしっかりとした重要な内容であること請け合いでしたが、ワープロが普及するとくだらない内容でも簡単に活字にすることができるようになり、混乱した記憶があります。
それと同じように、LLM登場以前は流暢な文章は内容も優れているだろうと推測できましたが、LLM普及後は流暢な文章でも内容の伴わないものが目立つようになりました。
その最たる例がハルシネーション（幻覚）と呼ばれる事実に基づかない内容です。
ワープロの普及期に活字の価値を補正したように、メールやレポートが流暢だからといって内容が伴っているとは限らないと流暢さの価値を補正しなければなりません。
ITエンジニア（プログラミング）の世界に限定すると、アセンブリ言語→コンパイラ言語→スクリプト言語と高水準の記述ができるようになってきた延長線上にLLM言語を位置づけています。
スクリプト言語が普及してもアセンブリ言語やコンパイラ言語がなくならなかったように、LLM言語が普及してもスクリプト言語はなくならないと読んでいます。
（３）LLMに適した仕事
インターネット上の情報を見放題で無限の時間を使えばできるような仕事がLLMに適しています。
アイデア出し、翻訳や要約など文章やフォーマットの整形、感情や分野の分類、定型的なプログラミングコードの生成などです。
司法試験の合格水準に達したと聞いても驚きはないです（インターネット上の情報を見放題で無限の時間を使えば司法試験に合格できると思うので）。
LLMは数学や推論が苦手だというのも、上記のLLMの捉え方からすると頷けます。
２．「正しさ」について
（１）一般論
上記のLLMの特性からすると、LLMが出力する内容が正しいとは限りません。
ハルシネーション（幻覚）は言うに及ばず、誰かが確かにそのような内容をインターネット上に書いているという事実水準では正しいとしても、その内容が正しい（真である）とは限りません。
よって、出力結果を見て自分で正しさを判定できない場合にLLMを利用するのは危険であると私は考えます。
推論や判断、政治学や経済学のような人文社会科学がそれに該当します。
逆に、出力結果を見て自分で正しさを判定できる場合には、安心してLLMを利用できます。
度忘れしてしまったけれども見たら再認できる内容や、文章に書かれた内容を表形式に変換するといった作業です。
プログラミングと、翻訳などの言語的なタスクについては微妙な点があるので以下で個別に論じます。
（２）プログラミング
プログラミングも動かしてみればすぐに結果がわかるので、基本的には出力結果を見て自分で正しさを判定できる場合に含まれると考えて差し支えないでしょう。
正しいプログラミングは動作するプログラミングです。しかし、逆は必ずしも真ならずで、動作するプログラミングが正しいプログラミングであるとは限りません。
例えば、動作はするけれども副作用があるプログラミングや、動作はするけれども非常に読みにくいプログラミングは、正しいとは言い難いです。
よって、LLMに頼り切るのではなく、LLMの出力を理解して微調整して使うべきだと私は考えます。
（３）言語的なタスク
多くの人が使っていてそれっぽく見える表現は正しいのだと割り切ってしまえば、言語的なタスクでLLMは大活躍します。
２つの似たような表現をGoogleで検索してヒット数の多い表現が正しいとするような考え方です。私は大学生のときに言語学関係の授業でそのような考え方に触れて衝撃を受けました。
英語（外国語）でビジネスメールを書くときにLLMに添削してもらい、あまり使われない表現をよく使われる表現に直してもらうといった使い方ですね。
他方で、出現頻度は高くないけれどもより適した表現があるのではないかという場面ではLLMに頼るのは避けたほうがよいでしょう。
親密な間柄でのメールや、内容を理解した上で英語（外国語）から日本語（母国語）へ翻訳する場合などは、出現頻度が高くても正しいとは限らないので、LLMの出力結果を丸ごと採用することにはならないでしょう。
３．自分がLLMを使う場合
この記事でのここまでの記述から想像できますように、私がLLMを使うのは、プログラミングでインターネットを検索して調べる手間を省きたい場合や形式の変換をしたい場合、一般的によく使われる言語表現を知りたい場合です。
具体的には、Pythonで日付のフォーマットを調整したいときや名前とメールアドレスのダミーデータがほしい場合、英文ビジネスメールで妥当な表現を知りたい場合などです。
私は実際にコードを書く時間がさほど多くないので、AIコーディングエージェントは使わず、ブラウザからChatGPTやGeminiを呼び出して使っています。
業務のうちで調査や設計、教育指導の占める割合が高く、LLMの恩恵をまだそこまで受けられていない（LLMに仕事を奪われない）印象です。
４．顧客にLLMを使ってもらう場合
顧客にLLMを使ってもらう場合は、API経由でLLMを呼び出すコードを書くのが私の仕事であることが多く、その点ではLLM登場以前の業務と同じです。
顧客はLLMを魔法のように何でも解決してくれるツールだと捉えていることが多いので、そうではないと説明するのも私の仕事です。
顕著なのはリアルタイムの情報で、普通にLLMを使うとリアルタイムの情報は使えないことを説明し、ブラックボックスではありますがAPIでオプションを設定することによりリアルタイムの情報を得るか、従来型のプログラムで情報を取得してからプロンプトに盛り込む（RAG）かを提案します。
顧客あるいはプログラミングスクールの受講生がLLMでプログラミングコードを生成したのはいいけれども、思うように動かなくて困ったと相談を受けることも多いです。そういうときは概念を整理しながら解決していきます。
現実的に妥当な設計をしてからLLMを利用するとたいていうまくいきますが、設計が曖昧なままLLMへの質問を繰り返すと道に迷いがちです。どれだけがんばってもHTMLだけでは本格的なウェブアプリは作れませんし、スマホ利用を想定するからといってSwiftとJavaで開発するのが最適解とは限りません。
ローカル環境だけでプログラムを書いたら、そのローカルPCの電源が入っていないときにプログラムの実行はできませんし、ほかのユーザーがインターネット越しにそのプログラムを呼び出すこともできません。
プログラムが小さい段階ではLLMの出力結果をよくわからないまま貼り付けても動いたのだけれども、プログラムが大きくなるにつれてコードがぐちゃぐちゃになり手が付けられなくなったという状況を目にすることもあります。変数名をわかりやすくして同じ処理は一箇所にまとめて繰り返さないといった、プログラミング学習にまつわる雑感（コーディング原則本等の自分なりのまとめ）で書いた内容を念頭にリファクタリングするのが私の仕事になることもあります。
ある程度の一般的なリファクタリングであればLLMに任せることもできるでしょうが、ビジネスに固有の命名であったり自分にとって最高にわかりやすい整理などは人力でしなければならないのではないかと感じます。
５．参考文献
 | LLMのプロンプトエンジニアリング : GitHub Copilotを生んだ開発者が教える生成AIアプリケーション開発 作 者： 出版社： オライリー・ジャパン 発売日： 2025年06月10日 |
LLMを原理的に説明してくれます。この記事は本書に依拠しています。
 | 大規模言語モデルを使いこなすためのプロンプトエンジニアリングの教科書 作 者： 出版社： マイナビ出版 発売日： 2024年04月05日 |
Pythonのような従来から存在するプログラミング言語と合わせてLLMの全体像を把握するのに有用です。
 | プログラミング知識ゼロでもわかるプロンプトエンジニアリング入門 作 者： 出版社： 秀和システム 発売日： 2025年04月30日 |
推論を重視した小手先のテクニックの紹介が多い印象ですが、LLMの特徴がわかります。
 | 生成AIアプリ開発大全 : Difyの探求と実践活用 作 者： 出版社： 技術評論社 発売日： 2025年04月10日 |
Difyというノーコードツールという切り口からLLMを眺められます。
cronの出力をslackに通知するシンプルな方法
cronを使うとコマンドやスクリプトを定期的に自動実行できるので便利です。
自動実行ですから、少なくともエラーが発生した場合には通知を受け取りたいです（通知がないとエラーが発生していても気づかず放置してしまいがちです）。
cronで実行するスクリプト内に通知を行うコードを書くことが多いですが、そもそもそのスクリプトが実行されなければ通知もされません。
cronにはデフォルトでエラーを含む出力をメール通知する機能が備わっています。
しかし、外部にメールを送信できるようにサーバーを構築するのは面倒なので、slackに通知しようというのがここでの問題意識です。
その方法を調べると、いろいろなやり方が出てきて混乱したので、なるべくシンプルな方法をここにまとめます。
１．事前準備（slackに通知をするシェルスクリプトを用意する）
事前準備として、標準入力から受け取った内容をslackに通知するシェルスクリプトを用意します。
標準入力からの受け取りやjsonの組み立て、特にダブルクォートのエスケープに苦労しつつも、最終的には次のシンプルなシェルスクリプトに落ち着きました。
webhookurlはご自身のものを指定してください。
#!/bin/sh
webhookurl='https://hooks.slack.com/services/XXXXXXXX/YYYYYYYY/ZZZZZZZZ'
stdin=$(cat)
message=$(jq --arg text "$stdin" -n '{text: $text}')
curl -X POST -H 'Content-Type: application/json' --data "$message" "$webhookurl"ここでは、このシェルスクリプトを、/usr/bin/local/slack_notification.shという名前で保存し、パーミッションを755に設定します。
２．ジョブごとに通知を設定する
ジョブの出力をパイプでslack通知スクリプトに渡せば、ジョブごとに通知を設定できます。
この記事では、実験のため、エラーが発生しないecho "cron slack test"とエラーが発生するnotexistingcommandを例に取ります。
標準出力と標準エラー出力の両方を通知するcrontabの例
* * * * * echo "cron slack test" 2>&1 | /usr/local/bin/slack_notification.sh
* * * * * notexistingcommand 2>&1 | /usr/local/bin/slack_notification.sh標準エラー出力だけを通知するcrontabの例
* * * * * echo "cron slack test" 2>&1 1>/dev/null | /usr/local/bin/slack_notification.sh
* * * * * notexistingcommand 2>&1 1>/dev/null | /usr/local/bin/slack_notification.sh３．一括で通知を設定する
cronで実行するジョブの数が少なければジョブごとに通知を設定すればよいのですが、たくさんのジョブをまとめて通知の設定をしたい場合は、cronにデフォルトで備わっているメール通知を活用すると楽です。
この方法では、メールの件名に実行コマンドが書かれているなど、詳細情報を取得できるという利点もあります。
postfixをインストールして、/etc/aliasesにcronslack: |"/usr/local/bin/slack_notification.sh"を追記し、newaliasesコマンドを実行します。
詳しくは「postfix スクリプト」などと検索してください。
標準出力と標準エラー出力の両方を通知するcrontabの例
MAILTO=cronslack
* * * * * echo "cron slack test"
* * * * * notexistingcommand標準エラー出力だけを通知するcrontabの例
MAILTO=cronslack
* * * * * echo "cron slack test" 2>&1 1>/dev/null
* * * * * notexistingcommand 2>&1 1>/dev/null ４．細かい話
crontabの実行結果をSlackで受け取る方法 | 北進総業と問題意識を共有していますが、私は既存のcronをなるべく変更せずにcronの記載自体から何をしているかわかるようにしたかったので、上に書いたような方法にしました。
【AlpineLinux】Cron(busybox)でMAILTOを指定してもメールが届かない件 – TokunagaKazuya.tkとか、sendmailコマンドを差し替えて、sendmailコマンドにくるメールをSlackに投稿する #Docker – Qiitaとか、cronの出力をメールでなくSlackに送る方法 #Slack – Qiitaとか、みなさんが書かれているいろいろな方法を参考にしました。
スクリプト言語に頼らずUNIX哲学に則った解決法を見出だせたのではないかなと思っています。
ITエンジニアとしてのプロフィール（２）ポートフォリオにつながる話
私のITエンジニアとしてのポートフォリオにつながるプロフィールを箇条書きにするなら以下のとおりです。
- ２０００年代初頭にホームページを作成した
- PCを自作した
- ２０１０年頃にPerlとJavaScriptを使って動的なサイトを一から作成して実際に利用した
- ２０年以上塾講師の仕事をすることにより英語と数学を鍛えてきた
- Linuxを１０年以上利用している
- WordPressで構築したブログに学習記録を蓄積してきた
- 日常的なデータをSQLで管理する仕組みを作った
- スクリプト言語（PerlやPython）で業務を効率化してきた
- 法律や経済に関係する仕事をしたことがある
- LaravelとDjangoでWebアプリをいくつか作った
- AWS、Google Cloud（GCP）、Firebaseなどのクラウドサービスを利用しながら勉強中
- エンジニアの業務に加えてIT翻訳やプログラミングスクールの講師をしている
以下は物語形式です。ITエンジニアとしてのプロフィール（１）昔話の続きです。Webサイト制作の個人史とWebサイト制作の個人史２を前後の話も加えて再構成しました。
大学１回生のときに、半期でホームページを作るという授業を取りました。HTMLとCSSが未分化だった時代ですから、太字にするなどの装飾のためにHTMLタグを使いました。出身地の紹介ページを作る学生が多い中、私は国語や数学などの勉強法を書いたページを作りました。今とやっていることが変わりませんね…。必修科目というわけでもなく、興味本位の軽い気持ちから参加したのですが、まさか後々これを仕事にすることになるとは思ってもみませんでした。何がどうつながるかわからないものです。
そこで得た知識を活用して茨木高校陸上部ＯＢ会のホームページを作りました。そのhtmlファイルを発掘したので、当時の雰囲気を味わうために貼り付けます。
最終更新から計算すると２０年以上前ですね。左上の領域には何があったのでしょうか。アクセスカウンターだったような気がします。
掲示板はWEB PATIO : KENT-WEB CGI/Perl フリーソフトの古いバージョンだと思われます。パーミッションに悪戦苦闘しながら試行錯誤を繰り返してどうにか設置した記憶が蘇りました。
同じ頃にPCを自作しました。夏休みにアルバイトに精を出して貯めた約１０万円を握りしめて大阪の日本橋に行き、一日でパーツを買い集め、次の日には使える状態にしました。AMDの1.3GHzくらいのCPUで、メモリは忘れましたがハードディスクが40GB、OSはWindows XPです。ブラウン管のテレビに画面出力しました。動いたのが奇跡だと感じました。このときの経験がインフラエンジニアとしての仕事の原点になっています。
ここで私のマシン遍歴をまとめます。自作PC→HPのノートPC（型番は忘れました）→ThinkPad X40→ThinkPad X220、以上です。ThinkPad X220を１０年以上使っています。キータッチが気に入っていて、この記事もそのキーボードで入力しています。メモリとストレージを増強すれば、今でも現役で十分使え、現に私はこのマシンで仕事をしています。軽量のLinux（Linux Mint 21 Xfce）を使っているおかげとも言えます。
茨木高校陸上部ＯＢ会のホームページを作ってからしばらくの間は、本格的なITエンジニアとしての活動をしませんでした。学業と塾講師を中心とするアルバイトに力を入れていました。今から振り返ると、英語と数学に取り組むことで、ITエンジニアとしての足腰を鍛えていたことになります。また、WordPressやその他サービスのブログ記事を投稿したり、動画の編集をしたりと、ITサービスやソフトウェア利用者としての活動は積極的にしていたほうなのではないかなと思います。
次の転機は京都アカデメイアサイトの制作です。２０１０年頃に当時の大学院生を中心に立ち上げた団体です。ホームページ作成の経験があるということで、私がサイト制作担当の中心になりました。最初はよくわからないままに先輩から教えてもらったDreamweaverでいじっていました。しかしそれでは掲示板などの機能が作れないと気づき、F先生の教えを受け、PerlでMVCモデルに則ったWebサイト（Webアプリ）を作るところまで到達しました。
この図もまた当時の雰囲気をよく伝えてくれます。デザインはさておき、動きのあるサイトを最初から作って実際に公開して利用したという経験は大きいです。サーバー、データベース、バックエンド、フロントエンド（JavaScript）といったWebサイト（Webアプリ）の全体像を掴むことができましたし、顧客（メンバー）の希望により苦労してイベントカレンダーを作り上げたのに入力が面倒だという理由ですぐに使われなくなったという、ありがちな経験をしたのもエンジニアとして仕事をする上での財産になっています。
このときに開発環境としてLinux（Ubuntu）を導入したことが人生を変えました。最初はWindowsと併用していましたが、徐々にLinuxの比重を高めてきました。日常的にLinuxを使っていると、本格的な開発業務をしていなくてもトラブル解決のためにLinux関係の事柄を調べますし、ちょっとしたテキスト変換などをプログラム的に解決しようという発想になります。塾講師の仕事で使う数学の教材をLaTeXできれいに作ったりもしました。
WordPressで構築したブログに学習記録を蓄積し始めたのもこの頃です。更新頻度は決して高くありませんが、長い期間にわたって多様な分野で苦闘してきた記録はあまり類例を見ないのではないでしょうか。初期に書いた記事の中では、残業代をエクセルで計算するの反響が大きかったです。
日常的なデータ管理にもSQLを使うようになりました。小さな団体の会計管理にはLibreOfficeのCalc（Microsoft Excelに相当）とBase（Microsoft Accessに相当）が適していて、今でもそれらを使って管理しています。わざわざ大規模な会計ソフトを導入しなくても、LibreOffice Calcのマクロで仕訳帳から総勘定元帳を作成するのようなミニマムな機能でいいと思っています。
ただし、現状ではLibreOfficeのCalcと比べてMicrosoft Excelのシェアが圧倒的ですから、顧客の依頼を受けて仕事をする場合はExcelを使うことが多いです。私が初めて対価を得たエンジニアの仕事は、ExcelのVBAとLibreOffice Baseを連動させて従業員の勤怠と利用者の送迎の座席などを管理するシステム制作でした。Microsoft Accessを持っていないということだったので無料でインストールできるLibreOffice Baseにしました。業者の見積もりが高すぎると相談された知り合いからの依頼でした。顧客が求めているのは、案外、見栄えがよくて汎用的だけれども高価なシステムではなく、地味だけれども安くて使えるシステムなのかもしれません。
事務員として勤務しながら自分の業務をPythonで効率化することにも取り組みました。別の人が作ったシフト表から、元請けが求める形式のExcelファイルへと、データを転記するためのプログラムなどを書きました。毎月わざわざ間違えやすいのに手でそのような作業をするのが嫌だったのです。また、業務記録を入力するExcelファイルが使いづらくよく壊れていたので（関数部分を触ってしまって壊れたのでしょう）、Djangoで入力システムを作りました。機密データを取り扱っていましたから、インターネットに接続して利用するのではなく、USBメモリに保存したSQLiteからデータを読み込んでローカルで起動する仕組みにしました。入力インターフェイスとしてブラウザを利用したかったので、Djangoで開発しました。当時はリファクタリングという概念を知らず、ぐちゃぐちゃのコードでしたが、自分で使う分にはどうにかなりました。
私は経済や法律に関係する仕事もしてきたので、その分野に関わるプログラムやアプリケーションを作ることに強みがあります。IT×○○というかけ算の力ですね。ビジネスドメインの知識を持っている人がプログラムを書くと無駄なく早いです。コードを書ける経理担当者として、給与計算をしてから給与明細を自動でメール送信するシステムを自分で作って使っていると（GASで宛先ごとに添付ファイルを差し込みメール送信する）、いざ定額減税が導入されても既存のコードを少し書き換えるだけで対応できました。
次の転機は２０２０年頃に訪れました。知り合いに誘われてWebアプリの開発を目指すスタートアップでエンジニアの業務を行うことになったのです。これまでの流れから、Perlを使ってGoogle, Yahoo, Facebook, Twitter, LINEの5種類のソーシャルログインまで実装したり、Gitを使ったほうがいいと中途半端に聞いてVPSに自前のGitリモートリポジトリを構築したりと、今から振り返ると努力の方向が間違っているように思われて仕方ありませんが、必死で食らいついていきました。さすがに途中で方針転換してLaravelを使うようになり、Vue.jsを導入して、リモートリポジトリにはGitHubを用い、Dockerを活用するようになりました。最終的には、Google Cloud（GCP）上のKubernetesで動くサービスを構築し、CypressのE2Eテストを実行して、GitHub ActionsによりCI/CDを実践するまでになりました。エンジニアは私一人で曲がりなりにもそこまで到達したのは奇跡的です。
それからはプログラミングスクールのインストラクターとして教えるために必要な技術をキャッチアップし、知人やクラウドソーシングサイトを通じて受けたエンジニア案件の仕事を完成させ、興味のおもむくままに新しい技術を学ぶなどして、現在に至ります。書き始めると脱線が多くなってしまったので、ポートフォリオはまた改めて別にまとめたいです。
ITエンジニアとしてのプロフィール（１）昔話
塾講師としての仕事を念頭に置いて１０年以上前に書いたプロフィールはありますが、現在主に従事しているITエンジニア関係の記述が薄いので、ITエンジニアとしてのプロフィールを書きました。
１９８２年生まれで、いわゆるデジタルネイティブ世代ではありません。コンピュータとの関わりはこの世代の平均的な姿だと思います。
初めて本格的に触ったコンピュータはファミリーコンピュータです。ビデオゲームの代名詞と言えるあのファミコンです。ドラゴンクエストIVが発売されたくらいの頃で、私は小学生でした。当時はインターネットが普及していませんでしたが、カジノで８３８８６１枚のコインを４ゴールドで買えるとか、８回逃げたら常に会心の一撃が出るようになるとか、口コミで伝わってきました。それがオーバーフローによるものだと理解したのは最近のことです。また、ドラゴンクエストIIIでは、マドハンドが現れたときに洗濯バサミでコントローラーのAボタンをずっと押しっぱなしにして一晩放置すれば勝手にレベルが上がるのではないか、と試行錯誤した思い出があります。これは業務効率化のための自動化処理に通じる考え方です。
私が小学生の頃と言えば、「コンピュータ」が社会科の教科書で習うような用語でしたし、ファミコンを除けば身の回りのコンピュータは銀行のATMくらいでした。社会見学で郵便局に行き、ハガキを大きな機械に入れると手書きの郵便番号（当時はたったの３桁でした）を読み取って自動的に仕分けをするのを見た記憶があります。最先端のハイテク機械を見学するという文脈でした。今では手書き数字の分類は機械学習の入門的な内容ですから（scikit-learnでMNIST手書き数字の分類機械学習）、時代が進んだものです。
時代の進化ということでは、当時導入されつつあった図書館の検索システムが思い出されます。ある時、地元の公共図書館にコンピュータ検索システムが導入されました。これは画期的なシステムだったのですが、大きな欠点がありました。「あ」などの短い文字を入れて検索すると、数十分から数時間程度、検索中の状態になって操作を受け付けなくなってしまったのです。そのような状態になってしまったコンピュータについては、図書館職員の方が「調整中」のような紙を用意して画面を隠していました。現代の水準で考えると、文字数でバリデーションをする、タイムアウトを設定するなど、初歩的な対応をすぐに思いつきますが、当時はそれなりの規模の市の公共図書館でもそれくらいのレベルだったのです。牧歌的な時代ですね。
当然学校でコンピュータや情報を本格的に習うはずもなく、かろうじて中学校にはコンピュータ室がありましたが、背景が黒い画面によくわからないまま文字を打ち込む授業があったくらいです。おそらくMS-DOSだったのではないかと思います。中学数学で習う公式が適用できない不規則な形の閉じられた図形の面積を、ランダムに表示したドットの数から推計するデモンストレーションを技術の先生がしてくれたことに感動したのは妙によく覚えています。モンテカルロ法による求積ですね。コンピュータを使って力ずくで問題を解決するという、これまでとまったく異なる発想に魅力を感じたのです。
高校ではそのレベルの授業さえありませんでした。オタクっぽい友人が自分で作ったホームページを学校の図書室からインターネット接続して見せてくれたことがあるくらいです。トップページの入口となっている画像をクリックするとリンクされたページがいくつかあるような、初期に典型的なホームページです。私は携帯電話を持つのが遅かったほうで、高校を卒業する直前（２００１年）にようやく携帯電話でメールを送れるようになりました。このあたりの事情は私の業務効率化ツールとの付き合い方でも触れました。
パソコンを使い始めたのもその頃で、初めて本格的に触るようになったPCのOSはWindows Meでした。定期的にデフラグをしても起動に数分以上かかりました。インターネット接続は関西電力が提供していたeo64エアで、月３千円で時間を問わず使い放題でした。テレホーダイとは異なり時間を問わず使い放題だったのは、夜が苦手な私にとってありがたかったです。
公式サイトを探したければエキサイト、カテゴリから階層をたどるならヤフー、単語を入力して検索するならgooのように使い分けていたような気がします。IT関係の事柄でも雑誌から情報を得るのが主流で、ネットランナーとかその手の雑誌の付録CD-ROMからソフトをインストールした覚えがあります。ソフトのダウンロードは窓の杜からもしましたし、とほほのWWW入門を読んでホームページを作ろうとしました。
昔話が長くなってしまったので、ここで一旦区切ります。ITエンジニアとしてのプロフィール（２）ポートフォリオにつながる話に続きます。