世界ではどのような産業でもITが活用されており、どんな企業でもほとんどがシステム開発部署を持っています。
これまでの日本の産業の多くは情報システム部が存在するものの業務効率化のためのシステム開発と運用を行っていることがほとんどでした。
経済産業省が発表している2025年の崖の問題やデジタル庁の発足は、政府があらゆる産業でITに向き合わないといけないことを伝えたいのだと思います。
さて、そのような時代背景の中、システム開発の内製化はとても重要なファクターで今後の企業生存に関わる重大なテーマです。
今回は、システム開発の内製化について説明していきたいと思います。
目次 [非表示]
開発体制の内製化は何から始める？
システム開発を内製化するというのは業務はもちろんのこと、システムを利用するユーザーや管理運用するエンジニア、さらに経営にも関わる一大プロジェクトで細心の注意と詳細な計画が必要です。
ITエンジニアを募集したりして、人数を集めるだけでは十分な目的を達成することはできないと言われています。
以下に一般的なステップを列挙します。
ビジョンと目標の設定:
内製化の理由と目標を明確に定義します。
これは組織が何を達成したいのか、どの程度の時間とリソースを投資する準備が必要かをプロジェクトメンバーが共通認識するための基盤となります。
今の国内であれば、システム開発やIT部門のスピードアップが目的であること多いと思います。
現状の評価:
既存のITインフラストラクチャ、システム、スキルセット、プロセスなどを評価します。
これによって、どの程度の改善が必要か、または新たに何を加えないといけないかを検討することができます。
技術要件の整理:
内製化するためには、現状の技術要件と将来想定される技術要件を整理する必要があります。
これにはプログラミング言語、データベース、フレームワーク、ツール、プラットフォームなどが含まれます。
人材の確保:
技術要件が整理できれば、どれくらいのITレベルの人が必要か検討した上で、人材を確保したほうがよいでしょう。
内製化には、適切なスキルセットを持つ人材が必要です。すでに組織内に必要なスキルを持つ人材がいる場合は、彼らの役割を再定義することも有効です。
もし必要なスキルを持つ人材がいない場合は、新たに採用するか、既存のスタッフに研修を行うことでスキルアップを図り新たな役割を創設するのもよいでしょう。
プロジェクト管理と開発プロセスの確立:
開発の進捗を管理し、品質を保証するためには、プロジェクト管理と開発プロセスが重要です。
アジャイル開発やスクラムといったモダンな開発手法を導入すると効果的です。
組織の特性や必要なシステムの複雑さによってはステップが前後することもあります。
今の情報システム担当者に内製化ミッションを与える？
すでに情報システムの担当者がいる場合は、システム開発の内製化に近い気がします。しかし、機動力の高いIT部門を作るという意味では、これまでのシステムを作る工程とは別物と考えておいた方がいいかもしれません。
システム構築の簡単なステップは以下の通りです。
基本設計: 要件定義が完了したら、システムの基本設計を行います。これには、システムアーキテクチャの設計、データベース設計、UI/UX設計などが含まれます。
開発:
設計が終わったら、開発を開始します。小規模な機能から始めてテストし、段階的により複雑な機能を追加していきます。常にコードの品質を保つために、コードレビューや自動テストの導入も検討してください。
テスト:
開発が一定の段階に達したら、システム全体のテストを行います。これにはユニットテスト、統合テスト、システムテスト、受け入れテストなどが含まれます。
デプロイと移行:
テストが成功したら、システムをデプロイします。既存のシステムから新しいシステムへのデータ移行も計画に含めてください。
保守と改善:
システムのデプロイ後も、定期的なメンテナンスと更新が必要です。また、ユーザーからのフィードバックを収集して、システムの改善を続けます。
これはウォーターフォールモデルと呼ばれる何十年も続く昔ながらの開発手法です。今では当たり前になったアジャイル開発やスクラムといった手法を前提として組織体制が作れるとよいですが、結局はその方法に縛られてしまうことのないようにしたいところです。
参考までに、スクラムについて解説したいと思います。
スクラム（Scrum）は、複雑な作業を効率的に管理するためのアジャイル開発手法の一つです。特にソフトウェア開発において広く用いられています。
スクラムの主な特徴は以下の通りです。
スクラムチーム: スクラムチームは、通常7±2人で構成され、プロダクトオーナー、スクラムマスター、開発チームの3つの役割があります。プロダクトオーナーはプロジェクトの方向性を決定し、スクラムマスターはスクラムプロセスが正しく運用されていることを確認し、開発チームは実際の製品開発を担当します。
スプリント: スクラムでは作業を一定の期間（通常2-4週間）ごとのイテレーション（スプリント）に分割します。各スプリントの開始時にはプランニングミーティングを行い、そのスプリントで何を達成するかを決定します。
デイリースクラム: 毎日、チーム全員が参加する15分のミーティング（デイリースクラム）を行います。このミーティングでは、前日の進捗、当日のタスク、問題点などを共有します。
プロダクトバックログとスプリントバックログ: プロダクトバックログは、製品に求められる機能や要件のリストで、優先順位が付けられています。スプリント開始時に、チームはこのプロダクトバックログからタスクを選び、スプリントバックログを作成します。
スプリントレビューとスプリントレトロスペクティブ: スプリントの終了時にはスプリントレビューとスプリントレトロスペクティブを行います。スプリントレビューでは、スプリントで得られた成果を評価します。スプリントレトロスペクティブでは、スプリントの過程を振り返り、改善点を見つけます。
スクラムは、フィードバックループを短くすることで、迅速な反応性と改善を可能にすることを重視しています。これにより、変化するビジネスニーズに対応する柔軟性を持つソフトウェアを開発することが可能になります。
また、スクラムは組織が新たなアプローチや技術を採用しやすくするために、コラボレーション、学習、問題解決、自己組織化、クロス機能チームを重視します。これらの価値観と原則を基に、開発チームは自己組織化し、目標達成に向けて最善の方法を見つけ出します。
全体的に、スクラムは高い透明性、柔軟性、反復的な改善を通じて、製品開発の効率と効果性を高めることを目指しています。
システム開発や保守運用のノウハウが属人化していてIT部門が思うように拡大しない
すでに数十人というある程度の規模のシステム運用が行われている状態では、SIerと呼ばれるシステム会社に丸投げされていることも少なくありません。SIerは、中小システム会社から人材を派遣してもらっているという状況が多々あります。
また、派遣で来ているエンジニアが多くのノウハウを属人的に有している場合は、システム内製化に時間がかかることが考えられます。
システム開発や保守運用のノウハウが属人化してしまうと、その人が欠けたときに問題が発生したり、組織の成長や効率性が阻害される可能性があります。そのような問題を解決するためには以下のステップを取り入れることが有効です。
ドキュメンテーション:
開発プロセス、システム設計、コードの構造、運用手順、問題解決手順等、全ての重要な情報を詳細にドキュメンテーションすることが必要です。新しいメンバーが組織に参加したとき、または現在のメンバーが新たなタスクに移るときに役立つ情報を共有しやすくします。
クロストレーニング:
スタッフ間でスキルと知識を共有するためにクロストレーニングを行います。これにより、一人のメンバーが欠けたときでも他のメンバーが役割を担えるようになります。
ペアプログラミング:
ペアプログラミングでは、2人の開発者が一緒に作業を行います。これにより、知識の共有とスキルの向上を促進し、コードの品質も向上します。
コードレビュー:
チーム全体でコードレビューを行うことで、チーム全員がプロジェクトの進行状況とコードベースを理解できます。また、コードの品質を向上させることもできます。
ツールの導入:
プロジェクト管理ツール、バージョン管理システム、知識共有プラットフォームなどを導入することで、情報とノウハウを共有しやすくすることができます。
役割の明確化とリーダーシップの育成: それぞれの役割と責任を明確にし、リーダーシップを育成することで、組織の強化と属人化の防止に役立ちます。
これらのステップを取り入れることで、システム開発や保守運用のノウハウを組織全体で共有し、IT部門の拡大を支えることができます。
内製化にはどのくらいの人数と何をミッションに雇えば良いか？
最初はITコンサルタントを起用するのもありです。
しかし、資料を作るだけのITコンサルではなく実際の開発者と同じ目線で対話できる人がいいでしょう。
ITコンサルの具体的な役割と活動は、組織の特定のニーズや目標、スキルセットや専門性など多岐にわたります。
まず、経営層などのDXが必要とされる場面で、ITコンサルと共に戦略立案と計画策定を行います。これには、主に目標の設定、必要なリソースの評価、時間枠の設定などがあります。
大まかな方向性がきまれば、現状分析に入ります。現在のITインフラストラクチャ、システム、スキルセット、プロセスなどを評価し、強みと弱みを明らかにしていきます。これによって、改善が必要な箇所や新たに必要となるリソースや課題が明確になります。
技術的なアドバイスはもちろんですが、ツールは何を選ぶべきか、どういった技術者が必要か、リソースの確保は可能か、など実際の現場の知見が重要です。日本ではシステムに関するプロジェクト成功率は50%程度と言われております。背景を知っているコンサルタントであればパートナーとして間違いないでしょう。
その他にも、プロジェクト管理などを得意とする人も多くいます。意外と大切なのは一癖も二癖もあるエンジニアとの円滑なコミュニケーションかもしれません。これは組織全体に影響を与える可能性があります。
コミュニケーションの延長ですが、ITコンサルがベンダー管理あるいは、内製化に伴うベンダー調整などが重要です。属人かしたノウハウなどを上手に引き出す手腕が問われます。
ITコンサルタントを選ぶ際には、キャリアだけでなくそこでどのようなポジションを担っていたのか、組織の具体的なニーズや目標に合った専門性と経験を持つ人物を選ぶことが重要です。
自社プロダクト推進をより効率化していきたい
できるだけスムーズな新規事業開発を考える経営者は少なくありません。これまでSIerに頼っていたなら特にその思いが強いかもしれません。徐々に開発体制を内製化したくても、SIerからすると仕事がなくなることを意味します。これまではITのことをよくわかっていない経営層の考えるシステムを、なんとなく作るだけの仕事もたくさんありました。
しかし、最近ではSEやプログラマーをいくら集めても、いわゆるDX（デジタル・トランスフォーメーション）と呼ばれるデジタルを使ったビジネス変革には程遠いことがわかってきました。
「ドックイヤー」とも表現されるように犬（Dog）の1年は人間の7年に相当すると言われており、IT業界の1年（1 ‘Dog’ year）は他の業界の7年に相当するという意味で使われてきました。AIやロボットなどの新しい技術の登場により、「マウスイヤー」とも呼ばれるほど急速にIT業界が進化しています。
IT専門家は常に新しい技術を学び、スキルをアップデートしていく必要がありますが、すでにデジタルネイティブと呼ばれる生まれたときからスマホがあり、オンラインである若者たちが社会に出てきています。
IT業界で働くプロフェッショナルが経験する圧力や仕事のスピードを象徴しているとも言えます。テクノロジーが急速に変化するため、IT専門家は常に新しいスキルを学び、新しいプロジェクトやタスクに対応する必要があります。
そこで、平均年齢も若く最新技術をどんどん吸収していくことのできるベトナムSEをコンサルが使うことで、費用対効果の優れた、より効率的な内製化を行なっていくことができます。
プロジェクトの規模と複雑さにも比例しますが、少数のコンサルタントが多くの優秀なエンジニアを動かす方が理にかなっています。コンサルタントやプロジェクトマネージャーなど高いコストで多く配置するよりも、適切なITキャリアを持つ少数のコンサルタントが、最後の目標である内製化に向けて徐々にシフトさせていくことがよいでしょう。
各ポジションの能力のバランスが悪いとコミュニケーションが困難になり、結果として内製化プロジェクトが終わらないことも考えられます。
ポイントは1人ないし少数のITコンサルタントと、大量のエンジニアを動かせるベトナムの開発会社、そこを繋ぐためのIT Communicatorがいれば、内製化あるいは開発拠点をベトナムとしたシステム子会社を持つことが可能です。
まとめ
いかがでしたか。
システム内製化は一朝一夕にはいきませんが、アタラキシアDXではシステム開発体制の内製化を主導し、多数のシステムやアプリのリリースを6週間〜3ヶ月という短期間で実現できる組織の構築します。
老子の格言「授人以魚 不如授人以漁」は、「飢えている人がいるときに、魚を与えるか、魚の釣り方を教えるか。」 という意味です。「人に魚を与えれば一日で食べてしまうが、釣り方を教えれば一生食べていける」という考え方です。
同じように、ITエンジニアをかき集めて無理やりシステム構築するよりも、ずっとシステム構築と運営をしていける組織の構築を目指した方が、この先の企業経営を考えると大切なのではないかと思います。
わずか1年で3名体制のIT戦略事業部を50名体制にまでしたアタラキシアDX実績にご期待ください！
