QCDの死角

内製化の壁

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

経営コミット

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

失敗回避策

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

仕組み化

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

まとめ

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

趣味の進化

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

IT黎明期

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

マニアの防衛

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

IT変革期

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

まとめ

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

営業依存の弊害

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

役割の細分化

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

開発の本質

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

相互理解

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

まとめ

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