現行踏襲という言い訳
▪️失敗するプロジェクトでよく聞くキーワード
私個人の経験で、業務説明で現行踏襲というキーワードが出たら、だいたいプロジェクトが炎上している。この現行踏襲だが、IT業界以外ではあまり聞く事が無かった。工場や建設現場に行くと改善とか品質向上、営業でも改善とか開拓といった、成長志向な謳い文句が多かった。
現行踏襲という考え方は、IT業界特有の傾向だと思う。ユーザの本音は、お金がかかるので、一度作ったものを100年でも200年でも使いたいのだろう。現行踏襲という言葉を聞くたびに、そんな意図が透けて見える気がする。
▪️現行踏襲の難易度
よく誤解されているのが、新しいシステムを設計するより現行踏襲の方が簡単だと思われていることだ。実際は、突貫で作られた不安定なシステム等、場合によっては新しいシステムを設計するより大変になることがある。
現行を踏襲するには、現行システムの仕様が明確でなくてはならない。構築時のドキュメントが残っていても、運用時の変更箇所が適切に更新されていないと役に立たない。なので、現状調査が必須になる。場当たり的な運用をしていると、この現状調査の難易度が高騰する。
システムを更新しようとした段階で、システムの事は全て把握できている。という状態でもないと、現行踏襲は簡単にはできない。そんな理想的な状態で運用されているシステムというのも稀だろう。
▪️システムリプレイスのあり方
現在運用されているシステムの大部分がコストを安く上げ過ぎていると思う。車でいうなら、ガソリン以外のコストをかけないくらいのレベルだ。コストを渋って、「動けばいい！」くらいのノリでシステムを構築する。そのまま行き当たりバッタリに運用して、いざリプレイス時にブラックボックスと化している事例をよく見てきた。
本当にシステムを安定稼働させたかったら、システムを新規で立ち上げる時から、リプレイスのための準備を進めていくことになるだろう。でもない限り、メンテナンス性の高いコードを書く気にもなれないだろうし、ドキュメントの更新なんてする気も起きないだろう。
理想を言えば、運用期間中にコードをリファクタリングしたり、リプレイス時の計画を長期で立てられれば良い。システムリプレイス時の負担を分散できれば、トータルのリスクはかなり減るのではないだろうか。システムに対してのエンジニアの練度も確保できるし、現状調査のコストも大幅に削減が見込める。
▪️システムとの向き合い方
最近の企業はエンジニアを雇いたがらない。何かと請負先に丸投げしたがる。システムを粗末に扱い過ぎている感もある。お金を払えば簡単に恩恵が享受できる、そういうインスタンントな思考に染まっている。
実際は物は使い手を選ぶ。便利な道具ほど使い手のスキルが要求される。多くの恩恵を享受したければ、相応に学ぶべきことも増える。安直に安く上げようとして、逆に多くのコストがかさんでいるシステムをいくつも見てきた。無学ほどコストがかさむものは無い。これが私の思う結論だ。
システムリプレイスの際に現行踏襲というキーワードが出てきたら、具体的に何をどうするかを聞いてみよう。ここで曖昧な答が返ってきたら、現状を把握していないと見て間違いない。実際、踏襲しても何の利益の無い現行もある。引き継ぐべきものと捨てるべきものが区別できなければ、負の遺産も引き継ぎ、後々のコストに響いてくる。
現行を知るというのは意外と労力がかかる。継続的なアプローチは必須だと考える。リプレイスの時だけ人を集めてバタバタやるというのは、いささか無理を感じる。日頃から使ってるシステムなんだから、もうちょっと普段から関心を向けてくれてもいいのではないだろうか。
コメント
やまぐち
一から作ってうまくいく保証も同じぐらいないじゃないですか？
だったらほんのわずかでも動きのわかる現行機を基準に話を
進めてもらいたいのです
っていうかそうすれば「いまどうなってる？」ていうのを
解析係の作業員に丸投げ出来るからその方が楽なのです
それに仕様書に記述されない業務に特化した仕様をすべて放り投げて
一から作ってうまくいく規模のシステムなどもはやこの世に
ないでしょう
ここは私がpcを触り始めた頃の常識と今とはちょっと違いますね
ksiroi
> やまぐちさん
ソースが仕様書だ、みたいな三流は業界から居なくなってほしいなぁ。
心の底からそう思う。
解析することでお金が動くよ！みたいなことを平気で喋る経営者もついでに消え去ってほしいなぁ。
技術立国ってなんだっけなー…
ぬめ猫
相変わらずいいとこ突きますね。
「現行踏襲」を根拠に、元が明らかにクソなモノをクソなまま再生産。改善提案を組み込んで作り直せば品質が上がって障害にも強くなるのに。
しかしそれは、最初に「現行踏襲」だからと予算をゴリゴリ削った結果。クソの再生産でいっぱいいっぱいなんです。
本当はクソ作るのは嫌だし、「はいっ、ご所望のクソです」と提供するのも心痛むんですけどね。
転職活動中
>日頃から使ってるシステムなんだから、もうちょっと普段から関心を向けてくれてもいいのではないだろうか。
この一言に全て集約されますね。
壊れてから、ボロくなってから慌てて新しいものを入れようとしたり・・・。
もっとも、兼任とか引き継ぎの繰り返しで現行を把握しきれていない状況も多々あるので、そうするとやっぱり作り直したほうがよっぽどいいものができるだろうなぁと思います。
ただし、業務部門が協力的かどうか、ちゃんとリソースを割いてくれるか、その説得ができるかというと、やっぱり出来上がるのはクソな気がします。
やまぐち
>ソースが仕様書だ、みたいな三流は業界から居なくなってほしいなぁ。
心の底からそう思う。
でも本当に全部を記述することはできないので
ある程度で線引きが必要になりますよね？
ぶっちゃけ私の回りではその辺担当者の匙加減で決まっています
ドキュメント書くのが好きって人もそんなに多くないです
bau
>やまぐちさん
おっしゃるとおりの所もあります。
細部は担当者のさじ加減にもなりますし、全ての仕様がつまった完璧な設計書なんて現実的にはほぼありえないでしょう。
ただ、現行の動いているシステムが完璧なものであることもないので、それをもとにちゃんと考えて取捨選択してあるべき姿にしていくことが大事なのかなと。
それをさじ加減という言葉に含まれてたのなら申し訳ないです。
だいたい「現行踏襲」って言葉が出てきたときはゴミも一緒に取り込むつもりが多いんで。。。しかもゴミとは知らずに取り込むからなおさらタチが悪い。。。
EXCELER
原稿を踏襲は重要
気分でカエル。ポリシーもなくカエル。なんの考えもなくカエルくらいなら、基本ポリシーやUIの基本設計は同じままそのまま素直にスペックのみアップデートした方がよりユーザーフレンドリーですよ。意味もなく新しいものを作って、利用者困惑・・？はだめです。勇気を持って現状維持すべき。
もちろんよりよい革新は必要ですけどね。意味なく新しくするのは駄目です。
hage
現行踏襲はプログラムを変えない事ではなく、用途/使途を現状のままとする＝他の機能の仕様が変更された時に反映されることを期待する、という事だと思っています。
たとえば、商品を特定の条件で集計する表があったとして、新しい種類の商品が追加された場合、今のままで良いのか悪いのか。
こんな時に現行踏襲と言われ、そのままで良いのか確認しても、意図した集計が行われていない、そういうつもりで言っていない、と言われ、改修する事になるのは何度も経験しています。
最近はこの言葉が出たら確約を取りつつ、リカバリー用の日にちを調整しますね。
今まさに炎上中
RFPでは現行踏襲など一言も語ってないのに、
契約してみたら誰も仕様を知らない現行機能
踏襲の追加要件だらけで、追加費用要求すると
詐欺呼ばわり。
どっちが詐欺だよ・・・
双方のプロジェクトリーダーは逃げだし
絶賛炎上中