こんにちは。 aciassの畠です。

aciassの立ち上げからバックオフィスも担当している私ですが、それまではバックエンドエンジニアとしてコードを書いてきました。

バックオフィスの経験が浅い私が、このような記事を書くのも少々烏滸がましいかもしれません。
ですが、エンジニア視点でバックオフィス業務について執筆できる人間はそういないと思い、この記事を書きます。

何かの選択肢を広げるきっかけになれば幸いです。

バックエンドエンジニアからバックオフィス

最初はまったく想定していませんでした。
エンジニアとしてコードを書き、プロダクトを作ることが自分の役割だと思って過ごしてきたからです。

それがいつの間にか、人事や労務、就業規則の整備といった、いわゆるバックオフィス業務も担うようになっていました。

正直に言えば、初めは戸惑いました。
「なぜ自分がこれを？」と思ったこともありますし、「これは専門外では？」と感じたこともあります。

ただ、実際にやってみて気づいたことがあります。
それは、エンジニアリングとバックオフィスの仕事は、似ている点が多いということでした。

違う仕事に見えて、考え方はかなり近い

“エンジニアリング” と “人事・労務” 一見すると、まったく別の仕事に見えます。

エンジニアはコードを書く。
バックオフィスは制度を整える。
やっていることは確かに違いますよね。

でも、「どう考えて進めるか」という部分に目を向けると、共通点がとても多いことに気づきました。

たとえば、エンジニアがコードを書くときに自然と考えていることがあります。

• この処理で例外は起きないか
• 特定の人しか分からない書き方になっていないか
• 後から仕様変更しても壊れにくいか
• 読む人が迷わないか

これらは、そのまま会社の制度作りにも当てはまると思いました。

就業規則は「人が動くための仕様書」

就業規則を書いていて、強く感じたのはこれです。

エンジニアが仕様書を読むように、従業員は就業規則を読みます。
ここが曖昧だと、判断に迷い、運用で混乱が起きます。

• この場合はどうなるのか
• 例外はあるのか
• 誰が判断するのか

これらが明確に書かれていないと、その場その場の判断に頼ることになります。

そして、属人化が起きる…

これは、エンジニアにとっては見慣れた問題の一つではないでしょうか。

バグは「制度の抜け穴」として現れる

コードにバグがあると、想定外の挙動が起きますよね。
それと同じように、制度に抜け穴があると、トラブルが起きます。

例えば次のような場合です。

• 想定していなかったケースで判断が分かれる
• 人によって対応が変わってしまう
• 状況によって不公平感が生まれる

これは誰かが悪いのではなく、「設計されていなかった」というだけの話です。

エンジニアは、バグが出たときに個人を責めません。
再現条件を整理し、原因を特定し、修正します。

バックオフィスも同じです。
問題が起きたときに必要なのは、「誰のせいか」ではなく、「どこが想定されていなかったか」を見る視点でした。

リファクタリングは、制度にも必要

一度作ったコードを、ずっとそのまま使い続けることはありません。
読みづらくなったり、要件が変わったりすれば、リファクタリングします。

就業規則や社内ルールも同じです。

• 会社のフェーズが変わった
• 働き方が変わった
• 人が増えた

そうなれば、制度にも自然と歪みが生じます。
それを「昔からこうだから」で放置すると、誰のためにもならない制約になったり、結果的に運用コストだけが増えていきます。

エンジニアがコードを整理するように、 バックオフィスでも「この制度は今の状況に合っているか」を定期的に見直す必要があると感じました。

例外処理をどう扱うか、という共通の悩み

エンジニアリングでもバックオフィスでも、必ず出てくるのが「例外」です。

• 想定外のケース
• イレギュラーな事情
• グレーな判断

これらすべてをルールで縛ることはできません。
だからこそ、「例外をどう扱うか」が重要になります。

エンジニアが例外処理をコードに書くように、 バックオフィスでは、例外時の判断基準を言語化します。

正直ここに、完全な正解はないと思っています。
しかし、判断基準が言語化されていれば、例外時の対応も一律に近くなりますし、「考え方が共有されているかどうか」で、従業員の安心感は大きく変わります。

エンジニア視点が活きる瞬間

エンジニアとしての経験があったからこそ、バックオフィスで活きたと感じる点があります。

• 曖昧な表現をそのままにしない
• 判断基準をできるだけ明文化する
• 将来の変更を前提に考える
• 属人化を減らす

これらは、エンジニアにとってはごく自然な思考です。

もしかしたら、バックオフィスの世界では「そこまで考えなくても…」と言われがちな部分かもしれません。
ただ、その「ひと手間」が、後々のトラブルや混乱を確実に減らしてくれると考えています。

どちらも「人が安心して動くための仕事」

コードを書く仕事も、就業規則を書く仕事も、突き詰めると目的は同じだと感じています。
それは「人が安心して動ける状態を作ること」です。

エンジニアは、システムを通じてそれを支える
バックオフィスは、制度を通じてそれを支える

使う道具が違うだけで、本質はかなり近いのではないでしょうか。

最後に

気づけば、コードを書きながら就業規則を書くようになっていました。
最初は想定外でしたが、今となっては面白い経験になったなあと思っています。

エンジニアリングの思考は、プロダクトの中だけで完結するものではありません。
人や組織、働き方や普段の生活にも、そのまま応用できる力があります。

もし「自分はエンジニアだから、これは関係ない」と思っていることがあれば、 一度だけ視点をずらしてみると、意外と馴染みのある世界が見えてくるかもしれません。
コードを書いてきた経験は、思っている以上にいろいろな場所で役に立つはずです。

エンジニアとしての技術や知見を高めながら、新しい何かに挑戦してみたい方は、ぜひ一度弊社の募集を覗いてみてください。