おはようございます
４月２日(_ _。)
本日は、朝1番から気が滅入る事ばかり積み重なり、久々にネガティブな１日と
なりましたデス。まあ、いろいろと書きたいこともありますが、とりあえず我慢
しておきます。
話はかわりますが、今日久しぶりにある先輩と話をしました。会社の先輩です。
ボクより少し年上の人ですので４０代半ばですかね。その先輩の顔を見たのは
３年ぶりくらいでしょうか？昔は、ボクにとっては、一番のバカ話の相手であった
先輩でしたので、およそ３年ぶりの今日も、そんなノリで話をはじめたボク
だったのですが、随分、昔と様子が違っていました。その先輩はバカ話には
全くのってくれず、ひたすら「都留ちゃん、オレもう仕事に疲れたよ。」って
繰り返すばかりです。そして、「カウンセリングとか行ってみようかな・・・」
って。
その先輩が、ここ数年間とても激務であった事は噂に聞いていました。
とにかく厳しいプロジェクトに従事していて福岡にもほとんど帰れない状況
であったようです。しかし、たった３年間で、それだけ先輩の様子を変えて
しまった仕事って？ 先輩の上司は、その変わり様に気がついているので
しょうか？気がついていてほっとけるものなのでしょうか？そこまでして
やらなければいけない仕事って？ 最近、うちの会社も、心の病とかで
休職している人も少なくはないですね。正直、今までは、「自分の気持ちの
持ち方が弱いだけでは？」って思っているところがありました。
ですが、その先輩は、そんな弱い人ではありません。ボクも今日は最後まで
「ＸＸさんだけはそんな事ないでしょー」って言い続けましたが、「それがね・」
って言葉だけが返ってきます。結構、ショックです。考えてしまいます。
明日は我が身なのかもしれませんね。
やっぱ、今日は気分がネガティブです。まあ、たまにはそんな日も
あるという事で＾＾；
今日は花見でしたね。ボクは花見に行くと、かなりの確率で風邪で寝込むので、
欠席しましたが、毎年毎年この寒い中、よくやるものです。
無理やり付き合わされたみなさま！お疲れ様でございます。
ボクにとって「花見」は、会社の悪しき習慣の最たるものという位置づけです。
まあ好きな人はやれば良いのですが、嫌な人まで巻き込むのは、いい加減に
やめるべきですね。断れない人もいるのにね。
明日は出張です。大切な打ち合わせが２つほどあります。
モチベーションあげなければ。
今回のプロジェクトの難しさ（#2）
先日の続きです。前回は、みなさんも十分に感じている「お客様体制」に
ついて書きました。今日は、私的に、２つめの大きなテーマと感じている
「システム利用部門の範囲」について書いてみます。システム利用予定
部門が広範囲に拡大している事により発生している問題です。
「システム利用部門の範囲」
問題点：システム利用部門の予定がお客様セクションの広範囲にわたる。
システム利用部門が広範囲になっている事で何が問題か？具体的には
以下を認識しています。
1.今回のシステム化対象業務の統一ガイドライン・運用基準がない
各部門は、現状当該業務に対して独自の運用・管理を行っています。
企画策定のタイミングも違えば、投入商品の選定基準や店舗との分担
レベルも違います。また、衣料品については、そもそも商品管理手法から
違っていますし、特売の位置づけも違うように感じています。
ですが、そのような実態を完全に把握している人間が、社内外に１人も
いないのが現状です。このような状況下において、お客様企画立案部門は
全部門に対してほぼ同等のサービスレベルを実現したいと考えています。
私自身は、まずそれは不可能な事だと考えています。そこには、予算が
あり、スケジュールがあるからです。現状においての、運用の統一化の
検討をお願いしておりますが、商品管理の性質や、商品そのものの特性が
違う以上、完全な統一化は望めないと考えます。その結果として、次々と
仕様変更、追加が発生している現状があるように思います。
大切なことは、無理に業務運用をあわせる事を強いる事ではなく、
あわせる事ができる所がどこで、オリジナルな部分を残さざるをえない所が
どこかをしっかり整理する事だと考えます。その上で、統一化できる部分を
中心にシステム化を進めていく事が有効と考えています。そこから
はずれている業務が何かをあらかじめ把握しておきさえすれば
対処はできるはずです。我々が、お客様から提出される仕様変更依頼を
検証する時には、そういう視点が必要と考えます。
また、設計において大切な事は、各部門に対する提供機能が
同一レベルにある事を意識する事です。
例えば、「衣料品向けの画面には、昨年実績を参照する機能があるが
食品向けの画面にはない」こんな状況を作らない事です。お客様から
変更要求が発生した場合、こんな視点でもその変更を承認すべきか
どうかを確認する必要があると思っています。
2.本格的なシステム化やシステム利用を行った経験がないセクションがある
システム化企画、システム利用を行った経験がないセクションは、システム化を
行う上で、どんな情報が必要か？ どこまで我々に伝えておけば良いのか？
などの判断が出来ないことが普通です。「我々に伝えきれている部分だけが、
システムになる。」という事も、わかっていないかもしれません。
もしもそのような状況を誰も省みず、要件定義が完了したとしたら、
完成したシステムは全く使えないものになってしまう可能性すらあります。
この状況を回避する為には、エンドユーザとシステム化要件について
直接話をする場合、また、情報部門にエンドユーザへのヒアリングをお願いする
場合、必要以上に具体的な話をしなければいけません。
「何が実現できるのか」「どのような運用をしなければいけないのか」は
もちろんですが、大切なことは上手くいかない事を具体的に伝える事です。
余計な心配と思われるくらいに心配して丁度良いかもしれません。
もう１つ気にとめておかなければいけない事があります。それは、エンドユーザ
は、自分が今話をしている業務要件の追加が、システム化に対してどれだけ
インパクトがある内容であるかを判断する事ができないという事です。
実現が難しい話であるとか、コストがかかる話であるとか、そんな事は、
全く判断基準にはないはずです。つまりコストパフォーマンを基準とした判断
にはなっていない事が多いという事です。ですが、それをそのまま受け止めて
実現案を検討し、見積りを作るのも我々の仕事としては間違っています。
我々は、コストについての問題をストレートに伝える事なく、エンドユーザが
機能を選別する手伝いをしなければなりません。その機能をシステム化の
対象外とした場合、運用にどれだけの負荷が残るのか？整理して考えて
もらうように仕向ける事が大切です。ゆっくりと冷静に考えてもらえば、
実は全くシステム化の必要性はなかったなどという話もあるはずです。
「必要ですか？」と聞けば、「必要！」との答えが帰ってくるはずです。
なかったらどうなるか？を聞く事が重要です。そして、それがなかった時の
運用をしっかりイメージしてもらって下さい。
お客様との要件確認、定義は現状主には私の責任範囲ですので、
今回の話は、どちらかと言えば、自分向けの話という気もしますが、
この難しさは最近大いに感じている部分でもあり、テーマとしてあげてみました。
私としては、ＤＷＨや発注システムを開発してきた時と同様に、
まずは、部門を絞ってシステム化を行い、それをブラッシュアップした後に
各部門への適合を意識した改造を行い横展開する事が最善策と考えています。
今までのシステムが成功してきたのは、この手法による所が大きかったと
感じております。ところが、お客様は、残念ながら、過去の成功の重要要素
の１つが、この手法にあった事を認識されていない様子です。私は再三
この件についてお話をしてきたつもりですが、現状を見るとこのように
認識せざるを得ません。そういった意味でも、この問題をしっかり意識して
処置しておかなければ、カットオバー後に、今までにはなかった問題が
発生する可能性あり！と懸念する次第です。
桜！満開ですね
おはようございます。
昨日は、飲みすぎ
ましたデス
どうにか終電で帰宅しましたが、
そのまま爆睡してしまい、ブログもお休みしてしまいましたデス
只今二日酔いモード全開＾＾； しばらく復活できそうにない予感でございます。
ＰＭＩから、受験承認のメールが届きました。申請に不備がなかったようで
一安心です。まだ、監査対象になる可能性は残っておりますが、
これでとりあえず試験を受ける事ができます。支払いも済ませました。
４０５＄です。監査に選ばれなければ、４月中旬で受験するつもりです。
あと２、３週間です。春の陽気に誘われて、遊びに出かけたい週末ですが、
頑張って受験勉強しなければ。
坂井さんから、春メールが届きました。
九段下の桜
だそうです。東京も、桜満開の様子ですね。
携帯での撮影と思いますが、綺麗にとれてますな。九段下と言えば
「たまねぎ
」思い出しますね。爆風スランプ聞きたくなります。
坂井さんも、相変わらず頑張っているようです。何かと大変そうですが
ビッグイベントも控えておりますし、「ふぁいとー」です。
そして、こちらは会社の前の桜です。満開！になっていました。
３月も今日で終わりですね。
今年は、信じられないくらいの速さで月日が過ぎていきます。
今回のプロジェクトの難しさ（#1）
今回のプロジェクトの難しさをまとめてみたいと思います。
何かと大変な状況が続いていますが、サブリーダーのみなさんには、
今後のプロジェクト遂行において常に気に留めておいて頂きたい話です。
テーマ的にも長くなりそうですし、私的に、最近少し元気がないせいもあり、
ボチボチと書いていくつもりです。気長に読んでください。
第一回目のテーマですが、「お客様の体制」です。
問題点：お客様の人事により、お客様側リーダーがかわった事
そのお客様側リーダーは、今まで大規模プロジェクトに本格的
携わった経験がない事
今回のプロジェクトにおいては、残念ながら、我々がこのお客様との間に
築いてきた多くの事を、捨ててかかる必要がありそうです。ある意味、初めて
お付き合いするユーザと同様に考えたほうが良いかもしれません。今回の
お客様リーダーであるＡ課長は、前任のリーダーであり現プロジェクト責任者
であるＢ部長より何も引き継がれていません。また現時点においてシステム
構築プロジェクトにおいて、自分のすべき仕事が何かを全く理解されていない
可能性があります。責任者であるＢ部長には、Ａ課長のフォローをお願いして
おりますが、何らフォローして頂いている様子がありません。引き続き、
お願いを続ける必要は当然ありますが、そこを期待していても、おそらくこの
仕事は上手くは進みません。我々の仕事のやり方を変えていくしかないの
かもしれません。また、Ａ課長も、最初からすべて上手くできるはずは
ありません。今回のプロジェクト経験を通して、多くの事を習得して頂くことも、
我々のミッションかも知れません。では、このような状況下において我々が
意識して行動しなければいけない事は何か？以下、私の考えです。
①.お客様と我々のスタンスを明確にしておく事
役割分担の意識を明確に持ってもらうようにしむける事です。我々が対応できる
業務の範疇、そしてお客様がやるべき仕事が何か？を曖昧にしない事です。
例え、我々が行った方が圧倒的に効率的との判断があったとしても、
その仕事が、我々の業務範疇かどうかを、少なくともＡ課長とはしっかり
議論すべきです。役割分担は、当然コストの上にあります。それを本質的に
理解していただく言動をとるべきと考えます。
②.約束を守る文化を築く事
プロジェクトを円滑に遂行する為には前提条件が崩されない事が不可欠です。
お客様が我々に約束した納期は、我々にとっては最重要な前提条件の１つ
です。前提条件が崩れた場合、プロジェクトにはほぼ間違いなく是正処置が
必要となってきます。度重なる補正は、どんなに注意深く計画をウォッチして
いたとしても、必ずほころびが発生すると考えます。また、是正処置には
計画立案以上のパワーが必要です。お客さんの約束を軽く考えないで下さい。
簡単に破って良い約束は、仕事の上で１つもないはずです。それを
Ａ課長に理解して頂くように行動して下さい。まず大切な事は、我々は
決して約束を破らない覚悟が必要という事です。お客様との約束は、確実に
やり遂げて下さい。我々が約束をたがえる事があれば、お客様の緊張感も
一気になくなってしまいます。またお客様に約束を守って頂く事を、強く求める
事も出来なくなります。そして、次に大切な事！我々が、その約束をどれだけ
大切に考えているかを伝え続けて下さい。切実さをＡ課長に理解してもらって
下さい。また、必要であれば、その約束が守られなかった場合のリスクが、
我々だけのものではない事を伝えて下さい。約束が守られなかった場合は
痛み分けになるような状況を作り出すことも時には必要と考えます。
③.良いシステムとは何かを深く考えるリーダーに
資金をはじめとするリソースは有限です。このリソースをどれだけ上手に
配分できたかが、良いシステムとダメダメシステムの明暗を分ける１つの
要素と考えます。であれば、すべてのセクションに対して同等のサービス
レベルを実現する事が、必ずしも良いシステムであるとは言えません。
すべての業務を網羅する事も然りです。リソースに限りがある以上、
強弱が大切です。その部分について最終的なジャッジができるのは
お客様しかありません。考えてもらうように仕向けて下さい。最適な配分が
出来ているかどうかを常に考えて頂けるように働きかけて下さい。
我々にもＹｅｓと言えない事はあります。お客様のシステムが稼動し始めて
から気がつくのでは遅いのです。Noは今言うべき言葉です。
④.B部長を巻き込め！
どんな些細な事も、必ずB部長に見えるように心がけて下さい。
我々の最終的な交渉相手はB部長です。費用面も含めてB部長です。
どんな状況も、交渉の場において、B部長に「知らない」と言わせては
いけません。B部長がA課長のフォローをして頂けていないのも
すべて現状を認識されていないからかもしれません。上手くやっている
と認識されているかもしれません。結果論だけをB部長に伝えるのは
フェアーではありません。お客様の問題は、我々が立ち入ることなく
お客様の中の気づきにおいて補正される事が理想です。その為には
リアルタイムでB部長にすべてを認識してもらうアクションが必要です。
今、どんな約束事があり、今、どんな仕事をお互いやっているか、
必ずB部長にメール又は電話で伝えて下さい。
長くなりましたが、以上、みんなに意識を持ってもらいたい問題点の１つです。
次回は、「システム利用部門の範囲」について書きます。