システム・ツール導入時に気をつけていること

こんにちは、DOAです。

システム導入・設計・構築・整理をありがたいことに携わらせていただいている中で、構築途中で葛藤する場面に遭う時があります。

おそらくシステムを構築したことがある方なら一瞬

「これ、私しか読めない/わからない作りにしてしまえばいいのでは？」

と頭をよぎる時があるのではないでしょうか？
無かったらすごい聖人の方だと思います。

是非その全くよぎらないコツを教えていただきたいです。

たとえばどうしてもお客様が希望される機能で
・自分しか知らない方法がある
・ちょっと複雑な形になるけれども実現できる
機能を必死になって作っている時とかです。

機能実現が可能なのも見えた上で、手法もはっきりわかった上で「じゃあ実現しよう！」で終わるのではなく
・お客様にきちんとお伝えができるか？
・仕様書を残せるか？
・その後運用ができるのか？
の確認と、時間コストが頭をよぎると、このまま属人化させてしまえば(*'▽')・・・となります

実際そういうサービスもあると思います。

そんな時は必ず、「6年以上システムサポート部門にいた経験」が速攻で頭をめぐります。

フルスクラッチシステムの3年・6年・10年後。
いろいろ担当者が改変したことによるその後のサポート。
バージョンアップ時のアレコレ（；ﾟ Дﾟ）

お客様/自社/開発者の三方面の間に立った時に、どうなったのか？を骨身にしみて体感したので、「業務を属人化させるな！汎用的に書け！もし独自の書き方をしなきゃいけないなら、担当者を見て案内する範囲を限定しろ！」と踏みとどまることができます。。

もしお客様の状況を顧みて、メンテナンスができなさそうと判断したらあえて言わずに、提供しない判断を毎回しています。

結局、シンプルに拡張性があるように設計をしなければ、その後に大変なのは自分だけではなくお客様。

お互いに次の新しいことができず、苦しむばかりになります(-_-;)

サポートフェーズより導入が多めの時期になると、どうしてもよぎる頻度が高くなりますが、その都度思いとどまれるのは、あの6年間のおかげ。

Q.サポートフェーズは何が起きるか？例：問合せ発生時
その当時のシステム解読から始めて、事象を確認、対処方法を推測するので、どうしても通常QAよりも時間がかかります。

推測力&スピードで数をこなしたので、おかげで解読パズルが若干得意になりました(´▽｀)

運用フェーズサポート部門（システムQA）の体験が長くあったからこそ、運用フォローを踏まえたお客様へのお伝え、講師、システム構築対応を行うよう、注意している面でもあります。

※構築段階ではそうではないときもありますが💦

お客様がシステムを使いこなせる状態になり、メンテナンスも自社内になり。

徐々に質問が少なくなっていくのを見るたびに、このお客様もここまで来たのかー！という感動と
巣立ちだなぁ（＊´・∀・＊）
というシステムの手放しをしみじみ体感する日々です。