やじゅ@アプリケーション・ラボ わんくま支局

目次

Blog 利用状況

ニュース

プロフィール

MSMVP

技術伝承の断絶が招く危機

IT業界は技術の変化が早いです、せっかく覚えた技術も陳腐化してしまうことも多々あります。ですが、ベーシックなところはほとんど変わらないですよね。

IT業界は他の業界と比べても、技術に関する書籍が多いことやグーグルなどの検索により情報が得やすい環境にあります。
それにより知識に関しては伝達することは出来ますが、一方、技能(スキル)について知識を駆使して作業を遂行する能力であり、伝達することが難しいところです。
実体験しないとなかなか覚えない、失敗してこそ覚えたりする。

現状、各個人の勘や経験に頼っていることが多いかと思います。その場合、「技術は盗め」となるわけですが、はたしてスピード
重視の世界でそんな悠長な事を言っている場合では無い・・・はずです。

会社内のコミュニケーションを円滑にして知識の蓄積と共有化する
システムを作り、全体のレベルを上げる体制を作るようにすることが
理想なのですが、現実は仕事に忙殺され、回りのことなどかまって
られないとこでしょうか、
それでも、伝えるための地道な努力を惜しんでなりません。GIVE5乗

勝手に添削 - 技術の盗み方
http://blog.livedoor.jp/dankogai/archives/50826413.html
設計時の見落とし-Google先生も教えてはくれない
http://blogs.wankuma.com/yaju/archive/2008/04/07/131967.aspx

本題:
日経SYSTEMSを定期購読しているのですが、2007/8号は
特集1「あなたにも出来る技術伝承 勘と経験の残し方」でした。
少し古い記事ですが会社にあれば読んでみて下さい。
http://www.nikkeibpm.co.jp/cs/mag/it/nos/index.html

もしその技術が伝わっていたら、プロジェクト遅延やコスト超過
システムの障害発生などの重大なトラブルの裏には、技術伝承の
失敗が隠されていることは少なくないはずです。

技術伝承の断絶が招く危機

■上流工程
・現状把握 → 問題の洗い出しに漏れが生じる
・要件定義 → ユーザーの要求が取り込めない
・外部設計 → 後工程で作業の手戻りが発生
・説明・交渉 → 費用負担を巡りユーザーとの関係が悪化

■実装/運用
・技術問題の解決 → 解決に時間とコストがかかる
・プログラム実装 → 性能要求を満たせず。メンテナンス性が低下
・テスト → テストが不十分になる。カットオーバー後に発生
・障害の切り分け → 復旧が遅延。場合によっては障害が再発

■プロマネ
・スケジュール管理 → プロジェクト完了の見通しが立たなくなる
・リスク管理 → 作業が遅延。予期しないコストが発生
・品質管理 → 後工程での修正となりコストが膨らむ
・危険度の推察 → 問題噴出でプロジェクトが制御不可能に

投稿日時 : 2008年5月12日 1:02

コメントを追加

# re: 技術伝承の断絶が招く危機 2008/05/12 9:46 シャノン

業界全体の話ならともかくとして、会社内に限ると、そもそも最初から伝承するような技術を持っていないところも多いのでは?

# re: 技術伝承の断絶が招く危機 2008/05/12 12:45 やじゅ

伝承する技術っていっても大それたものでなくてもよくて

こういう時にこういう失敗をしたから、次はこうするようにしましょう
っていう失敗と改善点を社内で蓄積すれば、次にあった場合は
失敗しなくなるよね。それだけでもいいと思う。

# re: 技術伝承の断絶が招く危機 2008/05/12 15:07 シャノン

一体、何が失敗だったのか?
そもそも、我々は何かを失敗したのか?
それさえ明確でない現場がいくつもあると思うのですよ。
あるいは、反省点は山積みだけれど、改善策を模索するよりも納期に間に合わせるほうが先だ、とか。

そこまで自浄作用が期待できないのであれば、外部からテコ入れするという手もアリかと思うわけです(「外部からテコ入れしよう」という決断を下すこと自体が最初の自浄かもしれず、それ故に実現困難だという問題はあるかもしれません)。
http://blogs.wankuma.com/shannon/archive/2008/05/11/137233.aspx

タイトル
名前
URL
コメント