AI時代にIT業界に求められるスキルや人材は何か -実践編 #1-

前回の記事で、「AI時代にIT業界で求められるスキルや人材は何か」という問いに対して、資格ではなく実績、それも実際に動く仕組みを作り、運用し、改善したノウハウで示すしかない、という答えを出しました。

ただ、答えを出しただけでは何も証明したことになりません。そこで、すでに自分が開発・運用している水槽レイアウトシミュレーター「AquaDraft」を実践の舞台にして、実際にやってみることにしました。

今回はその第1回です。派手な自動化ツールを作った話ではありません。プロジェクトの企画書を作った回です。地味ですが、ここを飛ばすと後で必ず破綻します。

前回の記事はこちらです。「AI時代にIT業界に求められるスキルや人材は何か」という1万回は聞いた問いをAIと考えた。

前回の答えを、もう一段だけ具体的にしました

「資格ではなく実績で示す」は、言葉としては分かりやすいのですが、そのままでは作業に落とせません。明日から何をするのか、が決まらないからです。

そこで、実践の指針としてこう決め直しました。

資格が証明するのは知識です。それに対して、このプロジェクトで証明したいのは「AIに何ができて何ができないかを見極め、実際の仕事に組み込む判断力」です。判断力は試験では測れません。実際に組み込んで、動かして、失敗して、直したという記録でしか示せません。

そして、最終的なゴールをこう置きました。

「作業が楽になる」ではありません。「関与しなくても止まらない」です。ここは意識的に厳しく置きました。楽になることを目標にすると、少し楽になった時点で満足して終わってしまうからです。

ちなみに、このプロジェクトに関わる人間は自分ひとりです。チームもいなければ分担相手もいません。つまり「人間を減らす」と言ったときの対象は、最初から自分自身しかいません。減らしていった先に残るのは、自分がどうしても手放せなかった仕事だけになります。そこに何が残るのかを見たい、というのが正直な動機でもあります。

まずは現状把握から始めました

やりたくなる気持ちをこらえて、いきなり自動化の仕組みを作ることはしませんでした。先に現状を洗い出しています。

これはIT業界の仕事の進め方に合わせたものです。システムの改善は、いきなり作り始めるのではなく、まず「今どうなっているか」を洗い出すところから始まります。業界ではこれを現状分析、あるいは英語のまま As-Is と呼びます。今が分からないまま作ったものは、たいてい現場では使われません。

自分ひとりのプロジェクトでも、これは同じでした。むしろ、ひとりだからこそ頭の中にしか手順が存在せず、書き出してみるまで自分の作業内容を正確には把握できていませんでした。

そもそも、あまり時間がありません

最初に確認したのは、使える時間です。ここが自動化の前提条件になります。

• 2026年8月から新しい職場で働き始めたため、平日の日中はまったく作業できません
• 作業できるのは夜から深夜のみです
• 5月から7月までの3か月は時間が取れたので集中的に開発でき、6月は131回のコード更新を行いました。ですが、8月に入ってからの更新はゼロです
• 希望としては、最低でも週に1回は新しい素材を追加したいと考えています

もうひとつ、想定していなかった制約もありました。AIの利用量です。素材を1回追加するのに、Claudeの利用枠を3時間から4時間ぶん消費します。上限に達すると最大5時間待たされることもあります。つまり、ボトルネックは自分の作業時間だけではなく、AIの利用枠でもあるということです。自動化の設計にあたって、これは無視できない条件になりました。

いちばん重い業務は「素材追加」でした

AquaDraftは水槽のレイアウトを画面上で組めるツールなので、水草・石・流木・底砂といった素材が増えるほど価値が上がります。今のフェーズでは、この素材追加が運用の主軸です。

その手順を、実際に書き出してみたものが次の表です。

13工程あって、そのうち8工程が自分に集中しています。しかも前半にかたまっています。Claudeに任せられているのは、モデルを渡したあとの機械的な部分だけでした。

書き出す前は「そこそこ任せられている」と思っていたので、これは正直こたえました。実際には、いちばん時間のかかる調査と選定と素材づくりが丸ごと手元に残っていたわけです。自動化の余地は明らかに前半にあります。

告知は4つの場所に散らばっています

素材を追加したあとの告知は、次の4か所で行っています。

• X(旧Twitter)。日曜電遊劇場のアカウントと共用で、日本語の短文とハッシュタグ、画面キャプチャ1枚
• Facebook。AquaDraft専用ページで、日本語版と英語版を別々に投稿。カテゴリ別に整理した詳しい更新内容と、動画や画像を添付
• Pinterest。個人名義のボードで、海外向け。ただしピンは4件で止まっています
• 公式ブログ。アップデート告知、レイアウト作例、素材の解説記事

並べてみて分かったのは、これらが定常的な運用になっていないことでした。素材を追加したら必ず4か所すべてに出す、というルールは存在しません。媒体ごとに投稿の頻度も、言語の出し分けも、説明の詳しさもばらばらです。

ただ、ここには気づきもありました。この4か所に出す内容と、公式ブログの素材辞典記事は、結局すべて同じ材料から作られています。素材の名前、カテゴリ、特徴、追加日。この4つがあれば、Facebookの日英の更新内容も、Xの短文も、Pinterestの説明文も、辞典記事も生成できます。

いちばん危ないのは、バグに気づく仕組みがないことでした

ここが今回いちばんまずいと分かった部分です。

• 不具合の発見経路は、自分が目で見て気づくことだけです
• 利用者から不具合の報告を受け取る窓口が存在しません
• 気づくのはたいてい、新機能を追加したり別の不具合を直したりしたときの、ついでの確認です
• 自動テストは導入していません。テスト用のファイルは1つもありません
• 自動で品質を守ってくれているのは、プログラム言語側の型チェックと、書き方の誤りを指摘してくれるツールまでです

アクセス解析を見るかぎり、利用者がまったくいないわけではありません。それでも、声が届く経路がないので実質的に何も分かりません。

つまり、自分が手を止めた瞬間に、不具合の検知はゼロになる構造です。「自分がいなくても運営が回る」を目標に置いた以上、ここは絶対に埋めなければいけません。

そしてこれは、そのまま次の要件につながりました。人間が目で見て確認する運用であれば、変更したところを中心に見れば足ります。ですが、人を外すのであれば、操作の流れを最初から最後まで通しで自動確認する仕組みが要ります。IT業界では、こうした「今まで動いていた部分が壊れていないかを確認するテスト」を回帰テストと呼びます。人力確認のうちは「あったほうがいい」程度でしたが、自動化を目指すなら必須になります。

AIをどこまで信じるかを、先に決めておきます

ここからが、このプロジェクトの中核です。

「AIの能力を正しく判断する」を実際の運用に落とすため、これから発生するすべての作業について、着手する前に必ず次の4つのどれに当てはまるかを判定することにしました。

大事なのは、この判定を毎回記録に残すことです。判定そのものが、このプロジェクトの成果物になります。「AIに任せられる作業とはどういう性質のものか」は、やってみた回数だけしか分からないからです。

そして、この判定は一度決めたら固定ではありません。実際に運用してみて、思ったより間違いが多い、確認の手間がかえって増えた、ということが分かれば、カテゴリを引き上げて人間の関与を増やす方向に見直します。人間に戻す判断は後退ではなく、検証を経た正当な結論として扱います。

そのうえで、自動化の度合いを5段階で決めます

評価カテゴリが決まったら、実際にどう運用するかを次の5段階に振り分けます。

おおよその対応は、高信頼がA、中信頼がB、低信頼がCからD、自動化禁止がDからEになります。

「可能な限り人間を排除する」と言っておきながら矛盾するようですが、最初から動かさないと決めた項目が2つあります。本番環境への反映と、セキュリティに関わる変更です。ここを自動化すると、失敗したときに取り返しがつかず、そもそも検証のしようがなくなります。人間を残すこと自体が合理的な判断だと考えています。

もうひとつ、素材のクオリティ判定も人間に残します。AquaDraftはシミュレーターなので、素材が実物のイメージからかけ離れていたら意味をなしません。これは品質の根幹に関わる判断なので、自分の承認を必ず挟みます。

仕事の型に載せます

個人開発ではありますが、作業の流れは日本のIT運用現場で使われている型に合わせました。障害対応や変更作業を進めるときの、起票して、評価して、承認して、実施して、記録して、報告する、という一連の流れです。

大げさに見えるかもしれません。ですが、この型に載せないと後から検証できません。何をどう判断してAIに任せ、その結果どうだったのかを追えなければ、ノウハウとして残らないからです。

具体的には、発生した作業を次の順で処理します。

• 起票(きっかけの発生を記録する。コード更新、アクセスの異常、改善のヒントなど)
• 影響度とリスクの評価(高信頼・中信頼・低信頼・自動化禁止のどれかを判定する)
• 実施方針の決定(AからEのどの分類で進めるかを決める)
• 承認(分類ごとに、承認が要るか要らないかが決まる)
• 実施
• 記録(何をやったかのログを残す)
• 検証(想定どおり完了したかを確認する)
• 完了報告
• 振り返り(評価カテゴリと分類が妥当だったかを見直す)

承認の要否は分類によって次のように決まります。Aは承認不要。BはClaudeが下書きを作ったあとに自分が承認。Cは通常は承認不要で、条件を超えたときだけ自分に上がってきます。DはClaudeが起案して自分が承認。Eは起案から自分が担当します。

もうひとつ、報告のルールも決めました。運用をClaudeに任せる以上、うまくいっているのかどうかが自分に届かないと困るからです。異常が起きたときは即座に報告、正常に動いているときは週1回のレポートにまとめる、という形にしました。何もなくても毎回通知が来ると、そのうち読まなくなるからです。

6つの段階に分けて進めます

全体の進め方は、開発の工程に対応させて6段階に分けました。かっこ内は対応する一般的な開発工程です。

• 第0段階(要件定義)。企画と要求分析。今回の記事がここにあたります
• 第1段階(基本設計・開発)。最小限の動く仕組みを作ります
• 第2段階(追加開発)。課題の起案と改善案の抽出を自動化します
• 第3段階(追加開発)。告知やブログ記事の作成を自動化します
• 第4段階(運用設計・テスト)。監視と通知、そして自動処理が失敗したときの対処を組み込みます
• 第5段階(運用評価・振り返り)。効果を測定し、自分の関与がどこまで減ったかを数字で出します

ひとつ、まだ決めきれていないことがあります。第1段階で何を作るかです。当初は週1回の運用レポートの自動生成から始める予定でしたが、現状を洗い出した結果、いちばん重い素材追加の自動化を先に持ってくるほうが実態に合うかもしれない、と考えるようになりました。ここは次回までに決めます。

成果物はWordPressで管理します

最後に、地味ですが決めておいてよかったことを1つ。

このプロジェクトで作る資料や記録は、クラウドストレージではなく、WordPress上、つまりこのブログとAquaDraftの公式ブログで管理することにしました。理由は2つあります。

• アクセスを追いたいからです。WordPress上に置けば、すでに導入しているアクセス解析の対象になり、どの資料がどれだけ読まれたかをそのまま計測できます。外部のストレージに置くと、この計測が途切れます
• セキュリティ上、個人のクラウドストレージに外部からのアクセスを許可したくないからです。共有リンクを発行するということは、自分の個人アカウントの中に外部からの入口を作るということです。公開範囲の設定を1つ間違えると、その影響が個人の領域全体に及びます。そもそもそういう設計を採らない、と決めました

コードとスクリプトについては、これまでどおりGitHubで管理します。作業中の未公開ドキュメントは手元に置き、公開する段階でWordPressへ移します。

今回の成果物

この記事を書いたあとで、ここまでの内容を要求分析書、要件定義書、プロジェクト計画書の3つの文書にまとめ直しました。方針どおり、WordPress上に置いてあります。どちらも実際に作成したものを体裁ごとそのまま公開していますので、様式まで含めて見ていただけます。なお本文が「である調」なのは、社内で使う設計文書の様式に合わせているためです。

• AquaDraft Ops Automation 要求分析書(ADO-RA-001)。現行業務の棚卸し、課題12件、要求24件をまとめたものです
• AquaDraft Ops Automation 要件定義書(ADO-RD-001)。機能要件24件と非機能要件26件、受入基準、トレーサビリティマトリクスを収録しています
• AquaDraft Ops Automation プロジェクト計画書(ADO-PP-001)。Phase 0からPhase 5までの全体スケジュール、タスク一覧、マイルストーン、KPI、今どこで止まっているかをまとめたものです

次回に向けて

今回やったことをまとめると、次のとおりです。

• 「資格ではなく実績」を、AIの能力を判断して組み込み人間を排除する、という実践方針に置き換えた
• ゴールを「自分がいなくてもAquaDraftの運営が回ること」に設定した
• 現状を洗い出し、素材追加の13工程のうち8工程が自分に集中していること、バグの検知経路が自分の目視しかないことを確認した
• AIの評価基準を4カテゴリ、自動化の度合いを5分類として定義した
• 作業の進め方を、IT運用現場の型に載せた
• 成果物の管理先をWordPressに決めた
• ここまでの内容を、要求分析書と要件定義書とプロジェクト計画書という3つの文書に書き出して公開した

正直に書くと、今回いちばん収穫だったのは自分の作業を書き出したことでした。任せられていると思っていた業務が、実際にはほとんど手元に残っていた。この事実は、書き出すまで見えていませんでした。

次回からは、実際に手を動かします。第1段階で何を作るかを決めて、動くものを組み、そこで何が起きたかを書きます。AIが判断を誤った話も、任せたつもりが確認の手間が増えた話も、そのまま載せる予定です。うまくいった話だけを並べても、ノウハウとしては何の役にも立たないからです。