前回、追加要素の予算を渋ったために「現場が動かなくなる」という事態に直面して慌てふためいた上層部が、結果的に人員追加を余儀なくされて人件費増大を引き起こしたうえ、やっぱりシステムの改修まで必要になってしまう・・という、どこかで実際に起きて…

ひとつの物語なのに、 「会議室で議論されるシステム要件」のストーリーは何故か 「現場業務を阻害するシステム要件」のストーリーで展開する。 一粒で二度美味しい（ブログネタとしては） 一切をシステム会社に依存したら、一体どうなるんだろう？？ 高い見…

戦いでは敵陣の中でも特に「最も弱い敵」に狙いを定め、まずは局地戦で彼我の陣営に「我が勝利」を誇示し、味方の士気を上げつつ敵の士気を挫くのが良いと言われます。 「勝つためのシステム」とは何だろう？ 「各自が抱く成功イメージ」に依存したらシステ…

「時間がないから特急料金で」はシステム開発ではどうしても無理筋になります。 これから何年も使い続ける基幹システムでその無理筋をやってしまうと、末端で事業を支える動体（作業者）の稼働が機能不全になり、ひいては全身症状になりかねません。 このこ…

現場の長でありながら、現場の動きに大きな見落としがあった上司。 憤る部下の突き上げを受けて、進み始めている新システムの機能追加計画を軌道修正する羽目に陥りました。 blog.dbmschool.net 事がシステムであるため、これをすべてシステム室にお願いして…

「現場の痛みが感じられない人」が集まって行われるシステム要件の会議。 テーブルの上にはその「現場の情報」が積み上げられています。 しかし、それらをアセンブリするには現場の実務に精通していることが重要です。 そうでなければ、せっかくの生きた情報…

システムを作る場合に「あーだこーだ」と議論できる時間は長くありません。 たとえばシステム改編だったら、現行システムの保守期間満了が期限になっているのが大半のはず。 ゆえに要件定義会議のテーブルを囲む全員にとって、堂々巡りで時間が過ぎていくの…

一般的に、システム開発はユーザーが要望を出し、エンジニアがそれを形にします。 いわば二人三脚で作り上げていくものですが、それぞれが担当すべき独自の事柄があります。 この「独自の事柄」の切り分けがうまくいけば、希望にかなり近いシステムが出来上…

開発費を高騰させる「システムエンジニアへの誤解」というタイトルで【システム雑談】というものを続けていますが、もう少し続きそうなのでいったん整理します。 blog.dbmschool.net blog.dbmschool.net 「SEへの理解」と「システムへの理解」 「システムエ…

「システムエンジニアには、ハナシ、ゼッタイ通じる！ だってあの人たちは私が使っているITデバイスに詳しいんだから、私の作業をいい感じ⤴️に理解して、ゼッタイ・・ゼッタイ・・手を差し伸べてくれるんだモン！」 このところ継続している【システム雑談】…

前回の記事で少し書いた「システムエンジニアとユーザーの、言葉に出てこないひそかな争い」についてもう少し続けてみましょう。 blog.dbmschool.net 開発費が嵩む理由は思わぬところに・・ 話が通じないとわかれば話ができる 「分かり合えるはず」という思…

システム要件を話し合うときに「文脈を揃える」という表現を私は使っています。 現場で接客や業務オペレーションに従事するユーザーが使っている文脈は、エンジニアには「通じるけど通らない」ことが多い。 「意味は通じても願いは通じない」と言うほうがし…

システムに ”魔法” を求めてはいけないのはもちろんだが、システムエンジニアに ”魔法使い” を求めることはもっといけない。 そんなことは誰もが知っているのに、なぜか現実の業務の中ではその自主規制がところどころ崩壊する。 要件定義の会議に臨む前に身…

要件定義にノイズが入る例として、経営陣からの "圧" があります。 むろん、現場にとってはありがたくないタイプの圧力です。 システムとは直接的に関係ないかもしれませんが、たとえば業績を良く見せたい経営者が、経理担当者に圧をかけて決算作業を複雑化…