要件定義のアプローチ

要件定義の基本

すべてをシステムで解決してしまおうとする要件定義には注意が必要である。システムの成功の可否は要件定義にかかっていると言っても過言ではない。しかし、十分に要件定義の時間を使ったにも関わらず、ITプロジェクトが失敗することがある。

規模別の要件定義

システム構築の規模によって、要件定義の粒度が変わる。小さなITプロジェクトの場合は要件定義をせずにプロトタイプを作りながらシステム構築を進めるといった方法がある。これをアジャイル開発、プロトタイプ開発と呼ぶ。

要件定義の本質

要件定義の粒度は時間を掛ければ細かくなるわけではない。ユーザー側でも要件定義を進めるにつれて、想定している機能の矛盾点が出てくることがある。この矛盾点を解消していくこと自体を要件定義としてはならない。要件定義はあくまで本質的なコアとなる部分から膨らませることが重要である。

対話型要件定義

要件定義フェーズで失敗するパターンは、ユーザー側との対話ではなく、システム会社側がヒアリングに徹する場合である。ユーザー側はITを利用してどのようなことができるかを知らない可能性が高いため、システム専門家がそれを鵜呑みにした仕様で要件を固めてしまうと、製造工程で無駄な工数が発生し予算をオーバーしてしまうことがある。

まとめ

本質的な要件をコミュニケーションによって、はっきりさせていく作業こそが要件定義と言えるのである。さまざまな視点から何度も繰り返し要件をなぞることで粒度が落ちていき、適切な要件定義書となる。何でもかんでもシステム化せず、オペレーションとの関係性を見合わせながら進めることが望ましい。

関連記事

中小企業のAI活用入門

AI導入の選択肢

近年、AI技術の急速な進化により、大企業だけでなく中小企業にもAI活用の波が押し寄せている。しかし、多くの中小企業経営者は「AIは難しそう」「コストが高い」「専門人材がいない」といった不安を抱えている。実は、現在のAIツールは以前より格段に使いやすく、低コストで導入できるものが増えている。ChatGPTやClaude等の対話型AIから、画像認識、音声認識まで、業務に合わせて選べる選択肢が豊富にある。重要なのは、完璧を求めず、まず小さく始めることだ。

業務効率化の手法

AI活用で最も効果が出やすいのは、定型業務の自動化である。例えば、顧客からの問い合わせ対応にチャットボットを導入すれば、24時間365日の対応が可能になり、スタッフは付加価値の高い業務に集中できる。また、請求書処理や在庫管理にAI-OCRを活用すれば、手入力の時間を大幅に削減できる。ある製造業の中小企業では、品質検査にAI画像認識を導入し、検査時間を70%短縮した。別の小売業では、需要予測AIで在庫の最適化を実現し、廃棄ロスを30%削減した。これらの事例が示すように、AIは確実に業務を変革する力を持っている。

導入の課題と対策

しかし、AI導入には落とし穴もある。最大の失敗要因は「いきなり大規模に導入すること」である。まず現状の業務プロセスを整理し、AIで解決したい具体的な課題を明確にすることが不可欠だ。次に、小規模なパイロットプロジェクトから始め、効果を検証しながら段階的に拡大していくアプローチが成功の鍵となる。また、従業員の不安を解消するため、AIは人の仕事を奪うものではなく、サポートツールであることを丁寧に説明し、研修を実施することも重要である。外部の専門家やコンサルタントの支援を受けることで、自社に最適なAI活用方法を見つけ、導入リスクを最小限に抑えることができる。

実践ステップ

AI活用は、もはや「検討する」段階から「実行する」段階に移っている。競合他社がAIを活用して生産性を向上させる中、導入を先送りすることは競争力の低下を意味する。まずは無料や低価格のAIツールを試し、自社業務への適用可能性を探ることから始めるべきだ。重要なのは、完璧な計画を立てることではなく、小さく始めて学習しながら改善していくことである。社内にAI推進チームを作り、定期的に成果を共有することで、組織全体のAIリテラシーも向上する。今こそ、中小企業がAIの力を借りて飛躍的な成長を遂げるチャンスだ。一歩踏み出すことで、想像以上の変革が待っている。

まとめ

中小企業のAI活用は、もはや特別なことではない。定型業務の自動化から始め、段階的に拡大していくことで、確実に成果を出すことができる。重要なのは、自社の課題を明確にし、適切な支援を受けながら進めることだ。AI導入は投資ではなく、未来への必要な一歩なのである。

続きを見る >

思考と決断のPM力

PMの真価

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

従順の呪縛

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

失敗からの成長

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

判断力の真髄

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

まとめ

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

続きを見る >

開発遅延の打開策

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

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

不具合と開発の不透明性

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

コスト削減と資源最適化

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

開発の透明性と妥当性

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

まとめ

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

続きを見る >