「要件定義をやめよう」の真意、普通にやると金と時間が無駄になるだけ
「要件定義をやめないといかんね」――。ある勉強会が終盤に近づいた頃、隣席の参加者がこうつぶやいた。それを聞いた周囲の参加者がうなずいた。驚いたことに自分も「おっしゃる通り」と同意してしまった。 なぜ驚いたかというと、「要件がすべてを決める」「じっくり時間をかけるべき」と教わってきたからだ。日経コンピュータ編集部に配属された1985年以降、取材先の情報システム部長やソフトハウスの幹部を取材した際、「情報化で重要なこと」を問うと、たいていこう言われた。だから「いわゆる最上流工程が大事」という記事をたびたび書いてきた。 勉強会に登壇した講演者たちが「要件定義をやめよ」と言ったわけではない。しかし隣に座っていた参加者は、講演の趣旨を「要件定義をやめよ」という一言に集約した。同じ話を聞いてきた筆者を含めた参加者はすんなり納得したわけだ。 失敗につながる要件定義の実態 DX（デジタルトランスフォーメー
基幹系刷新で大金をドブに捨てた経営者やCIO、後悔の弁は結構だが問題はこれからだ
基幹系システムの刷新プロジェクトは失敗したほうがよいのかもしれない――。こう書くと、この「極言暴論」が大嫌いにもかかわらず、なぜか毎回熱心に読んでくれる一群の読者から「いよいよネタに困ったらしく、木村が妙なことを言い出したぞ」と嘲笑されそうだ。だが、決して妙なことではないぞ。リアルな現実を踏まえた結論である。 この10年ほど、様々な日本企業の経営者やCIO（最高情報責任者）に話を聞く機会があった。その中で、完遂したはずの基幹系システムの刷新について反省や後悔の弁を述べる人が結構いたのだ。面白い（本当は面白くないが）ことに、その内容は驚くほど似通っていた。恐らく極言暴論の熱心な読者なら想像がつくと思うが、いかがか。 例えば基幹系システムにERP（統合基幹業務システム）を導入した大手製造業の経営者は、「うちの業務のやり方にソフトウエアを合わせてしまった。もっと現場の業務を整流化（＝標準化、パタ
クラウドERP移行企業がオンプレミスERPに回帰する理由
クラウドERPには多くの魅力があるが、全ての企業にとって有用とは限らない。自社のニーズにクラウドは時期尚早だったと判断して、従来のオンプレミスERPに戻した企業もある。なぜ回帰を決断したのか。 クラウドサービスは普及の一途をたどっている。ERP（統合業務）製品についても同様に、オンプレミスのERP製品（オンプレミスERP）からクラウドサービスとして利用可能な「クラウドERP」への移行が現実的な選択肢になってきた。だが製造業においては、必ずしもクラウドERPが優勢というわけではない。 製造工程をデジタル化する「デジタルマニュファクチャリング」を推進したい企業にとってクラウドERPが重要な役割を果たすことは間違いない。だとしても、オンプレミスERPとクラウドERPを比較検討している企業は、既存のオンプレミスERPを維持するケースが少なくないようだ。独自のカスタマイズ機能がどうしても必要だったり
［ERP編］いきなりプロトタイプを始めてはいけない
ERPパッケージ導入では，どこまで標準機能で実現できるかによって，プロジェクトの成否が決まるところがある。この標準機能での実現性を検証するうえで，「プロトタイプ」が重要な意味を持つ。 なお，ここでは「実機を使用してERPの標準機能を確認しながら，ERPの機能で業務運用が実現できることを確認する作業」とプロトタイプを定義する。プロトタイプと同様の作業をCRP（Conference Room Pilot）と呼ぶケースもある。 プロトタイプ・フェーズの目的は「新業務プロセスの決定」「標準機能とアドオン機能の切り分け」「パラメータ設定の決定」などがある。この目的を達成するために，プロトタイプで「何を」「どこまで」「どのようにして」決めるかを明確にしておかないと，プロジェクトは失敗する。 ここでは，ERPパッケージを導入するコンサルタントの立場で，プロトタイプに関する留意点について説明する。 いきな
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
