タイトルでわかる通り、ソフトウェア開発現場において、さまざまなタイプの人がいますが、
伸びる人、伸びない人は、水と油ぐらいパッキリと別れます。
そりゃあ多くの人が、「伸びる人」になりたいと思ってソフトウェアエンジニアという職に就いたんだと思うんですが、
現実は「伸びない人」の方が圧倒的に多いのが現実です。
もうそうなってしまったら、自分で何をどうすればいいか分からないというケースも多いはず。
そんな人に手を差し伸べて、本音で傷口をえぐってくれる、良い書籍です。
ずっと以前に古本で買っていたのを、kindleに自炊データを入れて読んだのですが、第二版がでていたので、こちらも読んでみたいと思いましたが、第一版を読んだレビューを今回は書いておきたいと思います。
レビュー
★★★★☆企業の開発コンサルティングなどをやる時に、エンジニア個別の評価をする指標が明確に書かれていてかなり参考になりました。 いつも自分が思っていたり、エンジニアと話している内容が言語化されていて、改めてソフトウェアエンジニアとは・・・の答えが書かれていた点が非常に良かったですね。
この書籍の学びポイント
伸びる人と伸びない人の分かれ目
後天的な考え方で決まります。 「自分には才能がないから」「自分には向いていないから」と諦めてしまう技術者は、誤っている。 考え方を少し変えるだけで、伸びる技術者になっていった例はたくさんある。 伸びる人にするかしないかは、自分の考え方一つである。ソフトウェア開発はクリエイティブである
不満やストレスはあれど、「ソフトウェア開発は知的労働とは程遠い。」と考える人は伸びない人。 同じ状況にありながら、ストレスを感じない人の考え方は、自分でしっかりと思考して、工夫をこなす事が、楽しみに感じる人が伸びる人。技術者の大半は「オタク」と呼ばれる
多くの技術者がコミュニケーションに問題を抱えており、「技術力はあるんだけど・・・」と少し物足りなさを他人に与えがちである。 コミュ障なエンジニアは、開発は、他人のために行なっている意識が薄く、ユーザーを意識できていない事が多いらしい。伸びる人、伸びない人のチェックリスト
わからないと言えないエンジニア
「わかりません」というには勇気がいる事が多いですが、プライドが高くて、自分がわからないのに、「分からない」と言えないエンジニアは、伸びないエンジニアです。 分からない = 悪い事 という、意味のわからない評価基準を持っているのだそうです。 「できない人と思われたくない」という思考や「背伸びをする」思考が強いため、分かったことにしてしまい、 結果的に弊害が自分に跳ね返って来てしまいます。説明する機会を避ける人
自分が調べたことや、作ったものを人前で発表する機会をみすみす逃げてしまう人は、伸びません。 「自分はプレゼンが下手だから」とか「人前で話すのが苦手だから」 こんなセリフは、何一つ救われません。 プレゼンテーションは最大のコミュニケーション能力が求められるため、ここから逃げている人は永遠に伸びない人から逃れられません。伸びない人は銀の弾丸を探し求める
「仕事で自分が作っているシステムは、誰の何のためのシステムか？」という問いに対しての答えをモテていないエンジニアは「解決策偏重」（かいけつさくへんちょう）の傾向があるようです。 このタイプは、次々に現れる技術に対して興味を持ち、自分で調べているため、一見優れた研究者に見えますが、 一つ一つの技術に対して、答えを持てていないため、単なる興味本位だけで動いている薄っぺらい人の場合が多いようです。 さらにこのタイプは、「銀の弾丸」を信じていて「これがあれば全て解決」という方法のみを求めてしまうため、深いエンジニアになりえる可能性が極めて低くなってしまうようです。 銀の弾丸なんて、世の中に存在しないと言いはるエンジニアの方が伸びる可能性があるとのことですね。伸びる人は「素直な人」
素直にひたすら努力をする人が、確実に伸びる人なのだそうです。 この対局にあるタイプが「実際にやる前から欠点を探し出して批判する人」や「本を読むだけで技術が身につけられると考えている人」です。 何かに対してカッコ悪いという印象を持っているプライドこそ、伸びることを阻害している要素でもあるようです。優れた技術者は抽象概念を持っている
システム開発をしてきたエンジニアに、次の質問をします。 「システム開発で起きたトラブルにはどんなものがありますか？」 「そのトラブルを起こした根本原因は何ですか？」 これに対して、 「システムによって違う」 と答えるエンジニアは伸びない人の可能性が高いです。 抽象概念が身についていないため、端的に答える事ができないという視点です。 伸びるタイプのエンジニアは、こまかな１つ１つのトラブルに対してそれぞれ話をします。優れた技術者に共通する３つのステップ
仕事を３段階にわけて取り掛かる良質なステップです。 ステップ1 : 目的は何か？ 1. 何のために行うのか？ 2. 何の問題、リスクに取り組むのか？ ステップ2 : 作るものは何か？ 1. 何を作るのか？ 2. 何に使うのか？ 3. 読み手は誰か？ 4. いつ必要なのか？ ステップ3 : どうやって作るのか？ 1. 技術は何を選択するのか？ 2. 方法論は何を選択するのか？ 3. 影響範囲はどこまでか？（利点、欠点、トレードオフなど） ステップ4 : 課題は何か？日々の習慣
ちょっとした習慣の違いが、伸びる人を特徴づけています。 それは「継続的な読書」と「好奇心」です。 たまに読むのではなく、毎日（定期的に）確実に本を読む習慣を持つ人は、確実になんでも伸びる人のようですね。 本を読んだ先にどう考えるか、自分のその先の何に繋げるかは、その人次第でもありますけどね。 また、いろいろなことに興味を持つことは、自己成長に大きく必要な要素です。 そもそも好奇心がなくて成長をする人は世の中には1人もいません。美的センス
「美しいものはシンプルである」 ソフトウェアの芸術性に対する感覚を「美的センス」と呼びます。 ソフトウェアの芸術性は、ソフトウェアの構造に現れます。 それはシンプルであり、各要素が独立した責務を持ち、要素同士の連携が疎であることなのだそうです。教えてもらうだけでは身につかない
実際にやらないとどんな技術も身につきません。 聞いただけ、読んだだけで、身についたと錯覚してしまうエンジニアは伸びません。 「目標達成」をするために行動をすると、自分が想像していなかった不思議な事が起き始めます。 行動をする人としない人の差は、この不思議体験をした経験の多さにも比例するのかもしれませんね。幸せになれる人チェックリスト
減点主義の技術者
プロジェクトが計画通りに進行しない時に、スケジュール遅れを悪いことと考えるエンジニアがいます。 会社でのロンチスケジュールが決められている場合など、その思考になる傾向が高いです。 また、ソフトウェアに何かしら不具合が発見された場合など、問題を隠そうとしてしまう人もたまにいます。 このタイプの技術者は、原点主義の価値観を植え付けられている可能性があります。 しかし、プロジェクトは生きているため、こうした減点主義の思考ではうまく進行できないでしょう。 確かに問題に対して怒られるとか、怒鳴られるみたいな組織も少なくないため、こういう思考になってしまいがちな事は往々にしてあります。 でも、その先に損をするのは誰かを考えると、この思考の愚かさは明確ですよね。使えないエンジニアをどうするべきか？
1. 使わない 2. 誰にでもできる仕事を与える 3. 特別プログラムで育成する。これは、新人社員に対しての処遇ではなく、上司や中間管理職に対しての会社の対応例です。 エンジニアは、ある一定年齢になったら、マネジメント職につくことを余儀なくされます。 これを嫌がって、スペシャリストで居続けたいと考えるエンジニアがほとんどのようですが、 年相応に、リーダーシップスキルを持たないと、組織の序列が壊れてしまいます。 上司も今や、育てる技術者として見ることになるし、使えない上司は切り捨てられる時代なんですね。
0 件のコメント:
コメントを投稿