【新人エンジニア】新卒1年目が終わる今、「業務を効率化するソフトウェア」の改善に挑戦した日々を振り返ってみた
こんにちは、2022年に新卒で入社し、クラウドソリューション事業部で「クラウドERP ZAC」の開発を担当している大山と申します。
オロに新卒で入社して1年経ったところで、私視点でこの1年間で取り組んだ仕事や学んだことをお伝えしてみようなんて考えてみました。オロへの入社を検討している方はもちろん、学生からソフトウェアエンジニア（BtoB）への就職を考えているみなさまの参考になれば幸いです。
本当にありのままにそのままに、オロでの1年間の経験や感じたことを書いてみましたので、ちょっと長くなってしまいました。。。興味はあるけど時間は無いよっていう人は、要約だけでもご覧ください。
要約
思ったよりも年次の若い社員が主体的に動くことが許されていた
本格的な設計も既存コードの量も、学生の頃の比じゃなかった
知識がなければバグをバグと気づかないこともある
開発サイクルに慣れる事には悪戦苦闘した
日々の鍛錬の重要性を感じた瞬間
オロで過ごしてみて感じたことは、「お互いの専門性への尊重」「意見や提案を言いやすい雰囲気」「学習する技術領域のバランス感覚の難しさ」
自己紹介
2022年4月入社 ZAC製品開発グループ配属（当時：新卒1年目）
公立はこだて未来大学大学院 システム情報科学研究科 高度ICT領域 出身
趣味は料理。得意料理はアルモンデ ※冷蔵庫にあるもんで料理を作ること
この1年間のあれこれ
4月 不安な気持ちで入社
入社するまでは北海道の実家から小学校～大学院まで通っていたので、新生活への不安がかなりありました。入社後にどのくらいの研修があるのか、研修が終わった後も技術的についていけるかなども不安でした。また、内定者アルバイトをしている方もそこそこ居たため、その人達と差が出来て置いて行かれないかといった不安もありました。
新生活の出費が結構多く、初振込が5月だったことも合わせて出費的にはきつかったのですが、内定後の制度改正で近隣手当ができたり、賞与分が給料に振り分けられるようになったりしたので、初振込以降は金銭的に困ることは無かったです。（参考：給与・待遇について）
入社後の2ヶ月間は全社、事業部、エンジニア研修で基礎を学んでいきました。
4月前半 22卒の同期みんなと一緒に全社研修
会社組織全体の説明だったり、ビジネスマナーやコンプライアンス、ツールの使い方だったり、論理的思考スキルやコミュニケーションスキルなど会社全体・社会人として最低限必要なことを学びました。
その中で年次が若いが会社で活躍している人の話があり、「年次が若くてもこんなに主体的に動くことが許されるんだ！」ってわくわくする気持ちと「こんなに主体的に動ける自信が無い…」という不安の両方を強く感じたので印象に残っています。これは後で知ったことなのですが、昔より研修に力を入れていて毎年改善されているそうです。
4月後半～ クラウドソリューション事業部の全体研修
事業部の中心となる「クラウドERP ZAC」というプロダクトの知識や使い方などを学びました。ERPという概念は理解しているつもりでしたが、実際にプロダクトを使ったこともないし、それが必要な立場（社会人）でも無かったので、具体的な中身や利用シーンなどを学ぶ場があって理解が深まりました。
6月前半～ ZACの開発エンジニアとしての基礎研修
前半・後半に分かれており、前半では課題形式でC#、 Angular、 SQLServerなどのZACを構成するメイン技術について学びました。課題形式で問題を解くこと自体は苦手ではなかったので、同期の中ではそこそこの速度で解くことが出来ていた記憶があります。ただし、学生時代はPythonやReact、postgreSQLを触っており、C#、Angular、 SQLServerは殆ど触ったことが無かったのは非常に不安でした。そうはいっても、どちらも元はJavaScriptなのでReactの知識がAngular開発でも普通に使えたというのは課題を進める上で大きな要素だったように思います。
そして、後半では実際のプロジェクトに近い形で開発を行う研修を受けました。
学生のころは少人数でのプロジェクトが多かったのでそこまで設計に時間を掛けないことが多く、本格的な設計はあまり経験が無かったので苦労しました。また、既存コードの分量が私が学生の時に触った比ではなく、必要な情報がどこにあるかを探すのにも苦労しました。その他にも色々な躓きがあったのですが、教育係として担当していただいた先輩に色々と助けていただいたり、1日の終わりにいただけるフィードバックから多方面の疑問を解消していったことで、遅れなく研修を終えることが出来ました。
6月後半～ 初めてのプロジェクト配属、UI/UX刷新プロジェクトに参加
研修を終えていよいよ実務に関わり始めるのですが、ここで既存コードの海に溺れ、そしてドメイン（会計）知識の重要性にも気付かされました。
現在ZACでは、各画面を新しいものへと変えていくUI/UX刷新（＝Blancoプロジェクト）が進行中です。
その一環となる、「仕入機能」の画面刷新プロジェクトに参加しました。
ZACには、プロジェクトごとに仕入(外注)を管理する機能があります
新たなバージョン（Blanco版）を続々とリリース中
ただ、私が参加したときには既に、大まかな機能の開発・実装は終わっていてバグ修正・追加要望の実装の段階でした。
当たり前かもしれませんが、プロジェクトへ途中から入ったのでこのバグを修正するには何処を見ればいいのかという開発知識もありませんでしたし、そもそも、刷新前のもとあったUIはどういう動作をするのか、というプロダクト知識も無かったので大変でした。
また、「仕入機能」画面は会計と深くかかわるため、赤伝票や黒伝票などの会計用語が使用されます。会計知識の不足からバグをバグだと気づかないこともあり、技術的な知識以外にもドメイン知識の不足も感じました。
もちろん、既存で実装されていたコードの知識も不足していました。
実践において自身の知識不足を感じた場面は多かったですが、やみくもに既存のコードを全て理解するのではなく、既存のコードやアーキテクチャの情報が、何処にあるか・どういう方法で調べると解決しやすいか、を学んだことによって、仕事に取り組むスピードが上がっていきました。
さらに、プロダクトとして提供するためにどのような検証・不具合修正のサイクルで取り組んでいるのかを経験しながら学べたことと、早い段階でプロジェクトの終わりを経験できたことは大きな価値だったと思います。
7月後半～ 細かな機能改善と開発サイクルの体験
はじめてのプロジェクトを終えた後は「小規模改善」と呼ばれる業務に携わりました。
特定の機能ではなく、ユーザーニーズの優先度に沿って開発テーマを決め、メンバーの能力に合わせて開発担当を決めています。私も多岐にわたる開発テーマに携わり、色々な画面や機能の挙動や仕様を調べながら都度開発に取り組みました。
開発のプロセスは、設計・実装した後に、コードレビューを受け検証チームにテストしてもらうサイクルになっています。レビュー待ちやテスト待ちになると次の開発テーマに手を付けるのですが、1つ1つは小さな開発ですので結果的に並行して色々な機能の開発をすることになりました。
プロダクト自体の規模も大きく私の理解もまだ浅かったこともあり、開発着手後に対象機能に修正を加えることの影響範囲が広いことが分かって修正方針を変更したり、私の手に余って先輩エンジニアに巻き取ってもらったり、どんな仕様にしても微妙になって開発自体を見直したりと、かなり悪戦苦闘しました。
レビュー待ちから返ってくるテーマといま実装を進めているテーマがつい混ざってしまうこともあり、優先順位を間違えずに切り替えて進めていくことが大変でした。対策としてドキュメントやメモをしっかり残すようにしたところ、徐々に効率よく開発できるようになりました。
小規模改善業務に関わって良かったこととしては、様々な機能の開発を担当して幅広いドメイン知識を得られたので、この後のプロジェクトでも役に立ちましたし、設計や開発を小さなサイクルで何回も行う経験から、1人でも不具合を修正するまでの流れを見通せるようになりました。また、小さな修正なら修正方針や必要な時間数がなんとなく分かるようになりました。まだまだ小さな一歩ですが、開発に必要な王道の知見を得られ、エンジニアとして少し成長できたと思います。
9月後半～現在進行形 PDF帳票生成エンジンのリプレイスプロジェクト
プロジェクト始動から関わることで得た知識
ZACの中には、見積書や請求書などの取引の際に必要な書類（=帳票）をPDFファイルとして出力する機能があります。そのPDFを生成するライブラリが古すぎて、ユーザーのニーズに応えきれない場面が多々あったという経緯もあり、刷新することになりました。
ライブラリ選定で色々と調べていたのですが、ZACの技術スタックで使いやすそうなものがなかなか見当たりませんでした。現機能を再現できるライブラリの選択肢がほとんどないという現実を突きつけられましたね。トータルのコストパフォーマンス（ライブラリの購入費用やプロダクトに組み込むフレームワークの開発工数、現PDFテンプレートを移行させる工数、実現できる機能や表現力など）を比較した結果、自社開発が最も優位とわかりました。自社で開発することによって、以前からユーザーから求められていた細やかな表現の実装が可能になることなどのメリットもありました。
選定段階において、私の頭の中では、自社開発だと旧ライブラリを他の有償ライブラリに置き換えるよりも高コストになると思っていました。帳票生成に関する知見やノウハウが世の中に殆どなく（つまりは需要が無い）、ZACの独自仕様の再現などを含めると低コストでリプレースすることが難しいと考えていたからです。
ところが検討を進めていくと、プロダクトオーナーのアイデアによって、低コストで置き換える方法が見つかりました。その方法がSVGやXSLTなどの、普段の業務内では使わない技術や手法を利用したものでした。そういった、業務では関わらないと思っていたような技術や知識を身に着けておくことで発想の幅が広がり、できないと思ってたことを実現できることを学びました。
いざ開発を進めていくと、レガシーな技術の仕様や、旧エンジンの独自仕様が後から明らかになるといった問題に苦しめられたり、ローカルではちゃんと動くのに検証環境では動かなくなるというバグがあったりと、多くの障壁がありました。過去に例のない取り組みというものは、想定外の事態に見舞われやすいので、それをどう乗り越えていくかを考える事が大切だと学びました。苦労することの方が数としては多かったものの、今回のリプレイスによって、旧エンジンの制約によって実現できなかった様々な機能が、今後は開発可能になるのがとっても嬉しいです！
オロで働く中で感じていること
ユーザー目線でもプロダクトを知れる・変えられる面白さ
オロの社員もみなZACユーザーであり、日々業務の中で利用しています。
なので、私自身がユーザーとして気になったところや不便な点の改善に関わることができます。それも、単にバグの指摘や機能の要望を挙げるのではなく、どう改善すれば既存のユーザに悪影響が無いか、コストが掛からないか、今後の機能追加に影響がないか（保守性）など、私がその改善開発に関わらなくても開発者の視点を生かした指摘・提案ができるのが面白いです。
また、社員全員がZACユーザーなので、日常的に利用者の視点から様々な指摘や意見を貰えますし、普段よく使う機能の改善には歓喜の声が上がったりします。
非エンジニアとの関係性
開発業務以外のところでも度々仕事のしやすさを感じます。
正直言うと、入社前は営業の力が強すぎて実現が難しい機能を作る必要が出たり、逆にエンジニアの力が強すぎて顧客の視点からかけ離れたプロダクト開発をしてしまうことがあるのではないか、といった想像を膨らましてしまっていました。実際に私が1年間働いてみて、そのような事態に出くわしたことがなく、価値あるものをきちんと届けていこう、という想いを会社全体から感じています。（もしかしたら個別の事象としてあるのかもしれないですが、会社全体・事業部全体としては感じたことは無いです。）
ここ最近の出来事なのですが、実際の営業活動の商談に同席するという研修がありました。会話を通じて隠されたニーズを掘り起こしたり、お客様のちょっとしたワードから必要としている機能を見つけたりする姿に、「凄い…!」と思い、そのことをその営業の方に伝えたら、「いやいや、開発の方が機能を作ってくれるおかげで、私たちが売る・提案することができるんですよ」といったことを言われて、互いの専門性を生かした理想的な関係ができている…！ と思い、いい意味で少しびっくりしました。
コミュニケーションに前のめりになれる環境
自分の所属しているチームでは質問・意見・提案を言いやすい雰囲気があると思います。特に初めの頃は、忙しそうにしている先輩に向けて、「こんなこと聞いてもいいのかなぁ」って思いながらも恐る恐る聞いていたのですが、いつもちゃんと話を聞いてくれて都度疑問を解消できています。他にも、もっとこうすればよくなるのに、と思ったことを上司に伝えたところ、そうした発言に何かしらのフィードバックがもらえることが多く、自分からどんどん意見を発信していこうというモチベーションが上がります。もともとは決して意思表示が得意な方ではなかったのですが、オロで過ごしているうちに小さなことでも質問したり、意見を表明する抵抗が小さくなったりしていました。
これからのお話
1年間を振り返る中で、これからのことも考えてみました。今の自分には、「今ZACに採用されている古い技術」と「今後ZACで採用したい新しい技術」の学習バランスが難しいなと感じました。まず、今採用されている技術がわかっていないと、既存の機能の改善が難しいです。とはいえ、新機能の実装や提案には新しい技術の知識が必要です。普通に業務をこなしていると、今目の前の課題だけを見てしまい、将来的なキャリアや技術力まで考えることを疎かにしてしまうので、そのバランスを考えながら開発していきたいです。
他にも、ERPや他社プロダクトの知識が足りていない、言い換えると、それらの必要性をやっと実感してきたというのがあります。ZAC以外のERPに触れる機会が殆どなかったり、他社製品は仕様が開示されていなかったりとで、ZAC特有の不便さや反対にいいところにも気づくことが難しいんです。例えばUI/UX刷新の際も既存の動きに合わせた仕様に開発しようとしていましたが、それよりも新しい動作にした方が利用者にとっては使いやすくなるといったことがありました。ZACだけでなく他社製品の知識は、機能設計などで役に立つことが多いと思うので、なぜそのような仕様になっているのかを普段から気にするようにして、分からないところはドンドン調べたり質問していこうと思います。
LT会そのものの布教も兼ねて、敢えてキャッチ―なテーマで登壇してみました。
最近は、Lightning Talkの発表者として参加したり、社内のスキルアップ委員会のメンバーとしても活動しています。社会人2年目突入に向けて、視野や活動範囲を広げるために、エンジニアリング以外でも私が貢献できる要素を探しているところです。
現在、新卒で一緒に働くメンバーや、ZAC開発にたずさわるエンジニアメンバーを絶賛募集中です！
私たちの取り組みに興味を持ってくれた方、そして、規模の大きなシステムを扱ってみたい、開発した後もその製品の改善をし続けたい、自分の技術を誰かのために生かしたい、自信を持って役に立つプロダクトに関わっていると言いたい、そんな想いを抱く皆さんと一緒に働きたいです！
この記事が気に入ったらサポートをしてみませんか？