技術者、エンジニアは長時間労働になりやすいと聞いたことがあります。
私の肌感覚では、そうでもないような感じもしてます。
人による、そんな感じがします。
さて、久しぶりの投稿です。
毎年のことですが、期の最後のほうは余裕が減ってくるのですよね。
中小企業の技術職に所属しており、開発も小粒であり、開発の大部分を1人でやることが多い環境です。
今期初めから周到に進めようと覚悟していたこともあってか、2月下旬に差し掛かる今では、そこそこうまく進んでいて、少しゆとりができてきた感じです。
技術者なら尚更、AI駆使してパパッと原稿書けよ、と思われるかもしれませんが、愚直に一字一句、自分で書いていきたいと思ってます。
開発がひと段落。
その答え合わせをしたくて、本を読みました。
牛尾剛先生が書かれた世界一流エンジニアの思考法という本です。
感想を簡単に書くと、
複数人・チームで開発している環境が前提となっていて、私のようにほとんど1人でやっているエンジニアだと環境が当てはまらないことが多いような気がします。
ただ、開発している環境が違っているだけで、思考法を知っておくのは非常に大切なことだと感じました。
仕事を進める上で持っておきたい思考法。
これを知っておかないと、昔ながらの、非効率の、恥をかくような、そんな仕事の進め方をするのは必然でした。
本書の著者はMicrosoftで得たことを本にしてくれていて、確かに一流の場所ですね。参考になりました。
私自身の立場環境上、これからマネージャーとしての仕事の割合が増えていくだろうし、自社でやりきれない開発を他社にお願いしていくことも増えていくと予想してます。
従いまして、モダンな手法や思考法を知ることができたことは、本当に有意義であったと感じました。
ゴリゴリのエンジニアはもちろんのこと、エンジニアと密接な関係になる職位・職種の人にオススメしたい一冊となります。
最近、日本の生産性が悪く、ドイツにGDPが抜かれたという記事をいくつか見かけました。
私の会社のみの話しとはなりますが、生産性を上げようと何か具体的な取り組み・変化は皆無です。
それどころか、今のままではダメだからあれもやろう、これもやろう、と10個も20個もお題目が出てくるありさま。
リソースや気持ちの問題でうまくいかないんじゃないかなと思っていたところです。
良い戦略、悪い戦略でもありましたが、いかにやるべきことを絞れるか、集中できるか、そのことが大切だと書かれていました。
優先順位が低いものは全く手をつけないというような内容には目から鱗でした。
減らすことに価値がある。
肝に銘じておきます。
その他にも、本書の内容と比較すると、ウチの会社はなんて古めかしいやり方なんだと思うことがたくさん。
また、失敗や批判、責任を恐れてまくっていて、誰かが何かをするまで何にもしない、そんな風土があります。
嘆かわしいことです。
とにかく、明日からでも真似しようと思ったのは、私のやったこと、苦労したこと、解決したこと、そういった経緯をわかりやすく記録・共有すること。
日頃から人に伝えることを前提とした記録の仕方をしておくこと。
技術者としては、自分だけのノウハウは、自分の立場を守る材料にはなり得ますが、チームとしては共有した方がいいことは、ぼんやりとは思ってました。
一方、私もそろそろプレーヤーから卒業する立場環境になってきました。
自分だけ。そういった考え方を改めなくてはと思っていたところです。
このようなノウハウに対する考え方の違いなどを、コマンドアンドコントロール型とサーバントリーダーシップ型の違いと書いてありました。
詳しくは書かないようにしますが、日本の企業の課題にも結びついているようです。
大変ためになる良書でしたが、2点ほどスッキリ入ってこなかった内容がありました。
どなたからかアドバイスを得られたらベストなのですが、視野を広く持つように心がけて生きていきたいと思います。
1点目は、自分よりできる人を観察したり、プロフェッショナルに相談したりするということ。
これは、やっている分野が違いすぎて、私の身近な人で私と同じようなことをやっている技術者がいないのです。
つまり、私みたいに頻繁にコードを書いている人なんてチーム内や部内いなくて、環境が違いすぎて参考にならないのではという先入観があります。
私の勤務時間が長いのは、一般的にコーディングとかは時間がかかるものなのか、私の能力が低いのか、よく分からないのです。
詰まって、1週間くらい1歩も進まなかったことも数回ありました。
本書にも補足のように記載がありましたが、どこかコミュニティに属する必要があるなと反省中です。
2点目は、脳の使用に余裕を持たせ、脳を休ませるということ。
もちろん脳を休ませるのは大切だと思います。
ただ、脳の使用に余裕を持たせ、クリアな状態で仕事をするということに、ちょっと引っかかりがあります。
私は社会人になるまでスポーツをやっていましたが、筋トレとか持久とか、もうダメとなるまで練習して、その結果が成長になってるような個人的概念があります。
負荷をかけ、回復させ、成長させる。
これは脳には当てはまらないのか？とすごく疑問になります。
私はイメージ的に、ずっとラクをしてると成長せず堕落するのではと思ってます。脳に関しても。
勝負所でコンディションを100%に持ってく、そういった調整ができたらと感じております。
開発心得
- 何でもかんでもやらない。もっとも価値がありそうなことにリソースを集中する。その他は本来コスパ的にはやる必要がないもの。
- 開発の失敗を批判しない。失敗はその人の能力以上のことにチャレンジしたことの証明であり、うまくいかないという結果をフィードバックしてくれるありがたい行い。
- もっとも価値があるものを、さっさと試し、さっさと検証し、さっさと改善する。綿密に計画を練っているとスピード感が遅すぎる。そもそも環境変化や状況変化に合わせて仕様や計画は変えていかなくてはならないもの。
- すぐに解決しないことはプロフェッショナルに相談する。相談しやすい社風と断りやすい社風、この2の雰囲気を作ることが大切。
エンジニアと接点のある方にお勧めの一冊です。
コメント