2008年8月アーカイブ

企業のシステム部の方とお話すると、自社のシステム企画やベンダーマネジメントができる

ような人材がなかなか育たないという声が良く聞かれます。

 

それもそのはずで、就職した会社の本業に魅力を感じて入った方がシステムを

構築するのに高いモチベーションをもって取り組めるのか、あるいは優秀な人材が

集まるのかという問題があります。

 

さらには、情報システム部に長年いたとしてもプロジェクトを豊富に経験できるとは

限りません。

 

先日、サマンサタバサジャパンリミテッドの寺田社長のお話を伺う機会がありました。

寺田社長はアクセサリーを扱う小さい店舗のブランドを創ったのは、新人ても優秀な人材に

店舗マネジメントの経験をする機会を創造する事がひとつの目的だとおっしゃっていました。

社員を愛する寺田社長にとても感銘を受けました。

 

人材を育成するにはチャレンジをする機会を創るという事につきると思います。

 

 

Googleのストリートビューを使ってみた

まず、自分や自分の家族の住所で検索

車のナンバーまでうつっていて、ちょっと気持ち悪い思いをしました。

 

会食先の住所を入れると

1本違った通りの写真が出て現地で若干違った方向へ行ってしまいました。

複雑でマイナーな通りには弱そうです。

 

別に、Googleを批判しようというわけではありません。

実はGoogleと同じようなサービスをしようと思っている企業は他にもあったはずです。

例えば日本のカーナビの制作している会社はGoogleよりもはるかに多くの日本の

道路情報を写真も含め持っています。

ただプライバシーの問題とビジネスモデルの問題があって実現に二の足を踏んでいるのでは

ないでしょうか?

YouTubeなどは著作権の問題がありながら、あれだけ拡大をしています。

Googleという会社の基本的なスタンスは

「問題はあっても、それより大きな社会メリットがあればいいじゃん」

と言っているようでもあります。

 

 

先日、古いお付き合いのお客様が東京に来られることになり、声をかけていただきました。

当時は喧々諤々というか、いろいろ大変なことや時を共有させていただき、

今振り返ると多くを学んだプロジェクトでした。

お客様にも部下にも恵まれ、今の自分があるのだな、と改めて感謝の気持ちを持ちました。

 

そして今日、別のお客様ですが、今月で終了するプロジェクトのお客様に

「ありがとうございました」と感謝の言葉をいただきました。

コンサルタントって結局、この言葉を聞くためにやっているんだなぁ、としみじみ思います。

 

これからも感謝の気持ちを忘れず、「ありがとう」のためにがんばりたいと思います。

 

「ユーザ要求とはシステムに対するエンドユーザの意見や希望のこと」

で、人によってはユーザ要求は受け入れないというのをシステム構築方針にしてしまう

ケースもあります。

ですが、例えば画面の操作性で著しく業務効率が損なわれるような場合に、

「これはユーザ要求ですから」って事を言っても現場は納得しませんし、

良いシステムとは言えません。

まぁ、そのあたりはバランス感覚が重要になるのですけど。

 

そもそも、ユーザ要求なのか、業務要求なのかという区別をつけて要件定義していないと

いうケースもけっこうあったりしますからね。

 

ユーザ要求で気をつけるのは、「ユーザ好み」にしないことです。

つまり、ユーザが10人いれば10人とも様々な意見を言うわけですから、

ユーザのコンセンサスを得た要求が議論の場に出てくるようにプロセスを整備する必要があります

要求分析とか要件定義とか言葉の使い方は会社、あるいは人のバックグラウンドで

違ったりしますが、業務要求、ユーザ要求などの要求を整理しシステムの要件を

決定するというシステムプロジェクトにおけるプロセスとなります。

システムの個々の機能の振舞いまでが要件となりますが、要求というのは、もう少しざっくり

した内容でシステム化の対象となるかどうか未定といったものも含まれると思います。

 

要件定義、あるいは要求分析はいずれにしても、大きな方針の決定から決めていくのが

ポイントです。例えば、システムのサービス時間、業務範囲、ユーザの想定など。

これらの大きな方針はステークホルダーで合意を得た上で次のステップに進めるべきです。

 

 

WBSの説明をするのは今更な感じがあるので、しませんが、、、

 

WBSをせっかく作っても個々のワークパッケージの内容が不明瞭であると混乱を招きます。

WBSを作成したら主要なプロジェクト当事者と内容の共有を行い、

合意をするというタスクを入れましょう。

 

WBSに利用する言葉は誰でも同じようなイメージを抱きやすい言葉を使うように心がけるのも

ポイントです。

 

 

 

 

ITプロジェクトでは常に業務改革などの○○改革というのがつきものです

改革を行うにあたって、「あるべき論」だけで通すと業務の現場では受け入れずらい

業務になったりしますが、これを「受け入れられるようにする」のではない「させるのだ」

という強引な手法をとるリーダーもいます。

ある意味正論ですが、結果的に業務負荷が増えるだけの印象を与えてしまっては

意味がありません。

企業内での力加減もありますが、業務側の負荷なども考慮にいれつつ、

全体のコスト、スケジュール、業務担当との調整をバランス感覚を

大事に推進するのもリーダーの重要な役割だと思います。

 

 

システム開発・変更を行う際に、既存のシステムベンダーに見積りを依頼するとします。

この際、要件を曖昧にしたまま見積りを出して出てくる金額が思ったより大きくて驚く。

ベンダーからすると曖昧な要件では様々な「想定」をして見積りを行います。

一度出した見積りはなかなか金額を上げられないという立場のベンダーからすると

当然の行動のようにも思えます。

 

一方、システムの見積もり依頼を行った方は、こんなにお金がかかるのかと驚き、

その金額で実行判断をしてしまいます。

 

要件を整理し、システム化の範囲、規模感の整理を行う事で開発コストが10分の1に

なる事もあり得ます。

また、将来的な拡張性や変更時のコストなどもトータルに考えてくれるコンサルタントを

活用するのは非常に費用対効果が高いことだと思います。

(良識あるコンサルタントは自分の費用に見合う利益を生み出せない仕事は

極力受けないのではないでしょうか。)

 

某大手企業では情報システム子会社にシステムの修正を依頼したところ、

かなり大きな見積りが出てきました。

私の感覚では桁がひとつ多いようにも思いますが、確かに見積り依頼をしている内容が

ラフすぎるという問題がありました。

「この子会社は言われたことを言われたとおりにします」というスタンスで、

「こうやったら安くできます」という提案はまったくしてくれません。

システムを知らない担当者はいわゆる「落とし所」がわからず、金額に悩みます。

しかも要件も決まらずに一括で発注するのですから、何とももったいな話しです。

(まぁ、どちらにしろ同じグループ内の取引ではありますが)

 

世の中にはこういう状況が山ほどあるように思います。

 

業務プロセスが明確でなく、人によって様々な運用を行っているような場合や

属人的な業務に対して、システム導入を行う場合は業務設計をきっちりやらないと、

システムの使い方も人それぞれで更新されないために利用されないシステムになってしまいます。

(システムを使わなくても業務が出来る、というケースは非常にこのリスクが高い)

 

また、(人によって情報の管理内容、方法が様々である場合)移行データを作成するのが

非常に困難なケースがあるので気をつけた方がいいです。

 

 

 

このアーカイブについて

このページには、2008年8月に書かれたブログ記事が新しい順に公開されています。

前のアーカイブは2008年7月です。

次のアーカイブは2008年9月です。

最近のコンテンツはインデックスページで見られます。過去に書かれたものはアーカイブのページで見られます。

メルマガ登録・解除
 

ウェブページ

Powered by Movable Type 4.1