Qooh0 @Qooh0 @nawoto あー、それはちょうど悩んでたとこです。 XP はプラクティス集、 Scrum はフレームワークといわれるのですが、どう違うのか?と。フレームワークは流れがあるとか、その辺なのかなぁとボンヤリ思っていたり…。私の中では、まだ、まとまってないです。あと、パタン。 2011-01-20 15:44:07
![バーチャルスクラム道 #1](https://cdn-ak-scissors.b.st-hatena.com/image/square/b462165dfb8159a0e92d772d2583ad4a396c5605/height=288;version=1;width=512/https%3A%2F%2Fs.togetter.com%2Fogp2%2Fb496bb58244cca1e065177e980f36b93-1200x630.png)
本ブログの記事に対して多くの皆さんからいただいた意見を総合すると、技術力のあるトッププログラマーにとって現状の日本のSI業界での仕事というのは、働き甲斐のない、魅力の少ない仕事として認識されているという残念な事実を思い知らされます。 オブジェクト指向の基本すらいまだにきちんと使いこなせない開発の現場 技術について勉強した知識をほとんど活用できないし評価もされない 無駄なドキュメント作成などに対する膨大な単純作業を強いられる いわゆる3K職場と言われるような過酷な労働と低い賃金 20年以上も前の仕事の進め方からあまり進歩が見られない 多重下請け構造によりユーザーに直接価値を提案するような仕事が難しい 多くの業務アプリケーション開発現場における体験を通して、以上のようなことが語られているということを考えれば、「業務アプリケーションのプログラマーは負け組だ」という意見が出てくることも当然のことか
ナレッジマネジメントシステムの導入を進めていく際にシステムの利用率が伸びない事がよくある。情報系のシステムの場合利用率が6割を超えれば十分だと思うのだが未だにシステムの価値を利用率で評価したがる人が多いのも事実で、利用率が低いとすぐに「システム利用率向上施策をうたなければ」ということになる。 利用率をあげようとする事自体は良いことだと思うのだが、この時に良く取られる「なぜシステムを使わないかユーザに聞いてみよう」という手法には注意が必要だ。そして使わない理由を聞くとたいていは、「使いにくい」と「欲しい情報がない」の2つの理由が1位と2位にくる。この結果を見て大抵の運営者は、システムの細かい機能修正とデータの大量登録作業に着手する。まずはデータを必ず登録する(あるいはブログを必ず書くやメッセージを発信する)ようにと通達を出すという流れだ。 こうしてユーザはいやいやながらデータ登録を始めその結
JR東日本の新幹線が一時運休した問題で、「システムの不具合が発生した」と誤解した運行担当の指令部門が所属する新幹線運行本部には、システムの開発者もいたことが関係者への取材でわかった。しかし連携できず「不具合ではない」と見抜けなかったため、1時間15分の全面運休を招いた。 JR東の発表によると、17日朝、東北新幹線の沿線で雪が降り、福島県内でポイントが切り替わらなくなる事故が相次いだ。新幹線運行本部(東京都)では同8時ごろから、指令部門の7人が、24本の列車ダイヤの変更を入力し始めた。 運行管理システム「COSMOS(コスモス)」では1分ごとにデータ修正が必要な箇所をチェックしており、上限の600件を超えると各列車の駅到着予定時刻を示す線がモニター上から消える仕組みになっていた。だが、これを知らされていなかった指令部門はシステムの不具合が起きたと考え、同8時23分に全線で停車を指示した。
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く