Back To HOME

CAREER SKILLSという本をご存じでしょうか？ これはSOFT SKILLSというベストセラー本を執筆したジョン・ソンメズ著作のキャリアガイドです。 そしてなんとこの本、650ページ以上もある鈍器です。

私はこの本を凶器として手に取ったのではなく、伸び悩むエンジニア人生を打開したいという思いで手に取りました。というのもエンジニアとしてキャリアをスタートして４年。仕事には慣れプロジェクトをリードするポジションにも就きました。しかし、いまだに設計の考慮もれを連発し、レビューではバグをスルーしてしまう毎日。このまま何も手を打たなければうだつの上がらないエンジニアになってしまうという危機感がありました。

そこで そもそも自分はどんなエンジニアになりたかったのか？ と考えたとき、漠然としたイメージしか抱けていないことに気づきました。目標が漠然としていると日々をどのように送るべきかも見えてきません。そんなときCAREER SKILLSを見つけて目次を読んだとき、まさに今の自分が求めていたものだと思いました。

実際読み終わった今、心底読んでよかったと思います。自分と同じような悩みを抱えているエンジニアにも是非読んで欲しいと思っています。

ただし、最初に書いた通りこの本、650ページもある！ 読書ペースが遅い自分は読破に１か月かかりました。

だから他人にはとても奨め辛い。時間に追われる現代人が気楽に読もうと思えるもんじゃないと思います。なので、自分がこの本を読んで付けた読書メモを共有しようと思います。 このメモを読んで読破した気持ちになるも良し、興味が出て買ってみるのも良しです。 ただし自分なりに要約してメモしている部分もあるので注意してください。

ソフトウェア開発はどんな仕事か

• 手作業を自動化すること
• 作業を自動化するためには、それを手作業でするためにはどうすればいいか知っていなければならない

この部分は自分が最近読んだエンジニアが事業で勝つための「概念整理」のスキルについてーー事業開発の現場で学んだ「技術と事業をつなぐ」思考法という記事の

日本語で説明できないことを、プログラムで書けるわけがない

という主張と通ずる部分があり刺さりました。

学習の仕方

• 実践あるのみ
• とにかく手を動かす

プログラミング言語の習得方法

• 書籍だけでなくネットの記事やオンライン講座など幅広く学ぶ
• 既存のコードを見つけてきて各行が理解できるまで熟読する
• 小さなプロジェクトのアイデアを選び、アプリにしてみる

自分が作って学ぶタイプの人間だったので、自分がやってきた学習法は間違ってなかったんだと自信が持てました。

履歴書の書き方

• プロに依頼する
  • 紹介してもらう
  • IT に精通した履歴書ライターを探す
• あなたがどういう人で会社にどんな価値を与えてくれるか、手っ取り早く効果的に伝える
  • 短く簡潔で、できる限り専門的に書かれていて、あなたがキャリアのなかで積み重ねてきた最も重要な達成を強調するものを書く
• あなたのスキルと専門は何か、過去にその力を使ってどんな大きな成果を生み出したか、あなたが就こうとしているポストでその力がどのように活かされるかを書く
• ユニークにする
  • 履歴書で大切なのは目立つこと
  • ただし型破りにすることで履歴書の読みやすさやコミュニケーションの要素を排除してはいけない

面接

• ググってフロントエンドエンジニアの面接質問集的なのには答えられようにしておく
• 人柄に関しての質問は少なくとも以下には答えられるようにしておく
  • ●あなたの最大の強みは何ですか？ ●あなたの最大の弱点は何ですか？ ●5年後の自分はどうなっていると思いますか？ ●仕事で出会った難問や摩擦はどんなもので、それにどのように対処しましたか？ ●この会社で働きたい/このポストに就きたいと思ったのはなぜですか？ ●あなた自身のことについて少し話していただけますか？ ●なぜ、今の仕事を辞めようと思っているのですか？
  • マイナス面の詳細をさらけ出させすぎずに、できる限り正直に、ポジティブにまとめる。
  • 誰についても批判しないようにする
  • 自分の弱みについては馬鹿正直に答えるのではなく、○○のように工夫して補っている、のようにポジティブに言い換える
  • ほとんどの面接官は結局自分の好みの人を採用する
    • 面接以外もみられているかも。ネットの活動で良い印象を与えられると＋
    • 究極的には面接前から面接官と仲良くなれてると最高
    • きっちりとした服装をしよう
    • わからないことはわからないと言い、調べておくと言う
    • 言い訳しない
      • 面接官に攻撃されてると感じても逆らわない。自分の能力に自信を持っているからこそ馬鹿にされてもひるまないストイックな姿勢を見せる
    • 練習、練習、練習あるのみ

交渉

• 時給で給与を考える
  • 給与が高くても働く日数が多ければ意味がない
• 昇給で給与を上げるより初任給で給与を上げるほうが圧倒的に得
• できれば企業の給与テーブルの情報を得てどこまで交渉できるかの感覚を掴んでおく
• 有利な立場で交渉する
  • 複数の企業から内定を得ている
  • 紹介者がいる
  • ブログを更新している
  • 社会的評価を高くする
• 先に数字を言ったほうが負ける
  • 自分から今の年収、希望年収を言わない
  • 聞かれたら機密なので言えないと言う
• カウンターオファーを恐れるな
  • カウンターオファーをしても内定取り消しとなることはまずない
    • 低リスク高リターン
  • 自分が妥当だと思う年収よりずっと大きな数字をふっかけ、少しずつ下げていく
• 時間の圧力に抗う
  • ３日以内に内定承諾を決めろと言われたら延ばしてくださいと言う
  • 断られたらその日のうちに非常に高いカウンターオファーをする→時間が稼げる
  • タイムリミットによって急かされた気分で慌てて契約しないようにする
• 複数の会社からオファーがある状況を作る
  • 注意点として〇〇社からは750万のオファーがある、といったことを言ってはいけない。他人に脅しかけられて気分が良くなる人はいない

交渉をするのは苦手なのですが合理的に考えればしない理由はないなぁ、という気になれました。

会社の辞め方

• 新しいチャレンジができず、人間としてもスキルも成長の見込みがない場合は辞め時
• 有害な人間と仕事しなければならないときもやめたほうがいい
• 2週間前に退職勧告すれば十分
  • やめる人間に仕事は振りにくい。無駄な時間を会社で過ごすことになる
• 退職面接で他人を傷つけることはしない
  • 本当の事を言いたい気持ちを堪える
  • 世界は狭い、他人の土地悪口を言う人間に好印象を持つものはいない
  • 百害あって一利なし

この辺りは賛否両論ある主張な気はしました。ただ辞めるときに後を濁さないのは必ず意識すべきことだと思いました。

職種

• フルスタックプログラマーになれることは何かと役に立つ
  • ただし1つ2つの分野においては専門とできるスキルを身に着けておく

自分はフロントのスキルしかもっていないのでもう少し手を広げていきたいところ。幅広くスキルを付けて、でも誰にも負けない専門分野を１つだけでも会得したいものです。

品質保証

• 実際にどのようなテストをしているか知ることがプログラマーとして抜きん出たキャリアを築くのに重要
• ソフトウェアのテストで重視されるのは、ソフトウェアを使う顧客がマイナスの影響を受けるリスクを減らすこと
• ソフトウェア開発者は他の誰よりも品質のことを意識しなければならない。なぜならバグが見つかるのが開発の後になればなるほど、修正のためにかかるコストが高くなるからである。

テスト駆動開発

• アサーションがない、のページは記事を書くときに引用するとウケそう。自分は笑った。

デバッグ

• バグを修正した後、自分の解決策で問題が解決した理由を理解しなければ仕事を完了したとはいえない。
• バグが発生したとき同じタイプのバグが他のところでも起きていないか探る

メンテナンス

• 優れたデベロッパーは非常にメンテナンスしやすいコードを書く
• コードのメンテナンス性に関わる最も重要なものの1つは読みやすさである

仕事の種類

• 優れたプログラマーになるには自分が構築するシステムの要件をよく理解する必要がある
• 経験を積んだソフトウェア開発者がチームに感謝されるには、他のプログラマーのアシストをしたりメンタリングをすることが重要。

これは最近上司からもフィードバックをもらった部分。自分の仕事をこなすだけではなくチームのサポートや、他者を巻き込みながら大きな仕事をこなすなど、自らの影響を大きな範囲に拡大できるようになりたい。

人間関係

• 第一印象は大切
  • 自信と好奇心を併せ持つっといった感じを目指したい
  • あなたよりも長く職場にいる人に敬意を持つ
  • 知的な質問をたくさんする
  • 会う人すべてに挨拶し、相手の名前を覚え、会話の最初に〇〇さんと呼ぶようにしよう
• できる限り他人の役に立つように振る舞おう
  • 同僚が抱えている問題の解決を進んで手伝う
• ドラマを避ける
  • ここにいない誰かの噂話が話題になったらその人の良い部分だけ話すようにする
  • だが衝突を避けてはならない
    • 誰かの提案に賛同できない時は、如実なく振る舞いつつ自分の意見を言う
    • 衝突は適切に解決できれば有益なものになる
    • 感情的にならないように注意する
    • 自分が正しく相手が間違っていることを証明するつもりならそれは論争であり、論争は避けるべきものだ

上司との付き合い方

• 上司を理解するには上司が何によって評価されているか理解する必要がある
  • プロジェクトが円滑に進んでいるか報告してほしい
  • チームの作業効率を下げる問題に対処してほしい
  • 上司に重要と思ってほしければ、こういった分野で上司の仕事を楽にすることに力を入れる
• 上司にとって優先順位の高いことを探り、言われる前にやる
• 週報を作る
  • 上司はプロジェクトが円滑か、重大な問題がないか向こうから連絡してくれるのを望んでいる
• 一段上に立ち、チーム全体がスムーズに動けるよう心がける
• 上司を馬鹿と思わないようにしよう
  • 本当は馬鹿ではないかもしれない
  • 一般的な態度として良くない
  • 馬鹿な提言をしてきたら論理で論破せず、正しい方向に導けるよう努力してみる
• 上司が本当にひどい人間でとても耐えられないと思うなら新しい仕事を探すことをおすすめする

この辺りは処世術に近いものもあり、仕事の本質はエンジニアリングだと思っていると軽視してしまいがちですが実は一番大事なのかもしれない。

ワークライフバランス

• 時間外労働が有益になることはまずない
  • 生活の質が落ちる
  • だらだら長時間働くより、短くし強高い仕事をしたほうがいい
• 時間を自分のために使う
  • 毎朝1時間早く起きて、その時間を自分のために使う
    • 副業
    • 楽器の練習
    • ゲームでもいい
• 今を生きる
  • 〇〇を達成したらやりたいことをしよう、大いに結構だが人生は今しかない
  • 過去に生きることができないように、未来に生きることもできない
  • 日々の生活のことを、より良い人生を送るための通過点のように考えるのをやめる
  • 人生のあらゆる瞬間を最大限に大切にしよう

チームワーク

• 自分が金メダルを取るよりも、スロー・ダウンして転んだチームメイトを助けることを優先する
• 良いチームは共通の目標を持っている
• 特に優れた開発者とは、まわりのすべての人々の力を上げ、チーム全体の力を向上させる人物だ
• 健全なチームは、健全な人間関係と同じで、ある程度の健全な衝突がなければならない。
  • 何かが間違っているときや、自分の意見がまわりとは異なるときには、それを言う必要がある
  • 正し伝え方には十分配慮する

自分の目標に固執しがちでチームの目標をあまり意識できていなかったので自戒的にメモリました。周りをエンパワーできる人材はどこにいっても求められそうですが、なるハードルは高そうです。

アイデアの売り込み方

• キャリアを伸ばしたいなら、いいアイデアを持ち、それを実現させられるソフトウェア開発者だと見られる必要がある
• 自分のアイデアを売り込めなければ、あなたは何もわかってないのに声だけは大きい馬鹿なプログラマーが提案したことをしなければならなくなる
• アイデアを売り込むとき、論争しない
  • 直接反対したり、反論したりしてはならない
• 説得力を上げる
  • 説得力を上げるための最良で単純な方法のひとつは共通点を見つけること
  • 自分が提案したり言ったりしていることが、すでに提出された相手の提案と一致していること、あるいは相手の重要な目的のために役立つことを示す
  • 相手に合わせて話の枠組みを作る
    • メンテしやすいコードが書けるフレームワークの使用を上司に許可して貰うとき、上司が開発スケジュールを気にしているなら、メンテのしやすさを推すのではなくスケジュールが短縮できることを推す
  • 権威を作る
    • 権威がある方がずっとアイデアが通る
    • 権威を得る簡単な方法はブログを書くこと
  • 自信を持って話す
    • 単純に自分のアイデアに確信を持ち自信と熱意を込めて話すだけで支持される

良いアイデアを持っていても伝え方が悪いと宝の持ち腐れなんですよね。ここは自分の弱いところなので刺さりました。（自分が良いアイデアを持てているかは別）

人事考課

• 定期的に上司とミーティングして成果をアピールする
  • 一年に一度の人事考課で突然上司をビックリさせるようなことをしない
  • そのときに自分の仕事ぶりについて改善すべきことはないか率直に問う
  • 次のミーティングで改善の取り組みをアピールする
  • ↑のやりとりを記録に残す
    • なるべく公の形で
  • あなたのことを褒めてくれるメールを集める
    • なるべく誰もが参照できる形で
  • 不服な評価には反論する
    • ただし妥当な成果の証拠を必ず残す
  • 自己評価
    • 拒否できるなら拒否する
      • 自分を正確に客観的に評価するなど不可能
    • 拒否できないなら全てを最高評価で出す
      • ただし自分の最大の弱点のみ２ランク下の評価で出す
      • 自分自身に低評価を下すメリットは一つもない
      • 少なくとも1つは低い評価にしたほうが評価の信頼性は上がる
      • そもそも自己評価や同僚評価はクソみたいなもんだからhackするのがベター
      • したがって同僚評価は全て最高点にして提出しよう。同僚に悪い評価を与えていいことなど一つもない

この辺はわりと爆弾発言というか、過激な主張に思えました笑。ただ褒められたことを記録していくのは自己肯定感も上がりそうでいいなと思いました。

リーダー

• 模範を示す
  • チームのために誰もやりたがらない仕事をする
• チームリーダーとして最も重要なことは周囲の人々をできる限り成功させること

昇給したいなら

• 責任を持つ
  • 責任を持つことは権力を持つことであり、お金は権力についてくる
• 要求された以上のことをやる
• 社外に影響力をもつ
• 会社を稼がせる
• お金が必要な理由を言ってはならない
  • 哀れみから昇給できる確率は極めて低い
• 結局転職すれば給料は上がる

IT業界における女性との接し方

• 過度に親切にしない

キャリアの築き方

• 個人ブランドを作る
  • どういうことで有名になりたいか決める
  • ブログを書く
  • 本を書く
  • 定期的なSNSへの投稿
• 他人のために役立つものを作りあげていくという原則を忘れない
  • なるべく無料で提供する
  • 自分を売り込むための最良の方法は、他人の人生のために役立つことをすることだ
• 長く続ける
  • 多くのプログラマーがブログを１年で辞めてしまう
  • 2、3年、いや5年かかるかもしれないが、うまずたゆまず前進すれば、最終的に成功に達する。

このブログを作り始めたきっかけです。

人脈の作り方

• 他者にとって価値のあることをする
• 話題がないなら相手のことについて聞く
• 人間関係の種を蒔くイメージで長期的な関係を築くことを心がける
• あらゆる場所で人に声を掛ける
• カンファレンスに参加する

スキルの鮮度の保ち方

• プランを作る
  • ブログを読む
  • 本を読む
  • カレンダーに学習計画を書き込む
  • 勉強するものを絞り込む
    • 決して使わない新しいプログラミング言語を学ぶために何か月も使ってしまうと、その時間はキャリアを伸ばしたり、自分の目標に達したりするためにはほとんど役立たない。
  • 短時間で学ぶことを心がける
    • 〇〇について記事をN本書くといった目標を決めてから勉強を始める
  • コードをたくさん書く
    • いつもサイドプロジェクトを手掛けるようにする
    • コーディングスキルは錆びつく

スペシャリストかゼネラリストか

• 両方になるべき
• スペシャリストになることは最強
  • みんなスペシャリストに仕事をしてほしい
• 全てのスペシャリストはゼネラリストでもあるが、ゼネラリストはスペシャリストではない
  • そもそもスペシャリストになるにはその分野周辺のことも知っていなければならない
• 追求すべきはゼネラリストにな？ことでもスペシャリストになることでもなくT字型のスキルを持つこと
  • ゼネラリスト的に勉強し、少なくとも1つは群を抜く知識、技術を持つこと
• ゼネラリストはもはやなれない
  • 技術の進化スピード速すぎて追いつくのは物理的に不可能
• 大きすぎる専門分野を選ぶくらいなら、小さすぎて特殊すぎる専門分野を選ぶ
  • C#の専門でなくC#のフレームワークの専門家になる

この辺りはエンジニアなら誰しもが悩む部分だと思いますが、この本ではスペシャリストになれ！ と結論を出していて痛快でした。

カンファレンス

• スライドは教えることより面白さを意識する
  • 単純にする
  • 箇条書きで説明するくらいなら言葉で説明する

ブログの作り方

• ソフトウェア開発者としてのキャリアを伸ばすためにもっとも効果があるもののひとつは、ブログを始めて定期的に更新することだと本心から思っている
• 人に伝わりやすい文章を書くことを心がけているとコミュニケーションスキルが向上する
• ドメインを獲得する
  • SEOに有利
• 最初のうちはブログのテーマを絞って小さなものにする
  • きわめて狭い範囲に焦点を絞ると、ひとつの分野でもっとも影響力の高いブログになりやすくなり、その分速いペースで成長できるようになる。
  • そのテーマについて少なくとも50のアイデアが浮かばないようでは小さすぎるので注意
  • ２つの大きなテーマを組み合わせてニッチを作る方法もある
  • ブログのテーマとしてどんなものを選べば、自分がそのニッチで世界一になれるかを考える
• 調査が必要ならブログを書く前に終わらせておく
• あなたができるもっとも大切なことは、継続すること
  • カレンダーに個々の投稿の公開予定日時と投稿を執筆する日時を書き込もう
  • ブログなんか全然書きたくないと思う日や週がきっとやってくる。ブログを書いても何の反響もなく、自分のブログには価値も意味もないように感じるときがやってくる。それでも、書き続けなければならない。
• 閲覧数を伸ばしたいなら人々がシェアやリンクしたくなる記事を書き続けること
• 自分らしいユニークな文体で書く

ブログ継続したいけど１週間に１記事はキツイ・・・。

仕事

• どんな会社にとってももっとも価値の高い社員は、自分の仕事をできる限り自動化したり、ほかの社員も自分がしていることをできるように教えたりして自分の仕事を不要にするような社員
  • 仕事を不要にしたら用済み？逆、昇進する

サイドプロジェクトを手掛ける

• 会社で業務こなすより圧倒的に経験値上がる
• マネタイズは考えておく
  • 少なくともドネーションのリンクは作っておく

おわりに

大事だと思った部分をすべてメモしたら膨大な量になってしまいました。ページが多すぎるから仕方ない。 何回もこのメモを読み直して、あとは実践していこうと思います。 長くなってしまいましたが読んでいただきありがとうございました。 良いなと思ったらぜひ共有して頂けると嬉しいです！