良いITエンジニア,ダメなITエンジニア

良いITエンジニア,ダメなITエンジニア
Tweet このエントリーをはてなブックマークに追加 良いITエンジニアとダメなITエンジニアの違いを考えると、技術的なスキルだけでなく、ソフトスキルや態度も大きな要素です。それぞれの特徴を挙げてみましょう。
良いITエンジニアの特徴
  1. 問題解決能力が高い
    複雑な問題を論理的に分析し、効率的な解決策を見つける力があります。
  2. 継続的な学習意欲
    技術は常に進化しています。良いエンジニアは新しい技術を学び、スキルアップを怠りません。
  3. チームワークが得意
    他のメンバーと協力し、情報共有を重視します。コミュニケーション能力が高いのもポイントです。
  4. 責任感が強い
    任された仕事に責任を持ち、結果に対してしっかり対応します。納期や品質にも気を配ります。
  5. 柔軟性 変化に対して柔軟に対応し、新しいツールやプロセスに迅速に適応できます。
  6. 顧客志向
    クライアントや最終ユーザーのニーズを理解し、それに応じたソリューションを提供します。
ダメなITエンジニアの特徴
  1. 問題を先延ばしにする
    小さな問題を放置し、後で大きな問題になった時に対処する態度が目立ちます。
  2. 学習を怠る
    新しい技術やトレンドに興味を示さず、過去の知識やスキルに頼り切ってしまう。
  3. 自己中心的
    チームワークを軽視し、自分のやり方や意見を押し通そうとする。
  4. 責任を回避する 失敗やミスが起きた時、他の人に責任を押し付けたり、自分のミスを認めない態度。
  5. コミュニケーション不足
    クライアントやチームとほとんど連絡を取らず、情報共有がうまくできない。
  6. 変化に対応できない
    新しい技術や方法に対して抵抗感が強く、柔軟に適応できない。

技術だけでなく、人間関係やプロジェクトの進め方にも注力することが、良いエンジニアであるための鍵と言えますね。

ただし、これらの特徴は全てのITエンジニアに当てはまるわけではありません。個人によって、またプロジェクトの状況によっても異なるため、一概に良いエンジニアとダメなエンジニアを区別することはできません。

良いITエンジニア,ダメなITエンジニア:図解

私もITエンジニア(情報処理技術者)として50年以上を経過しましたが、最近はマスコミでも取り上げられている、システムの不具合を考えさせられますが、システムの不具合は設計時点で発生しています。・・・さて本題ですが良いITエンジニア,ダメなITエンジニアの判断は、面接のように、ある程度の質問や一目見てすぐに判るというわけではないが、下図は思考過程をとらえてまとめたものです。
左側はダメなITエンジニアの思考過程、右側は良いITエンジニアの概念を表記したものです、この考え方は30年以上の前のもので、若い方に指導した時の資料をまとめたものですが、良いITエンジニアになる思考過程は変わらないと思っています。
システムを売り込みに来る営業マンなどの受け答えなどを参考にしてみると、良いITエンジニア,ダメなITエンジニアの理解できると思いますが、如何ですか?最低限のカタカナ語の使用は避けられないがカタカナ語を多用するITエンジニアは避けた方が良いです。

考える習慣に乏しいITエンジニアが陥りがちな思考過程
考える力を身に付けたITエンジニアによる理想的な思考の過程
「とにかく、この問題を解決しなくてはならない」
考える方向性
「納得性のある解決策を出すにどうしたらよいか?」

良いITエンジニア,ダメなITエンジニア

「SEが考えていることは常に正しい」

前項ではITエンジニアと記述したが、ここではSE(システムエンジニア:System Engineer)の考えを提示します。
*SEは顧客の要求から仕様を決定し、大まかな設計をするまでの情報システム開発における上流工程を担当します。その際、予算や人員、進捗管理などのマネジメント業務を行えるものとする。
「SEが考えていることは常に正しい」。という資料を紹介します
概要:この発言を聞いたのは20年半ほど前だが今でも記憶に残っている。 SE とはシステムズエンジニアを指し、情報システムの企画、設計、開発、運用にかかわるすべての人を指す。 企業の情報システム部門やシステム子会社にいるSE、メーカーやソフトハウスなどIT企業にいるSE、組織に 属さずコンサルタントなどをしているSE、すべて含む。 「SEが考えていることは常に正しい」とすると、「正しくないことを考えている人」がいるはずだ。 それは「ビジネス側の人たち」である。情報システムを利用する人たちと言い換えてもよい。経営者、事業 部門の長や部員、管理部門の長や部員、関連会社や取引先の経営者や社員、すべて含む。 SE が情報システムを企画、設計、開発、運用していこうとすると、ビジネス側の人たちと意見が衝突するこ とが往々にしてある。


システム開発技法 階層的手法内で紹介している資料

Google翻訳によるエドガー・W・ダイクストラ著『謙虚なプログラマー』をご覧ください。

上記資料は弊社の独立後、数社のシステム構築を行ってきたが、相通ずることがあるので紹介します。一読の価値はあります
しばらくおまちください・・・