yellowfoxの巣

[これが現実です] カテゴリの記事

全277件 (277件中 101-150件目)

< 1 2 3 4 5 6 >

• いうか、いわないか！！

  　最近、ふと感じたこと。　ITシステム開発において。　「このプロジェクト、どこか仕事の進め方がおかしいよな～！！」　このようなことを感じたとき。　プロジェクトに関わっている人の中には。　一部の人を除いて。　同じようなことを感じている人。　いるものなのかもしれませんが。　大きな違いは。　それを、あえて口に出していうのか？　それとも、いわないのか？　ただ、それだけなのかもしれません。　http://plaza.rakuten.co.jp/yellowfox/diary/200803010000/　現在関わっているプロジェクトにおいて。　一緒に仕事をしている人に。 　プロジェクトの進め方について。　それとなく聞いてみると。 　自分自身以外にも。　「どこか仕事の進め方がおかしいよな～！！」　このようなことを感じている人が。　数少ない20代前半のエンジニアも含め。　プロジェクト内に何人か存在したことが。　今の自分には。　せめてもの救いになっているのかもしれません。　http://plaza.rakuten.co.jp/yellowfox/diary/200803060000/　おわり

  2008年03月14日

• 逃げ出していなかったらどうなっていたんだろう？

  　最近、ふと感じたこと。　ITシステム開発において。　システム開発の基本がわかっていない。　このような人たちと一緒に仕事をすると。　いつまでたっても意味のない仕事をさせられるため。　まともなシステムが完成することは。　永遠にないものなのかもしれません。　さらにいえば、このような職場環境の中。　「3月いっぱいで、契約終了になっていなかったら、　　今頃、自分はどうなっていたんだろう？」　このようなことを考えたりすると。　ゾッとしたりもするものです。　IT業界において。　うつ病になる人が多いとよく耳にしますが。　約5ヶ月間。　下請けの立場として。　システム開発の基本がわかっていない人たちと一緒に仕事をしてみると。　その理由が。　実感できるようになるのかもしれません。　http://plaza.rakuten.co.jp/yellowfox/diary/200803120000/　http://plaza.rakuten.co.jp/yellowfox/diary/200802180000/　http://plaza.rakuten.co.jp/yellowfox/diary/200801040000/　おわり

  2008年03月13日

• わかっていない人ほど「順調です」というようです

  　最近、ふと感じたこと。　ITシステム開発において。　システムを依頼されたお客さんは。　システム開発の方法を知らないとことが多いものです。　それゆえ、システムのテストを行なうとき。　画面のデザインや操作性。　こういった外部処理の動作確認しか行なわないものです。　そこで、システムを開発するベンダー側のエンジニアは。　お客さんのテストがはじまる前に。　外部処理の動作確認だけでなく。　お客さんにはわからない内部処理の動作確認をしっかりと行なう。　こういったことが必要なものです。　しかし、こういったことがわかっていないエンジニアがシステムを開発すると。　お客さんのテストがはじまった段階で。　「テストは、順調に進んでいます！！」　このようなことをいうのかもしれませんが。　こういう人に限って。　内部処理の動作確認が十分にできていないため。　テストが進むにつれて。　不具合を多発させ。　最終的には、収拾のつかないトラブルプロジェクトへと発展させてくれるものなのかもしれません。　ITシステム開発において。　プロジェクトの状況を確認したとき。　「順調です！！」　もしも、このように答えるエンジニアがいたとしたら。　そのエンジニアが、本当にシステム開発に必要な知識を持ち合わせているかどうか？　合わせて確認してみる必要。　あるのかもしれません。　http://plaza.rakuten.co.jp/yellowfox/diary/200608060000/　http://plaza.rakuten.co.jp/yellowfox/diary/200710170000/　おわり

  2008年03月11日

• 「素人」集団に関わるとろくなことがありません

  　最近、ふと感じたこと。　ITシステム開発において。　システムを依頼されたお客さんは。　システム開発の方法を知らないとことが多いものです。　そこで、システムを開発する企業（ベンダー）が。　お客さんを導きながら。　システム開発のプロジェクトを進めていかなければ。　うまいこといかないものなのですが。　ベンダー側に。　システム開発の基本を知らない人ばかりが集まっていると。　お客さんのいいなりで、プロジェクトが進んでいくものなのかもしれません。　さらにいえば、プロジェクトにもよりますが。　規模が大きいシステムであれば。　本番稼動1ヶ月前をむかえるころには。　すべてのテストをほぼ完了させ。　お客さんと本番稼動前の最終確認や。　本番稼動に備えた準備をはじめる。　こういった段階に入っていくものなのですが。　システム開発の基本を知らないベンダーが。　お客さんのいいなりになっているトラブルプロジェクトでは。　このような時期になっても。　お客さんから新しい機能の追加をいわれると。　ベンダーは、突貫工事でその対応を行ない。　ただでさえ品質の悪いシステムに。　さらなる不具合を増やすことになるため。　トラブルがトラブルをよび。　ベンダー側のプロジェクトマネージャーが、　「品質が安定しない～！！」　このようなことをいう羽目になるものなのかもしれません。　現在関わっているプロジェクトを見ていると。　「素人」が集まってシステムを開発すると、どうなるのか？　こういったことを、如実に表しているとしか思えないものです。　ちなみに、プロジェクトに関わっている人ですが。　ほぼ全員が30歳代、40歳代です。　http://plaza.rakuten.co.jp/yellowfox/diary/200803070000/　おわり

  2008年03月10日

• 名将のもとには名参謀がいるようです

  　最近、ふと感じたこと。　ITシステム開発において。　いったん、プロジェクトがトラぶり出すと。　たとえプロジェクトマネージャー自身が。　なんとかしようとして。　現場で孤軍奮闘したとしても。　もはや、どうにもならないこと。　結構、多いものです。　http://plaza.rakuten.co.jp/yellowfox/diary/200803070000/　さらにいえば、どのようなプロジェクトであろうとも。　プロジェクトマネージャーやリーダーに対して意見をいえる。　こういった人がいないと。　マネージャーやリーダーが暴走をはじめたとき。　だれも止めることができないため。　自滅への道を突っ走る。　こういったことにもなりかねないのかもしれません。　http://plaza.rakuten.co.jp/yellowfox/diary/200803010000/　さらにさらにいえば、ITシステム開発だけでなく。　どのようなことであろうとも。　名将と呼ばれる人のもとには。　名参謀。　いるものなのかもしれません。　おわり

  2008年03月09日

• 育てなくても育つ人は育つものです

  　最近、ふと感じたこと。　ITシステム開発において。　会社の人材を育成するために。　いわゆる「若手」を。　プロジェクトリーダーに抜擢すること。　もしかしたら、あるのかもしれませんが。　育成する人と。　育成される人が。　机上だけでなく。　現場経験から学んだシステム開発の基本を知らなければ。　プロジェクトそのものがトラぶってしまい。　育成どころではなくなること。　もしかしたら、あるのかもしれません。　さらにいえば、リーダーの育成には。　システムを依頼されたお客さんも含め。　そのリーダーとともに働く人の協力が必要なものですが。　プロジェクトそのものがトラぶってしまうと。　ともに働く人のあいだにも。　不満がたまってくるため。　育成どころではなくなることも。　これまた、もしかしたら、あるのかしれません。　さらにさらにいえば、自ら学ぶ気持ちがある人は。　自らの経験から。　自らに足りないものに気がつき。　さらには、自ら学ぼうとするようなので。　育成しようとしなくても。　勝手に育っていくものなのかもしれません。　おわり

  2008年03月08日

• トップの意識と行動が成否を決めるようです

  　最近、ふと感じたこと。　ITシステム開発において。　かつてプロジェクトリーダーとして。　システム開発のプロジェクトを失敗させたことのある人。　もしかしたら、いるのかもしれませんが。　このような人が。　過去のプロジェクトの失敗の原因を。　自分自身にではなく。　勤務している会社の体質にあると考えている限り。　その後のプロジェクトで。　仮にプロジェクトマネージャーになったとしても。　そのプロジェクトを成功させることは。　できないものなのかもしれません。　さらにいえば、プロジェクトマネージャーは。　現場から一歩引いた客観的な立場で。　プロジェクトの状況を把握し。　次の一手を「考える」。　こういった仕事が、最も重要なのかもしれませんが。　システムを依頼されたお客先で。　テストに忙殺されているようでは。　プロジェクトの舵取りができないため。　失敗につながる可能性。　ますます高くなるものなのかもしれません。　さらにさらにいえば、プロジェクトの成否を決めるのは。　トップの意識と行動なのかもしれませんが。　現在関わっている大手IT企業の。　プロジェクトマネージャーやリーダーを見ていると。　そういった企業には。　そういった人材しか残らないことを。　証明しているのかもしれません。　http://plaza.rakuten.co.jp/yellowfox/diary/200802110000/　http://plaza.rakuten.co.jp/yellowfox/diary/200712170000/　おわり

  2008年03月07日

• ミスリードが業界をおかしくしているのかもしれません

  　最近、ふと感じたこと。　ITシステム開発において。　いわゆるトラブルプロジェクトは。　様々な点において。　仕事のやり方がおかしいものですが。　プロジェクトに関わっている人を見渡すと。　諸悪の根源となる人。　必ず存在するものです。　http://plaza.rakuten.co.jp/yellowfox/diary/200803020000/　さらにいえば、諸悪の根源となる人が。　わかっていない人に。　おかしな仕事のやり方を。　正しい仕事のやり方だと教えてしまうミスリード。　もしかしたら、あるのかもしれません。　さらにさらにいえば、ミスリードする人が増えれば増えるほど。　間違った知識を持った人も増えていくため。　トラブルプロジェクトも増えていく。　もしかすると、こういった悪循環が。　IT業界において。　もっとも危惧すべきことなのかもしれません。　http://plaza.rakuten.co.jp/yellowfox/diary/200803050000/　http://plaza.rakuten.co.jp/yellowfox/diary/200803040000/　おわり

  2008年03月06日

• リハビリは意識しないとできないものです

  　最近、ふと感じたこと。　ITシステム開発において。　いわゆるトラブルプロジェクトは。　様々な点において。　仕事のやり方がおかしいものですが。　そんなプロジェクトに関わったがために。　おかしな仕事のやり方が。　知らぬ知らぬのうちに。　自分自身にも身についてしまうこと。　もしかしたら、あるのかもしれません。　さらにいえば、おかしな仕事のやり方が身につくと。　その仕事のやり方が。　あたりまえだと勘違いし。　新しい仕事に関わったとき。　プロジェクトを間違った方向に導いてしまう。　このようなこともあるかもしれませんので。　「この仕事のやり方はおかしい！！」　このようなことに気がついた時点で。　意識して。　きちんとした仕事のやり方を取り戻していく。　こういったリハビリが必要なのかもしれません。　http://plaza.rakuten.co.jp/yellowfox/diary/200712210000/　ついでにいえば、きちんとした仕事のやり方を取り戻すためには。　おかしな仕事のやり方をしている連中からの呪縛。　まずは、打ち破らないといけないようです。　http://plaza.rakuten.co.jp/yellowfox/diary/200802060000/　おわり

  2008年03月05日

• あることがあたまの中に浮かびはじめました

  　最近、ふと感じたこと。　ITシステム開発において。　契約期間が終了するまで。　残り約1ヶ月とはいえども。　どう考えても失敗するとしか思えないプロジェクトのために。　毎日出勤し。　意味のない、かたちだけの仕事をこなすのは。　非常につらい一方で。　これまでも、意味のない。　かたちだけの仕事をつづけてきたがために。　トラブルプロジェクトへと発展した。　このようにいいかえることもできるのかもしれません。　http://plaza.rakuten.co.jp/yellowfox/diary/200712190000/　さらにいえば、現在のプロジェクトに関わった昨年11月から。　契約期間が終了する今年3月末までに経験したことを。　なんからの形式でまとめることによって。　システムを開発する人だけでなく。　システムを依頼する人にとっても。　「なぜシステム開発のプロジェクトはトラぶるのか？」　こういったことを考えるきっかけになるものを。　もしかしたら、作ることができるのではないかと。　ぼんやりとあたまの中に浮かびはじめたところです。　http://plaza.rakuten.co.jp/yellowfox/diary/200803020000/　「こんなプロジェクトに2度と関わりたくない～！！」　このような願いもこめて！！　おわり

  2008年03月04日

• 「先生」の選び方を間違えると高い授業料を支払うことになるようです

  　最近、ふと感じたこと。　ITシステム開発において。　プロジェクトがトラぶると。　こちらのバグ（不具合）を直せば。　次のバグが見つかる。　あちらのバグを直せば。　こちらのバグが直らない。　このような「もぐらたたき」状態になること。　もしかしたら、あるのかもしれません。　で、開発しているシステムが。　このような「もぐらたたき」の状態であろうとも。　プロジェクトリーダーが。　自分の立場を守るために。　ムリヤリ本番稼動させてしまうことも。　もしかしたら、あるのかもしれませんが。　そのようなことをすれば。　本番稼動後に。　お客さんの業務そのものが大きく混乱する。　こういったことにも、なりかねないものです。　そこで、システムを依頼されるお客さんは。　システムを本番稼動させる前に。　開発されたシステムが。　日々の業務に耐えうるだけの品質を確保しているのか？　このようなことをチェックする知識が必要とされるものなのですが。　自分自身にそういった知識がないことに気がつき。　さらには、システム開発の依頼先が間違っていたことにも気がついたときには。　すでに結構な数の「0」がついた授業料を支払いおえていることも。　もしかしたら、あるのかもしれませんね！！　http://plaza.rakuten.co.jp/yellowfox/diary/200802130000/　おわり

  2008年03月03日

• すべては過去の経験がものをいうようです

  　最近、ふと感じたこと。　ITシステム開発において。　これまで、きちんとした仕事のやり方を身につけ。　それなりの結果を出してきたと思われる人は。　現在関わっているプロジェクトがトラぶっているかどうか？　さらには、行く末がどうなるか？　それなりに判断できる一方で。　これまで、きちんとした仕事のやり方も身につけず。　いい加減なことしかしてこなかったと思われる人は。　現在関わっているプロジェクトがトラぶっているかどうか？　このようなことが判断できるどころか。　その人自身の存在がトラブルの元凶となっている。　このようなことにすら、気がつかないものなのかもしれません。　http://plaza.rakuten.co.jp/yellowfox/diary/200712200000/　さらにいえば、トラブルプロジェクトを回復させる方法は。　いくつかあるものですが。　http://plaza.rakuten.co.jp/yellowfox/diary/200802290000/　プロジェクトを仕切っている人たちに。　システム開発に必要な基礎力といったものが身についていなければ。　プロジェクトを終結させる。　これ以外に選択の余地はないのかもしれません。　http://plaza.rakuten.co.jp/yellowfox/diary/200802280000/　さらにさらにいえば、自らが関わったプロジェクトだけでなく。　身のまわりのプロジェクトや雑誌などから。　過去の失敗プロジェクトの本質的な原因。　こういったものを考察し。　自らにフィードバックすることによって。　システム開発に必要な知識を増やすことができるだけでなく。　知識に対して確信を持つこと。　もしかしたら、できるようになるのかもしれません。　おわり

  2008年03月02日

• 本当のことを伝えるには時機をうかがうことが必要です

  　最近、ふと感じたこと。　ITシステム開発において。　プロジェクトがトラぶりつづけると。　開発メンバーの中にも。　「もうダメかもしれないね～！！」　このような雰囲気。　蔓延してくるようですが。　こういったタイミングをねらって。　本当のことを伝えることができれば。　プロジェクトの流れは、大きく変わってくるのかもしれません。　http://plaza.rakuten.co.jp/yellowfox/diary/200802110000/　さらにいえば、本当のことを伝えると。　中心メンバーとして。　プロジェクトを引っ張ってきた人の中には。　「ガンバレば、なんとかなるかもしれない！！」　このようなことを考える人もいるのかもしれませんが。　目の前の現実を受け入れることができなければ。　いつまでたっても同じ失敗。　繰り返すものなのかもしれません。　さらにさらにいえば、本当のことを伝えた翌日は。　これまでのようなバタバタした状態はなくなり。　なにごともなかったかのような落ち着いた雰囲気の中で。　いつもどおりの仕事がつづけられるようですが。　プロジェクト全体としては。　立ち止まることなく。　これまで通り前へ進む選択がなされたようなので。　契約最終月となる3月は。　自滅していく様子を。　見届けることになりそうです。　http://plaza.rakuten.co.jp/yellowfox/diary/200802290000/　http://plaza.rakuten.co.jp/yellowfox/diary/200801200000/　http://plaza.rakuten.co.jp/yellowfox/diary/200802190000/　おわり

  2008年03月01日

• 絞り込むことによって資源を集中させることができるものです

  　最近、ふと感じたこと。　ITシステム開発において。　プロジェクトがトラぶり。　どう考えても本番稼動日までに。　すべての機能の開発をおえることができない。　このようなことが判明したとき。　プロジェクトマネージャーやリーダーは。　システムを依頼されたお客さんに事情を説明し。　開発優先度の高い機能を絞り込み。　本番稼動日まで。　ありったけの人という資源を投入し。　それらの機能の開発に専念させる。　このような決断を下すことができれば。　道が開けたりするものですが。　これまでと同様。　すべての機能を開発しようと。　資源を分散させているようでは。　「デスマーチ」が進行するだけなのかもしれません。　http://plaza.rakuten.co.jp/yellowfox/diary/200607280000/　ついでにいえば、トラブルプロジェクトから脱却するためには。　機能の絞り込みをおこなったあと。　これまで開発してきたプログラムがどこまで使えるのか？　このような見極めが必要なようですが。　お客さんにろくに仕様も確認せずに。　好き勝手に開発したプログラムが。　再利用できるとは。　とてもとても思えないものです。　http://plaza.rakuten.co.jp/yellowfox/diary/200802280000/　おわり

  2008年02月29日

• 

  ついに末期をむかえたようです

  　最近、ふと感じたこと。　ITシステム開発において。　末期をむかえたトラブルプロジェクトでは。　打つことができる手が限られてくる一方で。　プロジェクトに関わる人たちは。　なんとかしようとして。　目先の作業にバタバタする。　このような傾向があるのかもしれません。　先週の土曜日（2/23）の夜。　なぜか、ある本が読み直したくなって。　　その本の後半部分を読んでいましたが。　もしかすると、潜在意識の中で。　現在関わっているプロジェクトの「おわらせ方」を。　模索していたのかもしれません。　http://plaza.rakuten.co.jp/yellowfox/diary/200802190000/　会社経営においても。　ITシステム開発においても。　いかにして、「最後」をおわらせるか？　意外と重要なことなのかもしれません。　おわり

  2008年02月28日

• テストがおわりました？

  　最近、ふと感じたこと。　ITシステム開発において。　システムの品質を上げるために。　テスト（動作確認）を行なうとき。　ふつうは、どのようなテストを行なうのか？　こういった項目を洗い出したチェックリストを作成し。　そのチェックリストにそってテストを行い。　バグ（不具合）が見つかれば。　不具合の内容や修正方法などを記録し。　テストがおわったあとに。　どのような不具合が何件発生したのか？　このようなことを見直すことによって。　きちんとテストができていて。　なおかつ、システムの品質が保証されているかを。　確認するものなのですが。　プロジェクトの中には。　どのようなテストを行なったのか？　さらには、どのような不具合が発生したのか？　このようなことがわかる資料も作成せずに。　「テストがおわりました！！」　このようなことをいっているプロジェクト。　もしかしたら、あるのかもしれません。　さらにいえば、このようなシステムを使って。　システムを依頼されたお客先でテストをしたとき。　どのようなことが起こり。　さらには、お客さんからどのようなことをいわれるのか？　このようなことが容易に想像できるだけでなく。　たとえ下請の立場であろうとも。　元請と同じ会社の人間として見られるため。　自分自身の信用も失う。　このようなことに、なりかねないのかもしれません。　ついでにいえば、現在関わっているプロジェクトですが。　先行開発しているシステムが。　お客先でテストをしているようですが。　なにやら雲行きが。　かなりあやしくなってきたようです。　http://plaza.rakuten.co.jp/yellowfox/diary/200802190000/　おわり

  2008年02月27日

• 次をまかせられる人材探しが重要なようです

  　最近、ふと感じたこと。　ITシステム開発において。　自分自身がプロジェクトを抜けるとき。　プロジェクトがまわる仕組みを作り。　さらには、その仕組みをひきつづきまわしていくことができる。　このような人材を探しておかなければいけないようですが。　パッとまわりを見渡すと。　適した人材がいないことが。　もしかしたら、今のプロジェクトの現状につながっているのかもしれません。　http://plaza.rakuten.co.jp/yellowfox/diary/200802110000/　さらにいえば、組織を強くしていこうと思うのであれば。　次をまかせられる人材を探し、育成する。　このようなことがいかに重要であるかも。　合わせてわかってくるものなのかもしれません。　http://plaza.rakuten.co.jp/yellowfox/diary/200802210000/　さらにさらにいえば、　「この人には、ついていきたくない！！」　このようなことを感じさせる人が。　いくらプロジェクトをまわそうとしても。　誰もついてこないため。　これまた、プロジェクトが破綻する可能性。　高くなるものなのかもしれません。　おわり

  2008年02月26日

• 他人の運転が信用できないのであれば自分でハンドルを握るしかないようです

  　最近、ふと感じたこと。　ITシステム開発において。　プロジェクトリーダーが。　技術のことがわからない。　システムを依頼されたお客さんとの折衝方法がわからない。　プロジェクトを管理する方法がわからない。　この3つの条件のうち。　1つにでもあてはまると。　見かけ上の進捗（進み具合）の数字を上げる。　このような意味のない仕事のために。　つきあい残業や。　つきあい休日出勤をさせられるだけでなく。　プロジェクトそのものが。　トラブルプロジェクト。　さらには、デスマーチへと発展していくものなのかもしれません。　http://plaza.rakuten.co.jp/yellowfox/diary/200802110000/　http://plaza.rakuten.co.jp/yellowfox/diary/200607280000/　さらにいえば、他人の運転が信用できないのであれば。　自分でハンドルを握り運転する。　これが安全確実。　かつ責任がとれる方法なのかもしれません。　http://plaza.rakuten.co.jp/yellowfox/diary/200707210000/　http://plaza.rakuten.co.jp/yellowfox/diary/200802220000/　おわり

  2008年02月25日

• 下には下があるようです

  　最近、ふと感じたこと。　独立してから約2年間。　大手IT企業や。　いわゆるベンチャー企業などで。　下請の立場として。　ITシステム開発の仕事をしてきましたが。　あくまで個人的な見解ですが。　サラリーマン時代の経験もふくめると。　メーカー系企業で。　金融システムの開発を経験することによって。　品質の高いシステムを開発するために必要な基礎知識を。　経験から学ぶことができるのかもしれません。　さらにいえば、かつてサラリーマンだったとき。　「このプロジェクト、最悪だな～！！」　このようなことを感じた金融システムの開発プロジェクトがいくつかありましたが。　独立してはじめて。　下には下があること。　知ることができたものです。　http://plaza.rakuten.co.jp/yellowfox/diary/200707300000/　おわり

  2008年02月23日

• プロジェクト凍結へのカウントダウン？

  　最近、ふと感じたこと。　かつてサラリーマンだったときから。　いやな仕事についたとき。　「あと何日ガマンすれば、この仕事はおわる！！」　このようなカウントダウン。　よくしていたものです。　さらにいえば、カウントダウンをおえたとき。　気がつくと。　自分自身の手元に残っていたものはお金だけであった。　こういったことがほとんどだったものです。　逆にいえば、お金以外のものが手に入る。　このような仕事についたときは。　カウントダウンという発想すら。　あたまに浮かんでこなかったものです。　現在関わっている仕事は。　3月いっぱいでの契約終了が確定したため。　これからは、毎日がカウントダウンな日々である一方で。　このカウントダウンが。　プロジェクト凍結へのカウントダウンになるのではないかと。　なぜか、感じはじめるようになりました。　http://plaza.rakuten.co.jp/yellowfox/diary/200802110000/　おわり

  2008年02月19日

• 下請いじめって本当にあるんですね！！

  　最近、ふと感じたこと。　たとえば、ITシステム開発において。　下請の立場として。　いくら仕事で結果を出しても。　元請の担当者から文句をいわれるつづけること。　もしかしたら、どこにいってもあるのかもしれませんが。　結果を地道に出しつづけていれば。　ある1つのできごとをきっかけに。　大きく形勢が逆転しはじめることも。　もしかしたら、あるのかもしれません。　http://plaza.rakuten.co.jp/yellowfox/diary/200801260000/　さらにいえば、これまでどれだけの仕事をやらされ。　その結果に対して、どのようなことをいわれてきたのか？　こういったことをふりかえる余裕が出てくると。　「下請いじめって本当にあるんだな～！！」　こういったことにも、はじめて気づかされるものなのかもしれません。　さらにさらにいえば、元請の立場を利用して。　下請けをいびり。　一時的に儲けることができたとしても。　いびられた下請は嫌気をさして取引をやめてしまう。　最悪の場合は、倒産してしまう。　こういったことにつながる可能性が高いため。　下請いじめによって。　長期に渡って利益を得つづける。　このようなことはできないものなのかもしれません。　ついでにいえば、真の「パートナー」としてふさわしい相手かどうかは。　社内用語ではなく。　ふだんの仕事での言動から。　判断できるものなのかもしれません。　http://plaza.rakuten.co.jp/yellowfox/diary/200610260000/　おわり

  2008年02月18日

• おかしな仕事はおかしなリーダーによって生み出されるようです

  　最近、ふと感じたこと。　ITシステム開発において。　きちんとした仕様書や設計書が存在しない。　このようなプロジェクト。　もしかしたら、結構あるのかもしれませんが。　こういったプロジェクトが生まれる背景には。　きちんとした仕事のやり方を身につけていない。　こういったリーダーの存在があるのかもしれません。　http://plaza.rakuten.co.jp/yellowfox/diary/200801230000/　さらにいえば、おかしなリーダーのもとからは。　まともなメンバーは逃げ出し。　おかしなメンバーだけが残るため。　プロジェクトが成功する可能性も。　小さくなる一方なのかもしれません。　http://plaza.rakuten.co.jp/yellowfox/diary/200802110000/　おわり

  2008年02月17日

• 知識がなければ質を見抜くことはできないものです

  　最近、ふと感じたこと。　たとえば、金融機関には。　勘定系（ホスト）の開発や運用を行なうために。　システム部門というものがあり。　なおかつ、システム部門の人は。　システム開発に必要な知識を持ち合わせているものです。　そのためか。　かつてサラリーマンだったとき。　某大手メーカーのSE（システムエンジニア）として。　金融システムの面倒を見ていたとき。　金融機関の人に、　「このエンジニアには、仕事をまかせられない！！」　「この営業では、お話にならない！！」　このような判断を下されたメーカーのエンジニアや営業は。　ことごとく交代させられていたものです。　ところが、業種を問わず。　社内にシステム部門がないため。　システム開発に必要な知識を持ち合わせている人が皆無に等しい。　このような会社になってくると。　システム開発を行なうには、どのようなスキルを持った人材が必要なのか？　このようなことがわからないため。　技術のことがわからない。　システムを依頼されたお客さんとの折衝方法がわからない。　プロジェクトを管理する方法がわからない。　このような3拍子そろった人がリーダーになっても。　「交代させる」といった判断ができずに。　失敗へとつながる。　こういったプロジェクトが意外と多いのかもしれません。　http://plaza.rakuten.co.jp/yellowfox/diary/200802110000/　どのような仕事であろうとも。　その業務を行なうために必要な知識を身につけていないと。　人材の質を見抜くことができないため。　後々になって、とんでもない代償を支払う。　こういったことにつながるものなのかもしれません。　http://plaza.rakuten.co.jp/yellowfox/diary/200710170000/　おわり

  2008年02月13日

• すべて自分自身に返ってくるようです

  　最近、ふと感じたこと。　ITシステム開発において。　たとえ下請の立場であろうとも。　結果を少しずつ出していけば。　プロジェクトの主導権を握ることができる一方で。　元請となる大手IT企業の社員であろうとも。　自分の役割を認識した上で。　その役割に見合った仕事をこなすことができなければ。　いずれは、そのツケを支払う。　こういったときがくるものなのかもしれません。　http://plaza.rakuten.co.jp/yellowfox/diary/200801260000/　さらにいえば、自ら手を動かさずに。　他人（下請）に仕事をやらせる。　このような方法で給料をもらってきた人は。　日々の業務を通じて。　仕事に必要な知識を身につける。　このようなことができていないため。　これまた、いずれそのツケを支払う。　こういったときがくるものなのかもしれません。　http://plaza.rakuten.co.jp/yellowfox/diary/200801220000/　どのようなことであろうとも。　今、現在の行動は。　将来、なんらかのかたちで。　すべて自分自身に返ってくる。　もしかすると、この言葉が。　独立2年目に得ることのできた。　大きな収穫なのかもしれません。　http://plaza.rakuten.co.jp/yellowfox/diary/200511040000/　おわり

  2008年02月12日

• 事実上の失敗が決まったようです

  　最近、ふと感じたこと。　ITシステム開発において。　プロジェクトを進めていく上で。　仕事に必要な知識を持ち合わせてない人がリーダーについている。　このような大きな問題点が見つかったとしても。　システム開発を依頼されたお客さんとの関係を重視し。　リーダーを交代させようとしなかったプロジェクトは。　結局、リーダーの存在がボトルネックとなって。　仕事が前に進まないため。　残された膨大な作業や課題。　さらには、本番稼動までに残された期間を考えると。　やはりというか、案の定というか。　事実上の失敗が決まってしまうこと。　もしかしたら、あるのかもしれません。　http://plaza.rakuten.co.jp/yellowfox/diary/200801250000/　http://plaza.rakuten.co.jp/yellowfox/diary/200712260000/　さらにいえば、プロジェクトを立ち上げたとき。　技術のことがわからない。　システムを依頼されたお客さんとの折衝方法がわからない。　プロジェクトを管理する方法がわからない。　このように3拍子そろった人をリーダーとして抜擢した時点で。　そのプロジェクトの命運は。　もしかしたら、すでに決まっていたのかもしれません。　http://plaza.rakuten.co.jp/yellowfox/diary/200709020000/　さらにさらにいえば、親会社をはじめとする。　グループ企業内での内部取引や。　上場による資金調達によって。　お金の心配をする必要がない企業に勤務していると。　プロジェクトが成功しようと失敗しようと。　ふところは痛くもかゆくもないため。　その企業で働く社員の認識も。　もしかしたら、どこかずれたものになるのかもしれません。　http://plaza.rakuten.co.jp/yellowfox/diary/200802100000/　http://plaza.rakuten.co.jp/yellowfox/diary/200802010000/　http://plaza.rakuten.co.jp/yellowfox/diary/200712180000/　おわり

  2008年02月11日

• より複雑に、よりわかりにくく！！

  　最近、ふと感じたこと。　ITシステム開発において。　システムを依頼されたお客さんが。　どのような業務をこなすために。　どのようなシステムが必要なのか？　こういったことが理解できていないSE（システムエンジニア）は。　お客さんにいわれたことや。　自分のあたまの中で思いついたことを。　そのままシステムに反映させる傾向があるため。　時間をかけて。　きれいに作ったデモ画面なんぞ見せてもらうと。　あまりの複雑さに。　「本当にお客さんが、こんなシステム要求してきたんですか？」　このような言葉が思わず口をついて出てしまうこと。　もしかしたら、あるのかもしれません。　http://plaza.rakuten.co.jp/yellowfox/diary/200802020000/　さらにいえば、何度もお客先に行っているにも関わらず。　どのようなシステムを開発するのかといった仕様がなかなか決まらないとき。　お客さんに提出した資料や。　デモ画面を作った人の説明を聞いていると。　すべてがわかるものなのかもしれません。　http://plaza.rakuten.co.jp/yellowfox/diary/200801150000/　おわり

  2008年02月05日

• 

  プロジェクトを成功させたいな～！！

  　最近、ふと感じたこと。　たとえばプロ野球において。　フロントは、現場を見て。　現場に足りない選手を獲得する一方で。　現場では。　指揮官となる監督が。　フロントが獲得した選手を使って。　勝利をつかんでいく。　このような相互依存が成り立ってはじめて。　強いチームを作ることができように。　ITシステム開発においても。　フロントに位置づけられるマネージャーは。　まず現場を見て。　現場に足りないメンバーを獲得する。　いらないメンバーをはずす一方で。　現場では。　指揮官となるリーダーが。　マネージャーが獲得してくれたメンバーを使って。　プロジェクトを前に進めていく。　このような相互依存が成り立ってはじめて。　プロジェクトは成功するものなのかもしれません。　逆にいえば、フロントやマネージャーが。　なにもせずに。　現場に勝利やプロジェクトの成功だけを要求するのは。　単なるフロントやマネージャーの怠慢なのかもしれません。　さらにいえば、強いプロ野球チームのGM（General Manager）と。　なにもしない大手IT企業のマネージャー連中とを比較することによって。　これから新しい「世界」を作り。　http://plaza.rakuten.co.jp/yellowfox/diary/200801160000/　ITシステム開発のプロジェクトを成功させていく上で。　どのような点がポイントになってくるのか？　もしかしたら、見つけること。　できたのかもしれません。　　おわり

  2008年02月04日

• 異常が見つかったクルマには乗りつづけたくないものです

  　最近、ふと感じたこと。　たとえばクルマに異常が見つかったとき。　その異常をほったらかしにして運転していると。　おそらくですが、事故につながる可能性。　非常に高くなるものなのかもしれません。　さらにいえば、ITシステム開発において。　プロジェクトに大きな問題点が見つかったとき。　その問題点が解決されないプロジェクトは。　おそらくですが、失敗につながる可能性。　非常に高くなるものなのかもしれません。　http://plaza.rakuten.co.jp/yellowfox/diary/200801250000/　さらにさらにいえば、異常が見つかっても。　修理されないクルマには乗りつづけたくないように。　大きな問題点が見つかっても。　その問題点を解決しようとしないプロジェクトには。　いつまでも関わりたくないものです。　http://plaza.rakuten.co.jp/yellowfox/diary/200802010000/　http://plaza.rakuten.co.jp/yellowfox/diary/200607280000/　おわり

  2008年02月03日

• きれいな資料を作っても理解してもらえるとは限りません

  　最近、ふと感じたこと。　ITシステム開発において。　システムを依頼されたお客さんに対して。　どのようなシステムを開発すれば良いのか？　こういったことをヒアリングするとき。　お客さんから、　「説明がよくわからない！！」　このようなことをいわれると。　さらにきれない資料を作成する。　さらにきれいなデモ画面を作成する。　このような行動をとるSE（システムエンジニア）。　もしかしたら、結構いるのかもしれません。　しかし、どれほどきれいな資料を作成しようとも。　どれほどきれいなデモ画面を作成しようとも。　プレゼンテーション（説明）をする人が。　開発するシステムの本質を理解した上で。　お客さんが、いったいなにを求めているのか？　こういったことが理解できていなければ。　お客さんからシステム開発に必要な情報を聞き出すことは。　できないものなのかもしれません。　http://plaza.rakuten.co.jp/yellowfox/diary/200801150000/　さらにいえば、かつて大企業のシステム子会社でサラリーマンをしていたとき。　A4用紙数枚に。　文章や図がぎっしりと書かれたシステム障害報告書を何度か読ませてもらったことがありますが。　原因はいったいなんだったのか？　読み取れない報告書。　結構あったものです。　http://plaza.rakuten.co.jp/yellowfox/diary/200501060000/　ITシステム開発だけでなく。　どのようなことであろうとも。　問題点の本質を取り違えている限り。　その問題点が解決されること。　決してないものです。　おわり

  2008年02月02日

• 大企業も使いようです

  　最近、ふと感じたこと。　ITシステム開発において。　大手IT企業のプロジェクトの中には。　「おそらくこのプロジェクト、アカンやろな～！！」　このようなことを感じさせるプロジェクト。　結構あるようです。　しかし、そのようなプロジェクトであろうとも。　見方によっては。　次の仕事に必要と思われる経験。　積むことができたりするものです。　そこで、どのような状況に置かれようとも。　現状に対してくさったりせずに。　吸収できるものをしっかりと吸収し。　そのときを待つ。　こういった姿勢が必要なのかもしれません。　さらにいえば、たとえプロジェクトが失敗しようとも。　いたくもかゆくもない大手IT企業は。　下請企業にとってみると。　もしかしたら、使い勝手が良い存在なのかもしれませんね！！　http://plaza.rakuten.co.jp/yellowfox/diary/200707130000/　おわり

  2008年02月01日

• 「フォーマット」を信じても成功するとは限りません

  　最近、ふと感じたこと。　ITシステム開発において。　いわゆる大企業には。　「フォーマット」というものがあり。　設計書などは。　そのフォーマットに従って作成する。　このようなことが、もとめられるものです。　http://plaza.rakuten.co.jp/yellowfox/diary/200712220000/　さらにいえば、大企業の社員にとってみると。　会社が準備してくれたフォーマットに従っていれば。　プロジェクトは成功する。　このような勘違いをしている人が。　もしかしたら、結構多いのかもしれません。　ITシステム開発において。　フォーマット（マニュアル）を盲目に信じ。　型どおりの仕事をするのではなく。　フォーマットをもとにして。　いかに自分自身のあたまで考えて仕事をするか？　こういった点がプロジェクトの成否をわけることに。　気がついている人は。　もしかすると、非常に少ないのかもしれません。　http://plaza.rakuten.co.jp/yellowfox/diary/200707190000/　ついでにいえば、独立や起業とは。　自らのフォーマットを。　自らのあたまと。　自らの手で。　作り出すことなのかもしれません。　おわり

  2008年01月27日

• 能力がなければコンバートのしようがないものです

  　最近、ふと感じたこと。　日本のプロ野球において。　かつて内野の守備が下手だった選手であろうとも。　外野にコンバートすることによって。　持っている能力を開花させ。　高額年俸をもらえるメジャーリーガーにまで成長する。　このような選手もいるのかもしれませんが。　打てない、守れない、走れない。　このような選手であれば。　メジャーリーグはおろか。　チーム内でも。　コンバートのしようがないものです。　http://plaza.rakuten.co.jp/yellowfox/diary/200801230000/　ITシステム開発において。　技術、お客さんとの折衝、プロジェクト管理。　このようなことが、ひとつもわからない人であろうとも。　システム開発を依頼されたお客さんとの関係上。　はずしたくてもはずせないとき。　その人を、プロジェクト内でコンバート（配置転換）する。　もしかしたら、このようなこともあるのかもしれませんが。　現場で仕事をしている人とってみれば。　その人の存在そのものが。　お荷物であることに変わりはないのかもしれません。　ついでにいえば、技術、お客さんとの交渉、プロジェクト管理。　このようなことが、ひとつもわからない人が。　プロジェクトの中に2人もいると。　非常にしんどいものなのかもしれません。　というのも。　野球にたとえると。　内野を3人、外野を2人で守るようなものですからね！！　おわり

  2008年01月25日

• 規模が変わろうとも基本は同じです

  　最近、ふと感じたこと。　ITシステム開発において。　小規模プロジェクトであれば。　多少、仕事の進め方がまずくても。　力ずくでプロジェクトをおわらせること。　できるものです。　しかし、中規模プロジェクトや大規模プロジェクトになると。　仕事の進め方がまずいと。　あっという間にトラブルプロジェクトへと発展し。　炎上してしまう。　こういった傾向があるのかもしれません。　さらにいえば、小規模プロジェクトしか経験していない人が。　中規模以上のプロジェクトに関わると。　小規模プロジェクトで通用した仕事の進め方をしようとするようですが。　その進め方が通用しないことに気がついたときには。　すでに大炎上しているものなのかもしれません。　さらにさらにいえば、大きくとらえて小さくおとす。　http://plaza.rakuten.co.jp/yellowfox/diary/200801110000/　この考え方は。　プロジェクトの規模に関係なく。　通用するものなのかもしれません。　おわり

  2008年01月24日

• 打てない、守れない、走れない

  　最近、ふと感じたこと。　ITシステム開発において。　技術のことがわからない。　システムを依頼されたお客さんとの折衝方法がわからない。　プロジェクトを管理する方法がわからない。　このような3拍子そろった技術者（？）は。　野球でいえば。　打てない、守れない、走れない。　このような3拍子そろった選手と同様。　使いようがないものです。　さらにいえば、3拍子そろった選手をかかえることができるのは。　金満球団であるように。　3拍子そろった技術者（？）をかかえることができるのは。　もしかすると、大企業だけなのかもしれません。　http://plaza.rakuten.co.jp/yellowfox/diary/200801210000/　おわり

  2008年01月23日

• 大企業の売上は下請企業の犠牲のもとに成り立っているようです

  　最近、ふと感じたこと。　たとえば、日本のプロ野球において。　FA（フリーエージェント）による移籍で。　高額年俸をもらいながら。　大した働きもせずに引退する。　もしくはトレードに出される。　このような選手が。　これまで結構いたようですが。　日本の大手IT企業においても。　大した働きもせずに。　高い給料をもらっている人。　もしかしたら、結構いるのかもしれません。　さらにいえば、あらゆる経済的取引は、誰かの価格と、他の誰かの価値との交換である。　http://plaza.rakuten.co.jp/yellowfox/diary/200709130000/　こういった経済の本質が理解できるようになると。　大手IT企業の売上（価格）や。　大して働かない社員の給料（価格）は。　下請企業の社員が。　必死に働くことによって作り出された設計書やプログラム（価値）によって生み出されている。　このようなこともわかってくるのかもしれません。　さらにさらにいえば、大手IT企業の成長の源泉（バリュードライバー）は。　会社の名前（ネームバリュー）をちらつかせることによって。　優秀な人材がいる下請企業をいかに抱えこむことができるか？　こういった点であることも。　合わせてわかってくるのかもしれません。　実際に大手IT企業で下請けとして働き。　その実情を知れば知るほど。　大手IT企業の弱点がよ～く見えてくる一方で。　http://plaza.rakuten.co.jp/yellowfox/diary/200801180000/　新しい「世界」を作り出すために。　http://plaza.rakuten.co.jp/yellowfox/diary/200801160000/　なにが必要なのかも。　よ～くわかってくるものです。　http://plaza.rakuten.co.jp/yellowfox/diary/200709190000/　おわり

  2008年01月21日

• ときには立ち止まるといった判断が必要なものです

  　最近、ふと感じたこと。　ITシステム開発において。　コーディング（作り込み）がおわると。　単体テスト　　　　↓　結合（組合せ）テスト　　　　↓　システム（全体結合）テスト　このような順番でテストをするものです。　で、たとえばシステムテストの段階になって。　5桁の数字しか入力できないところに。　6桁の数字が入力できてしまう。　このような単体テストで見つけなければいけない不具合が見つかったとき。　いったんシステムテストを中止して。　同じような不具合がないか。　単体テストレベルの見直しを行なえば。　おそらくですが、同じような不具合がいくつも見つかるだけでなく。　あとあとになって。　トラブルプロジェクトへと炎上する可能性を。　小さくすることができるものですが。　スケジュールを気にして。　先をあせるがために。　ちょっとした見直しもせずに突き進み。　大炎上させる。　このようなパターンがほとんどなのかもしれません。　ITシステム開発において。　「これ、マズイよな～！！」　このようなことを感じたとき。　プロジェクトリーダーが。　いったん、立ち止まって。　あやしい箇所を見直すといった判断ができるかどうかが。　プロジェクトの成否をわけるものなのかもしれません。　おわり

  2008年01月20日

• 「記憶」よりも「理解」が必要です

  　最近、ふと感じたこと。　たとえば、ITシステム開発において。　システムの内容を「理解」している人であれば。　同じ質問を。　違う表現でしたとしても。　同じ回答が返ってくるものですが。　単に内容を「記憶」しているだけの人は。　同じ質問を。　違う表現ですると。　一方の場合は、回答できても。　もう一方の場合は、回答できない。　このようなこともあるのかもしれません。　http://plaza.rakuten.co.jp/yellowfox/diary/200709240000/　さらにいえば、お客さんにシステムを提案する場において。　お客さんの発言内容を「理解」しようとする人は。　お客さんが、いったいなにを求めているのか？　こういったことがわかるため。　お客さんの要望を満たすシステムを提案できるようですが。　お客さんの発言内容を「記憶」しようとする人は。　提案をするどころか。　お客さんからいわれたことをメモするのに必死になるため。　あとから説明を受ける開発者は。　なにをいっているのかわからない。　このようなことになりかねないのかもしれません。　http://plaza.rakuten.co.jp/yellowfox/diary/200801150000/　さらにさらにいえば、覚えるのではなく。　理解する。　こういったことができていない人ほど。　「自分は仕事ができる！！」　このような勘違い。　しているものなのかもしれません。　http://plaza.rakuten.co.jp/yellowfox/diary/200710170000/　おわり

  2008年01月19日

• 大企業中心の業界構造をひっくり返してみたいものです

  　最近、ふと感じたこと。　かつて大企業のシステム子会社で。　サラリーマンをしていたとき。　「これやっといて！！」　「予算をやらないといけないので、その仕事はできません！！」　このようなことをいって。　仕事（本業）をしようとしない親会社の社員。　たくさん見てきました。　で、サラリーマンをやめる間際になって。　大企業とは。　仕事をしない8割社員の雇用を守るために。　2割の社員が働いている。　しかし、その2割の社員は居心地が悪いと感じているため。　いずれは、去っていく一方で。　仕事をしない8割の社員は。　会社に来るだけで、給料がもらえるため。　居心地の良い場所であると感じている。　このようなことを悟ったものです。　IT業界おいて。　いわゆる大企業の社員は。　目の前の仕事に対して。　できる方法を考えるのではなく。　できない理由を考えることが得意なようですが。　そんな大企業中心の業界構造を。　いつか、ひっくり返してみたいと。　なぜか、こころに強く感じてしまうものです。　http://plaza.rakuten.co.jp/yellowfox/diary/200710110000/　おわり

  2008年01月18日

• 伝えるだけならハトでもできます

  　最近、ふと感じたこと。　ITシステム開発を行なうとき。　システムを依頼したお客さんが。　どのようなシステムを開発したいのか？　このような要望を知るために。　ヒアリングを行なうものです。　で、このとき。　SE（システムエンジニア）とよばれる人は。　お客さんの話をもとに。　どのようなシステムが業務に必要なのか？　どのような方法（技術方式）であれば、システムを実現できるのか？　このようなことを考え。　お客さんに提案する。　こういったことが本来の仕事なのかもしれません。　ですが、これまたIT業界においては。　このようなことを理解していない人が。　お客さんにいわれたことを。　そのまま開発者に伝えるだけといった。　伝書鳩のような仕事をしている人が、結構多いのかもしれません。　ついでにいえば、かつて大企業の子会社でサラリーマンをしていたとき。　「営業」とよばれる人は。　お客さんからいわれたことを。　SEに伝えることが仕事でした。　http://plaza.rakuten.co.jp/yellowfox/diary/200512280000/　おわり

  2008年01月14日

• じゃまをしなければそれでいい！！

  　最近、ふと感じたこと。　かつてサラリーマンとして。　大企業のシステム子会社で。　ITシステム開発の仕事をしていたとき。　仕事にからめばからむほど。　仕事全体をトラブらせる人と仕事をしたとき。　http://plaza.rakuten.co.jp/yellowfox/diary/200801120000/　その人が仕事でおかしな指示を出したり。　おかしな作業をしたりして。　仕事の「じゃま」をしていないか？　監視をしていたものです。　http://plaza.rakuten.co.jp/yellowfox/diary/200712290000/　さらにいえば、いわゆる大企業には。　たくさんの社員がいますが。　もしかすると、ほとんどの人が。　いわゆる下請企業の仕事のじゃまをしているだけなのかもしれません。　プロジェクトを成功させたいのであれば。　あなたたちは、仕事のじゃまをしなければそれでいい！！　今、一緒に仕事をしている一部の人に。　いいたい一言です。　おわり

  2008年01月13日

• 巨額損失の原因がわかったような気がします

  　最近、ふと感じたこと。　かつてサラリーマンとして。　大企業のシステム子会社で。　ITシステム開発の仕事をしていたとき。　仕事にからめばからむほど。　仕事全体をトラブらせる人。　いたものです。　で、このような人の特徴をあげてみると。　全体をとらえずに。　細かい点ばかりを見ているだけでなく。　http://plaza.rakuten.co.jp/yellowfox/diary/200801110000/　ものごとを膨らまして考える。　このようなことができない人がほとんどでした。　http://plaza.rakuten.co.jp/yellowfox/diary/200712060000/　さらにいえば、かつてこのBLOGで。　ITシステム開発の失敗により。　巨額の損失を出した企業の話を書きましたが。　http://plaza.rakuten.co.jp/yellowfox/diary/200712170000/　その原因はなんだったのか？　ようやくわかったような気がします。　社員がトラブっていく仕事の進め方しか知らなければ。　プロジェクトの成功はおろか。　利益がついてくるわけがありません。　おわり

  2008年01月12日

• 大きくとらえて小さくおとす

  　最近、ふと感じたこと。　かつて大企業の子会社のサラリーマンだったとき。　某金融機関の某システムを担当するSE（システムエンジニア）として。　金融機関の人と月一回の定例会をやっていると。　出席していたサポートセンターの人が。　自社の人間がだれもいない場で。　次のようなことをいって（グチって）いました。　「（ITシステム開発において）全体を見ようとせずに、　　細かい話ばかりしている。アホちゃうか！！　　まあ、ええわ！！」　で、当時この発言を聞いたとき。　この人はシステム開発の基本がよくわかっている。　このようなことを感じた一方で。　後々になって。　この発言をしたサポートセンターの人は。　システム部に在籍していた過去があることを知ったものです。　大きくとらえて小さくおとす。　これが、システム開発の基本であることを。　IT業界で仕事をしていても。　理解している人は、ほとんどいないどころか。　「独自の開発手法ですか？」　このようなことをいわれると。　「アホちゃうか！！」　思わず口から出そうになるものです。　http://plaza.rakuten.co.jp/yellowfox/diary/200712030000/　おわり

  2008年01月11日

• 弱いチームには意識改革が必要なようです

  　最近、ふと感じたこと。　たとえばスポーツなどにおいて。　弱いチームを強くしようと思うのであれば。　選手の意識改革を行なう。　このようなことからはじめないといけないように。　ITシステム開発においても。　自らの手を使って、システムを本番稼動させた経験がない。　もしくは、失敗プロジェクトしか経験したことがない。　このような人たちが集まっているプロジェクトにおいては。　これまでの仕事のやり方は間違っている。　これくらいの意識改革が必要なのかもしれません。　さらにいえば、どのようなことであろうとも。　意識が変わることなくして行動が変わること。　ないものです。　http://plaza.rakuten.co.jp/yellowfox/diary/200702230000/　おわり

  2008年01月10日

• リスクの中にヒントが隠れているようです

  　最近、ふと感じたこと。　ITシステム開発において。　いわゆる下請けとして働くリスクを考えてみると。　システム開発の基本や本質を理解していない元請けにマネジメントされる。　こういった点が一番大きいのかもしれません。　さらにいえば、わかっていない人であればあるほど。　簡単な仕事を複雑にする傾向があるため。　トラブルプロジェクトへと発展していく可能性も。　高くなっていくのかもしれません。　http://plaza.rakuten.co.jp/yellowfox/diary/200707210000/　さらにさらにいえば、下請けして働くリスクの中には。　下請けを抜け出すヒントが。　もしかしたら、隠されているのかもしれません。　http://plaza.rakuten.co.jp/yellowfox/diary/200712300000/　おわり

  2008年01月04日

• 復旧させたあとは監視が必要です

  　最近、ふと感じたこと。　本番稼動しているITシステムにおいて。　障害が発生したとき。　障害の原因を特定し。　復旧させたとしても。　対応策があまかった場合。　また同じような障害が発生する可能性。　結構高いものです。　そのため、システムを障害から復旧させたあとも。　当面の間は、同じような障害が起こらないかを監視する。　こういった行動が必要になるものです。　さらにいえば、人間というものは。　他人から厳しく叱責されたりすると。　それなりに反省するため。　一時的に言動が変わったりするものですが。　本来持っている性格そのものが変わるものではありません。　そのため、どのような仕事であろうとも。　人に起因する問題点は。　一時的に解決したように思えても。　いつ再発するかわからないため。　ITシステム以上に厳しい監視が。　もしかしたら、必要なのかもしれません。　おわり

  2007年12月29日

• 小さな点検が大きな障害を防いでくれるものです

  　最近、ふと感じたこと。　本番稼動しているITシステムの中には。　年が変わると。　これまで潜んでいた不具合が表面化し。　本番障害が発生すること。　結構あるものです。　逆にいえば、今年のうちに。　システムのあやしいところを点検しておけば。　未然に本番障害を防ぐことができるものですが。　「たぶん大丈夫やろ～！！」　このような根拠のないことをいって。　年明けに大騒ぎをしている。　こういった人が結構多いものなのかもしれません。　ついでにいえば、　「システムのどこを点検したらいいんですか？」　このようなことをいっている人に。　本番稼動しているシステムの面倒を見させていると。　これまた、本番障害。　引き起こしてくれるものです。　http://plaza.rakuten.co.jp/yellowfox/diary/200501060000/　おわり

  2007年12月28日

• この人、いらな～い！！

  　最近、ふと感じたこと。　ITシステム開発において。　プロジェクトの問題点を突き詰めていくと。　「この人がいるから、プロジェクトが前に進まない。」　このような結論に達すること。　もしかしたら、あるのかもしれません。　さらにいえば、過去に同じような問題点が見つかったとき。　早い段階で「問題点」を「解決」できなかったプロジェクトは。　ほぼ間違いなく。　トラブルプロジェクトへと発展したものです。　http://plaza.rakuten.co.jp/yellowfox/diary/200709020000/　http://plaza.rakuten.co.jp/yellowfox/diary/200604290000/　おわり

  2007年12月26日

• システムはビジネスを実現するための手段です

  　最近、ふと感じたこと。　いわゆるIT企業の中には。　ITシステムの開発遅れを理由に。　事業やサービスの終了を発表する企業もあるようですが。　終了した事業やサービスの内容を分析してみると。　しっかりとしたビジネスモデルが構築されていなかったため。　採算が取れずに終了したと思われるものも。　結構あるのかもしれません。　どのような事業であろうとも。　ビジネスモデル。　もう少し突っ込んでいえば、バリュードライバー（成長の源泉）。　こういったものがしっかりと構築されていなければ。　どれだけしっかりとしたITシステムが開発されていたとしても。　その事業を継続することはできないのかもしれません。　というのも、あくまでITシステムは。　事業を実現するための手段にすぎませんからね！！　おわり

  2007年12月25日

• まだまだおかしなサービスがはびこっているようです

  　つい最近。　大阪梅田で、ドトールコーヒーに入ったとき。　たまたま、となりにいた2人連れの方が。　なにやら話をしていました。　コーヒーを飲みながら、その2人の会話を聞くともなしに聞いていると。　営業と思われる一方の人が。　お客さんと思われるもう一方の人に。　自社商品の説明をしているようでした。　その商品の内容とは。　なんとなくしか覚えてはいませんが、要約すると。　1ヶ月あたり、52,500円で。　企業の人材採用のために。　1日1回定期的にメールを配信するという。　どう考えても費用対効果が合わないサービスでした。　で、ふと感じたこと。　自称ベンチャー企業の中には。　どう考えても「売れない」。　もしくは、「おかしい」としか思えないサービスを展開し。　ITやネットに対する知識のない人から、お金をぼったくっている。　このような企業が、まだまだたくさんあるようですが。　http://plaza.rakuten.co.jp/yellowfox/diary/200707060000/　いくつの企業が生き残っていけるかは、容易に想像できる一方で。　ある程度サービス内容の説明を聞けば。　そのサービスを展開している経営者自身に。　経営や事業に必要な知識を持ち合わせているのかどうかが。　もしかしたら、簡単にわかってしまうものなのかもしれません。　おわり

  2007年12月23日

• 経験はなにものにも代えがたい財産です

  　最近、ふと感じたこと。　ITシステム開発において。　たとえ規模の小さなシステムであろうとも。　何度も本番稼動させたてきた経験は。　この業界で仕事をしていく上で。　もしかしたら、なにものにも代えがたい大きな財産になるのかもしれません。　逆にいえば、一度も本番稼動させた経験がないまま。　年数だけを重ねても。　大した実力はついていないのかもしれません。　ついでにいえば、どのようなことであろうとも。　経験から学んだことを。　本やネットなどを通じて。　文字としてすべてを伝えることは。　もしかしたら、できないのかもしれません。　おわり

  2007年12月20日

全277件 (277件中 101-150件目)

< 1 2 3 4 5 6 >