フルスクラッチは体力

開発手法の選択

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

SESのリスク

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

技術の総合力

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

表層の即効性

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

まとめ

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

関連記事

開発の遅延「技術的にはできます」の罠

素人仕様と開発遅延

なぜ、システム開発の進捗が悪いのか?
それは、ずばり素人が考えた仕様を開発者に伝えてしまうからである。
すべての原因ではないが、もしシステムのユーザー側の現場担当者や営業担当者がシステム仕様を決めている場合は、ほとんどの場合で満足のいくスピード感はだせていない。

潜む技術的負債

システム仕様さえ伝えていれば、きちんと動くものを作ってくれるので、あとはスピードを上げるだけ。と考えているようであれば、技術的負債が溜まっていることに気付けていない。非エンジニアが決して理解できない技術的負債の怖さは、開発スピードが遅いということだけではない。開発者側から見てシステムが複雑になっていて、メンテナンス性も低い状態になっている。

「できます」の罠

非エンジニアには技術的負債は見えないし説明もわからないことと思う。しかし、技術力でカバーしてくれているから、きちんと動いているのだと思っているなら、それは実は技術力ではない。
「技術的にはできます」このような言葉を聞いたことはないか?
システムエンジニアは「できない」と言えない。「できないことはない」ということが価値なので、素人が考えたシステム仕様でも、言われた通りに作ってしまう。

持続可能な開発へ

システムエンジニアから「技術的にはできます」を聞いたときは、いったん立ち止まるべきである。
エンジニアには、様々な影響範囲や未来のメンテナンス性への懸念などが見えている。これを必要以上のコストだと考えるのか、必要コストと考えるのかで、技術的負債は変わる。

まとめ

自分の理解の範囲でしか人間は発想しないので、システムのことを知らない非エンジニアは、システム仕様を考えるべきではないと言える。また逆に、システムにおいてはシステムエンジニアの方が発想の幅は広いが、業務に関する知識は乏しい。
システムをよく知り業務のこともわかるシステムエンジニアがシステム仕様を考えるべきだが、そんな万能な人は多くはない。だから、その間を取り持つ人間が重要なのである。

続きを見る >

マニアの逆効果

趣味の進化

趣味やコミュニティにファンが定着しないという話をよく耳にする。この現象を理解するには、戦後日本の変遷を振り返る必要がある。高度経済成長期に入ると、人々の可処分所得が増加し、余暇時間も確保されるようになった。これに伴い、日本人の趣味の選択肢は爆発的に広がっていったのである。

IT黎明期

そんな多様な趣味の選択肢の中から、パーソナルコンピュータという新しい文化が誕生した。初期のパソコンマニアたちは、その後のIT業界の礎を築いていった。彼らの情熱と探究心は、技術革新の原動力となったのである。ユーザー数が増加するにつれて、独自の用語やネットスラング、コミュニティ文化が形成され、デジタル時代特有の新しいコミュニケーション様式が確立されていった。

マニアの防衛

しかし、ユーザー層が拡大するにつれて、必然的にライトユーザーや一般層の参入が増えていった。この変化に対して、コアなマニア層の中から、自分たちが築き上げた文化や価値観を守ろうとする動きが現れる。彼らは意図的に専門用語を多用したり、新規参入者に対して高い障壁を設けたりすることで、独自の世界を保持しようとした。このような排他的な姿勢は、結果として健全なコミュニティの成長を阻害する要因となったのである。

IT変革期

このような状況は、しばしば「マニアが業界を衰退させる」という批判の対象となってきた。IT業界を例に取ると、黎明期には「オタク」というレッテルを貼られ、社会的偏見にさらされることも少なくなかった。しかし、ITバブル期に入ると状況は一変する。テクノロジーの急速な発展と共に、IT関連の職種は一気に注目を集める花形職業となっていったのである。この変化は、マニア文化が一般社会に受け入れられていく過程を象徴的に示している。

まとめ

現代では、パソコンの使用者をマニアと結びつけて考えることはほとんどなくなった。しかし、同様の現象は量産型のプログラミング業務の中でも起きていた。ローコード開発の台頭により、プログラミングは特別な知識を持つ人だけのものではなくなり、誰もが気軽に扱える時代となったのである。

続きを見る >

Excel業務のDX化は本当に必要か

DX化の現状

多くの企業でExcel業務のDX化が話題になっている。「Excelは古い」「すぐにシステム化すべき」という声も聞かれるが、本当にすべてのExcel業務をDX化すべきなのだろうか。実は、やみくもなDX化は逆効果になることも少なくない。Excel業務のDX化には正しい順序と判断基準が必要である。本記事では、DX化の利点を理解しながら、適切なアプローチについて考えていく。

DX化の利点

Excel業務をDX化することで得られる利点は確かに多数ある。まず、データの一元管理により情報の正確性が向上し、複数人での同時編集や更新作業がスムーズになる。次に、自動化による作業時間の大幅な削減が可能である。手作業で行っていた集計や転記作業から解放されることで、より付加価値の高い業務に時間を使えるようになる。さらに、データ分析の高度化により、経営判断のスピードと精度が向上する。これらの利点は、企業の競争力強化に直結する重要な要素である。

DX化の落とし穴

しかし、DX化を急ぐあまり失敗するケースも多く見られる。業務フローが整理されていない状態でシステムを導入すると、非効率な業務がそのままシステム化されてしまう。また、現場の声を聞かずにツールを選定すると、使いにくいシステムが現場に定着せず、結局Excelに戻ってしまうこともある。さらに、すべてを一度に変えようとすると、従業員の負担が大きくなり、業務が混乱する。投資したコストに見合う効果が得られず、DX化自体が目的化してしまう危険性もある。適切な準備なしのDX化は、かえって生産性を下げる結果を招くのである。

正しい進め方

Excel業務のDX化を成功させるには、段階的なアプローチが不可欠である。まず、現状の業務フローを可視化し、本当に必要な作業とムダな作業を明確に区別する。次に、Excelで十分な業務と、システム化すべき業務を見極めることが重要である。すべてをシステム化する必要はない。その上で、優先順位をつけて小さく始め、効果を確認しながら展開していく。従業員のITリテラシーに応じた教育も並行して行うことで、スムーズな移行が実現する。DX化は手段であり目的ではない。自社の状況に合わせた最適な方法を選ぶことが、真の業務改善につながるのである。

まとめ

Excel業務のDX化は、正しく進めれば大きな効果をもたらすが、順序を誤ると逆効果になる。利点を理解しつつ、自社の状況を冷静に分析し、段階的に進めることが成功の鍵である。やみくもなシステム化ではなく、業務改善を第一に考えた戦略的なアプローチを取るべきである。

続きを見る >