内製化の成功術

IT報酬の実態

海外と比べて日本のITエンジニアの報酬が低いという記事をよく目にする。それもそのはずで、ハイクラスIT人材は都合のいい「何でも屋」にはならないからである。

導入時の誤解

ユーザー企業やシステムのユーザーは、IT化を行うことで業務が減るという先入観を持っていることがある。システム導入を着手したときの目的を忘れて、その時、その場の課題を優先して都合よくITエンジニアを動かしてしまう。また動くITエンジニアもそこにいたりする。

システムと医療

たとえば、「お腹が痛い」と病院にいって「すぐに切開しよう」とはならないはずだ。このようにシステムにもその他にも色々な条件が絡まり合っている。システムは取り扱う情報量や関連する業務が多く導入に時間がかかる。時間がかかる結果、最初の導入目的を忘れてしまうのである。

真のIT人材価値

ハイクラスIT人材はユーザー側の状況と心理を配慮しつつ、現場のプログラマーの状況と心理を考慮して陣頭指揮できる人材といってもよいだろう。心理というのは物の言い方だけではなく、無形の財産を構築したり業務にフィットさせたりするので、プロジェクトの円滑さが変わるのだ。

まとめ

小手先だけでシステムに関するプロジェクトを推進しようとすると、「言われた通りにやった」という受動的な参加者が増えてしまう。情シスのSIer化を回避するにはITエンジニアを「何でも屋」にさせて疲弊させないことも大切である。開発チームの雰囲気作りも非常に効果がある。

関連記事

ローコード開発とAI活用

AIとローコードの融合

ローコード開発プラットフォームの普及により、非エンジニアでもアプリケーション開発が可能になった現在、生成AIの活用が大きな注目を集めている。ChatGPTやCopilotなどのAIツールを組み合わせることで、開発スピードがさらに向上すると期待されているが、本当にすべてのローコード開発にAIが必要なのだろうか。コスト、品質、保守性など多角的な視点から、AI導入の真の価値を見極めることが、企業のDX戦略において極めて重要になっている。

コード生成の現実

生成AIによるコード生成は確かに魅力的だが、実際の品質には課題がある。AIが生成するコードは、単純な処理であれば高品質だが、複雑なビジネスロジックや例外処理が絡むと、不完全なコードが生成されることが少なくない。さらに深刻な問題は要件定義の壁である。AIは与えられたプロンプトに基づいてコードを生成するが、曖昧な要件や暗黙の前提条件を正確に理解することは困難である。結果として、開発者は生成されたコードを詳細に検証し、修正する必要があり、期待したほどの効率化が実現しないケースも多く見られる。

保守性のコスト

AIを活用したローコード開発において、最も見落とされがちなのが保守性の課題である。AI生成コードは、その時点では動作しても、後から読み解くことが困難な構造になっていることがある。変数名が不適切だったり、処理の意図が不明瞭だったりすると、半年後に修正が必要になった際、開発担当者が変わっていた場合、大きな手戻りが発生する。また、AIツールのバージョンアップや仕様変更により、過去に生成されたコードとの互換性が失われるリスクも存在する。初期開発のスピードを重視するあまり、長期的な運用コストが膨らんでしまっては本末転倒である。真のDX推進には、目先の効率化だけでなく、持続可能な開発体制の構築が不可欠なのである。

適切な見極め

ローコード開発におけるAI活用は、すべてのケースで必須というわけではない。定型的な画面開発や単純なCRUD操作など、パターン化された開発にはAIが有効だが、複雑なビジネスロジックや高度なセキュリティが要求される領域では、人間による丁寧な設計と実装が重要である。重要なのは、プロジェクトの性質、チームのスキルレベル、長期的な保守計画を考慮した上で、AIを活用すべき領域と従来手法を維持すべき領域を明確に区分することである。段階的にAIツールを導入し、効果を検証しながら適用範囲を拡大していく慎重なアプローチが、失敗リスクを最小限に抑え、真の生産性向上につながる。

まとめ

ローコード開発へのAI導入は、万能の解決策ではなく、適材適所で活用すべきツールである。コード生成の質、要件定義の難しさ、保守性の課題を十分に理解した上で、自社の開発体制に合った形でAIを取り入れることが成功の鍵となる。短期的な効率化だけでなく、長期的な運用まで見据えた戦略的な判断が求められている。

続きを見る >

賢いコスト削減

投資と競争力

バックヤードのシステム開発は収益と直接結びつかないため、できるだけケチりたいものである。にもかかわらず、バックヤードのデジタル化には大きなコストがかかる。しかし、新しいインフラに適切な投資ができない企業は競争力を失うのである。

要件定義の罠

バックヤードのシステムをできるだけ安く抑えようと思うと、要求定義や要件定義をしっかり作って依頼すればよいと考えがちである。もちろん、間違ってはいないが、入り口が安くなるわりに、システム開発の途中で追加工数が発生してしまい、結果としてシステムが高くなってしまうのである。

未来志向の要求

システム開発の途中で追加予算がかかってしまうのは、最初の要求定義や要件定義のときに想定される未来が見えていないことが原因である。これを見通すには要求定義や要件定義を行う背景や、未来の目指すところまでをエンジニア出身のアナリストに情報共有しなければならない。

投資の真価

導入時の金額だけをケチることは、保守運用などのランニングコストに跳ね返ってきてしまい、システムの寿命が短くなる。そうならないために、第三者のIT業者やITコンサルタントを入れるほうがよいと言われている。うまくDX化できれば生産性が上がり、投資を大きく回収できる。ことIT投資については、竹槍戦か空中戦かくらいの違いを生んでしまうのである。

まとめ

システム設計やプログラミング作業と同じようにITコンサルタントも1人の能力に偏りがちである。それゆえ、PMOと呼ばれるチームを形成することで、集合知を活用して、さらに未来を予測できるような体制を構築することが望ましい。

続きを見る >

開発遅延の打開策

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

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

不具合と開発の不透明性

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

コスト削減と資源最適化

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

開発の透明性と妥当性

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

まとめ

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

続きを見る >