「社員が不安を感じていると生産性は下がる」 山梨県でジュエリー業を展開する光彩工芸の深沢社長の言葉です。 まったくそのとおりですね。 私が自分の経験をかえりみて補足するとこんな感じです。 不安を感じる対象から自分の身を守るため、身辺の事柄に注…

基幹システムを巡る人間関係の悪化 導入、または改編のためにシステム作りを推進しつつも、現場の声の吸い上げに失敗した上席・・ その結果できあがった使いづらいシステムの使用を強要されつつも、改善要望の声を上げられない現場・・ 対立とまでは行かなく…

現場は新しくできたシステムにダメ出しをする なぜなら最も頻繁に使用する末端作業者の意見が反映されず、言葉によるフィードバックも無いから・・ ありていに言えば「システム改編に必要な、”ある種のコミュニケーション” に失敗している」ということになり…

現場は「システムが完成してからが仕事」です。 「システムを完成させたことが成果」となる層とは立場が異なります。 シナリオの時間軸が違う、とでもいうか・・ 実務に役に立つことが何よりも重視される「実質本位」で現場は動く。 そして実質本位ゆえ、シ…

現場との人間関係が苦手なリーダーが、やや逃げ腰で要件定義に取り組んだ末のシステム改修 掘り下げが不充分で、使用者たちが本当に必要としているディティールが伝わらないまま、額面どおりの改修が進む。 そのまま現場に投下したら反発が起こるのは必定で…

前回の続きです。 現場（実務担当者たち）との関係性に難があるリーダー。 彼が ”システム化” に求めている業務改善は、システム機能の埒外にある無理筋なものだったのかもしれません。 「現場が強い」はむしろシステム改編がやりやすい 現場のフトコロに入…

システムの最もシンプルな効果は「加速」 しかしその加速は、作業そのものだけではなく、作業に付随するあらゆるものに作用する。 「作業だけ加速させたいんだ」というのは甘い期待で、システム周りに存在する社内の各種問題をも加速させる。 blog.dbmschool…

ここ最近の記事を書きながら頭の中で同時並行で走っていた文章を、残しておこうと思いました。 日産GT-Rに関する話を引き合いに出した【システム雑談２２】の ”裏話” です。 blog.dbmschool.net 「中間管理職」よりも『企業トップ』 「遠くのトップ」よりも…

「加速」という言葉の意味として「今している事柄の速度を上げる」があります。 言い方を変えれば「今の自分がより強く具現化する」です。 業務を加速するつもりで機械化を図る場合、その業務に付随している「問題点」も同時に加速すると考えておいたほうが…

「テコ入れ」はいろいろな場所で聞かれる言葉ですね。 特定のタイミングで、全体の中のキーポイントに対して、一時的に通常よりも多くの資源を投入し、その部分からのリターンを加速させる狙いのことをそう評するのが一般的かと思います。 ”部分強化作戦” と…

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

本来、基幹システムとは『働く人の味方』という性質を持っている。 それまで人間が手間ひまかけてやっていた社の業務の中でも特に、重要かつ速さと正確さが要求され、その分だけ従業員を消耗させて社業の力を削ぐ部分を機械化するものだったはず。 導入する…