「こっちは客なんだから」とドヤ顔で。
一瞬、筋が通っているように聞こえるんですよね。
社内SE的には「あーあ、言っちゃった・・・」と内心苦々しく見ています。
私はガマンできないときは、ベンダーに助け舟を出してしまいます。珍しくw
ベンダー側もため息交じりです。
ちゃんと反論すればいいのにしないんですよね。
まあ使えないマニュアル作るだけで小銭が稼げますからねw
この部分、結構スルーしてしまいがちですが、実は基幹システム開発のゆくえを占う象徴的なシーンなんですよね。その後の流れが決まるというか。
ベンダーだけが被害こうむるならいいのですが、結果として社内SEひいては会社に、ブーメランのように返ってくるところなんですよ。
以下にその理由を書いてみます。
一瞬、筋が通っているように聞こえるんですよね。
社内SE的には「あーあ、言っちゃった・・・」と内心苦々しく見ています。
私はガマンできないときは、ベンダーに助け舟を出してしまいます。珍しくw
ベンダー側もため息交じりです。
ちゃんと反論すればいいのにしないんですよね。
まあ使えないマニュアル作るだけで小銭が稼げますからねw
この部分、結構スルーしてしまいがちですが、実は基幹システム開発のゆくえを占う象徴的なシーンなんですよね。その後の流れが決まるというか。
ベンダーだけが被害こうむるならいいのですが、結果として社内SEひいては会社に、ブーメランのように返ってくるところなんですよ。
以下にその理由を書いてみます。
システム開発にエンドユーザがコミットしなくなる
まずエンドユーザの、基幹システムプロジェクトに主体的に関わる雰囲気が薄れるのが怖いんですよね。
マニュアル作りをベンダー任せにすると、
「あなた(=ベンダー)作る人、私(=エンドユーザ)食べる人」
という受身の態勢になっていくんですよ。その後もずっとです。癖になっていきます。
開発が終われば自分たちが使うシステムなのに、他人事として関わるようになります。
使う人がコミットしないシステム開発がどうなるか・・・
いったん上げ膳据え膳に慣れた人の考え方を変えるのは、大変難しいです。
誰だってラクなほうがいいですから。
そんな状態でも、ベンダーは適当に開発をしてしまいます。
彼らは¥さえもらえれば何でもいいですからね。後は野となれ山となれ。
で、使えないシステムの一丁上がりです。
最初はマニュアルだけの問題と思ったら、システムの存在意義をも揺るがす大問題になってしまうのです。
これを防ぐには、「マニュアル作成は現場の責任」と、キックオフミーティングでグランドルールとして宣言しておくべきなんです。
マニュアル作りをベンダー任せにすると、
「あなた(=ベンダー)作る人、私(=エンドユーザ)食べる人」
という受身の態勢になっていくんですよ。その後もずっとです。癖になっていきます。
開発が終われば自分たちが使うシステムなのに、他人事として関わるようになります。
使う人がコミットしないシステム開発がどうなるか・・・
いったん上げ膳据え膳に慣れた人の考え方を変えるのは、大変難しいです。
誰だってラクなほうがいいですから。
そんな状態でも、ベンダーは適当に開発をしてしまいます。
彼らは¥さえもらえれば何でもいいですからね。後は野となれ山となれ。
で、使えないシステムの一丁上がりです。
最初はマニュアルだけの問題と思ったら、システムの存在意義をも揺るがす大問題になってしまうのです。
これを防ぐには、「マニュアル作成は現場の責任」と、キックオフミーティングでグランドルールとして宣言しておくべきなんです。
マニュアルはベンダーが作るものではない
そもそも、
基幹システムのマニュアル≒業務マニュアル
なんですよね。
基幹システムのマニュアル≒業務マニュアル
なんですよね。
そして「業務マニュアルはユーザ側が作るべし」とはよく言われることです。
何故ユーザ側が作らなければいけないのかと言うと、ベンダーが作っても使い物にならないからなんですね。
彼らにマニュアルを作る能力がないというわけではありません。
問題なのは「重み付けができない」ということなのです。
ベンダーがマニュアルを作るとどうなるか。
画面に出てくる「○○区分」などの選択肢1つ1つについて、全部解説したようなものが出来上がります。
「○○区分のボタンを押すと、A・B・C・D・Eの選択肢が表示される」のような、画面を見たらわかるような情報しか書いてありません。
ベンダーが作るマニュアルは、メリハリのない、のっぺりとした辞書のようなものになるのです。
辞書を物語として読む人はいませんよね。
上の例で言えば、
・Aの値に何の意味があるのか
・業務ではほぼ9割方Aしか選択しない
といったことも書いて欲しいのですが、それはベンダーには書けません。
だから「業務マニュアルはユーザ側が作るべし」なんですよね。
テストシナリオを利用してマニュアルを作る
ではどうやってマニュアルを作るべきか。
実は基幹システム導入のプロジェクトをやっていれば、マニュアルを作る機会は必ずやってきます。
それは社内SEのスケジュール感で言うところの、テスト作成フェーズ・テスト実施フェーズの時です。
実は基幹システム導入のプロジェクトをやっていれば、マニュアルを作る機会は必ずやってきます。
それは社内SEのスケジュール感で言うところの、テスト作成フェーズ・テスト実施フェーズの時です。
・テスト作成フェーズ:要件定義・仕様策定後、ベンダーがプログラム開発を行っている期間
(ベンダーで言うところの「開発」フェーズ)
・テスト実施フェーズ:ベンダーがプログラム開発後に、ユーザ側でテストを実施する期間
(ベンダーで言うところの「仮稼動フェーズ」)
(ベンダーで言うところの「開発」フェーズ)
・テスト実施フェーズ:ベンダーがプログラム開発後に、ユーザ側でテストを実施する期間
(ベンダーで言うところの「仮稼動フェーズ」)
こちらとベンダーではフェーズ認識が違いますので、注意が必要です。
こちらがベンダー側の認識に合わせる必要はないです。
こちらがベンダー側の認識に合わせる必要はないです。
関連記事:
テストには実際の業務に合わせたテストシナリオが必要です。
テストシナリオは、頻度の高い業務から記載していきます。
業務には、毎日行うものから数年に1回しかやらないものまでありますから、毎日行うものから書きます。
業務には、毎日行うものから数年に1回しかやらないものまでありますから、毎日行うものから書きます。
これが重み付けなのです。ベンダーにはこの重み付けをつけられないのです。
丁寧にヒアリングしていればわかるはずなのですが、ベンダーは面倒くさがってやりませんね。
だからユーザに振り回されるんですよ。
「この機能がないと困る!」なんて言われて苦労してプログラム開発したら、実は年に1回しかやらないその人の趣味の世界の業務だったなんてことがあります。
重み付けのあるテストシナリオを文書化すれば、業務マニュアルになるはずなのです。
丁寧にヒアリングしていればわかるはずなのですが、ベンダーは面倒くさがってやりませんね。
だからユーザに振り回されるんですよ。
「この機能がないと困る!」なんて言われて苦労してプログラム開発したら、実は年に1回しかやらないその人の趣味の世界の業務だったなんてことがあります。
重み付けのあるテストシナリオを文書化すれば、業務マニュアルになるはずなのです。
テストシナリオは業務マニュアルの骨子と言えます。
もちろん最初から完璧なものはできません。
だんだん継ぎ足していけばいいんです。
でもそれを継続するのは大変難しいんですよね・・・
そういう地味な作業こそ仕事の肝だし、評価されるべきなのですが、派手な動きが好きな経営者にはまるで響きませんね。
働き方改革において100点満点主義が有害である5つの理由
記録に始まり、記録し続ける
「基幹システムの全体を知らないから、全部使いこなせていないかもしれない」と言うエンドユーザがどの会社にもいます。
そういう完璧主義(?)が「マニュアル作ってよ」のセリフを言わせている面もあります。
メリハリのないのっぺりした辞書のようなマニュアルがあれば、使いこなせるのかな?といつも不思議に思います。
辞書は何か知りたいことがある際に引くものであって、起点になるものではないですからね。
関連記事:
もちろん最初から完璧なものはできません。
だんだん継ぎ足していけばいいんです。
でもそれを継続するのは大変難しいんですよね・・・
そういう地味な作業こそ仕事の肝だし、評価されるべきなのですが、派手な動きが好きな経営者にはまるで響きませんね。
関連記事:
記録に始まり、記録し続ける
「基幹システムの全体を知らないから、全部使いこなせていないかもしれない」と言うエンドユーザがどの会社にもいます。
そういう完璧主義(?)が「マニュアル作ってよ」のセリフを言わせている面もあります。
メリハリのないのっぺりした辞書のようなマニュアルがあれば、使いこなせるのかな?といつも不思議に思います。
辞書は何か知りたいことがある際に引くものであって、起点になるものではないですからね。
システム設計など上流工程の勉強をし、高い視座からベンダーに質問するほうが早いと思うのですが、そういう地味な意見は聞く耳持たないんですよね。経営者も含め。
あとそうそう、マニュアルに限らず、最初からベンダーに期待するのが間違いというのもありますね。
結局いつもこの結論になりますがw