Photo by shaz wildcat
こんにちは、吉岡(@yoshiokatsuneo)です。
動きの速いIT業界において、良い製品やサービスをどれだけ素早く生み出せるかは大変重要なことです。
そのためには、エンジニアにとって質が高く、成長できる開発環境が欠かせません。
では、開発チームの質はどうすればわかるのでしょうか?
開発チームの質を調べる方法の一つとして、Stack Overflowの創業者であるジョエル・スポルスキーさんが提案する、
「ジョエル・テスト」と呼ばれる方法があります。
(ジョエルさんは、その他Microsoft Excelの元プログラムマネージャ、Trelloの作者、著名ブロガーとして知られています。)
http://japanese.joelonsoftware.com/Articles/TheJoelTest.html
「ジョエル・テスト」では、プログラムの行数やバグの数を詳しく調べなくても、12の質問に答えるだけで、3分で簡単に開発チームの質を測ることができます!
「ジョエル・テスト」の発表は2000年です。ほとんど今でも有効ですが、現在の環境に合わせて簡単に紹介していきます。
ちなみに、ジョエルさんによる判定基準はこのようになっています。
点数 | 判定 |
---|---|
12点(満点) | 完璧! |
11点 | 許せる範囲 |
10点以下 | 深刻な問題を抱えている(--; |
それでは「ジョエル・テスト」を見て行きましょう。
1. ソース管理システムを使っているか?
現在はGitHubですね。広く使われており、他のサービスとの連携にも優れているGitHubの一択です。
2. 1オペレーションでビルドを行えるか?
ビルドに限らず、ミスを招くマニュアル操作をなくすことがポイントです。
今では、ソフトウェアがサービスとして提供されることが多いので、構成管理ツールなどを使い「1オペレーションでデプロイができるか」と言えます。
3. 毎日ビルドを行うか?
こちらも、ビルドに限らず、間違いを以下に早く発見し、常に間違いがない状態にするかという点がポイントです。
ツールが整っている現在では、ビルドに加えてテストやデプロイも自動で行えますし、毎日と言わず、レポジトリ更新毎に実行することが多いです。
「GitHub更新毎にテストを行うか?」ぐらいになると思います。
4. 障害票データベースを持っているか?
人が記憶できる情報は限られていますので、バグはなんらかの方法で記録しておきます。簡単にはGitHub Issueでもいいですし、Jiraなどを導入してもいいですね。
まずは、どのような方法でもいいので、最低限、再現手順・エラー内容・対応状況、などを記録します。
5. 新しいコードを書くまえにバグを修正するか?
数回・数人にしか使わないソフトウェアではバグを直さないことも選択肢ですが、広く使われる製品・サービスを成長させるには、バグを直すことが重要になります。
まず、時間が経って放置されたバグは直すのが難しくなって行きます。時間が経ってどのようなコードを書いていたか忘れてしまいますし、コードを書いた人を探してみたら、既に南の島に行ってしまっているかもしれません。(paizaのプログラミングゲーム「もし次の常駐先が女子エンジニアばっかりだったら」のように・・・)
また、バグがどのような原因かは調べないとわからないので、直す期間を見積もることは難しいです。
バグが多い状態では、スケジュールを見積もることは難しくなってしまいます。
現在では、「自動テストを常に通過する状態にしておく」ことが近いと思います。
6. 更新可能なスケジュール表を持っているか?
多くの場合、ビジネス上の理由からスケジュールを決定することが必要です。
さらに、締め切りがあることで機能に優先順位を決めざるを得なくなる、というのも重要な点です。
現在では、サービスなどは継続的にリリースできますが、その分、優先順位を考えることをより意識する必要が出てきます。
7. 仕様書を持っているか?
これは決して、誰も読まない文章を大量に作ることではありません。
要求や設計を明示・共有することで、実装前に早めに問題を見つけて改善しようという意味です。
スクラムにおいては、計画会議でストーリーやタスクを明記して関係者やエンジニア間で詰めることなどが該当すると思います。
8. プログラマは静かな労働環境にあるか?
プログラミングでは、頭の中で多くの情報を保持しながら考えて書くことが必要です。
電話や叫び声が響くような環境では、集中が途切れ、また元の状態に戻るまでに時間がかかってしまいます。
騒音が多い環境より、静かな環境の方が集中できるようになります。
ただし、常に一人で黙々とプログラムするだけが良いとも限りません。
チームメンバーや関係者と相談することも必要ですし、何気無い話からアイデアがでてくることもあります。
特に日本の、広いフロアのオフィス環境では難しいこともありますが、集中が必要な場合には他の場所やオフィスの外で作業したり、時間を決めて静かにするなどの方法も考えられます。
9. 買える範囲で一番良い開発ツールを使っているか?
同業者が倍の速度のマシンで開発していたら、どちらが勝つ可能性が高いでしょうか?
当たり前ですが、遅いより速い方が生産性は高いです。
さらに、少しの待ち時間でも、ちょっと暇だからとTwitterを見て何をしていたか忘れたて大幅に遅くなります。:-)
また、開発マシンは日々エンジニアが利用するものですので、エンジニアの満足度に強く影響を与えます。
良い開発環境は採用においても有利と言えます。
現在では、どれだけ最高の環境を揃えても一式50万円を超えることは少ないと思います。
一人のエンジニアを採用するコストと比べてみてもいいと思います。
エンジニアからしてみると、どのような開発環境を用意しているかで、開発をどの程度重視しているか見る目安ともなります。
無い袖は振れないですが、お金だけで解決できるという意味では簡単な方法かもしれません。
ちなみにpaizaのエンジニア向け求人票では求人ごとに、どのような開発環境を使っているかを詳しく見ることができます。
10. テスト担当者はいるか?
かつては、製品リリース前にはテスターと呼ばれるアルバイトや新入社員が製品のテストを行っていました。
製品リリース時に最高の品質にすることが大事だったからです。
現在では、継続的にサービスとしてリリースする必要の高まりなどにより、自動テストが広く使われています。
テストを担当者も、単純にテストを繰り返すよりテストを行うスクリプトなどを記述するエンジニアが求められてきており、人でしか見れない部分のみ人がテストするようになってきています。
この項目は「自動テストが導入されているか?」と言い換えていいと思います。
11. プログラマを採用するときにコードを書かせるか?
エンジニアが良いプログラムを書けるかどうすればわかるでしょうか?子供でも簡単な答えです。
プログラムを実際に書いて見てもらえばいいのです。
特にプログラムというものは、究極的に言えば正しく動くか、動かないかの2択ですので、比較的客観的に見ることもできます。
手前味噌ですが、paizaは正にこれを実現するためのサービスを運営しています。エンジニアの方は、コードを書くことで仕事を探せますし、IT企業は実際にコードが書ける人と出会うことができます。
12. 「廊下での使い勝手テスト」を行っているか?
製品・サービスを作っている人が、初めてそれを使った人がどう感じ・どう使うかを想像することは難しいことがあります。
それでも、実際に使ってもらえばすぐにわかることがあります。
ただ、現在では、サービスを継続的に改変することができますので、A/Bテストを行ったり、サービスの利用状況を監視・解析することができるようになっています。
まとめ
あなたの職場は何点でしょうか?また、あなたが重要だと思う項目はどれでしょうか?
「ジョエル・テスト」を使うと、視点を変えながらチームの状態を見ることができます。
「ジョエル・テスト」について詳しくは元記事にありますし、書籍も出版されていますので、是非こちらも読んで考えてみてください。
http://japanese.joelonsoftware.com/Articles/TheJoelTest.html
paizaは、技術を追い続けることが仕事につながり、スキルのある人がきちんと評価される場を作ることで、日本のITエンジニアの地位向上を目指したいと考えています。
「paiza転職」は、自分のプログラミング力が他社で通用するか(こっそり)腕試しができる、IT/Webエンジニアのための転職サービスです。プログラミングスキルチェック(コーディングのテスト)を受けて、スコアが一定基準を超えれば、書類選考なしで複数の会社へ応募ができます。
まずはスキルチェックだけ、という使い方もできます。すぐには転職を考えていない方でも、自分のプログラミングスキルを客観的に知ることができますので、興味がある方はぜひ一度ご覧ください。
また、paiza転職をご利用いただいている企業の人事担当や、paiza転職を使って転職を成功した方々へのインタビューもございます。こちらもぜひチェックしてみてください。 詳しくはこちら