2026
2025
2024
2023
2022
2021
2020
2019
2018
2017
2016
2015
2014
2013
2004年05月の記事
全29件 (29件中 1-29件目)
1
-
もしもプロジェクト再生機構があったら
破綻しかかっているトラブルプロジェクトを見た帰りに、ふと電車の中で考えたこと。 破綻した企業を再建させるのは、「産業再生機構」。 もしも、システム開発などの破綻したプロジェクトを再建する 「プロジェクト再生機構」があったら...。 結構、需要があるのかも！！ おわり
2004年05月31日
-
下手なプログラムは処理能力を低下させます
ＰＣなどでプログラム開発をしたとき、 「設計が複雑で、解析しにくいプログラム」を組むと、 「途中の処理が多すぎて、結果が出るまで時間がかかり すぎる」といった現象が発生します。 最悪の場合、 「永久に処理結果が出ない」といった現象が発生することもあります。 こういったプログラムはふつう使い物にならないので、再度設計を含めプログラムを見直す必要があります。◆◇◆◇◆◇◆◇◆◇◆◇◆◇◆◇◆◇◆◇◆◇◆◇◆◇◆ ここで、「プログラム」の考え方を仕事の計画に当てはめて考えてみましょう。◆◇◆◇◆◇◆◇◆◇◆◇◆◇◆◇◆◇◆◇◆◇◆◇◆◇◆ 普段の仕事を進めるとき、 「書いてある内容・言っている内容が複雑で、 何をいつまでにどうしだいのかが見えない計画」を組むと、 「結果を出すまでに、やたら時間がかかる。」といった現象が発生します。 最悪の場合、 「ものすごい労力をかけているにも関わらず、結果が 何も出ない」といった現象が発生することもあります。 こういった計画はふつう使い物にならないので、再度仕事の内容を含め計画を見直す必要があります。◆◇◆◇◆◇◆◇◆◇◆◇◆◇◆◇◆◇◆◇◆◇◆◇◆◇◆ プログラム開発も、仕事の計画も、 「設計や内容をいかにシンプルに表現できるか！！」 これが、その後の結果を左右します。 おわり
2004年05月30日
-
永久に終わることのない無限ループ
ＰＣなどでプログラム開発をしたとき、プログラムの設計や記述を間違えると、永久に処理が終わらない 「無限ループ」におちいることがあります。 無限ループから脱出するには、いったん処理を強制的に中断させ、プログラムを見直し、修正する必要があります。 開発者本人が原因（プログラムのどこがおかしいのか）を見つけ出すことができない場合、第3者にだずねてみるのも有効な方法です。 ここで、「無限ループ」の考え方をシステム開発プロジェクトに当てはめて考えてみましょう。 システム開発プロジェクトで、プロジェクトの進め方や努力の方向性を間違えると、永久にプロジェクトが終わらない 「無限ループ」におちいることがあります。 無限ループから脱出するには、いったんプロジェクトを強制的に中断させ、プロジェクトの進め方・体制・問題点などを見直す必要があります。 これまでのプロジェクト関係者で原因（プロジェクトのどこがおかしいのか）を見つけ出すことができない場合、第3者にだずねてみるのも有効な方法です。 おわり
2004年05月29日
-
外からプロジェクトを勉強します
プロ野球を引退した選手、辞意を決意した監督、コーチがよく使う言葉。 「外から野球を勉強します。」 これは、解説者などの仕事を通じて、グランドとは違った視点で野球を見ることによって、野球の中にまた新たな発見を見出すことができるという意味です。 システム開発のプロジェクトでも同様に、自分が関わっていないプロジェクトを外側からみることによって、 プロジェクトの進め方の良い点・悪い点など、プロジェクトに関わっている時とは違った視点でものごとをみることができます。 さらに、 「これこれこういった状況で、自分ならどう判断するか？」といったケーススタディーに使うこともできます。 野球と同様に、 「外からプロジェクトを勉強する」ことによって得られるものはきっと大きいことでしょう！！ ただ、そんな余裕があるかは別の話ですが！！ おわり
2004年05月28日
-
藤原紀香はついていませんでした
金融機関のシステムセンタは、街の中心から離れたへんぴな所にあることが多い。 システム開発のプロジェクトなどで、トラぶってしまうと、関係者は、 朝早くから夜遅くまでプロジェクト対応に追われる ↓ へんぴな所にあるため、終電の時刻が早い ↓ 終電までに仕事を終わらすことはできない ↓ 家に帰ることはできなくなるといったことになる。 そこで、睡眠を確保する手段をましな順に挙げると、 ●近くのウィークリーマンションを借りる ●近くのホテルに泊まる ●システムセンタの仮眠室を借りる ●センタ内で雑魚寝 ： ：といったようになる。 ちなみに、あるトラブルプロジェクトでは、システムセンタの近所にあるレオパレス２１を借りているそうな。 当然、会社のお金です。 レオパレス２１を借りている人にきいたところ、 藤原紀香はついていなかったそうです。 おわり
2004年05月27日
-
対処療法では治りません
身近でおこっているトラブルプロジェクトをみていてふと思うこと。 システム開発などのプロジェクトがトラぶってくると、 ●プロジェクトに人を増員する ●開発しているシステムに詳しい人をつれてくる ●スケジュールを見直し本番稼動を延期する ： ：といった方法をとる傾向がみられる。 しかし、人を何人増やそうと、どんなにシステムに詳しい人をつれてこようと、どんなにスケジュールを先延ばししようと、 ●プロジェクトの問題点を解決せず先送りにする ●肝心な決定事項をあいまいにしておく ●形式的な打合せに終始する ●根本的・抜本的な見直しをしない ： ：といったようなことを繰り返しているようでは、決してトラブルは解決しない。 プロジェクトがトラぶってきたときほど、 ●プロジェクトの問題点を先送りすることなくその場で 決める、もしくは、期限を設けて回答させる ●肝心な決定事項もその場で決める、もしくは、期限を 設けて回答させる ●形式的ではなく、つっこんだ内容の打合せをする ●表面的でなく根本的・抜本的な見直しをする ： ：といったことが必要となってくる。 （すべて当たり前のことだけど！！） 一度トラぶったプロジェクトは、対処療法では治りません。 根本的・抜本的な治療をすることを考えましょう。 おわり
2004年05月26日
-
トラブルプロジェクトに出没するミスターコスト
トラぶっているプロジェクトには必ずといっていいほど、「お偉いさん」たちがぞろぞろとやってくる。 しかし、この「お偉いさん」たち。 対策会議では、抜本的、根本的なトラブル解決案を出すわけではなく、あーだこーだとただ思いついたことだけをしゃべり、最後は現場の人間に 「任せたぞ！！」と言い残して去っていく。 何の責任をとるわけでもない。 ひどい人になると、単に座っているだけ！！ いったい何しに来たんだと思う人が多い。 しかも、この「お偉いさん」たち。 なんの「利益」も生み出すことができないくせして、給料はかなり高い。 こういった人たちは単なる「コスト」にしかなりません。 「ミスターコスト」とよんであげましょう。 おわり
2004年05月25日
-
地獄の日々が1ヶ月間延びました
2004年5月9日の日記に書いたプロジェクトのその後。 （このプロジェクトについて最初から読みたい方は、 2004年4月4日の日記からどうぞ！！） このプロジェクトについてその後見たり、聞いたりしたこと。●その１：他のプロジェクトから人間を次々と収集している 先週、別件の用事で現場へ行ったら、やたら人がいました。 中には座っているだけで、「この人なにしてんねん？」という人もいました。 人が多すぎると、 ・意思疎通が思うようにとれない ・調整などで余計な手間ひまがかかる ・理解していない人の世話で時間をとられる ： ：といった理由で、かえってプロジェクトが進みにくくなる場合があります。 人海戦術が絶対確実な方法とは限りません。 人海戦術をとるなら、多数の1人1人が機能するように（仕事がまわるように）プロジェクトの体制・仕組みを整えることが必要です。●その２：24時間体制でシステムのテストを実施 電話でちらっと聞きました。 当初、2週間でシステムのテストを終わらせる計画と聞いていました。 しかし、大規模な新規開発では、到底不可能なことです。 システム開発の難しさを知っている人間なら、誰でもわかることです。●その３：ベンダ内部と金融機関提出用2種類の スケジュールが存在する このプロジェクトには関わっていない社内の人からちらっと聞きました。 ・ベンダ内部用のスケジュールには、現状が正確に 記述されているようです。 ・金融機関向けには、良い報告をしたいという意識が 働いているため体裁を整えたスケジュールを提出して いるようです この話を聞いて、ちらっと、Ｍ菱自動社のことが頭によぎりました。 仕事をする上で、現状を正確に把握し伝えることが、とても大切なことです。 虚偽報告のようなことをして、あとからとんでもないことにならなければよいのですが...。 ちなみに、当初の予定では、今週なかばが本番稼動でした。 しかし、6月中旬に本番稼動延期が決定。 関係者一同、口をそろえて、 「地獄の日々が1ヶ月間延びた！！」といっているそうです。 さらなる今後をお楽しみに～♪ おわり
2004年05月24日
-
使いにくいシステムはなぜうまれるのか－その２
昨日の日記のつづき。●指摘その３：金融機関関係者や第3者からシステムに 対する意見をまとめることができないのか 開発者が個人が勝手に決めたシステムの画面や遷移のレビュー(点検、チェック)は、定期的に行われます。 しかし、レビューをするのは、 ●現役の金融機関関係者 ●ベンダに勤務しているが金融機関に以前に勤務して いた人 ●ベンダに勤務している金融業務に詳しい人 ： ：ではなく、「ベンダのシステム開発責任者」です。 責任者といっても、金融業務に詳しいわけではありません。 そのため、レビューするときは、 ●機能がどうのこうの ●設計がどうのこうの ： ：といった観点でレビューすることが多く、画面デザインや遷移が、 ●利用者が使いやすいようにデザインされているか ●利用者が使いやすいように統一性がとれているか ： ：といった観点でレビューされることはほとんどありません。 ましてや、開発の途中で、金融機関関係者を含めた第3者に開発中のシステムを実際にさわってもらい、意見をもらうといった発想すら現場にはありません。 第3者の意見を取り入れることが、システムの改善につながるのに...。 開発現場で実際に行われていることを昨日、今日2日間の日記で簡単ですがまとめてみました。 なぜ、お客さんが使いにくいと感じるシステムが生まれてくるのか？ 少しでも、ご理解できれば幸いです。 最後に改めて、これは、あくまであるシステムの開発現場です。 すべての、開発現場にあてはまるわけではありませんのでご了承ください。 おわり
2004年05月23日
-
使いにくいシステムはなぜうまれるのか－その１
昨日の日記のつづき。 なぜ、お客さんから指摘を受けたシステムの開発現場の裏側を書いてみましょう。 これは、あくまであるシステムの開発現場です。 すべての、開発現場にあてはまるわけではありませんのでご了承ください。●指摘その１：文言(※１)の意味がわからない (※１)文言：画面上に書かれている操作等の説明文 このシステムは、各金融機関ごとに画面上の文言を自由に変更することはできません。そのため、文言を決めるときは、誰が読んだもわかる文章となるよう細心の注意を払い決定する必要があります。 ところが、開発現場では、 「文言の見直しはあとからするから今はとりあえず 決めておいて！！」といった指示を開発者は受けます。 そこで、開発者がとりあえず適当に文言を決めて開発を進めていきます。 しかし、開発作業でスケジュールが切羽詰まっていき、文言の見直しに手間ひまをかけることができなくなります。 そのため、あとからするといっていた文言の見直しは行われることなく、システムが本番稼動を迎えてしまいます。 開発者が適当に決めた文言が、そのまま本番稼動したシステムで使われる。 これが、現実です。●指摘その２：操作しづらい箇所が多々ある このシステムは、ブラウザ上で操作します。 ブラウザ上での画面デザインを考えるときは、説明文を読まなくても画面を見ただけで直感的に操作できるようにするのが良心的です。 しかし、こういったことを説明しても、開発者はこの考え方を受け入れようとせず（理解できないのかも？）、開発社個人が使いやすいと感じた自分好みの画面を勝手に作成します。 また画面遷移(※２)は、システムで統一されている方が利用者は使いやすいものです。 (※２)画面遷移：「画面Ａで○○ボタンを押すと画面Ｂへ移動する」 といった画面の移動順序。 しかし、こういった考え方などまったく念頭になく、これまた、開発者個人がわかりやすいと感じた画面遷移を勝手に決めて開発を進めていきます。 ここで、 「個人が勝手に決めた画面や遷移をレビュー(点検、 チェック)するために、第3者にみてもらうんとちがうの？ 金融機関の方からのメールでも指摘されてるやん！！」とお感じになった方もいらっしゃるでしょう。 この点ついては、また後日書いてみます。 おわり
2004年05月22日
-
お客さんの意見がメールで送られてきました
複数の金融機関向けにASPサービス(※)を提供しているあるシステムでのお話。(※)複数の金融機関で、1つのシステムを共同利用する サービスのことです。 このシステムに加盟しているある金融機関が、ベンダに対して意見を言ったそうです。その内容をまとめたメールが手元に送付されてきました。 そのメールを読んでいて気になったこと。 以下、メールの一部を要約。--------------------- ここから -----------------------●画面上の文言、操作性、画面遷移などシステムの開発者が作った仕様と感じるものが多い。文言の意味がわからなかったり、操作しづらい箇所が多々ある。●金融機関の要望を聞いて作っていると思うが、基本項目について金融機関の意見を聞くことができないのか。複数金融機関あり意見を聞けない、まとめきれないというのであれば、開発者ではない第3者に使ってもらい意見をまとめるなどしてほしい。--------------------- ここまで ----------------------- 実は、約9ヶ月間、このシステムの開発に関わっていました。 なぜ、このような指摘を金融機関の方から受けるのでしょうか。 後日、開発現場の裏側を書いてみます。 おわり
2004年05月21日
-
ゴキブリは1匹見かけると30匹はいるといわれます
９６年には欠陥認識 三菱ふそうが会見の記事。 ゴキブリは1匹見かけると30匹はいるといわれます。 三菱自動車の隠ぺい事件も1件表面化すると、30件は表に出てくるのでしょうか？ おわり
2004年05月20日
-
腐ったみかんはまわりのみかんも腐らせます
腐ったみかんは、まわりのみかんも腐らせます。 使いようがないので、腐ったみかんは捨てられます。 腐った上司は、まわりの部下を腐らせます。 使いようがないので、腐った上司は捨てようとします。 しかし、腐った上司ほど捨てられることをいやがります。 引き取り手（転職先）がないと感じているからでしょうか？ 腐ったみかんと、腐った上司。 まわりを腐らせる点では同じです。 腐ったみかんは使いようがありませんが、腐った上司は環境を変えれば「再生」できるかもしれないという点が違います。 おわり
2004年05月19日
-
人のマネをするだけでは自分のものになりません
他人から仕事のやり方をぬすむとき。 まず、相手がやっていることをそのままマネしてみる。 しかし、マネをしただけでは自分のものにはなりません。 相手が、 ●なぜそういった方法をとっているのか？ ●意味や目的は何なのか？を理解することができなければ、自分のものにはなりません。 人のマネをするだけで、仕事ができた気分になるかもしれません。 しかし、自分のものになっている（身についている）とは限りません。 おわり
2004年05月18日
-
理解することができなければ応用はできません
ふと思ったこと。 仕事のやり方を教えてもらうとき。 （教えられる立場にいるとき。） 教えてもらったやり方を覚えることは言うまでもなく必要。 しかし、覚えるだけでは不十分。 教えてもらったやり方にどのような意味や目的があるのかを理解することが必要。 理解することができなければ、教えてもらったことを応用はすることはできません。 今度は、仕事のやり方を教えるとき。 （教える立場になったとき。） 教える方法にどのような意味や目的があるのかを理解していることが必要。 理解していなければ、人に説明することはできません。 おわり
2004年05月17日
-
根性論で勝てるほどあまくはありません
こんな記事をみつけました。 女子バレーアテネ五輪出場の裏側には、データに裏付けられた 「相手の分析」があったようですね。 今の時代、なにごとにおいても、根性論だけで勝てるほど、あまくはありませんね。 おわり
2004年05月15日
-
部下よりもエキサイトフレンズ
またまたこんな記事を読んで、以前にあるシステム開発プロジェクトで一緒に仕事をしたある上司のことを思い出した。 この上司とは、サブシステム開発チームのリーダで席がとなりどうしだった。 で、ある日会社に来ると、その上司は何やら画面にむかって一生懸命。 ふと、画面を見てみると、エキサイトフレンズで出会った女の子にメールを書いている様子。 この上司、部下であるチームのメンバに対しては、 ●大事なメールを送ることを忘れる ●締切日を過ぎた作業依頼のメールを送る ： ：といった人なのに、朝一でエキサイトフレンズの女の子にメールを送るとはいったいどういうこと！？ 「やることの優先度がおかしいちゃうん！！」とこころの中でつっこんだことは言うまでもありません。 ちなみに、この上司は、Vectorからいろいろなフリーソフトをダウンロードしては、会社のPCにインストールし、再起動し...といったことを1日何度も繰り返す。 そのため、作業が進まず...。 こんな上司が、仕事ができるかどうかは普通に考えれば想像がつくと思います。 しかし、今年の春、課長に昇進しました。 不思議です。 おわり
2004年05月13日
-
かつての目標(ゴール)は将来の過程(プロセス)に変化する
目標(ゴール)を達成するまでに、必ず過程(プロセス)が存在する。 ここで、ある目標Ａを立てたとする。 目標Ａを達成するために、計画を立てて実行する。 そして目標Ａが達成される。 次に、目標Ａよりも大きい目標Ｂを立てたとする。 目標Ｂを達成するために、計画を立てて実行する。 そして目標Ｂが達成される。 さらに次に、目標Ｂよりも大きい目標Ｃを立てたとする。 ： ：といったことをつづけていく。 そして、ついに目標Ａよりはるかに大きい目標Ｆが達成されたとする。 そのときふとふりかえると、 ●目標Ａは目標Ｆを達成するための過程だったこと ●かつての目標が現在の過程にかわっていること ●目標Ａが達成されなければ、目標Ｆを達成することは できなかっこと ： ：に気づくかもしれない。 人間は、 ●「過去の目標」→「現在の過程」 ●「現在の目標」→「将来の過程」に変えながら成長していくものなのかもしれない。 もしも、これが正しければ、自分で目標を立てることの出来ない人に、成長はないのかも...。 おわり
2004年05月12日
-
何かを手にすれば、何かを失う
日曜日(5/9)の深夜に、またまたあるドキュメント番組をテレビで見ていた。 内容は、某ゲームメーカの現状を伝えたもの。 その番組の中で社員に対していろいろとインタビューをしていたが、メインテーマは、 「このゲーム会社に入社して、手にいれたもの、 失ったものはなんですか？」 社員によって、回答は様々。 しかし、 「何かを手にすれば、何かを失う。でも、失う ことを恐れていては、前に進むことはできません。」といった考え方は共通しているようでした。 おわり
2004年05月11日
-
会社を捨てるか、人生を捨てるか
三菱ふそうの事件を見ていて思ったこと。 会社や上司から、会社ぐるみ・組織ぐるみの隠ぺい工作や犯罪に関わる指示を出されたらどうするか？ ●指示にしたがう ●指示を拒否する ●改善策を提案する ●内部告発する ●会社を辞める ： ： 人によって選択肢はいろいろあると思う。 会社の雰囲気や、その人の立場、役職...etcによって変わってくるかもしれない。 しかし、不正はいずればれるもの。 会社を守ろうとして、人生を捨てることになった人はこれまでにもいろいろな報道の中で何人も見てきた。 というわけで、あなたならどちらを選びますか。 会社を守ろうとして、その後の人生を捨てるか？ 会社を捨てて（辞めて）、その後の人生を守るか？ 一度考えてみては！！ おわり
2004年05月10日
-
プロジェクト終焉の予感
2004年4月30日の日記に書いたプロジェクトのその後。 （このプロジェクトについて最初から読みたい方は、 2004年4月4日の日記からどうぞ！！） このプロジェクトを担当しているＩ課長から1本の電話がかかってきた。 話の内容を聞いていると、サーバに組み込まなければならないあるソフトウェア製品（以下、製品）が手配されていないことに気づいた様子。 そこで、Ｉ課長は他のシステムで使用している同じ製品を使いまわそうとして電話をかけてきたのだ！！ そんなん、許されるんか...？ しかも、その製品というのが、サーバと金融機関のホストを接続するうえで必要となる重要な製品。 なんで、今ごろになって気づくねん～！！ 本番稼動を約2週間後を控えてこんな状態。 いったい、これまでどんな仕事の進め方をしてきたのか？ かなり疑問！！ だから、トラぶっているんでしょうけどね！！ とりあえず、Ｉ課長とは、この製品に関連しそうな情報をメールで送ることで決着。 そして、この電話でのやりとりを終えて、ふと思ったこと。 『このプロジェクトは終焉を迎えた！！』 今後、どうなっていくかは...お楽しみに～♪ おわり
2004年05月09日
-
日本ではもうからないので海外に発注します
ゴールデンウィーク中にニュース番組でやっていた特集のお話。 「日本アニメ産業の攻防」 この特集の詳しい内容については、以下のサイトをみてください。 http://d.hatena.ne.jp/hottu/ 「2004-04-30 日本のアニメ産業の光と闇」 この特集を見ていて、 同じような現象がアニメ産業だけでなくＩＴ業界にも起きている！！とふと感じた。 詳しいことは、また日をあらためて書いてみたいものです。 『日本ではもうからないので海外に発注します！！』 これまでも...。 そして、これからも日本の産業が抱える大きな問題点なのかもしれませんね！！ おわり
2004年05月08日
-
何のために日記を書くのか
これは、仕事で知り合ったＭ君と昼休みに交わした会話。 （Ｍ：Ｍ君 Ｙ：yellofox） Ｍ君には、日記を書いていることは伝えていません！！ Ｍ：「ホームページでいろいろ自分のこと書いている人 おるんや！！ そんなに人に自分のこと見られたいんかな？」 Ｙ：「ストレスとか発散できるんとちがう？ 書くことによって、自分の中に溜めこまずに、 人に知ってもらうことできるから！！」 Ｍ：「そんなもんなんかな～！！」 何のために日記を書くのか？ 理由は人それぞれ！！ でも、楽しくなければつづけることはできません！！ おわり
2004年05月07日
-
さようならスリーダイヤ
タイヤ脱落事故、宇佐美・前三菱ふそう会長ら７人逮捕の記事。 過去に書いた三菱自動車の日記。 うそはいつまでもつきとおせるものではありませんね。 ◆◆◆さようなら、スリーダイヤ！！◆◆◆という日は間近...！？ おわり
2004年05月06日
-
コミュニケーションが生み出すコスト
ゴールデンウィーク中に、あるドキュメンタリ番組を見ていたときのこと。 その番組の中で、ある商店主が言ったこと。 『コミュニケーション不足によって誤解を生むほど ばかばかしいことはない。これは、すごいコスト なんです。』 『コミュニケーション』。 目には見えるものではないが、仕事をしていくうえで、不可欠なもの。 しかし、コミュニケーションにいくらのコストがかかっているかまでは考えたことはなかった。 ましてや、コミュニケーション不足がどれほどの損失を発生させるかは...。 『コミュニケーション』。 目には見えない要素にもコストが発生していることを気づかせてくれました。 おわり
2004年05月05日
-
作品のおもしろさを決める重要な要素
ゴールデンウィーク中に、あるアニメのメーキングシーンを見ていた。 その中で気になったフレーズ。 「リアルを追求し...」 「リアルにとことんこだわりつづけた製作陣が...」 アニメ、マンガ、ドラマ、映画、小説、etc...。 フィクションで作られる作品はいろいろあるが、おもしろいもの、人気があるものはリアルさを追求している。 （だから、中身が濃いのかも...。） リアルにどこまでこだわるか。 これが、作品のおもしろさを決める重要な要素であることは確かなことでしょう。 おわり
2004年05月04日
-
労働力を提供するのか、サービスを提供するのか
現在は、ある金融機関（お客さん）ですでに本番稼動しているシステムの運用支援を行っている。 （2つの金融機関を担当しています。） で、お客さんからもらっている金額は、1つの金融機関当たり月○○万円。 （金額は秘密！！） このことをふまえて、昨日の日記を書きながらふと思ったこと。 2通りののSEを考えてみる。■タイプ１：『労働力』を提供するSE ●お客さんに言われたことだけをします ●どこにでもいます ●SE自身に付加価値はありません■タイプ２：『サービス』を提供するSE ●お客さんに付加価値を提供します ●なかなかいません ●SE自身にも付加価値をつけようとします お客さんに対して、 『月○○万円分の労働力』を提供するのか？ それとも、『月○○万円分のサービス』を提供するのか？ どちらを提供するかによって、仕事に対する考え方や取り組み方（やり方）は変わってくるはず。 どちらになりたいかは、その人によりけりですが...。 おわり
2004年05月03日
-
お客さんは何に対してお金を払うのか
繁華街をうろうろしていて、ふと感じたこと。 ●何かものを買うとき ●食べるものを選ぶとき ●イベント用チケットを買うとき ●移動用の乗物を選ぶとき ： ： 人が値段を、 「高い」or「安い」or「妥当」と判断する基準のひとつは、これらのものを買うことによって得られる 「付加価値」や「サービス」によって決められているような気がする。 今は、「もの」そのものにだけでなく、「もの」を買うことによって得られる「付加価値」や「サービス」に対してお金を払う時代なのかも...。 こんなことを感じた、ゴールデンウィークの中日（なかび）であった。 おわり
2004年05月02日
-
100の仕事をこなすより重要な20の仕事をみつける
『パレートの法則』に関する記事をみつけました。 この記事を読んでふと感じたこと。■その１ プロジェクトなどで100の仕事があるとします。 1人で100の仕事すべてをやろうとせず、 『ポイントとなる20の仕事』を見つけ出し、自分が担当する。 そして、『残り80の仕事』は他人にやってもらう。 そうすれば、効率よく結果が出せるようですね。■その２ 100の仕事をすべてやらなくても、 『ポイントとなる20の仕事』をかたづけておけば、まわっていくのかもしれませんね！！ （意外と無駄な仕事は多いのかも！！）■その３ ●『残り80の仕事』を『ポイントとなる20の仕事』と 勘違いしている人 ●100の仕事をすべてやろうとする人 こんな人は、いつまでたっても仕事が終わらず、結果が出せないのかもしれませんね。 何かのお役に立てば...。 おわり
2004年05月01日
全29件 (29件中 1-29件目)
1
-
-
- iPhone
- 【物欲との闘い】新型iPhoneは要らな…
- (2026-04-25 09:06:28)
-
-
-
- 【楽天市場】☆☆楽天おかいどくお買い…
- 【P10倍】おうちで極上ヘッドスパ。u…
- (2026-05-12 19:42:04)
-
-
-
- 3DCG作品
- 新たな母艦を造る １８
- (2026-05-17 06:30:05)
-
