標準化と情シス（その２）
以前、こんな記事を書きましたが、このときはインフラ環境面のところの標準化をしていましたが、もう少し広い話をし始めています。
標準環境の整備
弊社の場合、ずっと大型機がメインだったこともあり、ハードウェアの環境を標準化するという考え方がありませんでした。
人によっては、
「環境？知らねーよ、ベンダーに聞けよ」
という感じ。
これではいけませんので、クラウド移行とあわせて下記のようなプロセスで整備してきました。
１）基本的な設定環境の「型」を作る
２）フレームとして、ガイドライン化する
３）規定化する
１）を行ったうえでやっているので、そこまで混乱はない感じではありますが、問題はルールを守るかどうかという問題。
開発工程の標準化について
ここにもやっと本格的に着手しました。まずは、開発のマイルストンを決めるところですが、まあ、これはV字モデルの考え方に沿って考えていけばよい。
最初に重視したのは案件化する超上流プロセスとテストプロセスで、ここで「やる・やらない」と、「必要な個所はテストして品質をはかってリリースする」ということを担保しました。
品質を合意することの難しさ
一番苦心したのはテスト工程でした。下記のようなプロセスで標準化していったのですが、一番苦労したのが２）であります・・・・！
誰も試験項目なんて作ってなかった（ガーン）。
１）テスト計画を立てる…テスト範囲や方法を決める
２）テスト項目を作る…項目書を作る
３）テストの進行管理をする…進捗状況を計測して管理する
それまで、ユーザともベンダーともわりとなあなあというかズブズブでやってきたので、要件にも何にもないことを
「これはおかしい！不具合だろう！」
とユーザがいったのが通ってしまったり、
「これ、どんな仕様なんですか？」
とテストしながらユーザがいってきて、そこで仕様相談が始まるなんて言うこともありました。
レビューもやってなかったですしね。
なので、
・レビューを徹底する
・試験項目書を作ってそれをもとにテストする
ということをやったのですが、これだけでずいぶん改善されました。
「試験するまで試験項目なんて決められない！」
なんていう部門もいらっしゃいましたが、
知らんわ。
システム運用ルールは守られない？
しかし、このあたりはユーザだけではなく、足元の情シスにも問題あり。
ルールを守らない社員が多すぎるんですよ。
ここにもありますが、ひと言でいうと自分ごとじゃないの。
フレームやチェック過程を作ってしまえ
なので、100％を求めようとしても無駄なのでやっているのがこれです。リリース作業であったり、さまざまな作業の前のチェック過程を決め打って
「このゲートを通るにはこの申請書を出しなさい！」
とやるか、
「月次でこの内容を埋めなさい」
と「仕事」にしてしまうことです。
このあと、開発の内製化に向けて標準を決めていきたいんですけど、まだまだ道は遠そうで。
少しずつ、できるところからやっていきたいと思っています。
この記事が気に入ったらサポートをしてみませんか？