前回のあらすじ
新卒大手フリーランスでPM業務というめちゃくちゃなキャリアスタートから気づいたらベンチャーの一人情シスに!?しかもいきなり150時間分の作業の自動化なんて出来るの???
第四話 月150時間の行程を自動化？！
上からバックコストの削減について相談されたある日、「自動入力RPA作ってよ笑」との無茶ぶり打診を受けるも内心冷や汗タラタラ。「いや俺のかけるPythonなんて素人に産毛か生えた程度だし...」ってもう戦々恐々生まれたての小鹿くらい震えてChatGPT握りしめて書いてみたらまさかの、、、
出来た。出来たけどお盆はなくなった。差し入れのアイスは美味しかった。
～作業する前に知っておきたかったこと（初めてのコーディング with ChatGPT編)～
・ChatGPTよりもGithubのコメント欄の方が信用できる
・エラーメッセージを用いてネット検索の上でコード修正するようプロンプトエンジニアリング
・結構GPT上でのライブラリだったり変数エラーするので雛形はあらかじめ作っておく
～作業する前に知っておきたかったこと（Selenium編)～
・構築されたのが昔(今回のケースだと最終メンテ2007年のWebフォーム)だとFull Xpath推奨
・実行ファイルとdriver.exeは同じレポジトリにあると楽
・ブラウザ表示モードにしておくと処理してるのが分かってモチベが上がる
参考にさせていただいた記事→https://qiita.com/mochio/items/dc9935ee607895420186
先人の知識の大切さと「もしかしてコーディングちょっとだけ分かればChatGPTで開発できる？」と可能性を感じた夏のとある日でした。
第五話 要件定義ってめちゃくちゃ大事だよねって話
例の自動入力RPAで150時間分の人力業務を自動化したら、今までバックコストの高さからシステムよりも人力ムードだった社内にも「アレって出来る？」「こういうの出来たらめっちゃいいよね！」みたいな理解したいんだけどね～みたいなムードが出てきた。正直凄く嬉しかったし、自分が貢献できている気がして誇らしかった。
でも、それに乗っかって自分のふわっとした無茶ぶりを具現化してくれみたいなお願いも増えてきた。すり合わせの打合せをしたり作っては手戻しが発生する未来が見えたので前職の見よう見まねで要件定義書、英語で言うとRequest for Proposal, RFPなんて呼ばれたりするやつを雑に作った。
ドキュメントベースじゃないと要望聞けないし責任取れません！！
この世の全ての理不尽に苦しむ中小企業の一人情シスの皆さん、要件定義書を作ってドキュメントにしてもらいましょう。。。僕は場合はいわゆる、As-is, To-be, ユースケース、納期の4つに絞って記載してもらいましたが大分作業自体に集中できるようになり、依頼側も自分のもやっとしたものをエイヤでも言語化することで整理できたケースが多くてラッキーでした。
(開発V字モデルの存在は後に知りました)
開発V字モデルの分かりやすい先人の記事はこちら→https://qiita.com/mars0925y/items/9d03b89b2ce6af53ade1
第六話 クラウドって結局どれが正解なの？？弊社編
弊社の機関DBシステム、実は創業時５年間、メジャーアップデートなしで運用されています。確かにノーコードで改修や機能つけられるし、お手軽で現場スタッフでも作業できます。しかし、そもそものDB設計が現在の事業スケーリングに合わない、取り急ぎミラーリングでもいいからクラウドにお引越しだ！と一人情シス的には地獄のような大号令が聞こえてきたわけです。そこからは毎日狂ったようにUdemyで動画を見ながらQiitaで記事を読み漁り、無料クレジットで使える分は全部使う！！くらいの気概で調査に明け暮れていました。
弊社のように営業がずっと使ってるから高可用性は絶対譲れない、でもCognitive SearchもいいしDuet AIも良さそう。そもそもGoogle Spreadsheet使うケース多いしGASもやりたいなーなど迷った結果、、、
決まりませんでした。全部のいいところをちょこちょこ使う事になりました。
サーバーはAZだったりBCPが強いAWSに、AIがらみの部分は元々Open AIの課金ユーザーだったのでAzureに、GASだけはGCPしかないのでお願いしたりと。今はまだなんちゃって導入なので良いのですが、ここからのスケーリングや冗長性、取り回しやすさなどなど考えるといつか一つに絞る必要があるのかなとは思いますが怖いです。引き続き勉強します。