SAP Knowledge Wiki
チラシの裏/戒めの備忘録
の編集
Top
/
チラシの裏
/
戒めの備忘録
-- 雛形とするページ --
(no template pages)
下記は、過去～現在までのトラブル、その原因、心残りなソリューションを提供してしまったこと等、後悔している事項について己を戒めるため備忘録として残すことを目的として記述します。 ---- #contents ---- * プロジェクト [#rac2ada6] ** コンサルワーク [#wf523db5] *** マスタ設計 [#qe10b7c9] 取引先マスタの営業と営業外は、やはりコード体系を分けるべきだった。 SAPの話ではなく、他の貧弱なシステムを導入する段でのことだが、どうせ機能が貧弱だし数もそこまで多くないしと、色々甘く見すぎたし、エイヤでやってしまった。 具体的には、「そもそも貧弱なシステムの検索機能で、望まないデータが大量に引っかかる」や「銀行情報など特定の項目のメンテについて、要不要の目印として必要」など。 *** 要件定義 [#ree5e340] 相手が自分なりの答えを出せない場合、こちら側の提供する情報の質や量を疑うこと。 答えを出さない或いは出せないこと自体にイライラしても仕方ない。 確かに決められない病の人は存在するが、多くの場合は自分が悪い。 思い通りにいかないからイライラして、くだらない消耗をしては大義を成すに障る。 *** 業務設計 [#j0f3ea60] そもそも、レビューは三度もいらなかったのではないか？ 確かに繰り返し磨くことで良いものになることは間違いないが、3ヶ月という短いプロジェクトの中で、レビュアのスケジュール確保の根回しも不充分なまま理想論が先行しすぎた。 手戻りを過剰に嫌がったり仕様の凍結的なことに拘り過ぎたのでは。 *** 工数見積 [#edb4ab19] いくら期間ありきの背景があったといえ、工数の見積が甘すぎた。 業務フロー数なんて、いくら最新化されていないと言っても既存のものがあるし、同業他社の成果物と比較できたわけで、もっともっと確からしい概算予定は出せたはず。 開発工程ならできたはずなのに、なぜコンサルワークの見積が甘くなってしまうのか、もう少しよく考えろ。 ** マネジメント [#fce52bcd] *** 移行リハの進め方 [#tb1ed05f] トラブルシュートを予めスケジュールに組み込まなければならなかった。 今思えば「定量的に量れないものを計画に組み込むと、表面的な遅れが出る」とか、下らないことを考えていたのではないか？ そのわりには課題対応という枠をスケジュール上に設けており、軸足のない考え方をしていたのではないか？ それはさておいて、このやり方をするのであれば、「解決しないと先に進めないものは即時対応」「そうでないものは2W目に送る」などの前提が必要であった。 というより、そもそも進め方自体が間違っていたのかもしれない。 *** 人に任せる、ということ [#w36b61d5] 久しぶりに納品でしくじった。 納品後に要件漏れや不具合が発覚するという、およそ自分がこんな無様なことをしでかすなんて、考えてもいなかった。 多忙であったことに起因するわけではないし、それを言い訳にするつもりは全く無く、原因は単純に「人に任せすぎた」「成果のレビューが充分でなかった」に尽きる。 確かに一つ一つの要件定義に参加するのは難しいし、設計書に全て目を通すなんてやっていたら、複数プロジェクトの掛け持ちなんて立ち行くわけがない。 が、それを言い訳にして、或いはタテにして「じゃあ、どれくらいなら参加できるか」「品質担保のために最低限関わるべき時間はどれくらいか」を考えることをサボタージュしていたのではないだろうか？ 苦楽を共にしたこともあるユーザだったからまだ挽回の余地はあるものの、下の面倒を見なければならない立場として、コンサルとして、PMという名の現場監督として、また会社組織の代表として、品質に対する意識が甘いのではないか？ * 営業 [#ccc888dd] ** 価格交渉 [#z6d39847] *** 自分の値段 [#x3accf62] 金の話は即答しないこと。自分自身に冷静になる時間を与えろ。 ** 提案 [#w6a2a56a] 新規顧客およびボリュームの大きい提案などの重要なプレゼンは、飽きるほどリハーサルすること。（もちろん、日常的なプレゼンでは油断しててよい、なんてことではない） 裸の力で挑んでも上手に乗り切れるだなんて、自分の力を過信するな。それで何とかできてきたことなんて忘れろ。 カミカミになったり、目が泳いだり、進行を変に急いでしまったりと、負の形で必ず表れるなんて、とっくの昔に理解しているはずだ。 それに、それなりの準備をしてきたかどうかなんて、聞くほうの身になってみれば当然肌で感じられるわけで、つまりは「碌な準備をしないでこいつは来た。なめられている」と受け取られても仕方ないということ。 契約が取れたから良い、だなんて決して考えないこと。 リカバリできない、その機会を永久に失うこともある。 * その他「仕事」全般 [#ge9528d3] ** スケジュール管理 [#s3711108] とあるプロジェクトにて、入館証の写真撮影をすっぽかしてしまった。 相手が総務の方であること、いつでもいいと言ってくれていたこと、入館証の写真撮影という急を要しないテーマであったこと、また非常に物腰の柔らかい方であることが幸運にも幸いし、たまたま大して気にもせず笑って許していただけたが、これが営業活動やマネージャクラスとのMtgだったらどうなっていたか？ いつもスケジュールやタスクを管理しているのだから、常にちゃんとすること。取り返せない失敗もこの世にはある。 ~ ~ CENTER:【スポンサードリンク】 #htmlinsert(amazon_book_sap_system_implement) ~ ~ ---- #pcomment(reply)
タイムスタンプを変更しない
下記は、過去～現在までのトラブル、その原因、心残りなソリューションを提供してしまったこと等、後悔している事項について己を戒めるため備忘録として残すことを目的として記述します。 ---- #contents ---- * プロジェクト [#rac2ada6] ** コンサルワーク [#wf523db5] *** マスタ設計 [#qe10b7c9] 取引先マスタの営業と営業外は、やはりコード体系を分けるべきだった。 SAPの話ではなく、他の貧弱なシステムを導入する段でのことだが、どうせ機能が貧弱だし数もそこまで多くないしと、色々甘く見すぎたし、エイヤでやってしまった。 具体的には、「そもそも貧弱なシステムの検索機能で、望まないデータが大量に引っかかる」や「銀行情報など特定の項目のメンテについて、要不要の目印として必要」など。 *** 要件定義 [#ree5e340] 相手が自分なりの答えを出せない場合、こちら側の提供する情報の質や量を疑うこと。 答えを出さない或いは出せないこと自体にイライラしても仕方ない。 確かに決められない病の人は存在するが、多くの場合は自分が悪い。 思い通りにいかないからイライラして、くだらない消耗をしては大義を成すに障る。 *** 業務設計 [#j0f3ea60] そもそも、レビューは三度もいらなかったのではないか？ 確かに繰り返し磨くことで良いものになることは間違いないが、3ヶ月という短いプロジェクトの中で、レビュアのスケジュール確保の根回しも不充分なまま理想論が先行しすぎた。 手戻りを過剰に嫌がったり仕様の凍結的なことに拘り過ぎたのでは。 *** 工数見積 [#edb4ab19] いくら期間ありきの背景があったといえ、工数の見積が甘すぎた。 業務フロー数なんて、いくら最新化されていないと言っても既存のものがあるし、同業他社の成果物と比較できたわけで、もっともっと確からしい概算予定は出せたはず。 開発工程ならできたはずなのに、なぜコンサルワークの見積が甘くなってしまうのか、もう少しよく考えろ。 ** マネジメント [#fce52bcd] *** 移行リハの進め方 [#tb1ed05f] トラブルシュートを予めスケジュールに組み込まなければならなかった。 今思えば「定量的に量れないものを計画に組み込むと、表面的な遅れが出る」とか、下らないことを考えていたのではないか？ そのわりには課題対応という枠をスケジュール上に設けており、軸足のない考え方をしていたのではないか？ それはさておいて、このやり方をするのであれば、「解決しないと先に進めないものは即時対応」「そうでないものは2W目に送る」などの前提が必要であった。 というより、そもそも進め方自体が間違っていたのかもしれない。 *** 人に任せる、ということ [#w36b61d5] 久しぶりに納品でしくじった。 納品後に要件漏れや不具合が発覚するという、およそ自分がこんな無様なことをしでかすなんて、考えてもいなかった。 多忙であったことに起因するわけではないし、それを言い訳にするつもりは全く無く、原因は単純に「人に任せすぎた」「成果のレビューが充分でなかった」に尽きる。 確かに一つ一つの要件定義に参加するのは難しいし、設計書に全て目を通すなんてやっていたら、複数プロジェクトの掛け持ちなんて立ち行くわけがない。 が、それを言い訳にして、或いはタテにして「じゃあ、どれくらいなら参加できるか」「品質担保のために最低限関わるべき時間はどれくらいか」を考えることをサボタージュしていたのではないだろうか？ 苦楽を共にしたこともあるユーザだったからまだ挽回の余地はあるものの、下の面倒を見なければならない立場として、コンサルとして、PMという名の現場監督として、また会社組織の代表として、品質に対する意識が甘いのではないか？ * 営業 [#ccc888dd] ** 価格交渉 [#z6d39847] *** 自分の値段 [#x3accf62] 金の話は即答しないこと。自分自身に冷静になる時間を与えろ。 ** 提案 [#w6a2a56a] 新規顧客およびボリュームの大きい提案などの重要なプレゼンは、飽きるほどリハーサルすること。（もちろん、日常的なプレゼンでは油断しててよい、なんてことではない） 裸の力で挑んでも上手に乗り切れるだなんて、自分の力を過信するな。それで何とかできてきたことなんて忘れろ。 カミカミになったり、目が泳いだり、進行を変に急いでしまったりと、負の形で必ず表れるなんて、とっくの昔に理解しているはずだ。 それに、それなりの準備をしてきたかどうかなんて、聞くほうの身になってみれば当然肌で感じられるわけで、つまりは「碌な準備をしないでこいつは来た。なめられている」と受け取られても仕方ないということ。 契約が取れたから良い、だなんて決して考えないこと。 リカバリできない、その機会を永久に失うこともある。 * その他「仕事」全般 [#ge9528d3] ** スケジュール管理 [#s3711108] とあるプロジェクトにて、入館証の写真撮影をすっぽかしてしまった。 相手が総務の方であること、いつでもいいと言ってくれていたこと、入館証の写真撮影という急を要しないテーマであったこと、また非常に物腰の柔らかい方であることが幸運にも幸いし、たまたま大して気にもせず笑って許していただけたが、これが営業活動やマネージャクラスとのMtgだったらどうなっていたか？ いつもスケジュールやタスクを管理しているのだから、常にちゃんとすること。取り返せない失敗もこの世にはある。 ~ ~ CENTER:【スポンサードリンク】 #htmlinsert(amazon_book_sap_system_implement) ~ ~ ---- #pcomment(reply)
テキスト整形のルールを表示する
