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

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

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

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

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

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

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

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

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

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

システムをカットオーバーさせて「作りました」とアピールすることが終着点。 そんな人たちが目指すシステム開発（改編）のことを前回少し書きました。 blog.dbmschool.net この場合の恩恵を受ける ”システムユーザー” は、現場で物理的にそのシステムを使う…

現場で嫌われる「バッタモン要件定義」の話です 私が考える基幹システムの存在とは『働く人の味方』 なぜなら、起業した経営者が当初は自分でしなければならなかった各種作業を機械化するところに端を発しているからです。（⇩こちらにもそんなことを書いてい…

システムの「ここをこう改善してほしい」という現場の声は通るか？ 基幹システムは、日々携わっている業務に多大な影響がある重要なインフラです。 それなのに、なぜか圧倒的マイノリティになる「システム改善を求める声の主たち」 なぜか、色んな理由をつけ…

システムには高い金をかけてるんだからあまり細かいことでガタガタ言うなと暗に主張する上層部 しかし、高い金をかけたということと、それが免罪符になるということは全く別な話です。 むしろ 高い金をかけたのに役に立たないということで良いのか？ それが…

せっかくのシステムの機能が現場の実態に合っていなくて 「使いづらい。かえって仕事に差し支える」と 現場が切実な声を上げると、上から早々に批判・・というか叱責の声で潰される。 「この業務のために作られたシステムなんだから、役に立たないわけがない…