日経SYSTEMSを定期購読しているのですが、２００９/２号は
特集１「１０年後も通用するスキル」でした。
会社にあれば読んでみて下さい。
http://www.nikkeibpm.co.jp/cs/mag/it/nos/index.html
日経SYSTEM実践セミナー「１０年後も通用するスキル」もあります。
2009年2月18日（水）10時30分～16時30分 昼食付
青山ダイヤモンドホール（東京・表参道駅直結）1階 ダイヤモンドルーム
http://coin.nikkeibp.co.jp/coin/sys/semi/0902/
１０年後も変わらない４つのスキル
技術 ・技術を分解するスキル ・技術を比較するスキル
システム構築 ・事実を把握するスキル ・リスクを察知するスキル
■技術
・技術を分解するスキル
・技術を比較するスキル
①新しい技術の評価
a.本質を見極めるとき
目的、コンセプト、メカニズムの３つの観点で分解する
対象の技術をよく似た技術と比較するのがポイントで、
共通点や相違点が明確になり、新しい技術の本質が見えてくる。
b.使いどころを見極めるとき
「生産性」や「品質」という観点に分解して使いどころを評価する。
②不具合の究明・解決
a.バグを突き止めるとき
処理を細かい単位に分解、
似通った処理の別のプログラムと比較する。
b.不具合を解決するとき
過去の開発経験と比較する。
一本通した開発を経験しておく
さまざまな技術の関係を学ぶとシステム全体を見る目が養える
データ量によるリソース数、性能低下の前兆での現象の予兆が可能。
■システム構築
・事実を把握するスキル
・リスクを察知するスキル
プロジェクト・マネジメント
a.進捗を確認するとき
「きっとこうだ、リスクもこの程度だろう」という思い込みを捨てる。
メンバーからの報告を必ず文章にまとめて報告させ、事実を把握する。
その報告内容について質問を繰り返して進捗遅れがないか、リスクを察知する。
b.予定外の出来事に対応するとき
プロジェクトは進捗を確認するだけでは無事に完遂しない、予定外の出来事に
うまく対応することも大切、その事前リスクの察知で有効なのが、
過去の経験から、自分の基準を作っておくことが必要。
プロジェクトの失敗はその場かぎりとしないで、再発させないために自分の基準を多く持ち、今後に活かせるようにしてくことが大切である。
業務の分析・設計
a.業務を詳しく分析するとき
業務を詳しく分析する際に、把握すべきは「システム化の対象業務」という事実であり、察知すべきは「仕様漏れ」というリスクである。
E-R図や業務フロー図を作成して情報やプロセスのつながりに注目し、
そのつながりをユーザーに確認して事実を把握し、リスクを察知する。
ユーザーから聞き取った内容を論理的な整合性があるかどうかという視点で整理
すること。
ユーザーは帳票や画面にこのデータを出力してほしい要望は出すことが出来ても、
そのデータがそもそも入力されているかといった整合性までは気が回らない。
b.必要な機能を設計するとき
ITエンジニアはとにかく必要最低限の技能さえ設計すればよいと考え勝ちだが、ITエンジニアの立場を超えて柔軟に発想し、実務に役立つ機能を設計することが大切である、そのためには、情報の見方や使い勝手の観点から誰がどんな画面を使うのかという事実を把握すること。