Q&A
システム開発を中止してお金で解決しないの？
業務内で利用するシステムの開発をしています。
システムの概要としては業務の中での作業(帳票作成)を自動化するもので、
Excel VBAでの開発となっています。
ここ数年、部署内で連携しながら開発・運用を進めていたのですが、
肝心の担当者が言うことをころころ変えたり、言った・言わないの議論になったり、
管理する立場の上司すらその担当者を咎めずなぁなぁにする環境に置かれています…
(議事録で明文化していても平気でひっくり返し、上司は上司で「やる気が～」云々と抜かす始末です…)
この担当者自身も「VBAで作ったシステムはダメ！」だとか、
「マクロで作ったシステム(勿論VBAで実装しています)は良い！」と言ったり、
数年続いているのに大前提の説明が要りそうなとこもあります…
開発に当たってはメンバー間で整合会を通して要求内容を刈り取り、
それを仕様に落とし込んで実装の流れになっています。
システム開発を主にした業種でも無いので手続き的なとこも曖昧で、
立ち戻りを無くすための手段を考えているところです。
この手の業務で先述の「言うことをころころ変える」や、
「言った・言わないの議論になる」ような事例を経験ある方はいますか？
もし似た事例で何か改善できた事例(①)があれば紹介お願いしたいです。
また、自動化などで知識がない人に対して概念を説明する良い方法(②)や、
「動きを見えるようにしてほしい」という要望をどう解釈すれば良いか(③)も相談したいです。
(詳細を聞いても答えてくれないです…)
前提条件は以下になります。
・開発の外注は無し(費用対効果的側面より)
・担当者は外せない(現状、業務を把握しているのは当人のみ)
素直に言うと、それも選択肢ではあったのですけどね…
内部規定が変更されるとシステムの動作面も変更が生じるので、
今後の改修を考えると内製が適当という判断になっています。
個人的には話をころころ変える方が外部委託に絡むと、
契約的な面から何か問題起こしそうで恐れているところもあります。
回答4件
0
肝心の担当者が言うことをころころ変えたり、言った・言わないの議論になったり、
管理する立場の上司すらその担当者を咎めずなぁなぁにする環境に置かれています…
(議事録で明文化していても平気でひっくり返し、上司は上司で「やる気が～」云々と抜かす始末です…)
上記状況では正直手立てはないと思います。企業風土の問題だと思うのでお一人でどうこうできる気がしません。
質問者さんの立ち位置が分かりませんが、そのプロジェクトから離れることが幸せへの道だと思います。
また、自動化などで知識がない人に対して概念を説明する良い方法(②)や、
「動きを見えるようにしてほしい」という要望をどう解釈すれば良いか(③)も相談したいです。
(詳細を聞いても答えてくれないです…)
「自動化などで知識がない人」というのはどういう立場の人ですか？作業者であれば特に知識がないままでも実務には影響ないでしょう。（マニュアルをしっかり作ってあげれば良い）上長であれば「ここ数年、 ～ 開発・運用を進めていた」案件で「知識がない」ってことはないでしょうし、対象は誰なんでしょうか？？
後者については何に困っているのかよく分かりませんでした。
もしかすると開発着手前の要望吸い上げや話し合いが足りなかったのかもしれませんね。自動化が必要なことだとしても開発がスムーズにいかず現場の人が迷惑を被っていることは多々あります。そのフラストレーションが溜まって非協力的になっている可能性もあります。
投稿2025/02/16 03:59
総合スコア10823
> 上記状況では正直手立てはないと思います。
> 企業風土の問題だと思うのでお一人でどうこうできる気がしません。
> 質問者さんの立ち位置が分かりませんが、
> そのプロジェクトから離れることが幸せへの道だと思います。
はやりそうですよね…
候補には入れておきます。
> 「自動化などで知識がない人」というのはどういう立場の人ですか？
> 作業者であれば特に知識がないままでも実務には影響ないでしょう。
メンバー構成としては以下のイメージです。
課長
+-- 主務(グループの管理)
+-- 担当者(社員。これまで当該業務を担ってきた)
+-- 自分(作業の自動化システム開発担当)
担当者というのがこれまで手作業で当該業務を遂行してきており、
作業ポカの抑制などを目的とした自動化を進めるグループとなっています。
> 「ここ数年、 ～ 開発・運用を進めていた」案件で「知識がない」ってことはないでしょうし、
> 対象は誰なんでしょうか？？
これはメンバー構成でいう担当者に当たります。
全員集まった整合会にて何度も説明は繰り返し、議事録などで明文化もしていますが、
担当者が自分の都合良いように忘れている(ことにしている)と思われます。
フラストレーションは正直に言って全員が限界レベルにあるとは思います。
上記メンバー構成の主務も前任者が居ましたが耐えられずにグループから抜け、
グループ全体としても決めたことをひっくり返す担当者のおかげで、
「今決めたことが本当なのか？」という疑念が生まれている始末で…
要望吸い上げなどで工夫されている点などはあったりしますか？
「自動化」というものは本当に必要なものですか？上長が何となく"DX化"とかの言葉に載せられて、とりあえず”やれっ!”みたいなのでは無いんですよね？必要だとしてもVBAでというのは中々厄介ですね。
> 担当者というのがこれまで手作業で当該業務を遂行してきており、
上記がどのレベルを指すのかが分かりませんが・・・
手作業というのは何を指していますか？まさか紙の請求書とかじゃないですよね・・・？
> 作業ポカの抑制などを目的とした自動化を進めるグループとなっています。
上記で開発に数年かかるのは疑問です。
予算がないから外注できないと言っておきながら結局工数だけで結構かかっているのでは・・・？（これは管理者の責任だとは思いますが）
> 「動きを見えるようにしてほしい」という要望
上記についてはデモを見せてあげてはどうでしょうか？言葉での説明より分かりやすいかと思います。
DX化に感化されている印象はありますね。
ただ、今回の案件は担当者の作業ポカの多さや、
それによって発生する金銭ロス含めて進めなければならないと理解はしています。
個人的にはもう少し別の環境で開発したかったのですが、
「誰でも変更できるように(変更できる技術がある人は居ない)」という思惑もあったようで、
今の時代にもなってVBAで粘っております…
手作業と言うのは、改善前後で以下のようなイメージと思ってもらえれば大丈夫です。
改善前: 巨大なエクセルファイルのデータをフィルタ→必要なデータを依頼書に転記。1時間程度
改善後: 画面上のボタンを押して入力となるファイルを選ぶのみ。数秒程度
恐らく第三者が見れば「それだけのこと」なはずなのですが、
先の通りに話が二転三転して数年続いている状況です…
動きの可視化は開発中に手順書の整備から説明まで全て実施し、
一時期在籍していた派遣社員の方は十分に遂行できる内容だったのですが、
未だに「動きを見えるようにしてほしい」の一点張りで、
何をしてほしいのか・何を考えているのかを教えてくれません…
（実のところを言うと担当者はシステムの操作ミスも多く、
システム運用そのものからは外されているので、
そのような声そのものが出ないはずなのですが…）
取り敢えず直近で整合会を開催する旨は連絡受けていたので、
そこでどうなるか様子見しながら粘ってみます…
> 今回の案件は担当者の作業ポカの多さや、
> 担当者はシステムの操作ミスも多く
そもそも”システム”は操作する人による差を吸収するべきかと思います。操作ミスを０にすることは難しいかもしれませんが、操作ミスを無くすシステム設計をするべきです。そうなっていないなら設計が悪いのだと思います。
> 未だに「動きを見えるようにしてほしい」の一点張りで、何をしてほしいのか・何を考えているのかを教えてくれません…
作ったシステムは実稼働しているんでしょうか？クレームを言ってくる人がいたとしても実績（もちろん正しく動くことが前提）があれば会社としては問題ないんじゃないでしょうか？
担当者達の意見ではなく実際のデータを元に上長へ相談すべきかと思います。システム稼働前／後でのミス発生数や工数での比較など。
0
この手の業務で先述の「言うことをころころ変える」や、「言った・言わないの議論になる」ような事例を経験ある方はいますか？
状況が今一つはっきりしませんが、よくある話だと思います。
理由はいろいろありそうですが、そもそも担当者・該当部署がその自動化を望んでいないということなのではないでしょうか。
自動化することで、人員が削減されたり、 余った時間に他の作業をすることになることが抵抗を生んでいる可能性があります。
自動化の意義について丁寧に説明して理解を得る必要がありますが、解決には、高度な判断が必要になる場合があり、場合によっては現担当者抜きで業務を進める必要もあるかもしれません。
業務内容の変更に対する抵抗というのも大きな要因だったりします。コストを度外視すれば、これまで問題なくできていた業務のやりかたを変えなければならないというのは大きなストレスです。
これらの良い解決方法はわかりません。 上からの適切な圧力くらいでしょうか。
幸いにもこれらに問題が無いとしても、以下のような問題はよく出てきます。
自動化などで知識がない人に対して概念を説明する良い方法
これも無理だと思います。 知らのいので、実際に動いているものを見るまで、そのシステムをどの程度受容可能かどうかを含めて判断することはできません。
なので、提案する側に業務についての知識が必要であり、過去事例から適切な案を提示できる能力が必要になります。
また、スパイラルモデルのように顧客すらも何を必要としているのかわかっていないということを前提とした開発スタイルが出てくるのです。
ここ数年、部署内で連携しながら開発・運用を進めていた
もう、運用しているんですよね？
投稿2025/02/16 08:20
総合スコア14039
> そもそも担当者・該当部署がその自動化を望んでいないということなのではないでしょうか。
一応、部署内では必要と判断して取り組みが進んでいるので、ここは大丈夫だと思います。
> 余った時間に他の作業をすることになることが抵抗を生んでいる可能性があります。
これは実際あるとは思いますね。
実際、業務負荷が減ったことで他種の業務担当が充てるか話になったとき、
かなり強く拒んできたこともあるので。
上の人間も管理能力面で疑念があるレベルなので、
上の人間が変わるタイミングを待つしかないのかもですね…
> もう、運用しているんですよね？
はい、当初目標となっていた機能は半年経たずに動き始めましたが、
後になって「実は○○」「△△はダメ」「システムは不完全だ！」とごねていて、
一方で「どうしたいのか？」というところが一切明らかになっていませんね…
仰る通り「顧客すらも何を必要としているのかわかっていない」の典型例かもしれません。
> 一応、部署内では必要と判断
「部署」というのは影響を受ける本人そのものではありませんよね。
その方が、自動化を必要だと判断しているのであれば、そのツールを使って効率を上げたり、問題を減らしたりするのに活用すべく前向きに動いているはずですが、そうではないということはそういうことだと思いますね、はやり。
0
前提条件は以下になります。
・開発の外注は無し(費用対効果的側面より)
・担当者は外せない(現状、業務を把握しているのは当人のみ)
担当者というのがこれまで手作業で当該業務を遂行してきており、
作業ポカの抑制などを目的とした自動化を進める
発端は担当者の業務負荷とか品質に起因しているのでしょうね。
担当者からの聞き取り内容を主とするのではなく、断片的な情報であるという前提で、
漏れや矛盾を吟味とし、拡張性を考慮して設計を行う必要があると思います。
担当の方が手作業で行っているという事なら、プログラミングの為に必要な情報が何なのかを意識して説明できるとは思わない方が良いですね。
それを埋めていくのが要件定義という作業で、ヒアリングを行ったらその人はもう必要ない位に設計に長けていないと駄目な状況のようですので、あなたにとっては荷が重いのでしょう。
貶めているのではなく、そういう状況をみてコントロールできていない上司に問題があると思います。
・開発の外注は無し(費用対効果的側面より)
状況的に、今後、開発担当の工数が嵩んでしまう可能性があるなら、要件定義フェーズのみ外注するというのも費用対効果はあるのではないでしょうか。
※担当者の社内的な甘えも抑制できると思えますし。
社内にそういった人材がいるならそれがベストですけど。
追記
単に状況を変える為なら上司や担当者に責任を持ってもらう事を明確にしてはどうでしょうか。
・変更があった場合は、テストは担当者にお願いする。不備については内容を明らかにして報告する。
⇒いやなら、精度の高い情報提供をしろ。
・内容の変更がある場合はリスケをし、人員確保や納期についての責任は上司。
⇒いやなら、傍観者になるな。
投稿2025/02/16 07:46
編集2025/02/16 08:06
総合スコア25354
やはり要件定義はそこまで突き詰めて行うべきですよね。
要件定義を社外に委託するというのは考えたことがなかったです、参考にします。
(社内の甘えは100%あるとは思いますので…)
0
ベストアンサー
システム開発に当たって、立ち戻りを無くすための手段はありますか？
これは何らかの作業が出戻りになるということですか？
それとも、前提となる運用フローなどの確認作業が都度発生することを防ぎたいのですか？
作業の出戻りは仕方ない部分があるので、無くすということは基本的にできないかと思います。
業務フローなどの仕様部分の確認が都度発生するのは、事前にすべてのメンバーが情報を共有しておくことはコストが高いですし、一人でやってるわけでもないのでおかしな部分があれば都度共有の形で何ら問題はないかと思います。
肝心の担当者が言うことをころころ変えたり、言った・言わないの議論になったり、
性格的な相性があるので口論になるようなもの同士で組まずに調整することが必要かと思います。
管理する立場の上司すらその担当者を咎めずなぁなぁにする環境に置かれています…
基本的に口論などのトラブルはお互いが悪いという精神で成り立ちますし、人によるかもしれませんが、管理する立場の人は人間トラブルを関知しないのが普通かと思います。
誰かと誰かのトラブルを避けるために人を変えたいなど具体的に言わなければなぁなぁになるのは当然ですし、特別な理由がない限りそこら辺の調整は打診するのではないでしょうか。
(議事録で明文化していても平気でひっくり返し、上司は上司で「やる気が～」云々と抜かす始末です…)
これは開発を受注している人との取り決め次第なので、外部からどうこう言えることではないです。。。
この手の業務で先述の「言うことをころころ変える」や、
「言った・言わないの議論になる」ような事例を経験ある方はいますか？
議論や口論しようと思えば好きなだけできますが、そういうのをする性格かどうかという人間同士の性格相性があります。(逆に、この人は心地いいとかそういうのだってあります)
担当者は外せない(現状、業務を把握しているのは当人のみ)
それでは、その担当者と口論になっている側を外すのが妥当な判断になるかと思います。
個人的には共同編集可能なファイルに追加機能や対応を記載する形にすることで不要なコミュニケーションが減り、仕様の確認やタスクの状況把握が簡単になった事例はあります
(TeamsのExcelやgoogleスプレッドシートみたいな感じです)
質問について、せっかくこのサイトがテンプレートを用意しているのに使用していないですが、こういった文章は忙しい立場の人間からすると読みづらくうまく意図を組めなかったりすることが多くあるかと思います。
(私がどうこうということではなく、仕事をする上での話です)
質問にあるような状況の立ち戻り(?)は問題として無視できるほどかなり小さいことかと思います
蛇足
(数年かけて帳票出力の開発をVBAでしてるってそんなことあるのか。。。？数年かかるほどのデータとか業務フローあるならわんちゃんVBAで動かすのかなりのストレスシステムなのでは。。。？)
投稿2025/02/16 04:45
総合スコア524
テンプレートはどちらかというと技術的な解決手段(エラーの対応など)のものになっており、
今回の内容では使用しにくかったので、フリーテキストにしています。
そこは申し訳ございません。
Teamsや業務のタスク管理表なども職場内では活用し、
適宜不明点などを確認したりもしています。
個人的にはテキストベースであれば感情的なぶつかりも避けられて助かっているのですが、
一方でそれにすら返信が無い…という、恥ずかしながらそういう状況にあります。
ただやはり、タスク明確化と遵守は必須ですよね。
蛇足の方については、自分も(どうしてこうなった…)と思っているところです。
帳票を出す程度ならすぐに済む話のはずなのに、
話が二転三転とし続けて今に至っています…
自分(作る側)が抜けると開発自体が止まってしまいますし、
担当者(作業を知る側)が抜けると目的が定まらない、
そんな職場の人的資源の制約もあるので、もうしばらくは粘ってみます…
あなたの回答
tips
プレビュー
