2026
2025
2024
2023
2022
2021
2020
2019
2018
2017
2016
2015
2014
2013
2004年04月の記事
全22件 (22件中 1-22件目)
1
-
新幹線に乗っているのは行楽客だけとは限りません
2004年4月15日の日記に書いたプロジェクトのその後。 （このプロジェクトについて最初から読みたい方は、 2004年4月4日の日記からどうぞ！！） このプロジェクトで開発しているシステムについて書き忘れていましたが、 ●お客さんは関西の金融機関 ●開発部署は東京某所 ●お客さんと開発部署を橋渡しするＳＥ （システムエンジニア）部署は大阪某所となっています。 これまでもＳＥはお客さんや開発部署と打合せをするため、何度となく新幹線に乗って移動を繰り返す。 そして、ゴールデンウィークもほとんどなし。 連休中も、きっと満員の新幹線の中、移動することでしょう！！ ゴールデンウィークだからといって、新幹線や飛行機に乗っているのは行楽客だけとは限りません。 働いているサラリーマンが乗っていることもお忘れなく。 自分が休んでいると、まわりの人もみんな休んでいる気になってしまいますが...。 ちなみに、このプロジェクト。 ちらっと聞こえてきた会話が、 『運用設計でもらった資料がめちゃくちゃで使い物に なりません。一からやり直さないと！！』 『いろいろと情報がさくそうしているようです！！』 『人は何人でもほしい！！』でした。 本番稼動まで、1ヶ月を切りました。 はたして、間に合うのでしょうか？ 今後をお楽しみに～♪ おわり
2004年04月30日
-
メールに添付されているファイルをダブルクリックしてみました
またまたこんな記事を見つけました。 仕事では、会社から提供されているノートPC（会社PC）を使用している。 今年3月末のある日のこと。 社内の人から送られてきたメールに添付されているファイル(*.pifファイル)をなにげなくダブルクリックしてしまった。 しかし、何事も起こらず。 このことは特に気にも留めず、仕事を終え会社PCを家に持ち帰る。 そして、夜23:00ごろ。 メールを見ようと会社PCの電源をON。 すると、なにやら様子がおかしい。 Windowの起動が完了しているのに、ハードディスクアクセスランプの点灯が止まらない。 ふと、昼間にダブルクリックしたファイルのことが頭をよぎる。 もしかしたら、ウィルス...？？？ 急いで、自宅のＰＣでウィルスに関する情報を調査。 すると、こんな記事を発見。 やはり、「*.pif」ファイルをダブルクリックしたことによって会社PCがウィルスに感染。 それから約1時間。 ウィルス退治に精を出す羽目になりました。 身に覚えのない人から送られてきたメールの添付ファイルをむやみにダブルクリックする。 そのあと、面倒なことになるので気をつけましょう。 おわり
2004年04月29日
-
トラブルプロジェクトにゴールデンウィークはありません
いよいよ明日からゴールデンウィークがスタート。 しかし、トラブルをかかえているプロジェクトにゴールデンウィークはありません。 おわり
2004年04月28日
-
ビジネスの世界における初級者・中級者・上級者を考えてみる
あるアニメの中での登場人物のセリフ。 『ストレートで速い走り屋は初心者。 コーナーを極めて中級。 上級者ともなれば、ストーレートでもコーナーでもない 第3のポイントで相手に差をつける。 第3のポイントを極めることが、俺の最大の テーマだ！！』 ビジネスの世界での初心者・中級者・上級者を考えてみた。 『部下に指示できても、上司やお客に頭が挙がら ないのは初心者。 上司を巻き込み、部下をコントロールできて中級。 上級者ともなれば、社内の人間だけでなく、お客さん からも信頼を勝ち取り、自分の思い通りに仕事を 進めることができる。』 お客さんから信頼を勝ち取る方法を見つけだす。 これが、これからの最大のテーマになりそうです。 おわり
2004年04月27日
-
社内の理屈は社外に通用しません
昨日の日記のつづき。 システムＡの開発を一時的に中止し、システムＡに関わっていたメンバをシステムＢの開発に投入した。 しかし、システムＢはこれまでに対応したことのない新機能が目白押しで開発は難航。 なかなか順調には進まない。 人の数を増やせばどうにかなるというものではなかった！！ その一方で、システムＡはどうなっていたか。 お客さんテストも終わりに近づいたので順調に終了...とはいかず、最後の最後になってシステムのバグ(不具合)が見つかる、見つかる。 しかし、システムＢの開発にメンバを投入してしまったため、システムＡのバグ修正をする人はいない。 親会社の担当者とお客さんＡとの間でどのようなやりとりがあったかは知らないが、システムＡのバグ修正はしばらく対応せず（できず）。 しかし、数日するとお客さんＡの不満は大爆発！！ 客先に課長、担当者、その他関係者が呼び出されバグ対応の遅れを謝罪することになった。 そして、システムＢの開発メンバから数人がシステムＡのバグ対応にまわされることに。 このような大変な状況の中、途中でyellofoxは別部署のプロジェクトに移動しました。 （これも、よくわからない上層部の判断ですが...！！） その後、風の便りに、この部署はトンデモナイ状況になっていると聞きました。しかし、最後の最後どうなったかまでを聞くことはありませんでした。 会社の都合はどうあれ、ないがしろにされるとお客さんは怒ります。 （不具合が発生しているのに修正してくれないとなれば なおさらです。） 社内では、 ●システムＡはお客さんのテストが終わりに近づいて いるので一時的に開発を止めても問題ないと判断した ●システムＢの本番稼動が厳しいからシステムＡの メンバを投入したといった理屈は通用するかもしれません。 しかし、お客さんからすれば、 ●他のお客さんの状況がどうあれ、自分の会社には 関係ない ●自分の会社が依頼したシステムを予定通り本番稼動 させることが契約条件だ！！と言われることでしょう 社内の理屈は、お客さん（社外）には通用しません。 そこを勘違いすると、痛い目に合うようですね！！ おわり
2004年04月25日
-
お客さんからの依頼が重なりました
これは、かつて所属していたある部署での話し。 この部署では、金融機関向けにあるシステムを開発していた。 そこでの仕事は次のような進め方をしていた。 (1)仕様まとめ 親会社の担当者がお客さんからの仕様をまとめる (2)開発 まとめた仕様をもとに、所属していた部署の メンバで、 設計 → プログラム開発 → テスト を行う。 (3)お客さんテスト お客さん側で、仕様どおりにシステムが開発されて いるか、問題がないかを確認をする。 （問題が発生すれば、開発している部署に修正依頼が きます。） (4)本番稼動 お客さんのテストで問題がなければ、本番稼動と なる。 で、あるとき、お客さんＡとお客さんＢからシステム開発の依頼が重なった時期があった。 ここで、 ●お客さんＡのシステム → システムＡ ●お客さんＢのシステム → システムＢとします。 システムＡの進み具合は、お客さんテストが終わりをむかえていた。 その一方で、システムＢは仕様がまとまり、開発がちょうど始まるところだった。 しかし、お客さんＢから提示された ●仕様 ●スケジュール ●開発メンバの数 ：などを検討しところ、お客さんＢの要望どおりに本番稼動させることが厳しい状態。 そこで、親会社の担当者の課長はこう判断したそうな。 ●システムＡは、お客さんのテストも終わりに近づいて いるので一時的に開発をストップする。 ●システムＡに関わっていたメンバをすべてシステムＢの 開発に投入する。 そう、開発メンバを増やす「人海戦術」で、システムＢの本番稼動を実現しようと考えたのだ！！ この判断は正しかったのか？ つづきは、また後日。 おわり
2004年04月24日
-
好きな会社をひいきしたくなるのが人情です
これは、現在担当しているある金融機関でのお話。 この金融期間でも、いくつものシステムが稼動しており、 ●システムＡは、メーカＸ社が開発 ●システムＢは、メーカＹ社が開発 ●システムＣは、メーカＺ社が開発 ：となっている。 その一方で、 ●Ｌさんは、メーカＸ社のファン ●Ｍさんは、メーカＹ社の支持者 ●Ｎさんは、メーカＺ社がお気に入り ：といったように、担当者によっても好みのメーカが違っている。 そこで、例えば打合せなどでこんな光景が見られる。■例１：ＬさんがＸ社の担当者と打合せをしたとき Ｌさんは、Ｘ社の対応などについては好意的な意見を言っていただけるが、Ｙ社の対応に対しては愚痴っぽいことをうだうだと言う。■例２：ＭさんがＸ社の担当者と打合せをしたとき Ｍさんは、Ｘ社に対してわざといやみなことやちくりとしたことを言ったりする。 好きな会社をひいき、応援したくなるのが人情です。 でも、好き嫌いで他社の仕事の邪魔をするようなことがあってはいけませんね！！ (幸い、この金融機関ではありませんが！！) おわり
2004年04月23日
-
インプットがなければアウトプットは出せません
最近、日記を書いていてふと思うこと。 「インプット(入力)がなければ、アウトプット(出力)が できない。」 これを、日記やBLOGにあてはめてみると、 「ネタ(入力)がなければ、日記(出力)は書けない。」 これを、上司から部下への指導にあてはめてみると、 「これまでの蓄積(入力)がなければ、指導(出力)は できない。」 さらに、仕事に当てはめてみると、 「仕事(入力)がなければ、利益(出力)は出せない。」 （負の利益がでる場合もありますが...） いかに「インプット」を増やすか。 それが、「アウトプット」につながります。 当たり前のことですが。 おわり
2004年04月21日
-
全体のことを考えずに細かいことばかり決めようとします
何度か日記に書いているように、ある金融機関でシステム移行(※)プロジェクトの担当をしている。(※)システム移行 某大手ベンダのシステムを別の大手ベンダのシステムへ乗り換えること。 で、プロジェクトの定例会議の中で金融機関側の担当者Ｎさんがふともらしていたこと。 (やや、身内の金融機関に対してぐちっぽく) 「全体としてどれだけの作業があるかも把握せずに 細かいことばかり決めようとして...。」 この言葉を聞いて、これまでの経験から、こんな法則があたまに浮かんできた。 「システム全体のことを考えず、細部ばかりに気を とられているプロジェクトは、全体としての関連性を 見失っているためトラブルにつながる可能性が高い。」 Ｎさんのあの発言は、経験にもとづくものなのか、直感にもとづくものなのかはわからない。 ただ、何事においても、全体を大きくとらえたうえで、細部を決めていく。そうすれば、全体としての関連性を見失う可能性が低くなります。 トラブル防止を含め、何かのお役に立てば...。 おわり
2004年04月18日
-
パスワードが付箋に書いて貼られています
今日も手短に。 （手抜きではありません！！） こんな記事を見つけました。 パスワードを紙や付箋に書いてPCに貼っておく。 最近はそうでもありませんが、数年前は社内でもよく見られた光景です。 パスワードは何のために存在するか？ 一度考えてみては。 おわり
2004年04月17日
-
知識と経験はバランスが重要
今日は手短に。 あるサイトで見つけた記事。 2004年3月8日に書いた日記。 仕事をしていく上で知識は必要。 それと同時に、経験も必要。 ただし、両者のバランスが重要。 どちらかに偏っていては、力は発揮できないようですね！！ おわり
2004年04月16日
-
あいまいな表現が意識のずれをうみます
2004年4月6日の日記に書いたプロジェクトのその後。 進捗会議の中で、主要機能の本番稼動スケジュールについて、ベンダより金融機関へ確認をしたそうな。 その確認内容とは、つぎのとおり。 ●5月下旬に一部店舗でのお試し本番稼動 ●6月上旬に全店舗での本番稼動 ところが、金融機関からは、 「5月下旬から全店舗での本番稼動という 約束でしたよね？」と言われ、これまたあっさり却下。 なぜ、金融機関とベンダとの間に本番稼働日について意識のずれが生じているのか？ さかのぼること3月の会議でのやりとりの要約。 （き：金融機関関係者、べ：ベンダ関係者） べ：「（一部店舗でのお試し本番稼動である） 『店舗展開』は、5月下旬でよろしいでしょうか？」 き：「（全店舗での本番稼動である）『店舗展開』の 時期については問題ありません。」 この場になって、金融機関より、 「3月の会議で、ベンダが『店舗展開』というあいまいな 表現を使い、自分たちの都合のよい解釈をしている！！」と言われたそうな。 「店舗展開」という表現の確認をしなかった、金融機関にも 問題はあると思うが...。もはや泥沼？？？ 結局、金融機関に押し切られるかたちで、 ●5月下旬に全店舗での本番稼動となったそうな。 あいまいな表現は、意識のずれを生みます。 そして、意識のずれがトラブルを生みます。 「全店舗での本番稼動は、○月□日とします！！」と明確な表現を使っていれば、こんなことにはならなかったのに...。 これまた、教訓となりますね。 はたして、5月下旬の全店舗本番稼動を死守できるか。 進展を待つのみ～♪ おわり
2004年04月15日
-
契約がむすばれることなく作業が進められています
2004年3月26日の日記に書いたように、ある金融期間でシステム移行を担当している。 この作業をするうえで、金融機関とベンダの間でシステムの内部情報など機密事項が他社から外部にもれたときに備えて、 「機密事項契約」をむすぶことになっている。 システム移行の作業開始は今年1月。(終了は12月末。) しかし、作業開始時期になっても契約はむすばれず。 それどころか、契約担当部署から契約書が提出されてこない始末。 契約がむすばれるのを待って作業をしていては間に合わなくなるため、金融機関には、 「契約が結ばれてから、この情報に関しては公開します。」と言いながら、少しずつ作業を進めていた。 しかし、2月になっても、まだ契約担当部署から契約書が提出されてこない。 契約をむすぶことができないため、情報公開ができず作業をに支障が出始めた。 そこで、契約担当部署へ 「早く契約をむすばないと、作業が前に進みません！！」と強く言うと、数日後やっと契約担当部署から、 「今回は例外措置ですが、契約をむすぶことを前提に システム情報の公開を含む作業を進めていただいて 結構です。」という連絡がきた。 で、今は4月。 契約のことなど意識することなく作業は進めているが、いまだに契約はむすばれていない。 (契約担当部署から契約書は提出されているようです。) いつになったら、むすばれることやら...。 契約もまともにむすばれないまま仕事を進めて、情報漏洩など何かあった場合本当にどうするつもりなのか？ （そういったことを防ぐための契約なのに...。） 金融機関から、 「契約の1つもまともにむすべない会社なんですか？」という目でみられているかもしれないのに...。 お粗末な話ですが、これが現場で起こっている現実です。 おわり
2004年04月13日
-
お客さんが満足しなければ単なる自己満足におわります
これは、2004年4月7日の日記に登場したＨ君が体験したこと。 Ｈ君は、お客さんと毎月行なわれている定例会議にむけてシステム機能を拡張するための説明用資料を作成していたそうな。 そして、定例会議の前日、Ｈ君の上司にあたるＯさんがその資料を見たそうな。 Ｏさんはその資料を見て、 お客さんに提出できるレベルのものではない！！（説明するべき内容が記述されていない）と判断し、お客さんに提示するのを延期したそうな。 翌日、定例会議が終わって、Ｈ君が戻ってきてからの会話。 （Ｈ：Ｈ君、Ｏ：上司Ｏさん、Ｙ：yellofox） Ｈ：「あの資料、自分ではかなり出来がよかったと 思ってたんですけどね。」 Ｙ：「自分が満足しても、お客さんが満足してなかったら、 それは自己満足だよ！！」 Ｏ：「そのとおりです！！」 たとえ作者が満足していても、成果物を使うお客さんが満足、納得しなければ、それは単なる作者の自己満足におわります。 いかに、お客さんを満足、納得させられるか！！ 一番むずかしいところですが...。 おわり
2004年04月12日
-
根拠のないサインは出すな
昨日の日記に引き続き、野村監督流の古田選手育成法について。 同じテレビ番組の中で、こんなことも言っていた。 ヤクルトの守備が終わって、ベンチに戻ってきた古田選手に、野村監督がこんな質問をしたそうな。 「なんで、あの場面で（投手に）このサイン （投げる球種）を出した？」 すると、古田選手のこたえは、 「なんとなくです。」 そのこたえに、野村監督は、 「根拠のないサインは出すな！！ １つ１つのサインは根拠を持って出せ！！」と叱ったそうな。 この話を聞いて、ふと思ったこと。 野球だけでなく、ふだんの仕事の中でも、 ●根拠のない会話 ●根拠のない作業 ●根拠のない指示 ： ： ： ●根拠のない○○をしていませんか？ 「根拠のない○○」が原因で、トラブルになったことはありませんか？ 一度、考えてみては！！ おわり
2004年04月10日
-
新人を育てるのに現場はかかせません
4月になって、オフィス街では、新人と思われる人たちをよく目にするようになった。 そこで、今日はプロ野球に関わるお話。 (なんの関係もないか、な？) あるテレビ番組で元ヤクルト(現シダックス)の野村克也監督が出演していた。 その番組の中で、今や日本一の捕手とまで言われるようになった、古田敦也選手に 新人時代どのようにして配球について教えたか？について話していた。 その方法とは。 ヤクルトが攻撃になると、ベンチ内で野村監督の前に古田選手を座らせる。 そして、古田選手に、 「目の前（グランド）での『生きた教材』（試合）に 対して、オレが（配球について）ブツブツ言うから、 それを聞いとけ！！」と言って、配球を教えたそうな。 (これがすべてではなく、あくまで教育方法の一部だと思うが...。) この話を聞いて、 ●現場には多くのことを学べる『生きた教材』がある ●新人を育成するのに、現場はかかせない ●すばらしい素材（新人）を活かすも殺すも指導者 （上司）次第といったことを改めて感じたのであった。 何かの参考になれば...。 おわり
2004年04月09日
-
となりはなにをする人ぞ
これは、あるとき同じ職場にいるＨ君とした会話。 会話中の表記は、次のとおりです。 (1)○○：お客さんの企業名 (2)□□：プロジェクト名 (3)Ｈ：Ｈ君 (4)Ｙ：yellowfox Ｈ：「前にトラブルの渦中に放り込まれた○○での □□プロジェクトは最悪でしたよ！！ 同じプロジェクトなのに、となりにいる人がなにを しているのかわかりませんでしたから！！」 Ｙ：「そんな進め方しているから、トラブルんとちがう？」 Ｈ：「なるほど！！」 Ｙ：「トラブルから、そんな進め方になる。 これは、違うか？」 同じプロジェクトなのに、お互い誰が何を担当しているのかわからない。 これまでに、似たようなプロジェクトを経験したことがありますが、おせじにも 「順調」ではありませんでした。 おわり
2004年04月07日
-
そのような提案ではおはなしになりません
昨日の日記のつづき。 ベンダから提案した打開策に対する金融機関の回答が告げられる。 「とんでもない提案ですね。おはなしになりません！！」 あっさり却下。 「業務に必要な主要機能は、6月を本番稼動とする」方針は変わらず。 それから、金融機関とベンダとの間で、何度か話合いが行なわれ、次のような開発方針になったそうな。 ●業務に必要な主要機能は、6月を本番稼動とする ●運用で回避できる機能は、9月を本番稼動とする ●本番稼動までの開発を優先し、ドキュメント修正などは 稼動後に実施 そして4月になってからは、6月本番稼動とする機能の選別作業をしているそうな。 まにあうかな～？ さらにこのプロジェクトは、こんな問題をかかえているそうな。 ●2段階開発に伴ない膨らんだ費用はどうするのか？ ●開発に伴なう人員補充をどうするのか？ 今後、このプロジェクトに注目していき、また進展があれば書いてみようかな～！！ この開発プロジェクトから ●要件定義の決定スピード ●開発する機能の割切りがプロジェクトの成否を決めるといったことを学ぶことができました。 おわり
2004年04月06日
-
本番稼動を延期させてください
昨日の日記のつづき。 あれから、どのような紆余曲折があったかは知らないが、ようやくシステムに盛り込む機能が決定したようであった。 （よく知らないけど、決定したのは今年の2月上旬ごろかな？） これで、要件定義が決定し、いよいよ開発へ！！ しかし、ことは簡単に進まない！！ 今年の3月初旬になって、またまた問題が発生。 システムの開発部署から、要件定義に記述されている機能を6月までにすべて開発し、本番稼動させるには日数が足りないとのこと。 本番稼動延期の申し入れが...。 この連絡を受け、ＳＥ部署と開発部署の人間が、緊急会議を開き打開策を検討。 そして、3月上旬、金融機関へＳＥ部署の課長・担当者、営業が報告を行なう。 ベンダから金融機関へ現状を説明し、打開策として提案した内容は、次のとおり。 ●業務に必要な主要機能は、9月を本番稼動とする ●顧客登録機能など一部機能のみを、6月本番稼動とする さてさて、この提案に対して金融機関からの回答は？ つづきは、またまた後日！！ おわり
2004年04月05日
-
あれもやりたいこれもやりたいと言われてまとまりません
これは、現在進行中のある金融機関向けシステム開発プロジェクトでの話。 (自分は、関わっていません！！) 去年(2003年)の秋のこと。 このプロジェクトを担当している、ＳＥのリーダがぼやいていた。 「金融機関の人が、あれもやりたい、これもやりたいと 言ってくるので、用件がまとめられません！！」 どうやら、 「システムにどのような機能を導入するか」 （システムで、どのようなことができるようにするか）を決める要件定義をまとまめることができていないようだ！！ 導入する機能を決めることができなければ、システム開発を行うことはできない。 ちなみに、本番稼動は今年(2004年)の6月。 このプロジェクトは今どうなっているか？ つづきは、また後日！！ おわり
2004年04月04日
-
画面に注意書きを追加するのにいくらかかるでしょうか
2003年8月21日の日記で書いた金融機関でのお話。 この金融機関で使用している、インターネットバンキングシステムに対して、今度は画面（HTMLファイル）3つに、 「これこれこんなことには、対応していません。」といった注意書きを追加することになった。 で、金融機関へベンダーのＳＥが提示した見積金額の内訳。 ●画面の修正と確認：５日×６万円 ＝ ３０万円 (６万円は、１日あたりのＳＥ１人の人件費) ●本番環境反映費用：５万円 ●合計：３５万円 ちなみに、この金額を聞いての率直な感想は、 「５日も必要か？」 「何を確認すんねん？」 ちなみに、営業の人からも、 「高くない？」 「ぼったくってない？」と聞かれた。 その質問に対して、 「ぼくも、そう思います。」と答えるしかありませんでした。 （まだ、金融機関から高いといったようなクレイムはきていないとのことです。） おわり
2004年04月03日
-
便利かどうかは利用者が決めること
これは、ＡＳＰでサービスを提供しているある金融共同化システムでのお話。 そのシステムはすでに本番稼動しており、順調に動いている。 そこへ、さらなる付加価値を提供するため、システムに付随する運用ツールをＡＳＰ提供元で開発したそうな。 で、そのツールを使ってもらうため、共同化システムに加盟している金融機関に対して、はたらきかけを行なっている。 その宣伝文句が、 「これこれこんなことができるので、便利になります。」 「こんなことができるので、金融機関にもメリットが あります。」 金融機関で新しいツールを導入する場合、 ●ツールの機能（利用してできること） ●導入費用をベンダから説明してもらい、金融機関が費用対効果を検討して、 ●便利か？ ●メリットがあるか？を決める。 一方的に、ベンダが 「便利ですよ！！」 「メリットがありますよ！！」といっても、簡単に導入してもらえるものではありません。 そこを勘違いして、金融期間(お客さん)に売りこもうとすると敬遠されるだけ。 「便利かどうかは利用者が決めること！！」 （提供元が決めるものではありません！！） ふと、こんなことを感じました。 おわり
2004年04月02日
全22件 (22件中 1-22件目)
1
-
-
- Amazonマケプレ
- #タイムセール ロッテ コアラのマー…
- (2026-04-30 12:18:55)
-
-
-
- iPad
- ipad表示の不具合、CoPilotに聞く。
- (2026-04-12 00:07:57)
-
-
-
- 大好き！デジカメ！
- 新しいコンパクトデジカメ買いました
- (2026-03-20 07:03:08)
-
