はじめに

とある工場にて業務アプリ開発や業務自動化を行っているエンジニアです。
昨今は工場等の製造現場でもDX化に力を入れているらしく、私はその流れに乗って現在の現場に配属された形みたいです。
情シス部門だと管理しきれない部分のデジタル化(所謂EUCというやつです)の需要は増え続けていると思っているので、
今回はそういった現場に回された人やこれから回されるかもしれない人に向けて2年間業務アプリを開発して得た経験についてアウトプットしてみようと思います。
参考程度にどうぞ。

体制編

ウォーターフォール開発は無理ゲー

業務アプリの開発において一番伝えたい事はこれ。
ウォーターフォール開発は無理ゲーです。 業務改善系のプロジェクトには合いません。
理由を説明しましょう。

まず、「業務改善」という性質上、開発途中に要求仕様が変わったり、そもそも不要になってしまう事は日常茶飯事です。
そもそも業務改善プロジェクトは「改善案」をベースに動きます。「案が無いけどどうにかしたい」というケースでは業務担当と一緒に改善案を考えたりします。

そして改善案は１発目から完璧になる事はありません。 基本的に何度も検討や検証を重ねてブラッシュアップする事になるでしょう。

しかもそのブラッシュアップは開発着手後に発生したりすることが往々にあります。また、システムの納品後に発生する事もあります。その場合にウォーターフォール開発だと以下の問題が発生します。

設計そのものをやり直さないと対応できないような仕様変更がかかり、今までの開発が無駄になる
提示された要求仕様に実は穴があり、納品後に使えないシステムであることが判明する→結局作り直しになる
そもそも業務自体に変更がかかりシステムが不要になる

こうなってしまっては今までやってきた仕事がパーになってしまいます。なので、なるべく現場からの要望は何時でも取り入れられるような柔軟な開発体制にしておいた方が安泰です。

最初から全て開発するのではなく、少しずつ開発してレビューしてもらう。
所謂アジャイル開発的な手法で進めるのがベストだと思います。
そちらの方が要求変更に対する開発側のリスクも抑えられますし、現場からしても実際にシステムを触りながら改善案をブラッシュアップできるのでWin-Winだと思いませんか？

ITが「天職」の人は職場内に多くない

これは組織によるところが非常に大きいと思いますが、少なくとも自分の部署はITに強い人は少ないです。
自分の会社の場合だと、優秀なIT人材が全て情シス部門に抜かれており、現場にいるIT屋は他の技術屋からのスキルチェンジパターンが多いからというのがあります。
そこから上手くいくパターンもあるかもしれませんが、どうしても不得意分野だと分かっているけど仕方なくIT系をやっている人が多くなりがち です。
その影響で、最先端の技術ではなく既存のレガシー技術で何とかされているプロジェクトというのが往々に存在します。

最先端の技術を使って効率的に開発したい！と言った場合には、それ相応の時間と権力が必要です。新規プロジェクトに携わり、その技術選定に関与できるような信頼と技術力や発言力を身に着ける必要がありますので、手っ取り早く市場価値を高めたい人には向かないかもしれません。

ドキュメント(仕様書)が少ない

業務改善系のプロジェクトだと、「とりあえず動くものを作る」という事に重きを置かれがちのようです。
それ故に、設計書が開発者の頭の中にしか存在しないタイプのシステムが多く現存しています。しかもそういうタイプのシステムに限って既に開発者がどっかに飛ばされていたりします。
こういったケースは特にマクロやAccessで作られたシステムに多く、誰も保守出来ないブラックボックスを生むことになるので気を付けましょう。

要件定義・設計編

現場の要求をそのまま仕様にしてはいけない

システム開発をしているよくある事。「前言っていた事と違う話が出てくる」ケースです。
これがなぜ起きてしまうか。以下は個人的な見解です。

まず要件定義をする際、システム開発の経験がある人は「細かく定義して欲しい(じゃないと手戻りが発生するから)」と思うでしょう。しかしIT系以外の人はそのような事は知らないので、「伝えやすさ」を重視して細かい例外パターン等を省いた要求仕様を伝えようとします。

なので、要件定義をする際(ヒアリング時)にはとにかく話の深堀りをしましょう。
「~という前提の仕様になっているが、こういったケースは無いのか？」
「~が起きたらどうなるのか？」

大抵伝えてないか失念しているだけで、基本的に出てくる仕様には例外処理が存在するのです。そういった前提でヒアリングするだけで開発時の手戻りが最小限に抑えられます。

また、ヒアリングしている人が実際の業務担当ではない場合(管理職や現場監督等、指示を出す側の人)は特に注意が必要です。大抵その人が知らないような細かい話が実際の業務には存在します。それを防ぐために、ヒアリング時は必ず実際の業務担当からも話を聞くようにした方が賢明です。

仕様変更は「前提条件」にした方が良い

前述のとおり、業務アプリにおいては仕様変更が頻繁に起こります。
そういった場合に変更しずらいような設計になっていると最悪作り直しになってしまいます。
そのため、効率的に開発を行うには初めから仕様変更を前提にした設計にすることが重要です。
具体的に次の事を意識するのが個人的におススメです。

モジュール分割

長い関数・クラスは見づらいだけでなく、機能変更時に修正箇所を探すのが大変になったり、修正時の影響範囲が広くなったりなどといった問題が発生するので、長い関数は基本的に分割した方が良いです。自分の基準だと、関数は50行、クラスは300行を超えた場合は分割を考えます。

レイヤー分け

モジュール分割同様、レイヤー分けも大事です。DB操作やUI表示、ビジネスロジック(ドメイン)といった単位で適切にレイヤーを分けると、仕様変更時にどの箇所を変更しやすいか非常に管理しやすいです。逆にこういったことがされていないと、DB操作の変更をしたいのに関係ないUI表示のコードを閲覧する羽目になったりして余計なコストがかかる事になります。

凝集度・結合度

高凝集・疎結合な設計になるように心がけましょう。多分これが一番大事です。
経験上、機能変更するとすぐにバグが発生するようなシステムは大体これの逆(低凝集・蜜結合)になっています。とりあえずモジュールには単一の責務を持たせ、モジュール同士の依存度を極力下げるように意識するだけで断然保守しやすい設計になります。

依存方向は「変更が多い方」から「少ない方」に向ける

変更が多いモジュールに依存する処理が多いと、その分変更コストが高くつきます。なので予め「変更が多いだろうな」と予想されるモジュールに依存する処理を書かないこと。また、途中で変更が多くなった場合は依存の方向を変えるようにする等の工夫をするとその後の保守が楽になります。また、変更が多いモジュール同士を結合する場合は、仲介役の様な関数やクラス(Adapter)を用意すると変更に強くなります。

実装編

やっつけ感のあるコードになりがち

業務改善系のプロジェクトは、課題を早く改善したいという思いから開発スピードを重視しがちです。それ故にやっつけ感のある汚いコードが生まれる事が良くあります。
そしてそのまま放置し、更に機能追加までしてしまうと、見るも無残なスパゲティコードが完成してしまいます。それを防ぐために、時間がある際にリファクタリングをするといいでしょう。急ぎでなければ、機能追加と同時にリファクタリングするのが時間を効率的に使えておすすめです。

コードの解読に業務知識が必要

業務ルールというのは実に多種多様です。そしてそれを知らない人がコードの保守に当たる場合、「何でこんなコードが存在するんだ？」といった疑問を持たせ、解読に時間をかけさせることになります。最悪そのコードが無駄だと判断され消されることもあるかもしれません。
それを防ぐためには、「これはこういう理由でこのようなコードになっている」というのをコードを触る人に知らせておく必要があります。時間に余裕があれば業務知識をドキュメントやコメントで残しておくといいかもしれません。

保守・運用編

意外と導入までが長くなりがち

システムが完成しました！→即導入！とはいかないのが世の常です。そしてそれは業務アプリについても同様です。現場の強い要望から生まれたシステムであればいいのですが、トップダウンで開発したシステムだと現場から拒否反応を示される場合もあります。(大体それは現場へのヒアリングを十分にしていなかった時によく起こります)
逆にボトムアップで開発したシステムだとトップ層への説明が必要になったり、社内で規定された業務だとその規定を変更しなければならない等で上手く導入に至らない事が多いです。

スケジュールを立てる時には、開発終了から導入までシームレスに行くとは思わずに長めに設定した方が現実に即したものになるかもしれません。

気付いたら想定より複雑なシステムが完成しがち

仕様とは最初から完璧に想定できないものです。現場からの追加要求だったり、作っている最中に気づいた例外処理や定義漏れの要件などを逐次実装していくと、当初の想定よりも2~3割は巨大なシステムになります。小規模プロジェクトだろうと舐めていると大体こうなるので気を付けましょう。

まとめ

以上、工場内で２年間業務アプリ開発をして分かった事についてでした。
この仕事は最先端のIT技術に触れずらいというデメリットはありますが、様々な業務知識が増えるので結構面白いです。後これは職場にもよると思いますが配属＝即戦力扱いされ、1~2年で顧客との調整や設計・開発などを幅広く経験する事ができるのでこれもまた面白いです。
今後も気付いた事があればまた共有してみようと思います。