手順書作成のジレンマ。
今のプロジェクトはやたらと手順書が氾濫しています。手順書を読めば１～１０まですべて開発できるようになっています。異なる人が製造した成果物はほとんど同じで誰が作成したかは全くわかりません。
それ自体は良いことなのですが、あまりに手順書がそろいすぎているために、自分で考えて解決しようとする人がほとんどいません。
手順書も理解して作業すれば大きな効果を生みますが、理解せず従っていると必ずとんでもないミスをしでかしてしまいます。
「手順に従うのでなく、手順を従わせる」
をこころがけたいです。
-
-
チェックシートのチェックシート。
今のプロジェクトはあまりに変更が多く、チェックシートを利用して抜けを少なくしようとしている。例えば、
SAフェーズチェックシート。
UIフェーズチェックシート。
SSフェーズチェックシート。
PGフェーズチェックシート。
PTチェックシート。
ITaチェックシート。
ITbチェックシート。
提出物管理チェックシート。
２次修正チェックシート（チーム内）。
２次修正チェックシート（領域内）。
UI変更管理チェックシート。
SS変更管理チェックシート。
PG変更管理チェックシート。
進捗管理チェックシート。
などなど他にも細かいものはまだありますが、チェックシートへチェックしたかをチェックするシートまであったり、ちょっと何かが狂っています。 -
Ｋ－１ VS. ボクシング
今日Ｋ－１主催でＫ－１ VS. ボクシングの３対戦が開催された。
結果は３－０でＫ－１の勝利。試合内容もほとんど圧倒的なＫ－１の勝利でした。
やっぱりＫ－１は強い。とか、ボクシングの選手は蹴りになれていないので不利。とか色々な感じかたがあると思うが、私は全然別のことを考えていた。
ボクシング選手はみな一度は頂点をつかんだ選手ばかり、現役をとうに退き、どういう因果かＫ－１に出場することになった。お金かもしれないし、ボクシングの意地かもしれない。そんなことはどうでもいいが、おそらくＫ－１という形態を甘く見ていたに違いない。
人間色々な環境の中で高みに到達すると、なぜかその他の世界を小さく見てしまうことがある。おそらく頭の中のイメージでは自分のプラス面のみイメージしてしまう傾向がある。
このことはＩＴ業界にも言えることである。今ＣＯＢＯＬなどのレガシーな技術から、新しい技術への移行の為に環境を変えていく人が多く、同じような状況に置かれる機会が多いように思う。
自分もそのような経験をする日はそう遠くはないはず。
システム開発に必要な本質的な技術。異業界、異業種。を意識したいと思う。 -
思い出の場所。
昨日思い出の本町ぼちぼち（立ち飲みや）へ行ってきました。ひさいぶりにそこのおばちゃんに会えるかと思ったのですが、やめていませんでした。なんかこぎれいに、串もおしゃれっぽくなっていましたが、昔の思い出の場所に行った自分たちには非常にさびしい思いだけがのこりました。
最近年をとったのかそのような思いをすることがたまにあります。 -
「既存COBOL資産をオープンシステムに生かす」
というセミナーへ行ってきました。会社を休み、9000円も出した割には全然でした。
こんなセミナーでお金を取るなんて日経BPがやることなのでしょうか？9000円には欲しかった本がついてるのですが、ついてなければ相当クレームがつくのではないでしょうか。 -
そろそろ露が近づき、天気予報はいつも雨ですがほとんど降りません。最近の天気予報の的中率は２０％くらいではないでしょうか・・・。
Recent Comments