投稿者: ユウスケ

今回は趣向を変えて、TIPS記事のようなものを作成していきたいと思います。
記念すべき第一回目の記事はseleniumとRPAと、ちょっとだけAIについて書いていきたいと思います。

IEのサポート終了

2022年6月でIEのサポートが終了し、各プログラム言語に公式ライブラリとして備わっていたHTMLdocumentを使ったIEでのwebページのクローリングや自動操作が不可能になってしまいました。（アンインストールしない限りIEを起動させること自体は可能ですが、セキュリティ上大変危険なため皆さんは決して継続利用なさらないようにお願いします。）

seleniumやRPAといったツールは、そんなwebページのクローリングや自動操作に必須となるツールとして、IEのサ終以前から注目されておりました。

seleniumとRPAの違い

この2つの大きな違いを語る前にそれぞれの言葉の意味をまとめてみました。

selenium
・webページの動作テスト用に作成されたライブラリの名称
・PythonやJava、VBAなどの言語で参照でき、コーディングによってChromeやEdge、Firefoxといったブラウザをコントロールして任意の作業や繰り返しの作業を実行する

RPA
・ロボティック・プロセス・オートメーションの略称で、PCでの仮想の労働者に業務を行わせる技術や機能の総称
・デスクトップ上の作業をRTAのエディタで記録して、繰り返し実行したり、条件分岐や定型フローを組み合わせて業務を実行させる

といった感じ。ざっと羅列しただけでも違いがわかると思いますが、先ず大きな違いは「seleniumはWebを自動操作する」で「RPAはWebに限らずPCの操作を自動操作できる」の点になります。

根本的な土俵の違い

上のまとめだけを見ると「だったら、RPAを覚えた方が業務幅が広がるじゃん！」と思われがちです。

確かにできる業務の幅でいったらその考え方になりますが、ここで両機能の1番目に載せた特徴の「webページの動作テスト用に作成されたライブラリの名称であることと、「PCでの仮想の労働者に業務を行わせる技術や機能の総称」 という違いがあることを説明していきます。

先ずseleniumはライブラリであるため、単体で開発環境を持つことはなく、既に修復しているプログラム言語から参照して使用することができます。つまりプログラム言語でseleniumという機能をスタートさせて、プログラム言語で指定した通りの動作を再現してブラウザをコントロールしています。

一方のRPAはほとんどの場合独自の開発環境やソフトをインストールする必要があり、記述やフローチャートを勉強する必要があります。この・については既に修復している言語が有るか否かで選択肢が別れる点かと思いますが、RPAのほとんどは自分が操作したログをプログラム言語化して記録し、その操作を繰り返すことで自動化しております。

上記で説明しただけでも、「seleniumは記述したプログラムを動作にする」事と「RPAは動作を記録してプログラム化する」という決定的な違いが解っていただけると思いす。この点については真逆の性質を持っていると言えます。

結局どっちが便利なの？？

決定的に真逆の性質を持っているとなると、どっちを使ったらいいの？という疑問が生まれてくると思います。
適材適所としか言いようのない部分かもしれませし、これに関しては永遠の議題だと思っています。

個人的な意見としては、この議題の明暗を分けるのが、タイトルに記載したAI分野の技術だと考えています。chatGPTの登場によってコーディングの精度や環境構築スピードが格段に上がったと感じる技術者は多い事でしょう。

現在無料版のGPTでさえ「PythonでSeleniumを使ったコードを作成して」とトークしてみると、かなりの精度でコードをジェネレートすることが出来てしまいます。プログラム言語にちょっと疎くてもこれだけでseleniumはとっかかりが作れてしまいます。

一方で「●●のソフトを自動化する為にどんなRPAソフトを導入すればいい？」とGPT聞いた場合も、高確率で意図している通りの機能が備わった環境が提供される事でしょう。こちらに関しても少しの手間でとっかかりが作れると思います。

そこから先は使用する技術者の腕次第になりますが、それをサポートするAIの学習幅、解決能力は今のところseleniumに軍配が上がっているように思います。単純にGPT君のコーディングスキルがめちゃくちゃ高いので、コードから機能を作成するseleniumとの相性が良く、RPAのように明確な答えがない物の案内が苦手なような気がしています。

しかし、今後のGPTのVer4やその先の技術の能力によっては、その環境やパワーバランスはすぐに覆ってしまうんじゃないかなと私は考えております。

まとまりのない記事となってしまいましたが、seleniumとRPAの決定的な違いと、AIとの相性について参考になればと思います。

エンジニアヒストリーの更新第3回目は、期間空いてしまいましたが、前回に引き続きユウスケが部門内エンジニアから、いかにして専業エンジニアになり、BitDesignLaboに所属するようになったかをお話ししていこうかなと思います。

1、職場との別れ

私が部門内のエンジニアとして活動を終えた理由はズバリ退職したからです。といっても、その時点で専業を目指して自主退職をした訳ではなく、大幅な組織改革により遠方に転勤になるか、会社都合扱いで退職となるかの判断を迫られたのです。

前回までに登場していた上司も同じように決断を迫られておりましたが、上司は開発者である以上にマネージャーとしての責任感から転勤を決めていました。退職を考えていた私はかなり強めに引き止められました。しかし、ハッキリ言って転勤した先で同じように自由な開発ができるとは思っておらず、この機会で専業としての道に進むことはできないかと考え始めました。組織や上司への恩義はありましたが、このまま転勤族として生きる事になるより、会社都合で退職できるタイミングで新しい業界に飛び込みたいという意欲がわいてきたのです。

そこからはエンジニアの求人を探して転職活動を始めました。当初は年休消化期間の早い段階で次の職場を決めて、バカンスでも楽しもうかと浅はかな考えを抱いておりました。しかし実際のエンジニアとしての実務経験が乏しく、ほぼ未経験扱いの私で面接までたどり着きそうな中途採用求人は、私の地域にはほとんどありませんでした。

2、次の会社と新しいエンジニアの形

結果としてバカンスを楽しむヒマはなく、在職中に取引のあった協力会社に雇っていただくこととなりました。『結局専業じゃないのか？』と疑問に思われたかと思いますが、求人を探しているうちにフルリモートのエンジニア求人やクラウドワークス等でのフリーランスのエンジニアとして働く業態があることを知ってから方向性を変えたのです。
求人の決まらない私に声をかけてくれたその協力会社が副業OKだったので、クラウドワークスで副業としてエンジニア経験を積む方向に切り替えました。

正式に職場を退職してからノータイムで新たな会社に配属された私は、日中は本業での仕事をこなしながら、夜中はクラウドワークスで私のこなせるレベルの仕事を探して経験を積むという生活が始まりました。

ほとんどの募集はトレンドになっていたpython等の即戦力エンジニア募集ばかりでしたが、VBAやVBなどのスタンダードな開発言語の募集やオペレーション業務の募集もあり、その分野ではすぐに実績を残すことができました。

納期を遵守し、報連相を豆に取るだけで実績と高い評価のレビューが自然とついてきます。クライアント様から逆にオーダーされることや、『別の言語で経験を積んでみないか？』と勉強用のサンプルが渡される機会も増えてきました。

持ち前のコードを読み解く根気と、元上司から教わった『先ずは終わらせる』の精神でクラウドワークスに食らいついた私はVB以外にVC#、Unity(VC#)、html(cssとjsも)などの開発言語(環境)を力づくで体得していき、サーバーもSQLserver以外にもMySQLの環境作成まで経験していくこととなりました。サーバーについてはリモート操作でサーバーでセットアップする経験も豊富についていきました。

技術習得以外にも、一つの企業に所属しているだけでは到底得られなかったようなトレンドが知れたことも、副業でエンジニアを続けていくモチベーションだったと思います。
どんな企業がどんなツールを欲しているのか、世の中にはどんな業務ツールが存在しているのか、トレンドや世間を知る事は前職でサーバー構築に触れたとき以上に概念を壊した経験だったと今になって思います。

当然ですが本職での就業規則を守りながらの副業ですので、休息しなければならない時間の確保にも苦労しましたが、それ以上に実績を積める楽しさで毎日アドレナリンが全開だったと思います。(健康を著しく害する危険があるため、他人にあまりお勧めできないような業務体系でした。)

3、ついに専業へ

しばらくそんな副業での経験を積んだ後に、拾っていただいた協力会社を円満退社し、晴れて私の経験を認めてくれたBitDesignLaboに正式に専業エンジニアとして所属することになります。

…部門内エンジニアでのエピソードに比べると駆け足でのエピソードになってしまいましたね。(実際のところ、守秘義務等の問題があるため、詳しくお話できるエピソードがとても少ないのです…)

まとめになりますが、タイトルに書いてあった『私がエンジニアになった理由』とは、『新しい概念と出会うため』と言うことができると思います。この新しい概念との出会いが、一貫して私の開発への情熱に直結していたと思いますし、今ブログでこのエピソードを書いているのも、新しい刺激になるなと考えております。これからも新しい技術や概念と出会えることを生きがいとして、エンジニアの業務を遂行していきたいと思います。

といった感じで、3記事にわたって今の業態になるまでの経緯を書き連ねてまいりました。次回以降はTIPS系の記事なんかを書いてみようかな～と考えております。

次回の更新をお楽しみに！！

　今回はBitDesignLaboの第1回目の更新ということで、私がエンジニアを目指した理由について書いていきたいと思います。

　申し遅れましたが、私はブログ更新担当のユウスケと申します。

私は将来フリーランスのITエンジニアとして独立するべく、現在BitDesignLaboに所属してITエンジニアとしての実務経験を積んでいるところです。

…なんだか堅苦しい導入になってしましたが、↓からエンジニアを目指した理由を書いていきます。

１、プログラミングと出会う

　私がプログラミングと出会ったのは、社会人になって2〜3年目の事でした。
地元の工業高校を卒業後、私は電化製品メーカーへ就職し、製品の修理現場で働いておりました。当時のは義務教育の授業にプログラミング学習は無く、工業高校でも情報科でなければプログラム言語に触れる機会もなく、まさか自分が今後エンジニアを目指そうなどとは全く考えておりませんでした。

　きっかけは、何年目かの人事異動で、業務内容がデスクでの間接業務に変わった時でした。
部門内のデータや実績をまとめるために使われていた、Excelのマクロ機能(正式にはVBA)と出会ったのです。

それまで私の中でExcelは表をやグラフを作成したり、計算機の上位互換くらいにしか考えておりませんでした。（Microsoftに怒られそうなので自主規制いたしましたw）

その時触ったマクロ機能は、
①データベースからデータを抽出
②データからピボットテーブルを自動作成
③ピボットの内容が印刷用のシートに反映
④自動で印刷プレビューが表示される。

という非常にシンプルなシステムでした。同期が「システム化してるんですねー」などありきたりな感想をつぶやく中、私は1人ショックを受けていました。

　当時私はパソコンの知識には若干自信があり、プログラミングこそできなかったものの、データをまとめる作業など朝飯前だと思っていました。
それが、Excelの標準機能で自動化できると知り、マクロの記録を使えばコーディングの知識すら必要ないと知ったとき、私はなんと小さな世界にいたのかと思い知らされました。（かなり大げさに聞こえますが、相当ショックでしたw）

２、部門内のエンジニア(？)になる

　そこからはVBAのコードに興味を持ち、そのマクロ機能を作成していた上司へと教えを乞いました。
しかし、その上司はとても忙しく、私１人へ時間をさくほどの余裕がなく、「またあとでねー」などとあしらわれるのみで、教えてもらうどころではありませんでした。
それでも、どうしても自動化を身に着けたい私は、作成されたマクロのコードを1行ずつ意味を調べてはステップイン（1行実行）→調べてはステップインを繰り返し、力づくでコードの意味を解読していきました。

　その甲斐あってか、ルールのある程度を知ってからは、既存のコードを切り貼りして、日々の業務に役立ちそうな機能を作って他のメンバーよりも、効率的に業務をこなしていきました。
そうなってくると、他のメンバーも「その機能使ってみたい！！」となってくるので、Excelを配布して機能の使用感を聞いてみました。

「こういう機能もあったら便利だな～」⇒ 作ってみる ⇒ 皆で使用感を確認してみる ⇒「こういう機能も…」

そうしているうちに、自分でオリジナルのマクロ機能を作成できるようになりました。
当然、評価に直結しませんでしたが、効率改善ができたことは先に登場した上司の耳に届くまで時間はかかりませんでした。

上司「一緒にデータベースとかアプリの開発やってみない？」

　上司からかけられた言葉はホントに思い付きのような提案でした。上司は先述の通り毎日忙しそうにしておりました。上司の業務内容はメンバーのマネジメントは当然ですが、部門内で使用するExcelのマクロ機能、VB.NETによるアプリケーションの開発も一手に請け負っていた為、システムの保守や開発で毎日時間をとられていることを聞かされました。

　私は「おもしろそうだ！」と思い、すぐにその話に飛びつきました。上司はその時使用していたVisual Studio(Basic)とSQL Serverのセットアップ方法、基本的な操作方法を教得てくれました。が、

上司「あとはコードのサンプル渡すから、自分で何か１つアプリ作ってみてよ！」

と言って上司は通常の業務に戻ってしまいました。

その時の私はこんな顔⇒(　ﾟдﾟ)になっていたと思います。ここまで来てもまだ直接は教えてくれないのかと。

　教えてもらえないんじゃ仕方がないので、私はVBAを覚えた時と同じく、あたえられたサンプルコードを解読し、学習しながら知識をつけていきました。解読に関してはGoogleでの検索がメインだったので、文字通りGoogle先生の恩恵あっての技術習得となりました。

　今にして考えれば、コーディングについて対面で教わることも重要ですが、「このコードはどんな風に書き換えたら可読性が高くなるだろうか」「こんな機能を追加したら操作性が上がるのではないか」と考える力を育むために一人で考えさせられていたのかなと思っています。（実際の腹の中は未だに不明ですが…）

　その後も上司とはアプリについて大枠の説明を行うのみで直接コーディングについて打ち合わせや説明をすることなく、部門内エンジニア(正式な役割ではありませんでしたが)2人体制で開発を続けていきました。

　ここまでが、私がプログラム言語に触れて、部門内でエンジニアのような役割を担うまでの経緯でした。
ここからいかにして、専業エンジニアを目指すようになったかは、文字数の関係で次の記事でお話していこうかと思います。