効率化の誤解

目標設定の要諦

SESと呼ばれる派遣や準委任契約では、プロジェクトを完遂することが難しいとしている。これはゴールが未設定であったり、曖昧になってしまう場合が多くあるからである。ゴールの設定や未来像は非常に重要で、プロジェクトマネージャーなどリーダーが必ず持っておくべき指針である。

真のリーダー像

システム開発に参画するメンバーは一般的に経歴書やスキルシートによって決まる。プロジェクト経験数が多かったり、扱える言語が多かったりするだけでは、本当のスキルは推しはかれない。やはり、確認すべきは不測の事態が起きたときの対処方法を豊富に持つリーダーが必要となる。

アジャイルの本質

犬小屋を建てるときに設計書はいらないが、マンションを建てるには設計書がいる。アジャイル開発といっても、例えばマンションを設計図なしに建てるといったことを考えるとある程度は見通しや知見などを持つメンバーが方向性を決めていく必要がある。システム開発はその時その時の条件によっていい悪いの判断軸が変わる。さらに時間の経過でも判断軸が変化していくのである。

部分最適の罠

日本には「カイゼン」という高度経済成長期を支えた力強い言葉がある。しかし、時と状況によって判断軸が変わるソフトウェアという無形財産の前では、「善」に「改」めることができているのか、変化してしまう背景がある。職人気質である国民性も相まって、どうしても部分改善、部分最適を繰り返してしまうというプロジェクト現場が少なくない。

まとめ

システム運用や保守における部分最適は必ずしも全体最適になるわけではない。むしろ、この部分最適が全体を考えたときの労働生産性を下げていることすらある。小回りが利く人であればあるほど属人化してしまったりするため、誰が全体最適を見るのがベストなのか、改めて考える必要がある。

関連記事

ローコードとは何か

ローコード開発の基本

ローコード開発とは、従来のプログラミングで必要だった複雑なコード記述を大幅に削減し、視覚的なインターフェースを使ってアプリケーションを構築する開発手法である。ドラッグ&ドロップや設定画面を使って、まるでパズルのピースを組み合わせるように機能を実装できる。これにより、プログラミング経験が少ない人でも短期間でアプリケーションを作成することが可能になった。従来なら数か月かかっていた開発が、数週間で完成することも珍しくない。

注目される背景

現代企業が直面するデジタル変革(DX)の波により、業務システムの迅速な構築・改善が求められている。しかし、IT人材不足は深刻化しており、従来の開発手法では変化の速いビジネス要求に対応しきれない。また、コロナ禍を経てリモートワークが普及し、業務プロセスのデジタル化が急務となった。こうした背景から、非IT部門でもシステム開発に参加できるローコード開発が注目を集めている。市民開発者と呼ばれる現場担当者が直接システムを構築することで、真にビジネスニーズに合致したソリューションを素早く提供できるのである。

具体的なメリット

ローコード開発の最大のメリットは開発スピードの圧倒的な向上である。従来の開発では要件定義から運用まで半年以上かかっていたプロジェクトが、1〜2か月で完成する。また、専門的なプログラマーを雇用する必要がないため、人件費を大幅に削減できる。さらに、ビジネス要求の変化に応じて素早く修正・拡張が可能で、従来のシステムのように大規模な改修を必要としない。ユーザー自身が開発に関わることで、仕様の齟齬が生じにくく、より実用的なシステムが構築できる点も大きな魅力である。運用保守も簡単で、長期的なTCO削減にも貢献する。

導入時の注意点

ローコード開発を成功させるには、適切な用途の見極めが重要である。単純な業務アプリケーションや社内システムには最適だが、高度な処理や複雑なアルゴリズムが必要なシステムには向かない。また、開発者のスキルレベルに応じた段階的な導入が必要で、いきなり複雑なシステムから始めると失敗リスクが高まる。セキュリティやガバナンスの観点から、適切な開発ルールやレビュープロセスの確立も欠かせない。さらに、従来のIT部門との連携体制を構築し、技術的なサポート体制を整えることで、より効果的なローコード活用が実現できる。

まとめ

ローコード開発は、DX推進において極めて有効な手段である。開発スピードの向上、コスト削減、そして現場主導でのシステム構築を可能にする。ただし、適切な用途選択と段階的な導入アプローチが成功の鍵となる。企業の競争力向上のため、ローコード活用を検討してみてはいかがだろうか。

続きを見る >

技術的負債の返済方法

負債の本質

技術的負債には、設計負債やコード負債がある。金銭的な負債であれば借入金やマイナスの表記で数字化できるのだが、技術的負債においては数字化できないことがとても難しい点である。経営に関するほとんどのことは定量化や定性化が可能だが、たとえば企業創業者の発想する「野生の勘」を直接的に数字化できないように技術的負債も一筋縄では見える化しない。

設計時の対策

技術的負債の中でもコード負債については、システム開発の現場からよく発想されるリファクタリングや再構築などを行うことで比較的わかりやすい返済方法となる。知らない人が作ったプログラムや古くなったプログラムのバージョンなど、リスクを表現し対応することができる。何よりも最初の企画設計段階で負債が積みあがりにくい仕組みを考えることが大切である。

高負担な設計

技術的負債の中でも利息の高い負債が設計負債である。単体機能における設計であれば、モジュールごとの再設計によって返済が可能である。しかし、プログラムは複数のモジュールが絡まり合っていることがほとんどなので、複雑なオペになってしまう。また、稼働中のシステムにわざわざ再設計したプログラムを導入するリスクに対して、得れるメリットも少ないので見過ごされがちである。設計能力は例えば、紙というオブジェクトのメソッド(振る舞い)とプロパティ(保持する情報)を聞いて正しい答えが帰ってくれば多少安心であろう。紙の振る舞いは燃えるであり保持する情報は面積などがある。

根本的解決

しかし、技術的負債はこのように目に見えやすい設計負債やコード負債が致命的になることは少なく、やはりその上層でどのような指針に基づいてシステム運用がなされてきたか、また長期視点で一貫したメンテナンスを行うことが必要である。システムの維持には保守費用や運用費用を払っていることが多いと思うが、これだけでは将来の負債を減らしていくことはできない。やはり、鳥の目を持つITコンサルタントやITアナリストなどの役割を持つメンバーが必要である。

まとめ

ITコンサルタントやアナリストは、すぐに利益も生まない、経費を削減するわけでもないといったコストセンターとしてのポジションなので、あまり起用していない中小企業も多いようである。投資に対する効果が見えにくいのは、料理でいう香辛料と同じなのかもしれない。その少しの投資が未来を大きく変えることになる。IT技術は日進月歩で発展するからである。

続きを見る >

なぜベトナムはERPシステム開発に向いているか

ベトナムは、ERPシステムの開発を行うのに適した場所と言えます。特に、日本企業が自社の生産拠点や流通拠点をベトナムに持っている場合や、ERPシステムが過去に作成したwebベースのものである場合は特に向いています。ここでは、その理由について解説します。


ベトナムの市場理解と製造業との親和性

ERPは業務に直結したシステムであるため、業務理解と市場の理解が欠かせません。ベトナムを生産拠点にしていたり、ベトナム市場に製品を販売している日本企業は多いため、そのような日本企業はベトナムの物流や製造現場に慣れているからです。ベトナムの市場理解と製造業との連携により、ERPシステムの在庫管理など、製造業に特化した機能を効果的に開発することができます。これにより、生産管理や物流効率の向上を実現し、ビジネスの競争力を強化することができるでしょう。

ベトナムにおける既存の知識と日本語通訳者の能力

トナム人の日本語通訳者の能力も向上しており、生産や流通に関わる日本語も習得しています。これにより、ERPシステム開発プロジェクトの効率性が向上し、品質の高い成果物を生み出すことができます。

ベトナム国内には、日本企業の製造や流通、決済に関する知識が蓄積されています。日本企業の進出が主に製造業から始まったため、ベトナムではこれまでに日本独自の慣習や用語についての理解が深まってきました。このような環境下でERPシステムを開発することで、ベトナムとの意思疎通がスムーズに行われ、開発段階での要件の理解に対しての円滑なコミュニケーションが可能です。ベ

ベトナムのオフショア開発の特質と既存システムの改善

ベトナムのソフトウェア業界は、オフショア開発からスタートし、成熟した実装能力を持っています。しかし、そのような経緯のために上流工程については苦手です。要件定義や仕様作成の段階からベトナムに丸投げしてしまうのはあまり良いこととは言えません。その部分は日本側で行い、実装段階をベトナムで行なうのが良いでしょう。

特に20年前からのWebベースのERPシステムのリプレースや改善をする場合は、ベトナムは適切な場所と言えます。過去に作成された既存のシステムは現在の技術やセキュリティ基準に合致していない場合があります。しかし、ベトナムの開発者が現代的な技術を使ってUIやUXの改善に取り組むことで、既存システムの現代化やセキュリティの強化が可能です。 具体的には、DBはそのままにして、古い技術で作られているフロントエンド部分をリプレースすると言ったプロジェクトが良いでしょう。

続きを見る >