フルスクラッチは体力

開発手法の選択基準

大がかりなシステム開発においては、ウォーターフォールモデルという開発手法がとられ、設計書などのドキュメント類も整理してから、プログラミングへ着手する。逆に中小規模なシステム開発においては、アジャイル開発と呼ばれ、プログラミングをしながらシステム開発が進められたり、ドキュメント類は簡易にして、プログラミング工程へ着手するといった方法がとられる。状況に応じて開発手法は使い分ける必要がある。

設計書の必要と課題

建築では図面なく建物を建てることはないが、中小規模のシステムについては簡単な概要だけでシステムの開発ができてしまう。もちろん設計書をしっかりと書いて、要件を詰めてシステム開発を進めることができれば、トラブルもなくていいのではないかと言われる。しかし、設計書を作成するにはシステムをプログラミングすることと同じくらい費用が掛かる。

設計書の粒度と要因

中小規模のシステム開発において設計書が簡易になってしまう理由は、ユーザー側や発注側の予算が乏しいという理由がある。建築のパターンの場合は、法律によって作成しなければならない図面や、施主から同意をもらうべき書類などが決められている。システム開発には法的に作成しなければならない書類が明確にされているわけではないため、この粒度が各社・各エンジニアによりバラツキが発生する。

文書管理の現状

中小規模のシステム開発において、最悪の場合は設計書がないケースもある。小さなプロジェクトの場合は予算も少なく特にドキュメント類がないが多くある。あるいは、システムはアップデートされ続けているのにドキュメントはアップデートされていなかったり、ひどい場合にはシステム保守ベンダーが紛失している場合もある。

まとめ

システム開発に時間がかかる理由は、設計書から作成することでプログラミング作業の2倍以上の時間がかかると言われる。いわゆる動作検証の工程まで入れるとプログラミング作業の3倍程度は時間がかかる。また、システム開発はほとんどが人件費である場合が多く、かかる時間に応じて費用が上がる。つまり、非エンジニアが単純に開発費用を値切ると、プログラミング以外の重要な情報を削っていくことになる。

DX着手の課題

「DXを進めたいが、何から手をつければいいかわからない」。多くの中小企業がこの悩みを抱えている。実際、DXに取り組みたいと考えながらも着手できていない企業は約7割にも上るというデータがある。人材不足、予算の制約、そして「失敗したくない」という不安が足かせとなり、一歩を踏み出せずにいるのだ。DX成功の鍵は、最初の一歩をどこから始めるかにかかっている。

優先順位の決定法

DXの第一歩は「業務の棚卸し」から始まる。まず自社のすべての業務を書き出し、どこに無駄や非効率があるかを可視化する。次に、各業務について「改善効果の大きさ」と「導入の難易度」の2軸で評価する。効果が大きく難易度が低い業務こそ、最優先で取り組むべき領域である。たとえば、紙ベースの勤怠管理、手作業での請求書発行、属人化した顧客情報管理などは、比較的着手しやすく効果も実感しやすい分野といえる。重要なのは経営課題と紐づけて考えること。売上向上なのか、コスト削減なのか、目的を明確にすることで優先順位が定まる。

スモールスタートの原則

DX推進で最も重要な考え方が「スモールスタート」である。いきなり全社的な大規模システムを導入しようとすると、多大なコストと時間がかかり、途中で頓挫するリスクが高まる。まずは1つの部署、1つの業務から小さく始めるべきだ。たとえば、営業部門の顧客管理をクラウド化する、経理部門の請求書をデジタル化するといった身近なところからで十分である。小さな成功体験を積み重ねることで、社員のDXへの理解と協力が得られやすくなる。ある建設会社では、現場写真の共有をクラウド化しただけで、1日あたり1時間以上の工数削減に成功した。「まずやってみる」という姿勢が、DX成功への近道なのである。

経営者主導の重要性

DXを成功させるには、経営者自身が旗振り役となることが不可欠である。「現場任せ」「担当者任せ」では、部門間の壁や既存業務への抵抗に阻まれ、改革は頓挫してしまう。経営者がDXの目的とビジョンを社内に発信し続けることで、組織全体の意識が変わる。また、導入後の定着も見据えた計画が重要だ。新しいツールを入れただけでは、誰も使わなくなってしまう事例は少なくない。操作研修の実施、マニュアルの整備、成功事例の社内共有など、継続的なフォロー体制を構築すべきである。DXは一度きりのプロジェクトではなく、継続的な改善活動だ。PDCAを回しながら少しずつ変革を広げていく姿勢が求められる。

まとめ

DXは「どこから始めるか」で成否が分かれる。業務の棚卸しで課題を可視化し、効果と難易度から優先順位を決め、スモールスタートで成功体験を積む。この流れを意識することが重要である。経営者が主導し、全社一丸となって取り組むことで、着実にDXは前進する。最初の一歩を踏み出すことが、企業変革への大きな第一歩となるのだ。

システム開発の現状と課題

数名で開発した初期のシステム構築から、システム会社を変更して大がかりなリプレイスを行い、保守運用を実施しているが、月々の費用が高額であるわりに、開発スピードも遅い。開発スピードが遅いため、新しい機能を実装していけない。

不具合と開発の不透明性

リリースから何年も経っているのに不具合がなくならない。開発会社からの報告が曖昧で何にお金を支払っているのか謎のままであることが多い。

コスト削減と資源最適化

開発スピードを上げるには、システム開発コストの削減をしなければならない。コストを削減するということは、それで浮いたコストを開発に割り当てることができるため、結果的に開発スピードがあがることを意味する。

開発の透明性と妥当性

そのためにしなければならないことは、開発工程や開発過程の見える化および妥当性を担保することである。システムの比較検討ができないため、システム開発のコミュニケーションは一般的なものであると思い込んでいる。システム発注の担当者はシステムのことがわからないから、システム開発の進め方に違和感があったとしても技術者が言うことを信用するほかないと思っている。

まとめ

結果として、技術者の工数と称して月々の費用や、ひどいものでは言語のバージョンアップと称して、何もしていないことに費用を支払っていることもある。不明点はシステム発注の担当者が理解できるまで聞くべきである。