エンジニアがエンジニアであるために
はじめに
久々に思い立ってブログを書くことにしました。
僕が思う「エンジニアがエンジニアであるために」について、まとめようと思ったからです。
ここで言うエンジニアは俗に言うWeb業界がメインです。(僕がそうなので)
本とかブログとかを交え紹介をしていこうと思います。
基本的に3つの軸で書いていきます
- 考え方を身に付け
- 良いとは何かを知る
- 自分の知識を更新していくこと
この3つが必要だと、僕は思います。個人的見解なので、ほかにももっとこういう考え方あるよ、とかもあると思いますので、参考までに読んでいただけるとうれしいです。
考え方を身に付け
考え方を意識すること
まず、エンジニアであるということは、柔軟な思考と戦略的な思考が必要だと思います。そもそも今目の前にある課題をクリアするために、コードを書くだけが解決の方法ではありません。オープンソースを利用して対応する方法もあります。DBも多種多様です。柔軟に考えプロダクトを前進させていかなければいけません。
最初にお勧めしたいのが、このストラテジックマインドです。
企業経営のための本と書いてありますが、本質は戦略的な思考の本です。エンジニアは常に考えなければいけません、課題をどう解決するか、将来どのようにプロダクトを成長させるのか。その中で、いろいろな自分の固定概念やあるべき論に縛られることがあります。その時にどう考えればいいかを紐解く一冊になると思います。
books.rakuten.co.jp
次にお勧めしたいのがエッセンシャル思考です。
これは有名な本ですね。まず、エンジニアは時間がないことを知らなければいけないと思います。自分が勉強できる・成長できる時間。仕事中の時間をなにに使い、何に貢献するのか。なにも考えないとすぐに1年終わってしまいます。エンジニアには時間がないのです。そのため、「しないことはしない」、「やるべきこと」、「やりたいこと」をするためにどういう考えを持つ必要があるか。正直これができてないエンジニアは、成長が鈍化するだけでなく、ストレスをためてしまうかと思います。
簡単に読める割には、多くの発見がある本です。
books.rakuten.co.jp
エンジニアには文化があることを知ること
エンジニアリングをしていると、当然のように人とかかわることがあると思います。直接でなくてもコードの中やシステムを通して間接的にも多々かかわることもあると思います。開発をする、チームを作るということは、そのメンバーで文化を構築していくということを意識することが非常に重要だと思います。AgileやScrumなどもその文化の中のひとつだと思います。文化はリーダーだけでなく、そこにいるメンバー一人ひとりによって代わるものです。
文化については、ここら辺がお勧めです。どういう組織を作りたいかGeekな集団とは何か。
books.rakuten.co.jp
Spotifyの文化は、すごく参考になります。英語ですがスライドを見ればなんとなくわかるかと思います。
labs.spotify.com
labs.spotify.com
ちなみに、僕は文化として、重要だと思ってることは大きく3つ合ります。
- 真剣に振り返るできること
- Retrospective や Postmortem : https://landing.google.com/sre/book/chapters/postmortem-culture.html
- 安心感があること・失敗を恐れないこと
- Spotifyの文化だとFailure Celebration: 失敗をして新たな発見をできたことを祝う。
- 先を見越し動くこと(プロアクティブ)
- 言われて実装するのではなく、先見の目を持って技術投資を行い、プロダクトを改新していく感じ
- フォードもこの文化を持ってる1社ではないかと思います。
「もし顧客に、彼らの望むものを聞いていたら、彼らは「もっと速い馬が欲しい」と答えていただろう。」
by ヘンリー・フォード(アメリカの自動車会社「フォード」の創業者)
http://meigensyu.seesaa.net/article/205528783.html
良いとは何かを知る
良いコードを知ること・良いアーキテクトを知ること
コードを書くときに、動けばいいや?って書いてるとそれは大間違いです。コードを書いた瞬間からそのコードの運用が始まります。コードを運用するためにはコードを読まなければいけません。そのためには、どのようなコードが読みやすいのか知る必要があります。僕はこう考えています。「企業の成長速度は、コードの良し悪しで決まる」と。改修しやすい、変更しやすいコードは企業のビジネスの変更に強く、その仮説検証を促進してくれます。逆にテストがなかったり、汚いコードはすぐにリリースはできますが、変更に弱く、いざビジネスを進化させようとする際に足を引っ張ります。
ゆっくり読んでも1週間くらいで読める本だと思いますので、とりあえず読むといいと思います。
books.rakuten.co.jp
次にお勧めしたいのが、レガシーソフトウェア改善ガイド
これを読めば、そもそもどんなソフトウェアが危険なのかの勘所とそれに対してどうすればよいかがわかります。なので、自分がレガシーソフトウェアに携わってないと思っていても、1度読むことをお勧めします。そもそもソフトウェアの構造がここ数年でどのように変わってきたかもわかるので、ある意味歴史の教科書です。個人的に、心に残ってるフェーズは「チームが既存のコードを改修しなくなったらそれはレガシーの始まりである。」という、組織文化についても少し触れていた点です。
books.rakuten.co.jp
使っているモノをちゃんと知ること
自分の扱ってるプロダクトに合わせて言語習得をしたりすると思います。既存のコードや書きたいコードを検索して調べて、それで実装して、リリースしたりしてると思います。でも、本当にその言語の強み、フレームワークの利用方法を学習してますか?なんとなく使えるからと、怠らずちゃんとそれがなんなのか知りましょう。先人たちが知るべきことを示してくれてます。
ベストプラクティスを読む
あと、ツールやDBだとベストプラクティスは結構公式に乗ってます。きちんと理解しましょう。
Googleで「Ansible BestPractice」とか打つと大抵出てきます。独自の発想で使うのではなく、ベストプラクティスに合わせて使いましょう。
そもそも、ベストプラクティスはツールの意義に沿って案じてあります。それに沿わないと、ツールがバージョンアップするときに取り残されて将来古いバージョンを利用し続けなくならなければいけない危険性があります。そんな、運用したくないですよね。
- Ansibleだと
自分の知識を更新していくこと
幅広くアンテナを持ち続ける。
ご存知のとおり、Web含めIT業界の技術というものは日進月歩です。
日々とまでは言いませんが、常に少しだけでも読むようにしておきましょう。課題を解決するときに新しいOSSのことを知っていたり、既存のOSSをバージョンアップすることでより、より便利にしたりと、プロダクトとあなたをアップデートしてくれます。
ここでは僕が日々キャッチアップしている軸とサイトを少しだけ紹介します。自分に合ったものをちゃんと見つけましょう。
幅広くキャッチアップする
いろいろなものはどこかでつながってるもので、浅くてもいいので幅広く知っておきたいものです。
hacker news
ここでは非常に幅広いジャンルの記事を読むことができます。
OSSだけでなく、世の中の情勢記事(技術によってる)などを読むことができます。TOP30くらいが常にトップページに出てるので、朝から面白そうな記事だけ2,3個だけピックアップして読みます。
使い方的には技術新聞をぺらぺら読んで、情勢を知ったり、キャッチアップのために使います。
Hacker News
技術方法論を日々更新する
自分が良いと思っているやり方だけにこだわらず、いろいろな手法を勉強し続けることが大事だと思います。
dev to
表示速度が異常に早いことで有名になったページです。基本的にはWeb技術や手法についての記事が多いです。
自分のプログラミングや技術手法を改善するために、暇なときに読みます。
The DEV Community
利用してるものの知識を更新する
自分が使う技術回りは常にアップデートしておきましょう。それがそのまま自分の更なる強みになります。
ScalaTimes
名前から予測できるとおり、Scala周りの技術周り、ブログ周りを集めてるサイトです。
http://scalatimes.com/
ほかの言語でもいろいろとあると思います。メールを購読するようなサービスも意外と便利です。
同ジャンルの競合を知る。
自分が利用している技術の同ジャンル等はできるだけキャッチアップできることが大事です。
DB-Engines
DBのランキング紹介サイト。各ジャンルごとにDBのRankingを紹介しています。
僕は、上位のものを使うというより、そのジャンルで今どういうDBが出てるのかを知るために利用しています。それで、自分の利用用途に一番合うのはどれかを考えます。やはり、何かを採用する際は、ちゃんと競合には何が存在するのかを知っておく必要があると思います。
DB-Engines Ranking - popularity ranking of database management systems
最後に
最近、どのようにすれば自分がエンジニアとして価値を出せるのかを考えることが良くあります。この記事は、それに紐付いて思ったことを書きました。こういった人材を育て、同じチームでプロダクトに向かっていけるといいなと思います。もちろん自分もこういったエンジニアで在り続けないといけないなと思います。