開発の相場

内製化が注目される背景

「アプリ開発は外注するもの」という考え方が変わりつつある。ローコードツールの普及により、プログラミング経験がなくても自社で業務アプリを開発できる時代になった。しかし、ツールを導入しただけで内製化が成功するわけではない。実際には「ツールは入れたが、誰もアプリを作れない」という状態に陥る企業も少なくないのが現実だ。

内製化が止まる原因

ローコード内製化がうまくいかない原因は、ツールの問題ではなく環境の問題にある。まず、操作方法を学ぶ機会が限られている。公式ドキュメントは英語中心で、実務に即した日本語の教材が少ないのが現状だ。次に、学んだ知識を実践に移す場がない。研修を受けても、日常業務に戻ると時間が取れず、スキルが定着しないまま終わってしまう。さらに、推進担当者が社内で孤立しがちだ。周囲に相談できる人がおらず、一人で試行錯誤を続けるうちに疲弊してしまうケースが多く見られる。

一気通貫が必要な理由

内製化を成功させるには、「セミナー・サポート・教材」の3つを一気通貫で揃えることが必要だ。セミナーで基礎知識を学び、教材で実践的なスキルを身につけ、サポートで困ったときにすぐ相談できる体制を整える。この3つが揃って初めて、現場の担当者が自信を持ってアプリを作れるようになる。どれか1つだけでは不十分だ。セミナーだけ受けても実践で使えず、教材だけあっても疑問が解消されず、サポートだけあっても基礎がなければ質問すらできない。内製化は「点」ではなく「線」で取り組む必要がある。個人の頑張りに頼るのではなく、組織として学びと実践の仕組みを整えることが成功の鍵になる。

成功企業の取り組み方

内製化に成功している企業は、最初から完璧を目指していない。まず1つの業務でアプリを作り、小さな成功体験を通じてノウハウを蓄積している。そして段階的に対象業務を広げ、社内に開発できる人を増やしていくアプローチを取っている。大切なのは、最初の一歩を正しい方向で踏み出すことだ。独学で遠回りするよりも、経験のある専門家に相談することで、最短ルートで成果にたどり着ける。「まず何から始めればいいか」を一緒に考えてくれるパートナーがいることが、内製化成功の最大のポイントだ。

まとめ

ローコード内製化の成功には、セミナー・教材・サポートの一気通貫が欠かせない。ツール導入だけで終わらせず、組織として学びと実践の仕組みを整えることが重要だ。まずは専門家に相談し、最初の一歩を正しい方向で踏み出そう。

開発現場の想定外

基幹システムの開発現場では、最初に想定した仕様とは異なる業務フローが後から発覚することが多い。

マネジメントの試金石

後から発覚した業務フローは、すでに構築が進んでいるシステムに組み込むことが難しいため、どのように対応するかがプロジェクトマネージャーの腕の見せ所である。

プロジェクトの舵取り

プロジェクトマネージャーとは何かと問われたときに、一言で言い表すならば、不測の事態にどのように対応できるか、ということではないかと考える。プロジェクトが何の問題もなく、完遂できることは少ない。したがって、イレギュラーケースが発生した時にどのような手立てを打てるか、迅速に行動できるかがプロジェクトマネージャーのレベルとなる。

パートナーシップの重要性

プロジェクトマネージャーがシステムの完成しか考えていなければ、途中から発覚した仕様は「運用でカバーせよ」とユーザー側に責任を押し付けてしまうことがある。しかし、より良いシステムを目指す、パートナーとしてであればこの回答は好ましくない。

まとめ

どのような事象がきっかけで、途中で使用漏れが発覚したのか、プロジェクトの進行状況を見ながら、ひも解くことが重要である。運用でカバーというユーザー側だけにだけ負担をさせるのではなく、運用をカバーするようなシステムを構築できるのが理想である。

システム開発の現状と課題

数名で開発した初期のシステム構築から、システム会社を変更して大がかりなリプレイスを行い、保守運用を実施しているが、月々の費用が高額であるわりに、開発スピードも遅い。開発スピードが遅いため、新しい機能を実装していけない。

不具合と開発の不透明性

リリースから何年も経っているのに不具合がなくならない。開発会社からの報告が曖昧で何にお金を支払っているのか謎のままであることが多い。

コスト削減と資源最適化

開発スピードを上げるには、システム開発コストの削減をしなければならない。コストを削減するということは、それで浮いたコストを開発に割り当てることができるため、結果的に開発スピードがあがることを意味する。

開発の透明性と妥当性

そのためにしなければならないことは、開発工程や開発過程の見える化および妥当性を担保することである。システムの比較検討ができないため、システム開発のコミュニケーションは一般的なものであると思い込んでいる。システム発注の担当者はシステムのことがわからないから、システム開発の進め方に違和感があったとしても技術者が言うことを信用するほかないと思っている。

まとめ

結果として、技術者の工数と称して月々の費用や、ひどいものでは言語のバージョンアップと称して、何もしていないことに費用を支払っていることもある。不明点はシステム発注の担当者が理解できるまで聞くべきである。