フルスクラッチは体力

開発手法の選択

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

SESのリスク

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

技術の総合力

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

表層の即効性

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

まとめ

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

関連記事

内製化人材戦略

内製化の壁

システムの内製化が重要ということは、どこでも聞くと思う。しかし、具体的に内製化していくための段取りを整理して教えてもらうのは難しいのかもしれない。業種業態によって様々なケースが存在するからである。内製化を成功させるには、単に技術的な知識だけでなく、組織全体での戦略的な取り組みが不可欠となる。

経営コミット

システム開発の内製化を行っていくには、まず経営層からのコミットメントが必要不可欠である。これが必要であるから諸外国ではCRO(Chief-Revenue-Officer)という部門を横断した権限を持つ人を据えている。その上で、まず内製化の目的を明確にする。おおむねコスト削減、スピード向上、ナレッジ蓄積などであろう。目的がきまると、企画、開発、保守、インフラなどのどの範囲で内製化するのが見えてくる。組織全体での合意形成が内製化成功の基盤となるのである。

失敗回避策

よく聞く失敗例では、権限のないIT戦略室、デジタル推進部などを作ってしまうことである。あるいは、適切な人員の配置や育成がなされないパターンも同様である。大きな権限を持つことになることを前提に考えると、実施するプロジェクトについても小さなプロジェクトにおいて実績を積み上げたほうがいいだろう。たとえば、小規模低リスクである業務改善ツール(例:Power AppsやExcelマクロ)から市民開発を実施していくなどを計画することをお勧めする。段階的なアプローチが組織の信頼獲得につながる。

仕組み化

小さなプロジェクトで実績を積むと、こなれてきてしまうため、やはり属人化の危険性が伴う。ここで、いかに永続的に考えることができるか、内製化のための仕組みを構築できるかは、システム開発経験者などの知見のある人も交えて人材育成に取り組むべきである。定期的な振り返り(レトロスペクティブ)やナレッジ共有会、現場からの改善提案を吸い上げる文化を育て、仕組化していく。持続可能な内製化には組織文化の変革が欠かせない。

まとめ

開発基盤とガバナンス整備、ソース管理やドキュメント管理などの定性的な内製化は簡単に作ることができる。しかし、そのマインドや仕組み、自然とDevOpsをはじめとしたPDCAサイクルにもっていくには、システム知見だけでも難しくある。持続的な内製化にたどり着くためには最初の企画や構成段階で知見をもつメンバーを入れておくのがよいだろう。

続きを見る >

システム開発の混迷

営業依存の弊害

業務システムがうまくいかないのはベンダーやSEの問題だけではない。SEを取り巻く環境もシステム開発には重要である。業務システム開発を依頼するベンダーであれば営業担当者が挟まる。日本の縦割り社会の中で営業担当者は非エンジニアである場合が多く、プロジェクトの成功が目的ではない場合がある。

役割の細分化

SEをプロジェクトマネージャーとしている場合も注意が必要である。日本ではシステムエンジニアは細分化されておらず、建築でいうと参加者の全員が職人という扱いであることが多い。システムに関わる人全員がSEとしてしまっている間違いである。

開発の本質

SEやベンダーのプロジェクトマネージャーはそれ自体がプロジェクトと考えていることも多く、ビジネスとしてのプロジェクトとして捉えることができていないことがある。本来はビジネスが中心にあって、その中に業務システムが位置するはずである。それが見えているか否かで、業務システム開発の成功の確率は変わるのである。

相互理解

逆に、システムのことはSEに任せているというような場合も注意が必要である。システムのプロジェクトを経験したことがある、というだけでは、システムに関連するプロジェクトを成功させるのは困難である可能性が高い。プログラミングの経験がなければ、SEやベンダーが持つ心境を察することができないからである。最も重要なことはシステム導入時のイメージである。

まとめ

欧米では当たり前のように、間接的に関与する売上や利益の向上を管掌する部門や役職があるが、日本では良くも悪くもロジカルであり、数字がなければ行動に移せない厳密なルールがある。

続きを見る >

DX担当者の孤立問題

孤立の背景

DX推進担当者は、多くの企業で孤立しやすい立場にある。経営層からは変革の旗振り役を期待される一方で、現場からは通常業務の妨げと見なされることも少なくない。本来、DXは全社的な取り組みであるにもかかわらず、実際には担当者個人に責任が集中し、社内で十分な協力を得られないまま奮闘しているケースが散見される。この構造的な問題が、優秀な人材ほど疲弊し、離職につながる原因となっている。

板挟みの構造

DX推進担当が孤立する最大の要因は、経営層と現場の認識のギャップにある。経営層は売上向上やコスト削減といった抽象的な目標を掲げるが、それを具体的な施策に落とし込めていないことが多い。一方、現場は目の前の業務遂行に追われており、DXの必要性を感じていても「余裕がない」「やり方がわからない」と抵抗感を示す。この間に立つ推進担当者は、経営層の意図を現場に伝え、現場の声を経営層に届けるファシリテーターの役割を求められる。しかし、十分な権限や予算が与えられないままでは、単なる調整役に終わってしまう。

巻き込みの要点

社内を効果的に巻き込むには、三つのポイントが重要である。第一に、経営層のコミットメントを可視化することだ。経営層がDXの重要性を明確に発信し、推進担当者に権限と予算を付与することで、現場の協力を得やすくなる。第二に、部門横断型チームの編成である。各部署から選出されたメンバーでプロジェクトチームを組織し、多様な視点を取り入れながら推進することで、全社的な当事者意識を醸成できる。第三に、小さな成功体験の積み重ねである。大規模な変革を一度に進めるのではなく、パイロットプロジェクトから段階的に成果を示していくことで、現場の抵抗感を軽減できる。トップダウンとボトムアップの両面からアプローチすることが、巻き込みの成功につながる。

孤立防止の仕組み

孤立を防ぐためには、組織としての仕組み作りが欠かせない。まず、DX推進パートナー制度の導入が有効である。各部門に選任担当者を配置し、推進部門との距離を縮めることで、現場の課題を吸い上げやすくなる。次に、定期的な成果報告の場を設ける必要がある。経営層へのプレゼンテーションや社内への進捗共有を通じて、DXへの期待感を形成できる。また、現場の声を積極的に取り入れるフィードバック体制も重要である。デジタルツールを活用したアンケートやワークショップを定期開催し、改善策を現場と共同で立案することで、より実効性の高いDXが実現する。推進担当者を孤立させないことが、DX成功の大前提となる。

まとめ

DX推進担当者の孤立は、経営層と現場の板挟みという構造的問題から生じる。これを防ぐには、経営層のコミットメント可視化、部門横断型チームの編成、段階的な成功体験の積み重ねが重要である。組織的なサポート体制を構築し、担当者が一人で抱え込まない仕組みを作ることが、DX成功への第一歩となる。

続きを見る >