- - PR -
２００７年問題
| 投稿者 | 投稿内容 | ||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
投稿日時: 2004-03-25 15:16
はにまるです。
るぱんさんへ＞ どうやら上司の不満に対する 途中までの行動パターンは一緒のようですね。 
煙たがれるのは良く解ります。 「てめ〜このやろ、管理者が煙たがってんじゃねー！」と言いたい事もしばしば 話を聞くと、ある性質をもって私とるぱんさんは、その結果の行動パターンが違う様です。 その性質とは、私が我慢を知らない事です。 「我慢して待つ位なら、無駄な努力でも行動する」が信念（？）です。 その結果 「ちっさい問題を潰しても、しゃ〜ない」なら、 俺が管理者になって根本から叩き潰してやる！と言う事で、 「プロジェクトマネージメント」、「経営学」を勉強し始めました。 正直、この考えと行動が正しいかどうか解りませんが、 今の所、不満はかなり減少しました。その反面、悩みは増えています．．．
＞「してはいけない手抜き」も「先人の知恵」としていいものですかねぇ？ ＞大企業はどうかわかりませんが、中小の末端企業の現場の最前線なんて ＞そう言うのが多いんですよね。 「先人の知恵」とは意識しないと非常に見つけ難いものです。 もしかすると本当は、現在るぱんさんが認識している以上の問題が存在し それを上司や先輩が防いでいるかもしれません。 いや、間違い無くその恩恵は受けている筈です。 １００ある問題の内、１０個や２０個位漏れていても、いいじゃないですか。 先人の方々は既に８０もの問題を解決して来ているのです。 そして例え、るぱんさんが残りの問題を全て解決したと思っても、 必ず、その対応被害を誰かが受けます。 これは１００％メリットのみ「解決手段」が存在し無い為です。 今回のスレッドを元にして考えれば、 私達が注意すべき物は、問題発生した１０件、２０件の方では無く、 私達が知らない間に解決された８０件の問題とその手段と思います。 もしかすると、８０件の問題を知った時 非難していた上司に足を向けて寝る事が、出来無くなるかもしれません。 | ||||||||||||||||
|
投稿日時: 2004-03-25 16:10
さぁ、どうでしょう？開発側は、個人個人ではなく、もっと大きなところでされているように思います。 と、私が思っているのは、開発手法の変遷です。最初、マシン語に代表される、わかりにくいものであったのが、BASICをはじめとする高級言語になり、敷居が下がりました。そして、スパゲッティプログラムに代表される無秩序なものに、構造化プログラミングという、一定の秩序を与える動きが出てきました。そして、オブジェクト指向やコンポーネント指向というのは、作り上げたものの再利用が主目的ではないでしょうか。
まぁ、これはないでしょうね  。むしろ、はゆるさんの
の方でしょう。
第４回「にわか管理者奮闘記」よろしく、エライ人に音頭をとってもらわないとなかなか難しいのですが、エライ人は“今”を見て“将来”は見ていない場合が多いんですよね。または、変動しうる将来に見込まれる利益の為に確定的な今の投資をしない、とか。ある程度コストがかかるのは仕方がないのですが、そのコストを払いたがらない。未来にどれくらいの利益が得られるか説明されても、その未来が本当にやってくるのか懐疑的。 私が今いるところは、一応開発者による「勉強会」に対して補助があるのですが、何人くらい受講予定があって、どれくらいの期間行えるかというハードルがある。それを超えられない．．． | ||||||||||||||||
|
投稿日時: 2004-03-25 16:26
はにまるです。
ふと思い出した。情報源は忘れましたが... 経営陣は任期中の利益額で評価される。 投資をしても、その投資が任期中で効果が出なければ意味が無く、 また、任期の最初の方では何をすべきか模索する期間であり、 投資の決断をする必要性を感じた時には既に時間切れとなっている。 ん．．．同じジレンマだ。 誰でも一緒って事？ | ||||||||||||||||
|
投稿日時: 2004-03-25 16:30
NAL-6295です。 同意です。 というか、僕が新人の頃に全く同じような事を先輩方に言葉で言われたり、実践されているのを見たりすることで教えて貰いました。 #おかげで今の僕があると思えるくらいありがたい事だと感じてます。 そういう経験からすると技術的ではない仕事をする時の「意識」みたいなモノを後進に伝えるには「言葉」よりも「実践」している姿を見せるという事が大事なのかな。 なんて思ったりします。 仕事をする時の意識なんて、教えてどうにかなるもんでは無いかなと。 こうであって欲しい。 こうあるべきだ。 と思う姿にまず自分がなる事から周りに波及していくのかなと思ったりします。 #なんて書くのは簡単なのにね・・・。 | ||||||||||||||||
|
投稿日時: 2004-03-25 18:14
２００７年問題の本質は、 ２００７年近辺で定年を迎える元プログラマが当時に作成(２００６年まで）した プログラムの内、ブラックボックスとして今も動いているＰＧが外部要因の変化 により、突然システムが動かなくなる事への社会的な影響度合いの事だと思います。 従って、今後新たに作成するシステムが若いプログラマへの伝承が悪くて、 動かなくなるなんて事ではないと思います。 （全くないとはいいませんが２００７年問題の本質ではないと思います） その部分ではよほど今の若い人のほうが勝っている部分が沢山あると思いますし、 その部分の検証は開発段階におけるテストで充分に問題解決可能と思われます。 ここでいう外部要因の変化とは、 例えば２０００年問題の時のように入力の桁数が増えた時等です。(仕様変更も含む） この時に、ブラックボックス内への影響と出力の影響度合いの見極めが出来るかです。 今動いているプログラムのブラックボックス内の何処をどう対処すべきか 今のプログラマ（ＳＥを含む）には迅速な対処が難しいという事です。 （その部分の伝承は・・・・・・・ドキュメント？ ありますか？ あってもすぐ理解できますか？） 問題は、ブラックボックスとして動いているプログラムがＯＳを含め ミドルウエア、通信パッケージ、業務パッケージ、業務システムとして どれだけ今の世の中で動いているのかという事です。 彼らが現役の内は、問題が発生したら彼らの事だから、 徹夜してでも何とかするでしょう。 でも、もし彼らが居なくなったら、・・・・・・・恐ろしい・・・・・。 元々はCSKの有賀貞一副社長が旧来の基幹系のシステムで、 都銀の口座振替、製造業の部品表等が ブラックボックス化されているのを心配されたようです。 「深海」のメンテナンスと同じで、ブラックボックスのメンテナンスは、 その人しか出来ない？ 解決策は、仕様変更をあきらめて、早め新規に開発しなおすほうが・・・・・・。 でも、その人達が引退する頃には再び・・・・・・ですか。 ここまでくると、やっと皆様方の議論になりますね。 最近のパソコン系のブラックボックスの構造（ＥＪＢや関数を含む）はさらにしまつが悪いと思います。 | ||||||||||||||||
|
投稿日時: 2004-03-29 13:35
ん〜、どうなんでしょう？これは“ライブラリ”がブラックボックス化しているということでしょうか？ 私は、“自社開発以外の部分”については、ブラックボックスでもかまわないと思います。開発元に問い合わせればよいのですから。もっとも、開発元がサポートを他社に引き継げないような形で消滅した場合は、困りますけど。 | ||||||||||||||||
|
投稿日時: 2004-03-29 13:41
脱線的所感です。
そっか、それで製品のサポート期間は期限付きが当り前なんですね。 不便やな〜と思っていましたが。 確かに有料＆無期限としたら、サポート対象製品の知識保有者を ベンダーとして保持する必要がありますもんね。 つまらん所で納得。
[ メッセージ編集済み 編集者: はにまる 編集日時 2004-03-30 12:05 ] | ||||||||||||||||
|
投稿日時: 2004-03-29 13:45
そ、それは「バージョンアップに金を払ってね」という、メーカー側の販売戦略では
| ||||||||||||||||
スキルアップ／キャリアアップ（JOB@IT）
Copyright © ITmedia, Inc. All Rights Reserved.
著作権はアイティメディア株式会社またはその記事の筆者に属します。
当サイトに掲載されている記事や画像などの無断転載を禁止します。
著作権はアイティメディア株式会社またはその記事の筆者に属します。
当サイトに掲載されている記事や画像などの無断転載を禁止します。