今日は新人向け研修。いつもより一時間以上早く出勤。

20人以上の新人ディレクターを対象に、実際のシステムにログインさせて、ダミーデータの取り込み、画像の生成と調整、そしてAI音声、動画の作成まで、体験してもらうプログラム。

新人研修、さまざまな項目があるのだけど、パワポの資料投影されて話を聞く座講みたいなのばかりなので、ぜひ、制作作業の実体験ができるものをカリキュラムに入れたい、という事務局からの要望。もちろん、我々の業務の重要性もあるのだけど、システムの先進性とこれまでのDXの有効性が評価されてのこと。我々の前のコマが座講で20分ずつ、みたいなところ、ドーンと1時間半も割り当てられた。これは非常に光栄なことなので、それに恥じないように、面白く有意義なものにしないといけない。

最初の30分、山口の先輩が上京して、実際の動画もうまく使ってたっぷり笑いも取りながら、業務の概要を説明。残りの1時間が私の担当。

社内の多くの制作系システムはoktaというID管理システムで権限付与の管理をしているのだけど、まだ実業務をしていない新人たちのパソコンはその辺りが真っ白。今回の研修のために、事務局を通じて、自分で登録認証とか済ますようにお願いしてある。そしてそれを確認して、こちらでシステムの権限を付与。ただ、そういう準備をしてあるからと言って、研修本番で参加者全員が無事システムにログインできる、と考えるのは甘い。必ず何人か「入れません！」という人間が出るものだ。今回の研修は全員ログインさせることが目的ではなく、あくまで操作を体験することにある。なので、あらかじめ、新人を4人ずつのグループに分けて、そこに外付けの大型モニターを用意し、一人のPCを繋いで4人で一緒に作業をする設定にしてある。つまり4人グループの一人がシステムに入れれば、つつがなく研修が進行できる。このような形の研修は我々も初めてなので、経験もないし、慣れていない。でも、初めてだからと言って、進行でまごついたり、途中で止まってしまうのは超カッコ悪い。プロとは言えない。なので、あらゆる想定をして、対策を施して、順調に進行させないといけない。こういう実地研修で進行側がシステムの不調で「あれっ？あれっ？」とかやると、新人に「この会社大丈夫かな？」と疑念を持たせてしまう。ただ現実にはこういう研修でそういうみっともない様子を見ることは残念ながらとても多い。（笑）私はそういうカッコ悪いのは嫌なので、準備は入念に尽くすタイプ。

おかげで研修は完璧に制作体験が全員できて、新人君たちから、感嘆の声を多数もらえた。いやいや、ほんとホッと一安心。ようやく肩の荷が降りた。そして大変疲れた。

大仕事を片付けたので、もう帰ってもいいのだけど、今日は池袋のジュンク堂へ。ここ1〜2ヶ月、集中して色々考えて検証して来たAI関連について、「答え合わせ」が必要だと感じたからだ。世の中の先進的な人、そして多分一般的な人に比べても、AIに関しては、周回遅れくらいだという自覚があった。追いつくために、書店に並ぶハウツー本を片端から読む方法もあったけど、あまり私の趣味に合わないので、まず自分でいじり倒す方法を選んだ。その中で、こういう使い方がいいのか？こんなことにも使える？というのを自分なりに考えた。アプリを作ってみたのも、そういう試行の一つ。それを踏まえて、書店に行き、平積みのAIハウツー本を片端から開いて、「AIはこう使え！」みたいなところを読んだ。だいたい私が考えたことと同じような内容が出ていた。自分で考えた方向性は多分間違っていないと思う。

そして今日はコンピュータ関係のフロアも時間をかけて見た。読んだ、ではなく「見た」が正確。（笑）pythonのコーナーは、Ｃ言語とかJavaよりも大きい。なるほど。ただアプリは作ったけど、プログラマーになる気は無いので、読んでもね。こういう本、基本的にプログラマーが、プログラマーを目指す人向けに書いているものだから、門外漢にはあまり意味はない。「すぐに使えるコード付き」とか中には書いてあるけど。

フロアを歩いていて、ちょっと気になったのは「要件定義」という言葉が入った本がたくさんあること。これはプログラムを作る以前に顧客が求めているものはどんなものか、しっかり固めるための技術やテクニックで、最近のプログラム開発ではとても重要視されるようになっているらしい。この言葉になぜ私が違和感を感じたかというと、今回、自分でAIに指示を出してアプリを作る過程で、「要件定義」というワードを全く意識しなかったからだ。というか、私がAIに出していた指示そのものが、実はほとんど要件定義だけだったかもしれない。どうもプログラム開発の現場では「顧客 → 営業 → PM → 設計者 → プログラマー」と伝言ゲームが行われる過程で情報の劣化が発生しトラブルが起きることが多いらしい。そもそも顧客の方で、作って欲しいもののイメージを正確に示せてなかったり。その結果、できたものを見て、こんなんじゃない、みたいなトラブル。ビジネスの現場ではそこに金がかかっているわけだから、そりゃ大変だ。そういうことを防ぐテクニックやスキームを示した「要件定義」という本がたくさんあるらしい。でも、この伝言ゲームによる情報の劣化、今回のようにユーザーである私が直接AIに指示を出していると、全く生じようがない。これはどっちにする？という課題が出た時も瞬時に判断できる。実際、今回そういう分岐がいくつかあったけど、決めるのに時間は全然かからなかった。一般的なプログラム開発では、その度に顧客まで判断を仰ぐ伝言ゲームが発生するらしい。でもそれがないことが、今回ど素人の私が初めてプログラムを作ったにも関わらず、数日で使えるものが出来上がった理由の一つなわけだ。この辺りは家に帰って改めてGemini相手に問答を重ねて壁打ちしてみたが、間違っていないようだ。AI時代の新しい業務のやり方の勝ちパターンかもしれない。なるほど。

とりあえず、ガーっとやったことについて、少し整理して言語化できたことは、収穫。少しスッキリした。理屈っぽい話を書いてしまったけど、思考の記録として、こういう日記も書いておく。