====== 10年後も通用するスキル ====== 日経SYSTEMSを定期購読しているのですが、2009/2号は特集１「10年後も通用するスキル」でした。 ===== 10年後も変わらない４つのスキル ===== * 技術を分解するスキル * 技術を比較するスキル * 事実を把握するスキル * リスクを察知するスキル ===== 技術 ===== * 技術を分解するスキル * 技術を比較するスキル ==== ①新しい技術の評価 ==== === a.本質を見極めるとき === 目的、コンセプト、メカニズムの３つの観点で分解する。\\ 対象の技術をよく似た技術と比較するのがポイントで、共通点や相違点が明確になり、新しい技術の本質が見えてくる。 === b.使いどころを見極めるとき === 「生産性」や「品質」という観点に分解して使いどころを評価する。 ==== ②不具合の究明・解決 ==== === a.バグを突き止めるとき === 処理を細かい単位に分解、似通った処理の別のプログラムと比較する。 === b.不具合を解決するとき === 過去の開発経験と比較する。\\ 一本通した開発を経験しておく。\\ さまざまな技術の関係を学ぶとシステム全体を見る目が養える。\\ データ量によるリソース数、性能低下の前兆での現象の予兆が可能。 ===== システム構築 ===== * 事実を把握するスキル * リスクを察知するスキル ==== プロジェクト・マネジメント ==== === a.進捗を確認するとき === 「きっとこうだ、リスクもこの程度だろう」という思い込みを捨てる。\\ メンバーからの報告を必ず文章にまとめて報告させ、事実を把握する。\\ その報告内容について質問を繰り返して進捗遅れがないか、リスクを察知する。\\ === b.予定外の出来事に対応するとき === プロジェクトは進捗を確認するだけでは無事に完遂しない、予定外の出来事にうまく対応することも大切、その事前リスクの察知で有効なのが、過去の経験から、自分の基準を作っておくことが必要。\\ プロジェクトの失敗はその場かぎりとしないで、再発させないために自分の基準を多く持ち、今後に活かせるようにしてくことが大切である。 ==== 業務の分析・設計 ==== === a.業務を詳しく分析するとき === 業務を詳しく分析する際に、把握すべきは「システム化の対象業務」という事実であり、察知すべきは「仕様漏れ」というリスクである。\\ E-R図や業務フロー図を作成して情報やプロセスのつながりに注目し、そのつながりをユーザーに確認して事実を把握し、リスクを察知する。 ユーザーから聞き取った内容を論理的な整合性があるかどうかという視点で整理すること。\\ ユーザーは帳票や画面にこのデータを出力してほしい要望は出すことが出来ても、そのデータがそもそも入力されているかといった整合性までは気が回らない。 === b.必要な機能を設計するとき === ITエンジニアはとにかく必要最低限の技能さえ設計すればよいと考え勝ちだが、ITエンジニアの立場を超えて柔軟に発想し、実務に役立つ機能を設計することが大切である、そのためには、情報の見方や使い勝手の観点から誰がどんな画面を使うのかという事実を把握すること。 ===== 日経SYSTEMS　実践セミナー ===== 日経SYSTEMS実践セミナー「10年後も通用するスキル」\\ 2009年2月18日（水）10時30分～16時30分　昼食付\\ 青山ダイヤモンドホール（東京・表参道駅直結）1階 ダイヤモンドルーム\\ http://coin.nikkeibp.co.jp/coin/sys/semi/0902/\\ 日経SYSTEMS　実践セミナーに行ってきました。\\ 初めて自己負担によるそれなりの金額を払って(私は日経SYSTEMSの読者割引で、10,000円)かつ有給を使って、セミナーなるものに行ってきました。 内容はあえて書くのは控えるとして、それなりに楽しめました。\\ こういうテーマだとコミュニュケーションスキルうんぬんの話になってしまうのは仕方ないかな、ってことで人間性につきる気がします。\\ 心理学の勉強するのもいいのかも\\ そういえば、帰りの新幹線の中で熟睡してしまって、目が覚めたときに時計を見ると発車から１時間以上過ぎていて、乗り越してしまったかと到着駅のアナウンスがあるまで、もーどきどきもんでした。\\ まー幸いというかジャストタイミングで「静岡」のアナウンスが聞こえたときは、ほっとしました。\\ [[https://r25.jp/life/90006237/|電車の居眠りが至福なのはいったいどうしてなの?]]