効率化の誤解

目標設定の要諦

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

真のリーダー像

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

アジャイルの本質

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

部分最適の罠

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

まとめ

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

関連記事

要件定義の問題点

はじめに

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

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

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

要件定義の丸投げ

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

無理な受注

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

人材紹介会社の利益構造

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

エンジニアの責任範囲

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

発注側の保身

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

続きを見る >

相場の不在

開発の相場観

相場とは、一般的に市場で競争売買によって決まる商品の価格とされているが、ことシステム開発においては、相場というものが存在しない。

比較の難しさ

比較できる同じものであれば競争原理が働き相場が構築されるが、フルスクラッチされるシステム開発においては全く同じものができることはない。しかも、出来上がるものはパッケージシステムやSaaSの利用以外は、未来にしか完成しないので当然比較もできないものとなる。

将来要件判断

比較的ないからこそ、しっかりと吟味する必要があるが、吟味する材料や条件などは現時点で明確になるものが元となる。未来に発生する追加条件や変更される環境などはジャッジする時点にはすべて出そろわないという難しさがある。

変化への対応

システム開発は未来にどのような条件変更やルール変更が行われるかわからないものであるという認識を持つことが大切である。その上で最善のジャッジを行うべきである。その判断は過去を遡って正解か間違いかを評価すべきではない。

まとめ

日本では原点方式の人事評価が行われるため、イノベーションは起こりにくい本質的な問題がある。これを無視して「DXだ」といっている組織があるとすれば、それは本質を見誤っているといえる。

続きを見る >

生成AI失敗の3要因

期待と現実の乖離

生成AIを導入したものの、思うような成果が出ずに悩む企業が増えている。「話題だから」「競合が使っているから」という理由で導入したケースでは、現場から「結局使えない」という声が上がることも珍しくない。実は、生成AIで成果が出ない原因の多くは、ツール自体の問題ではなく、導入プロセスや運用体制に潜んでいる。本記事では、成果が出ない3つの主要因を解説する。

曖昧なゴール設定

成果が出ない最大の原因は、導入目的が不明確なことである。「業務効率化」という漠然とした目標では、具体的に何を効率化するのか、どの程度の改善を目指すのかが見えない。結果として、現場は何にAIを使えばいいかわからず、試しに使ってみても効果を実感できないまま放置される。成功している企業は「議事録作成時間を50%削減」「問い合わせ対応の一次回答を自動化」など、測定可能な目標を設定している。目的が明確であれば、適切なツール選定も、効果測定も、改善サイクルも回しやすくなる。

教育不足の弊害

二つ目の原因は、従業員への教育不足である。生成AIは万能ではなく、適切なプロンプト設計や出力結果の検証スキルが求められる。しかし多くの企業では「ツールを入れれば自然と使われる」と考え、十分な研修を実施していない。その結果、一度試して期待外れの回答が返ってきた社員は「使えない」と判断し、二度と触らなくなる。三つ目の原因は、業務との不適合である。定型的な作業や創造的な文章生成には強みを発揮するが、高度な専門判断や最新情報が必要な業務には向かない。自社の業務特性を分析せずに導入すると、AIの強みを活かせない領域で無理に使おうとして失敗する。

成功の3条件

生成AIで成果を出すためには、三つのポイントを押さえる必要がある。第一に、具体的で測定可能な導入目的を設定すること。第二に、継続的な教育プログラムを通じて社員のAIリテラシーを高めること。第三に、自社業務を棚卸しし、AIが得意な領域と苦手な領域を見極めたうえで適用範囲を決めることである。これらは当たり前のように聞こえるが、実際に徹底できている企業は少数派だ。逆に言えば、この基本を押さえるだけで、競合との差別化が可能になる。生成AIは正しく活用すれば強力な武器となるが、準備なき導入は失敗の元である。

まとめ

生成AIで成果が出ない原因は、目的の不明確さ、教育不足、業務との不適合の三点に集約される。これらはいずれもツール導入前の準備段階で解決できる課題だ。成功の鍵は、明確な目標設定、継続的な人材育成、そして業務特性に応じた適切な活用領域の選定にある。基本を徹底することが、AI活用の成否を分けるのである。

続きを見る >