記事

相場の不在

開発の相場観

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

比較の難しさ

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

将来要件判断

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

変化への対応

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

まとめ

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

賢いコスト削減 前の記事 オオカミ少年化の弊害 次の記事

関連記事

記事

生成AI失敗の3要因

期待と現実の乖離

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

曖昧なゴール設定

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

教育不足の弊害

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

成功の3条件

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

まとめ

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

続きを見る >
記事

リーダーの多忙による弊害

危険な繁忙化

なぜか忙しくしているPMやリーダーとなるSEがいれば危険信号である。リーダーが忙しくなると全体的な最適化や効率的な運用ができていない可能性がある。結果として、無駄に費用がかかったり、技術的負債が大きくなったりする。

役割分担の歪み

システムのユーザー側から見ると、SEという見え方しかしないと思われるが、実際はシステムの運用や開発には細かな作業分担が発生する。この作業分担ができていない場合は窓口のSEが余計な作業を行っている可能性がある。役割分担の不均衡がもたらす忙しさではなく、まったく仕事としてやらなくてもよいような事に時間を使っていて忙しい場合がある。

プロセスの確立

たとえば、プログラムが解析できる人をリーダーとしてしまうと、開発者に手取り足取り指示をしてしまうことがある。もし、リーダーがプログラムレビューなどの作業や、開発者にプログラム上の細かな指示をしている場合は注意が必要である。何を基準にプログラムレビューや指示を行うのか、という仕事を見える化し、仕組化することがリーダーの務めである。

俯瞰的視点

木を見て森を見ずという言葉があるように、リーダーとなる人は指針を作ったりメンバーをプロジェクト成功へ導く役割がある。リーダーが開発メンバーと同じように木ばかりを見ているようであれば、森を見る人が非エンジニアであるユーザー側となってしまうことが考えられる。

まとめ

誰が森を見るのか、リーダーやPMが常に忙しそうにしている場合は、何に時間を使っているのか調査する必要がある。実はここがボトルネックになっていてプロジェクトの進行が思うようにいかなかったり、頻繁にリスケが発生していることも多くある。しかし、これは本人にヒアリングするだけでは表面化しないため、ユーザー側の担当者やプログラマーなどの周辺人員から浮き彫りにすることが望ましい。

続きを見る >
記事

思考と決断のPM力

PMの真価

スキルシート上にあるPMというのは、どういった開発言語や開発環境などを使ってきたかという内容であることが多く、SEの延長という意味合いが強く残っている。もし、期待するポジションが発想力や提案力にあるとすれば、姿勢をみることが大切となる。

従順の呪縛

就職氷河期と呼ばれる世代より上の年齢層では、常に従うことを幼少期から叩き込まれていると考えられる。日本では「禁止」か「許可」かを常に意識しながら仕事をしており、「許可されるまでは禁止されている」と考えているのではないかと推察される。

失敗からの成長

正しいか、間違っているか、の判断基準しか持ち合わせていない場合、何か問題が発生したときに時間を遡ってどこで判断を間違えたのかを追求する。それは大切なことであるが、実際のプロジェクトでは誤ったことを反省しつつ修正しながら進むことが大切である。

判断力の真髄

エンジニア出身のPM（開発プロジェクトのPM）だと、禁止か許可かというデジタルのような見方をしている人もいる。特に今日のシステムに関するプロジェクトでは、ゼロかイチだけでは判断できないような、ウエットでアナログな状況判断が必要となる。

まとめ

たとえ能力の高いPMだったとしても、仕事になると発想することや作ることの楽しみより、ミスによる懲罰を恐れたりするために、無難で当たり障りのない判断をしがちである。システムに関するプロジェクトがなかなか前へ進まない理由でもある。

続きを見る >