という話を同僚としていた。いい話だからブログに書いてと言われたので、無茶苦茶久しぶりに記事を書いた。 通常のユーザーが利用できる面はどういった操作が行われるかわからない以上、テストはしっかり書くべきという意識が強いと思う。実際それは間違っていないし、考えうる限りのケースをテストするべきだと思う。 一方で管理画面は利用できるユーザーが限られているし、悪意のある操作が行われる可能性も限りなく低い。故にリソースが足りていないと「管理画面はまあそこそこのテストでいいでしょ」とか「管理画面は壊れてたら直せばいいから、単純なとこはテストいらないでしょ」みたいな考えに陥りがちだけど、実際は強い権限による操作が行われるのだから相応のテストを書いて然るべきだよね、ということを話していた。 管理画面は通常ユーザーが見れる面と違って権限チェックなども必要だし、これによってテスト書くのめんどくさくなりがちだよねと

最近エンジニア採用に関わる機会が増えました。エンジニアリングマネージャーとして、採用プロセス全体を機能させチームを組成する能力を獲得したいと考えており、その足掛かりとして面接官の役割を積極的にアサインしてもらっています。それなりの件数をこなして学ぶ土台ができてきた感触があるので、このあたりでエンジニア採用の全体像を学ぼうと考えました。 採用に関する書籍は数多くあり、どれを自分の教科書とするか迷いましたが、以前見つけてブックマークしていたITエンジニア採用入門がよさそうに見えました。自分が関わる採用市場とかなり近い文脈で、具体的な情報がエンジニアの目線から簡潔にまとめられています。全体像を学びたい自分にうってつけの資料です。これが無料で読めるのは本当にありがたいことで著者の方には頭が上がりません。 主要な学び EVPとアトラクト ITエンジニアの採用は競争が激しく、採用プロセス全体を通して「

ソフトウェアエンジニアとして安定した成果を出したいと思っている人は多いでしょう。妥当な方針を危なげなく定め、素早く的確に実装し、滞りなく仕事を片付けていきたいものです。しかし、いつでもそのように成果を出せるようになるのは簡単ではありません。言語、ミドルウェア、クラウド、アーキテクチャと、身につけるべき知識が無限に並んでおり、それら全てに習熟する日は永遠に来ないとすら思えてきます。 にもかかわらず、この記事を読むみなさんの同僚には、安定して成果を出せるエンジニアが相当数いるだろうとも思います。これは一体どういうトリックなのでしょう。彼ら彼女らは全てを勉強しているのでしょうか。もちろんそれに近い研鑽を積んでいる人もいるでしょうが、多くの人はそこまでしていないと予想します。少なくとも僕はそこまでやっていませんが、技術面でもそこそこバリューを出して、テックリードを1年勤め上げました。この記事では、

ソフトウェア開発で、より早くより多く価値を届けたいと考えた時、エンジニアの増員は有力な選択肢です。もちろん、人月の神話などで語られるように、人を増やしただけ線形に生産力が向上するというシンプルな世界ではありません。それでも多くの現場でエンジニアの増員が行われます。自分のチームでも、とりあえずエンジニアを増員すれば、いくつかの問題が解決してくれるような気もします。雑談ベースでメンターなどにこういう話を出してみるわけですが、改めて「なぜエンジニアを増員したいのか」と問われると、これが意外と広がりのある議論であることがわかってきました。本記事では、エンジニアを増員するロジックについて、自分が思考を広げられた範囲で書いてみます。 作り切りの場合は明快 まずエンジニア増員のロジックを素朴に立てられるのは作り切りの場合です。ある程度の規模のものを丸々作り切らないといけないケースです。締め切りがあること

スキルマップとは スキルマップは、チームで使っている技術を各メンバーがどのくらい習得しているかを集計したものです。スプレッドシートで表を書いてメンテナンスしているチームが多いのではないかと思います。このアクティビティのメリットは以下のようなものがあります。 チームで属人化している領域を可視化できる チームが使っている技術を一覧する機会になる 各メンバーの能力開発の資料になる スキルマップはいまつかっている技術を一覧するのが一般的ですが、今回はそこに未来の話も混ぜてみているという話です。 問題意識 こうした発想に至る問題意識は大きく分けてふたつあります。 ひとつは、いま使っている技術だけを見ていると、メンバーのスキルビルドの道筋が難しいことが挙げられます。特に長く運用されているサービスでは、どうしても技術の新陳代謝のスピードに限界があり、スキルマップに一世代前の技術が並んでしまうことが多いと

進化の先に理想のエンジニア組織がある─成長のジレンマを解消して進化するフューチャーの組織論 エンジニア組織が成長する際に直面するさまざまなジレンマを解消するうち、ホラクラシー型に進化したというフューチャー株式会社のエンジニア組織論を、宮原洋祐さんに聞きました。 ジレンマを解消しながら進化する組織 専門家とオーナーシップのトレードオフ 組織をリファクタリングしてホラクラシーに近く 組織の形が変わることでエンジニア個人も変わる チーム間の移動を容易にすることで成長を促す 進化の先にある理想のエンジニア組織 インターネットがビジネスに普及する以前から30年にわたり、日本を代表するさまざまな企業に向けたITコンサルティングを通して、企業経営の戦略システム開発を手掛けてきたITの専門家集団、フューチャー株式会社。 企業のパートナーとしてのIT構築を専門としていることから、エンドユーザーの目に触れる機