相場の不在

投資と競争力

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

要件定義の罠

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

未来志向の要求

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

投資の真価

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

まとめ

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

生成AIと業務の未来

近年、ChatGPTをはじめとする生成AIが急速に普及し、ビジネスシーンでの活用が注目されている。文章作成、データ分析、アイデア創出など、これまで人間が時間をかけて行っていた業務を、AIが短時間で支援できるようになった。特に中小企業においても導入ハードルが下がり、生産性向上のための強力なツールとして認識されつつある。しかし、単にツールを導入するだけでは効果は限定的である。業務フローに適切に組み込み、活用方法を理解することが成功の鍵となる。

5つの活用法

生成AIは様々な業務シーンで活用できる。まず、メール文面や報告書などの文書作成では、下書きの自動生成により大幅な時間短縮が可能だ。次に、会議の議事録作成では、音声データから要点を抽出し整理できる。カスタマーサポートでは、よくある質問への回答案を即座に生成し、対応品質の向上と担当者の負担軽減を実現する。マーケティング分野では、SNS投稿文やキャッチコピーのアイデア出しに活用でき、クリエイティブな業務も効率化される。さらにデータ分析では、複雑なデータから傾向を読み取り、レポート作成まで支援してくれる。

注意点

一方で、生成AI導入には課題も存在する。最も多い問題は、社員のITリテラシーの差による活用格差である。一部の社員だけが使いこなし、組織全体の生産性向上につながらないケースが見られる。また、生成された内容の精度確認を怠り、誤った情報をそのまま使用してしまうリスクもある。セキュリティ面では、機密情報を不用意にAIに入力してしまう情報漏洩の懸念がある。さらに、AIに過度に依存することで、社員の思考力や創造性が低下する可能性も指摘されている。これらの課題に対しては、適切な社内ガイドラインの策定、定期的な研修の実施、そして人間の判断を最終確認として残す仕組みづくりが重要である。

活用の3原則

生成AIを効果的に活用するためには、いくつかのポイントがある。第一に、AIはあくまで「支援ツール」であり、最終的な判断は人間が行うという原則を徹底することである。第二に、段階的な導入を心がけ、小規模なプロジェクトから始めて成功体験を積み重ねることが大切だ。第三に、定期的な効果測定を行い、どの業務でどれだけの時間削減ができたかを可視化することで、改善点が明確になる。また、社内でベストプラクティスを共有し、ナレッジを蓄積することも重要である。AIと人間がそれぞれの強みを活かし、協働することで、単なる効率化を超えた価値創造が可能になる。

まとめ

生成AIは業務効率化の強力な武器だが、導入方法次第で効果は大きく変わる。適切な活用シーンの選定、社員教育、セキュリティ対策を行うことで、組織全体の生産性を飛躍的に向上させることができる。まずは小さく始めて、徐々に活用範囲を広げていくことが成功への近道である。

はじめに

会社の雰囲気や要件定義の内容をみれば、おおよそそのプロジェクトが成功するか否かがわかる。うまくいかない場合のユーザー側とシステム会社側の原因の一例である。

・要件定義をシステム会社に任せてしまう
・元請けシステム会社が無理な要件でも受注する
・準委任契約の人材紹介会社がリスクなく利鞘を稼げる
・末端エンジニアの作業遂行以外の責任
・ユーザー側、発注側の担当者が保身する

今回はその背景を説明したい。

要件定義の丸投げ

要件定義をシステム会社に任せてしまう。
要件定義はシステム会社がユーザー企業をヒアリングして作るものではなく、ユーザーとシステム会社が議論を重ねることで答えを出していくものにしなくてはならない。ユーザーが目指すべき姿と、システム会社が実現すべき姿のすり合わせが重要である。

無理な受注

元請けシステム会社が無理な要件でも受注する。
無理な要件でも受注できるのは、発注側にもシステムの知識がないため、ゴールが曖昧なまま元請けシステム会社が請け負ってしまうからである。もし、発注側にITリテラシーがなければ、パワハラなども発生する可能性が高い。したがって、元請けシステム会社に精神的な課題を回避するため、要件定義を作る人でさえも二次受けシステム会社から集めてくることがある。

人材紹介会社の利益構造

準委任契約の人材紹介会社がリスクなく利鞘を稼げる。
システムの完成責任は負わず、作業だけ請け負うことになるため、人さえ集めてくれば、そこでリスクなく利鞘が稼げる。発注側のユーザー企業からすれば、契約は元請けシステム会社であるため、3次請け、4次請けを使おうが、完成さえすればいいと考えていることが多い。

エンジニアの責任範囲

末端エンジニアの作業遂行以外の責任。
末端のエンジニアには、クライアントとの調整や導入、一定品質や納期の遵守など、責任感や危機感がないこともある。プロジェクトの全貌が見えないことも原因である。また、言われたことをやるだけで報酬がそこそこあるのが、システムエンジニアの業界だったりするので、作業をした時間分だけ報酬を支払ってほしい、という話にもなる。

発注側の保身

ユーザー側、発注側の担当者が保身する。
システム開発がうまくいかなかったときに、発注側の担当者がシステム会社に責任を押し付けるといったことがある。これは信頼関係によるもので、共同でプロジェクトを成功させようという目標が作れなかった場合に発生する。システム会社を業者扱いして要件定義を丸投げしてしまわないようにしなければならない。