こんにちは！ふーがです。
この記事は「フィヨルドブートキャンプ Part 1 Advent Calendar 2021」の8日目の記事です。
Part2もあります。
昨日は @pofkumaさんの「フィヨルドブートキャンプの門をくぐって - pofkuma’s blog」と、@ogaworksさんの「OOPに対するもやもやがだいぶ晴れてきた話 - ogaworks」でした。
先に結論を書くと、フィヨルドブートキャンプはプログラミングスクールですが、プログラミングスキル”だけ”ではなく、他の汎用的なスキルも学べる場だということに気がつきました(おそい)。 現職での業務を通じてそれを強く感じることがあったので、何をどう活かせたのかを書きたいと思います。
僕のステータス
フィヨルドブートキャンプを11月に卒業したばかりの実務未経験者です。
WEBエンジニアとしてのスタートを切るため、現在転職活動中です。
現職の仕事内容
公務員としてDX推進を担当しています。
内部的な開発部門もあるのですが、それとは別に、事業者が提供しているソリューションを導入するなどして、組織全体の事務効率を向上させることを目的とした部署に在籍しています。
はじめてのRPA
現在の部署に異動して最初に任されたのが「RPA」の導入でした。
これがきっかけで業務でプログラムを書くことになりました。
少し前置きが長くなってしまいますが、その辺の経緯も書いていきます。
RPAとは
RPA（Robotic Process Automation）は、人間がパソコンを使って行う定型作業(人の判断が介在しないもの)を、ロボットで自動化することをいいます。
ここでいう「ロボット」とはいわゆるプログラムであり、例えばデスクトップにあるショートカットをクリックするだけでロボットが自動で作業を進めてくれます。
具体例をあげると、エクセルに入力されたデータを目視で確認しつつ別の業務システムに入力して登録する、定期的に様々な宛先へ報告メールを送信する、といった業務を自動化することができます。
RPAでロボットを作成できるソリューションは各社からさまざまな製品が出ています。
製品によってできることやプログラムの組み方も違うようです。
導入の背景
現職では、「時間外勤務の縮減」や「ワークライフバランスの充実」といった取り組みが進められている一方、時期ものの定型作業によってこれらの推進が阻害されているというのが現状です。
阻害の要因となっている業務を見てみると、「人の判断を必要としない」入力業務であったり、すでにあるデータを「他のシステムに入力しなおす」ものであったりと、RPAを導入することで大幅な時間削減と事務効率の向上が見込めました。
こういった状況から、「RPAを導入して定型作業を自動化し、職員の時間外勤務を削減してワークライフバランスの充実に貢献しよう！」という流れになり、導入を進めることとなりました。
RPAの導入と未知の技術に興味津々なわたし
導入当初、プログラムの作成については開発部門が一手に引き受けていました。
すでにフィヨルドブートキャンプで学習していた僕としては、「RPAってどんな感じで書けるんだろう？」と、未知の技術に興味津々でした。
打ち合わせと称して開発部門に足を運び、プログラムを組んでるところを見させてもらったり、どんなことができるのか教えてもらったりしているうちに、「もしかして自分にもできるのでは？」と思い始めました。
コードの記述の仕方や細かい挙動こそ違えど、やっていることはまさにプログラミングそのものでしたから。
とはいえ開発部門ではない僕は「自分がプログラムを組むことはないだろうな」と諦めムードでした。
プログラム開発をさせてもらえることに
そんな中、開発部門の人手が足りないという話をキャッチしました。
僕は今しかない！と思い、上司に「開発部門の人手が足りないと業務効率化が進まなくなる！」とか「僕プログラミングできます！」的なことを懇々とプレゼンし、紆余曲折の末RPAプログラムを開発する許可を得たのです。
これ以降、通常業務に加えてRPAプログラムの作成も行うようになりました。
Rubyではないにしろ、業務でプログラミングができる！ということにめちゃくちゃ舞い上がっていた記憶があります。
何を活かせたのか
さて、前置きがだいぶ長くなりました。
新しい技術で実装していくことや担当者からヒアリングして要望を形にしていくのはすごく大変なことでしたが、フィヨルドブートキャンプで学んだスキルがめちゃくちゃ役立ったと感じています。やっと本題です。
未知の技術を学び、使う
プログラミング全般的にそうかもしれませんが、新しい知識を学んで利用する機会がよくあると思います。
フィヨルドブートキャンプでのチーム開発や自作サービス開発を通じていろいろな知識・技術をインプットしては開発に反映する、ということを経験していたので、RPAプログラムを書くためのキャッチアップもまったく苦になりませんでした(むしろ楽しかった)。
また、「RubyだとこういうメソッドがあるけどRPAではどうだろう？」と考えて調べたり、今後僕以外がプログラムを修正することを考慮して「変数名わかりやすくしておかなくちゃ」とか「この処理はDRYにしておこう」と考えられたのも、フィヨルドブートキャンプでメンターの皆さんからそういったレビューをしていただいていたからだと思います。
実現したいことと実現可能性のギャップを埋める
実現したいことがあるとして、その実現方法を考えるには、「自分に何ができてどう活かすか」「足りない部分はどこでどうやって補うか」を整理することが必要です。
例えば、フィヨルドブートキャンプには「Rubyでlsコマンドを作る」というカリキュラムがありますが、初めて挑戦したとき「何から始めればいいんだ…」と絶望的な気持ちになった経験があります。 lsコマンドが実現したいことだとするならば、その実現方法がわからない状態ですね。
lsコマンドのカリキュラムに限らず、生徒がどうしていいかわからなくなっているときには、「小さいタスクに分割してみよう」というアドバイスがなされているのを見かけます。いわゆるタスクばらしです。
僕もすべてのカリキュラムにおいてタスクばらしを実践していましたが、この経験をそのまま今回の仕事に活かすことができました。
タスクばらしはプログラミングのみならず、仕事でも私生活でも応用が効きます。
実現したいことを小さく小さく分割していくと、今の自分にできること、今はできないけど少し努力すればできそうなこと、しっかり勉強する必要がありそうなこと…そして、それらを積み上げていけば実現したいことを実現できるということがわかります。
そして、それを共有することでRPAを必要としている担当者との認識の齟齬もなくなって、「最終的にどういうものが出来上がるのか」「この機能は入るけど、こっちは入らないよ」などといったビジョンの共有ができたように思います。
IT知識がない人に説明する
フィヨルドブートキャンプでは、学習をした日に日報を書きます。
Discordには個々人の分報チャンネルがあり、わからないことや日常のことなどしょっちゅうつぶやきます。
質問したいときには、何をどこまでどうやって今どういう状況でどうしたいのか、といったことを書き起こして質問します。
何かと文章を書く機会があるわけです。
自分の考えや状況をテキストで人に伝えるのって、想像以上に難しいです。
新しいことを学ぶときに理解するのにも、自分にわかりやすい言葉で咀嚼する必要があります。
こういった経験から、伝えることを意識した噛み砕いた表現を自然と意識するようになっていました。
そのおかげで、ITに疎い上司や業務担当者と話すときでも、平易な言葉できちんと説明して、伝えることができたように思います。
まとめ
フィヨルドブートキャンプでの学習は、与えられた課題に対して実装するというもので、「必要とする人から課題を引き出して実装する」というのは同じプログラミングでも似て非なるものでとても大変だということを、身を持って経験することができました。
ただ、大変ではありますが真摯に向き合ってプログラムが完成したときに、「すごく助かってるよ」「良いものを作ってくれてありがとう」といった言葉をかけてもらった時には、そんな苦労も忘れるくらい嬉しいです。
プログラムの先に人がいるのだということを、肌で実感できたと思います。
こうした喜びを感じることができたのは、フィヨルドブートキャンプでプログラミングスキルのみならず、汎用的なスキルも同時に身に付けられたおかげです。
僕はフィヨルドブートキャンプで、プログラミングの技術以外にも大切なことを学ばせてもらったのだと気づくことができました。
今はまだ組織内という小さな範囲内ですが、知識も技術も研鑽してもっと広い範囲で、広い視野で、課題解決できるエンジニアになれたらと思います。
（就活がんばろう…！）
次回予告
「フィヨルドブートキャンプ Part 1 Advent Calendar 2021」はまだまだ続きます。
明日は@isshi_hasegawaさんと@nekokitareさんです。楽しみですね。
