世の中には「面倒な手続きほど価値がある」と考える人が結構いる。エンジニアの苦悩 168
あるあるではある 部門より
しんざき氏が書いた『エンジニアをしていると、世間には「面倒な手続きほど価値がある」と考える人が、けっこういるとわかる。』という記事が興味深い内容となっている。
内容としては、同氏がある企業の社内業務システムのリプレースのプロジェクトに配属されたことから始まる。顧客からの要望は、本来なら日次で動かさないといけないバッチ処理が24時間で終わらないため、システムを高速化してほしいという趣旨だったようだ。
時間の掛かる処理中に発生した新たなデータは、Excelで入力しておいて、後から手動で再入力するなどの工程が発生、しかも複数の人が別々のExcelを作って後からそれを統合しているのでミスが発生していたという。ミスを確認するための人力チェック体制まで構築されていたという。企業のシステム系にありがちな複雑なフローを、手作業などを経由して無理矢理複数つなぎ合わせた構造になっていたようだ。
良くある話ではあるのだが、顧客側からの要求はこうした面倒かつ複雑なフローは維持したまま、処理時間だけを短縮してほしいという要望だったという。しかも予算がないわけではなく、システムはフルスクラッチが前提の案件で。なぜ顧客側から複雑なシステム改善要求が出てこないのかをヒアリングしたり、プロジェクトチーム内で議論した結果、
現状のシステムで複雑な仕事を丁寧に回せる人が評価されてリーダーになっていて、その人が今のフローを変えることを望まなかった
との結論（元記事では複数の理由が記述されているが）に至ったようだ。しかも、チームがヒアリングしたのがこの「今のフローを丁寧に回すことで評価されたリーダー」だったことから、プロジェクトはフローを変えること自体を拒絶されてしまった模様。最終的には経営陣を交えて不効率なフローを廃してシステムまるごとリプレースを通したが、そのリーダーは最終的には退職してしまったらしい。
本当に価値があるので困る (スコア:3, 興味深い)
「業務に特化した知識を持つ特定人物」が「何時間も掛けて作業する」ことは、
「代替性の効かない高単価の人材」が「大きな工数を積む理由として正当化」できるので、
人月工数で弾き出す日本の商慣習では大きな価値を持つ。
しかも「今のフローを丁寧に回すことで評価されたリーダー」は上司のウケもいい上に、
自分にしか出来ないように「業務最適化」してるので、こいつがいないと「明日の仕事」が
回らなくなる。
更迭するにも高コストを覚悟しなきゃいけないので、結局は「価値を持つ」状態。
Re:本当に価値があるので困る (スコア:1)
明日の仕事がまわらなくなるリスクを同時に抱えているので、そんな人材は負債でしかない。
そんな難しい話か？ (スコア:2)
単に中身が分からないからコストで値打ちを判断してるだけ。
#そう言えば、なぜか教育テレビで「資本論」やってるよ。
Re:そんな難しい話か？ (スコア:2)
一次近似としてはありですね
労働が単純だったころには精度も高かったのだろうし
こういう効率化の体験を小中学校あたりでやってもいいのかもしれないね
# 考えてみると反対のことが多かったような気もするが
Re: (スコア:0)
ロボットものでスイッチいっぱいオンにするシチュエーションは楽しいよな
Re: (スコア:0)
核ミサイル等の大量破壊兵器や自爆装置は、相応に「面倒な手続き」にして措かないと、暴発や工作活動成功の可能性が大きい。
Re:そんな難しい話か？ (スコア:1)
難解で面倒なプロセスは利権だから (スコア:2, すばらしい洞察)
「俺|私しか把握してない難解で面倒な手続き」というのは組織内で自分の地位を守るための道具であり、利権なので、
詳らかにされちゃ困るという手合いはこの国のある程度の規模の組織には必ずいる。少なくとも私の経験上例外はない。
そういう手合いは合理的なシステム化の巨大な障害になるのだが、まさにその利権によって発言力があったりするので厄介、というより多くの場合手に負えない。
そのブラックボックスをブラックボックスのままとして意味不明な設計を余儀なくされるという悲劇は向こう50年はなくならないだろう
Re:難解で面倒なプロセスは利権だから (スコア:2)
この国、で思い出したけど
アメリカの大統領選挙の仕組みとかこれの最たるものですな
Re:難解で面倒なプロセスは利権だから (スコア:2)
その点がまさにそっくり
複雑な仕事を回せるリーダー (スコア:2)
20万ステップ程のFORTRANプログラムを開発した人です
そのプログラムは設計上必須で、設計変更に伴って継ぎ足し改変を続けたので(その結果膨大になった)
彼以外に中身が分かる人はいませんでした
それが彼の狙いで、後継者を作ることもなく定年までそのプログラムを維持し続け
その結果、彼の地位も安泰で嘱託となっても活躍し続けたのでした
Re:複雑な仕事を回せるリーダー (スコア:2)
あまり早く計算が終わって職員が帰ってしまうと
偉いさんが仕事をしていないのではと心配するからだそうだ
某プラント会社は東海道線の沿線に本社があったが
線路側の電灯は深夜まで点けっぱなしにしていた
電車に乗って帰る顧客がわが社が頼んだ仕事をしていないのでは
と心配するからだそうだ
COBOLerのことか (スコア:2)
30年以上前に突如COBOL案件に投げ込まれた際の個人的な偏見です
Re:COBOLerのことか (スコア:2)
訂正
誤：30年以上
正：30年弱
人類にとっては少ない年数だが、一人の人間にとっては大きな年数である
Job security (スコア:1)
動いているものはいぢるな！ (スコア:1, 興味深い)
正常に動作しているシステムに手を加えると予期せぬ障害がでるのはよくあること。
特にシステム一新してトラブルと滅茶滅茶になって挙句の果てにものすごい労力を費やして元のシステムへ移行しなおすなんてことまで。
今回の案件は結果としては（書かれてないけどたぶん）トラブルなくうまく一新できてよかったのかもしれないけど、どんなトラブルが生じるかわかったものじゃなかった。
＃ソフトいじらずハードを速いのに変えてお茶を濁すかな
Re:動いているものはいぢるな！ (スコア:1)
そのシステムに(自動)テストを組み込んでいけるかが開発者のリアルな技術力が問われる所だろうな。テストは実装より難度の高い課題であることが多い。
「動いているものはいぢるな！」の心得はそれなりに正しいと思う。しかしその論に支配されたシステムは確実に腐る。
Re:動いているものはいぢるな！ (スコア:1)
ハードウェア保守とか、ソフトウェアサポートとかの期限で決めればよくない?
Re:動いているものはいぢるな！ (スコア:1)
// 忘れ去られるともいう
Re:動いているものはいぢるな！ (スコア:1)
それではちと長すぎるという話では
ハードウェア保守って、サーバだと大体標準で5年。
ソフトウェアの保守は、モノにもよりますが、どうかすると3年たたずに特定バージョンのサポートを切ったりすることもありますよ。
一体、どのくらいだったら満足なんです?
Re:動いているものはいぢるな！ (スコア:1)
// 仕事先がこんな感じ
エンジニアだけかな？ (スコア:1)
ラーメンのスープやコーヒーのいれかたみたいな？
潔癖症の手間とか愛情表現とか新コロとかApple製品とか？
効率の理屈が感情論で上書きされる例はよくありますよね
Re:エンジニアだけかな？ (スコア:1)
嗜好品なら効率無視でも良くね?
Re:エンジニアだけかな？ (スコア:1)
獺祭好きな人って結構多いですよ
清酒の獺祭ですか?
純米とか断吟醸とか二割三分磨きとか遠心分離とか、効率重視だったらやらないと思いますよ。
Re: (スコア:0)
この記事を思い出した
飲食店は電子レンジのチン音が鳴らないように改造依頼することがある
https://hardware.srad.jp/story/20/12/15/2014211/ [hardware.srad.jp]
ストーリーのタイトルは根拠がない (スコア:1)
単に「今のフローを考案した人がリスペクトされていて、そのフローが神聖視されていた」というだけじゃないんですかね。
だから、当初の要件では現行のフローを変えることは望まれなかったと。
でも実際には、経営陣も現場もシンプルにして不要な部分を取り除くことを選択したわけでしょう。
であれば、別に面倒な手続きに価値があるという根拠はなく、単に現行のフローを変えたくないというだけだったのでは？
タイトルにあるように「周りもシンプルより複雑なフローの方がいいフローだ、シンプルなのはよくない」と思っていたとは読めないんだけど。
Re:ストーリーのタイトルは根拠がない (スコア:2, 参考になる)
ただ言われたことをこなす SIer か、調査・分析、提案まで含めたコンサル的な動きができるかの違いかと
現場からは自分たちが見える範囲での改善、効率化しか見えてこないです
横断的、俯瞰的にシステムや運用を分析して最適な解を経営層に提案、そこから各現場を巻き込んでいくのが一番金が引っ張ｒ……求められる動きじゃないですかね
その金を持っていたというのがこの会社にとってもしんざき氏にとっても幸いでしたね
# 金がないとフランケンシュタインの指二本だけ取り替える、みたいな「これ意味あるのかな～」というパッチワークになってしまう
最終的には経営陣を交えて不効率なフローを廃してシステムまるごとリプレースを通した、って (スコア:1)
よく外部の請負人がそこまでできたね
見出しだけ見て (スコア:1)
面倒な手続きではなく (スコア:0)
旧来のやり方を変えられない人達がいるってだけじゃないか
Re: (スコア:0)
今でも「面倒な勉学で学歴を得た」という役に立たない価値や権威で無能さを隠す人、世の中に毎年増えてますよ
意味ないのに
Re:面倒な手続きではなく (スコア:1)
今でも「面倒な勉学で学歴を得た」という役に立たない価値や権威で無能さを隠す人、世の中に毎年増えてますよ
そう言う人は今も昔もいないわけではないと思うけど、「毎年増えて」いるとする根拠はあるんでしょうか?
大した勉強もせず、Fランク大学で学歴を得た人は、昔より増えてる気がしますが、それにしたってこの不況と少子化でむしろ減っているのでは。
Re:面倒な手続きではなく (スコア:1)
// 増えているかどうかはともかく
Re:面倒な手続きではなく (スコア:1)
価値はある (スコア:0)
手続きのコストが高くて困るというのは会社が考えるべきこと
末端の労働者にとっては実績になって高い給料を貰う口実になる仕事は価値が高い
雇用者の側から見れば実績に中身があって給料分を使い切れてる仕事の方が価値が高い
「実績になって収益が大だが不必要に大変ではない仕事」が双方にとってのベストで
やたらと末端が経営者目線で評価体系の検討など無視して収益重視の変更を入れるのは
必ずしも賢くない
理想としてはそもそも会社の収益が無限大なら全員自由出勤で収益を山分けすればいい
そうすれば個々人の実績なんか関係なく収益を上げ成長する方法をみんなで自由に研究すればいい
Re:価値はある (スコア:2)
社外との競争が無縁の部門に多い気がするな、こういう話は。
Re:価値はある (スコア:1)
社外との競争があるところはほとんどが10年以内になくなるからな。
ぴこーん (スコア:0)
ひらめいた！
努力と根性とおべっかで忠誠度を効率的に示す仕組みをシステム化すればいいんだよ
# エンジニアの技術/知識とか関係ない話じゃん
動いてるモノには手を加えるな教 (スコア:0)
教えとして間違ってるわけではないんですけどね。
むやみやたら手を加えてトラップを仕掛けるよりは。
航空機のスイッチ類と計器 (スコア:0)
航空機のスイッチ類と計器はもっと省略できると思うんですよ。
チェックリストとかも
Re:航空機のスイッチ類と計器 (スコア:1)
省略するには機械による自動化が必要になるけど、それにもデメリットがあるのよね。
・自動化する仕組みは複雑になり、複雑になると故障の可能性が上がる
・故障したときにマニュアル操作によるリカバリができなくなる
マニュアル操作によるリカバリとは、車で例えるならエンジン故障してもセルモーター回して短距離進むとか。ブレーキ故障したときにローギアにぶち込んで減速するとか。
Re: (スコア:0)
設計者に作る物に見合った能力があるならね
Re: (スコア:0)
エアバスは「正常時は消灯する」設計にしてるよ
例えばオフの時は「OFF」押すと「START」でオンになると「ON」表示→消灯とかね
パソコンと比べるとまだまだビジュアル的にうるさいのは事実だけど簡素化は少しずつ進んでる
Re:航空機のスイッチ類と計器 (スコア:2)
一つおかしいときに、1個だけ点いてるのと一個だけ消えてるのでは
点いてるほうが目立ちそうです。
ランプ故障は多系統化とかで対応してんのかな
Re:航空機のスイッチ類と計器 (スコア:1)
暗い中(コクピットは飛行中は暗くする)で、街のイルミネーション(ルミナリエみたいなの)で「ひとつだけ消灯」してるランプを探し出すのと、全消灯のはずなのに「ひとつだけ点灯」してしまっているランプを見つけるの、どっちが楽か考えたらすぐにわからない？
ちなみにエアバスに限らずボーイングも含めハイテクな世代の旅客機はほぼすべて、標準が消灯で標準では無い状態で点灯(ダークコクピットって呼ばれてたりする)
点灯させる色も各社でちょっとした差はあるけど、基本的にはほぼ統一されてる(色だけでも即座に対応すべきか余裕をもって対応すべきか判断できるように)
Re: (スコア:0)
でも封印を叩き割って二人同時に鍵を回さないとダメにスイッチには魅力を感じませんか？
#元記事が言いたいのは落語のぜんざい公社みたいな奴だろうけど
自治体のシステムを統合するらしいが (スコア:0)
至る所でこういう問題が出てくるんだろうなあ。
お疲れ様ですっ！
https://www.nikkei.com/article/DGXMZO64225300V20C20A9EAF000 [nikkei.com]
責任の集中 (スコア:0)
テストコード書いて100msで終わらせたら書いたプログラマーの責任で1人月
みんなで画面睨めっこして目視確認したらみんなの責任で5人月
自分の場合 (スコア:0)
「不要なもの削って！自動化できるものはして！」で設計して出したら、余計な手順足す事になりましたね。その分ムダ処理増えた。
Re:スラドもそうなんじゃないの？ (スコア:1)
type があるからコンパイラからツッコミがもらえて感謝してます。