業務改革のすすめ（ITシステム開発部門編）

１．よくある問題点

（１）技術者はベテランばかり

ITシステムは、稼働してからシステムトラブルがあってはなりません。仮に不測のトラブルが発生したとしても、すぐに復旧してユーザー側に迷惑をかけないことが求められます。

長年安定稼働してきたシステムほど、システム運用上でのトラブル発生時の対応手順が定着しており、ユーザー側も安心して利用できることに価値を感じていることが多いです。

このようなITシステムの開発部門では、経験年数が20年以上のベテランが揃っており、これまで培ってきた技術やノウハウをもとに、定期的なメンテナンスや小規模改善、問い合わせ対応などを行っていることが多いです。一定のシステム利用料が収益となるため、必要最低限のリソースのみを維持していくようになっていきます。

（２）開発者が不足している

時代の流れとともに周りの環境変化により、システム仕様など改変が必要となります。ところが、いざ改修しようと思っても、対象システムの開発者を調達できない状況が散見されます。ITシステムの改修頻度が少ないため、開発者を維持することが難しいことがその理由です。

協力会社に対象システムの改修ができる開発者が存在する場合もありますが、「他の案件にその技術者を割り当ててしまった。すぐに改修したいと言われてもムリだ」と断られるケースも多々あります。

（３）開発者同士の連携がない

ITシステムは、いくつかのアプリケーションが連携して構成されていることがよくあります。例えば、「サーバアプリケーションとクライアントアプリケーション」「集計用サーバアプリケーションと中継用サーバアプリケーション」といった構成です。

これらは、ユーザー側がITシステムを利用するうえで密接に関わるアプリケーションですが、役割が分かれていて、お互いのインターフェース仕様に基づいて開発されています。

長年ITシステムに携わっていても、自分の担当しているアプリケーションのことはわかっても、連携元や連携先のアプリケーションがどのような構造になっているかは、意外とわかっていないのが現実です。

２．よくある原因

（１）技術が古い

IT企業であれば、世の中のトレンドに乗り遅れないよう最新の技術を取り入れて事業拡大を狙います。新たな技術は若手社員や新入社員が柔軟に取り込んでくれるでしょう。

ところが長年使われているITシステムにおいては、若手社員や新入社員では対応することが難しいです。システム開発言語や開発手法が古いことが、組織の硬直化を生む原因としてあげられます。

（２）個人ノウハウとなっている

ITシステムの開発内容がドキュメント化されておらず、個人ノウハウとなっていることも組織の硬直化を生む原因です。

ITシステムを初期開発していた当時は、ドキュメントやマニュアルも整備していました。ところが、これらのドキュメントやマニュアルは、書いた人にしかわからないような記載がされており、属人的な内容となっていることが多いです。第三者が見てわかる記述内容でなくとも、次案件も同じ開発者が担当することになっていたからです。

また、初期開発以降の追加開発により機能が膨大となって巨大化したシステムは、構造が複雑となります。さまざまな開発者が改修に携わったなどの理由から、個別の改修内容を示したドキュメントは作成されても、ITシステム全体を表すドキュメントの更新は置き去りになってしまいがちです。

３．業務改革のポイント

（１）外からのアプローチが重要

硬直化してしまっている組織では、改革を進めようにも開発者からの協力が得にくい傾向にあります。なぜなら、長年培ってきた開発手法を変えろと言われても何をどのように変えればよいか、変えることによって何が自分たちにとってよくなるのかがわからないためです。

それに気づかせることができるのは、自社や組織にしがらみのない外部の人材です。客観的に見て、何がよくて何を改善しないといけないのか、その理由は何かを指摘することができるからです。さらに、自分たちでは気づいていない事業の「強み」や「弱み」が、外部の人材からの指摘によって浮き彫りになるというメリットもあります。

改革するためには、どこに問題があるのか、どこを改善すればよいかなど、忌憚のない意見を出してもらうことが大切です。

（２）ノウハウはすべてドキュメント化する

開発手法は古くとも、実現しているロジックやしくみは貴重なノウハウの塊です。このノウハウは継承しなければなりません。何の目的でこのようなロジックになったのか、ユーザー側の要求仕様や業務要件のどの部分を実現しているのかなど、後から第三者が見てわかる内容に仕上げる必要があります。

そのためにも、当事者だけでなく第三者も交えてドキュメント化を進めることをおすすめします。プロジェクトチームなどの体制を構築し、何をドキュメントに記載するのか目的を明確にしたうえで取り組むことが大切です。

（３）自ら作らないことも大切

あえて自分たちでは作らないこと、開発しないことも大切です。自分たちだけで対応するために必要以上に人的リソースを抱え込んでしまっては、業績にも影響を及ぼします。

内製化だけでなくパートナー企業との協業も視野にいれて、ITシステム開発ノウハウを継承することも重要な選択肢です。

４．実施する際の留意点

（１）業務改革はトップダウン＋ボトムアップで

業務改革の必要性を、組織全体で共有しましょう。業務改革が進まない理由の一つに、経営層だけで目標を設定し、トップダウンで実施を決定してしまうことがあげられます。日常の仕事をこなしながら、業務改革の仕事までも追加で押しつけられ、しかも残業時間も抑制される、こういった状況では組織内の開発者は動きません。

膝を突きあわせて現状の問題点を共有し、経営層・開発者の双方で改善点を話し合い、硬直化していることのデメリットを共有し、双方が同じ目標に向かって実行することが重要です。

（２）継承し続けることを意識

業務改革は単年度で完遂できるものではありません。中長期的な視点で、計画的に改善を進めていきましょう。単年度毎の効果目標を設定し、新たな人材の投入や役割分担の見直しなども踏まえて、継続して取り組むことが重要です。

ITシステム構築や運用における貴重なノウハウや特殊な技術を、事業の「強み」として継承していきましょう。

５．終わりに

硬直化したITシステム開発部門での業務改革について解説しました。組織の中で同じ開発に長く携わっていると、知らず知らずのうちに外部との接触機会も減って硬直化してしまいがちです。

本記事が、硬直化したITシステム開発部門での業務改革の参考になれば幸いです。