システムの「構成」の話です。
ある打合せで相談を受けました。
立派な資料が作れられていました。
そして、苦労されている様子が
分かりました。
この処理が・・
あの処理が・・
新しい方式に、
クライアントの方針が
変わって・・
かえってトラブルが多発している。
理由は、コストダウンで・・
信頼性が・・
結局、根拠の不明な・・
方針決定！
自社の負担が減らせる！
その分、貴社でがんばって！
という方針になっている様子!
コストの定義も不明で、
コンセプトが悪いとしか
いいようの無い方針でした。
これを受けての対応するしかない？
こんな事が、
発生しているのが現状ですね。
経緯は、トラブル発生があったようですが、
現象に対しての対策も、
根拠が不明でした。
やはり「構成」の問題です。
つまり王道の型でも、
順番が大事でした。
つまり、構成については
要素レベルで裏付けが必要！
情報収集をしないと
大きな損害、
部品代が減っても
工数が爆発です！
このような問題をもったまま
進んでいることを、
知ってしまった！
誰の責任だぁ？！
と考えさせられました。
つまり、
構成を評価する・・
テストするとは、
要素の裏付けも必要
ということです。
やはり、方針を左右する
構成の検証が
いかに重要かを
改めて気付いた
打合せでした。
みなさんも、
こんな悩みを持っていませんか？
是非、みんなで学んでいきましょう！
その為には、
このメルマガに登録頂いている方、
みなさまのご協力を得たい！
という思いです。
さあ・・
今年もあと少し！
やりましょう！
来年に向けての
セットアップ！
あなたは、どんな挑戦をしますか？
挑戦した人にだけ
新しいプレゼントがあるはずです。
