Zenn
😇

現場改善#023 内製開発のその後

2022/12/24に公開
#
現場改善
#
内製開発
tech

あらまし

もともと社内開発は汎用機しかなく、その技術者もすでに退職済み。オープン系の開発は皆無。全社的にPC導入が徐々に進んできてはいるが、まだ部署に数台でExcelでの作業に一部の方が慣れてきた程度。
そんな会社の中で、C#を使って社内開発を進めてみたところ、いろんな部署から問い合わせや頼み事、相談事が来ます。

社内で課題を抱えている役職者やリーダーからすれば、社内開発で予算もないところから、突然システムが生えてくるのです。使わない手はありません。

頼られると、ついつい調子に乗ってさまざまなアプリを社内向けにリリースし、業務に組み込まれて、4,5年経過したあたりから徐々に困った事態が顕在化します。

  • システムの不具合対応
  • システムからのデータ抽出対応

こんなケースがほぼ私しかできない作業になってしまいました。上司に作業内容について、報告はしていますが理解はしていないので、当たり前です。

当然、私自身も社内の体制強化を上司に訴えてはいましたが…

課題

内製開発を続けた結果、下記の課題が見えてきました。

  1. C#による開発が情シスの必須スキルになり、上司の認識している必要なスキルセットとギャップが広がっていた
  2. 経営層や管理職が内製開発することで発生する、保守やリプレースに必要なコストや人員を意識しないままシステムが稼働してしまう
  3. 一度運用開始すると、システムが不具合で動かないことが業務継続できない理由とされてしまう
  4. 教育体制が整備できていない

といったデメリットがありました。特に担当者間で運用開始してしまった、小規模なツールなどは、不具合や運用の変更によって使用できないと至急の対応を要求されるケースがあり、自分が良かれと思って作成したシステムに首を絞められる事態に陥りました。

また、求人を出してもそもそも応募者が少ないので選べない状況にありました。推測ですが、

  • 車が無いと通えない位置
  • 製造業の給与体系のため、かなり給与が安い

という2点が大きく影響したように思います。そのような中、開発スキルを持っている方はほぼ皆無でした。

対策

結果、地方情シスで内製開発体制を維持するのは難しく、下記の対策を進めました。

  • 社内開発は極力減らす
  • ローコード開発について調査し、リプレース可能なものは移行する
  • 求人に開発スキルは不問にする
  • 安易に内製開発しない(=外注と同じように内部リソースを使用する手順が必要)
  • リプレースのタイミングで協力会社に再構築を依頼する

可能な範囲で対応を進めましたが、最終的に転職をしたので詳細は把握していません。

もう一度同じことをするなら

情シスの開発要員が自分だけであれば、下記の運用が良かったのかな？と思っています。

  • 内製開発は原則しない
  • 開発に類する案件はノーコード開発(Kintone/UnitBase)とワークフロー関連にできるだけ留める
  • 情シスの役割はノーコード開発(Kintone/UnitBase)の問い合わせや指導ができるスキルを持つこととし、実作業は行わない
  • 社内でノーコード開発(Kintone/UnitBase)に必要な基盤となるマスタ情報を適切に提供できるようデータ連携システムを管理・運用する

どうしても内製開発せざる得ない場合は

  • 原則としてローコード開発ツール(OutSystems、intra-mart、WebPerformer)を使用する
  • かならず保守とリプレースに関する予算を認識してもらう
  • 他部門に影響するシステムであれば、部門長同士で認識を合わせ、議事録を残す
  • 外注した場合の試算コストと複数名体制についての打診
  • Redmineで仕様書や仕様変更の経緯を残す

を実施し、承認を得た場合に限定して対応するよう心掛けています。特に関係性が良好な社員間で作成したシステムが後任に引き継がれた途端、「システムが使えないから業務ができない」というケースは後から回避するのが厄介なケースなので、稼働前にシステムトラブル時の対応については、システム化する前の方法で対応できるようにしておく事を部門長同士で認識しておくことが重要だと今なら思えます。

仮に業務で使用するシステムで、停止が許されないのであれば、フェイルオーバー構成は必須で、保守も24x365で契約しますよね？そのコストを自分たちも理解しないまま、情シスで被ってしまってはいけません。

Discussion