記事

フルスクラッチは体力

開発手法の選択

フルスクラッチかパッケージか、最近ではSaaSなどもシステム構築の検討に入る。実は開発手法やツールよりも、どのようなシステムで、どれくらいの規模のシステム開発会社が担当するかが重要である。

SESのリスク

人数が多い会社であればあるほど安心感があってよいと安易に考えることは適切ではない。なぜなら、SE派遣やSESと呼ばれる人月（人工）単位で売り上げの経つ会社には技術の総合力がないからである。

技術の総合力

技術の総合力とは、SE作業やプログラミング作業などの1人で対応できる技術力を差すのではなく、システム構築やシステムの運用全般における最適手段を考えることができる能力のことである。

表層の即効性

SE派遣やSESの付加価値はその人単体のプログラミング能力に偏るため、一見対応がよく、何も問題がないように思える。しかし、これが技術的負債を作ってしまうひとつの要因でもある。

まとめ

フルスクラッチを考えるなら、SESを中心としないシステム会社で且つ人数規模も多い方がよい。安価にフルスクラッチでシステムを構築してしまうと、メンテナンスや運用でしっぺ返しが待っている。時間が経つごとにシステム保守費用が高くなるのである。

運用の昇華 前の記事 賢いコスト削減 次の記事

関連記事

記事

DXの始め方

DX着手の課題

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

優先順位の決定法

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

スモールスタートの原則

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

経営者主導の重要性

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

まとめ

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

続きを見る >
記事

リーダーの多忙による弊害

危険な繁忙化

なぜか忙しくしているPMやリーダーとなるSEがいれば危険信号である。リーダーが忙しくなると全体的な最適化や効率的な運用ができていない可能性がある。結果として、無駄に費用がかかったり、技術的負債が大きくなったりする。

役割分担の歪み

システムのユーザー側から見ると、SEという見え方しかしないと思われるが、実際はシステムの運用や開発には細かな作業分担が発生する。この作業分担ができていない場合は窓口のSEが余計な作業を行っている可能性がある。役割分担の不均衡がもたらす忙しさではなく、まったく仕事としてやらなくてもよいような事に時間を使っていて忙しい場合がある。

プロセスの確立

たとえば、プログラムが解析できる人をリーダーとしてしまうと、開発者に手取り足取り指示をしてしまうことがある。もし、リーダーがプログラムレビューなどの作業や、開発者にプログラム上の細かな指示をしている場合は注意が必要である。何を基準にプログラムレビューや指示を行うのか、という仕事を見える化し、仕組化することがリーダーの務めである。

俯瞰的視点

木を見て森を見ずという言葉があるように、リーダーとなる人は指針を作ったりメンバーをプロジェクト成功へ導く役割がある。リーダーが開発メンバーと同じように木ばかりを見ているようであれば、森を見る人が非エンジニアであるユーザー側となってしまうことが考えられる。

まとめ

誰が森を見るのか、リーダーやPMが常に忙しそうにしている場合は、何に時間を使っているのか調査する必要がある。実はここがボトルネックになっていてプロジェクトの進行が思うようにいかなかったり、頻繁にリスケが発生していることも多くある。しかし、これは本人にヒアリングするだけでは表面化しないため、ユーザー側の担当者やプログラマーなどの周辺人員から浮き彫りにすることが望ましい。

続きを見る >
記事

市民開発とは何か

市民開発の正体

市民開発（Citizen Development）とは、IT部門やSIerに依存せず、業務部門などの非エンジニアが自らアプリケーションを作成する取り組みを指す。従来は「プログラミングができないと無理」と思われがちだったが、現在ではノーコード・ローコードツールの登場により、非技術者でも業務に必要なツールを構築できるようになった。代表的なものとして、SaaSベースの業務アプリやMicrosoft Power Platformなどがあり、これにより業務現場の課題解決が加速している。

IT不足とマクロの功罪

市民開発が注目を集める背景には、深刻なITエンジニア不足がある。人手が足りないなら自ら開発するしかない——この流れが市民開発を後押ししている。その原型とも言えるのがExcelマクロである。かつて現場では、個人PC上で動作するマクロが業務改善ツールとして使われていたが、多くが属人化し、結果として保守不能な“遺産”となってしまっている。

マクロの限界

Excelマクロの最大の弱点は「ファイル単体依存」である。複数人での同時使用や、プログラムの共有に極めて不向きである。マクロ付きファイルをコピーすれば、そのコピーごとに独立した修正が可能となり、誰がどのバージョンを使っているのか把握が困難になる。しかも、更新履歴の管理も難しく、組織全体の業務統一を図るには限界がある。こうした特性が、非効率と混乱を招く要因となっている。

マクロの呪い

属人化の果てに起きるのが「ブラックボックス化」である。Excelマクロにパスワードがかけられ、開発者も不在、しかし業務には不可欠——そんな状態が現場には数多く存在する。これらは情報システム部の管理外にある「野良プログラム（シャドーIT）」と呼ばれ、セキュリティリスクを高める要因でもある。結果として、誰も触れず、誰も捨てられず、今も現場の根幹に鎮座している。まさに、手遅れになる前に対処すべき課題だ。

まとめ

市民開発は、Excelマクロに代わる次世代の業務改善手段となり得る。ローコード・ノーコードの活用により、野良プログラムの乱立を防ぐには、組織としての運用ルールとガバナンスの確立が不可欠だ。アタラキシアDXでは、Power Appsを活用し、手遅れになる前にブラックボックス化したマクロのリプレイス支援を行っている。

続きを見る >