はじめまして
私は、低圧と高圧の「IIJスマートメーターBルート活用サービス」サービスの開発 (以下、B ルートプロジェクト) を担当している青戸と申します。
本ブログへの投稿は初めてですが、よろしくお願いします。

ブログ記事デビューは遅かったのですが、実は B ルートプロジェクトの発足当初から参加していまして、今回の記事では、 B ルートプロジェクトの開発スタイルなどについて、開発メンバーの一員としてご紹介します。

自分たちが使いたいものを作る

IIJ 全体に言えることですが、開発するサービスは、自分たちが使いたいと思ったものを作るという精神があります。
この精神は、いわゆるドッグフーディングに基づいたもので、サービス開発する際はそのサービスを利用する人にとって本当に嬉しい機能かどうかが非常に重視されます。

例えば、皆さんご存知の IIJmio (個人向けのMVNO sim サービス) にはバースト転送という機能が搭載されています。まさにこの機能が自分たちが「こんな機能があったら便利じゃない？」と考えて実装したものになります。(バースト転送についてはこちらを参照ください: http://techlog.iij.ad.jp/archives/1059)。

B ルートプロジェクトの開発スタイル

驚かれるかもしれませんが、 B ルートプロジェクトのメインの開発・運用メンバーは 5 -6 人程度です。この人数でソフトウェアの新規開発だけではなく、サービス運用やお客様の技術的な問い合わせ対応までこなすのはなかなか大変ですが、これからも、これぐらいの人数で開発・運用し続けていくと思います。それは、少人数のほうが IIJ の精神である｢自分たちが使いたいものを作る｣ をより簡単に実現できると考えているからです。

例えば、少人数で開発･運用すると、チーム一人ひとりの責任や役割が、大きく、明確になるため、仕事の割当が ｢ゲートウェイにスマートメーターとの通信機能を実装｣ といった感じになり、自分の成果がダイレクトにサービスへ影響するようになります。

これは、自分のプロジェクトに対するのモチベーションが上がるだけではなく、常に最終的なサービスのイメージを思い描くようになり、｢この改良によってサービス利用者にどんな影響を与えるのか｣、｢本当にこの機能追加によってサービス利用者が満足できるのか｣ ということを強く意識することになります。
これらの意識はまさしく、 ｢自分たちが使いたいものを作る｣ であるといえます。

また別の観点から、少人数で開発するメリットとして、チーム内のコミュニケーションコストがあります。Bルートプロジェクトでは、何か相談･質問したいことがある場合、メンバ同士の席が近いこともあり、席に座ったままでインスタントに話し合います。以前はメッセンジャーアプリを利用することもありましたが、相手の理解度や納得度が面と向かって話したほうがわかりやすいため、メッセンジャーアプリでは物足りなくなり、利用しなくなりました。
ただ、これは 2-3 人だからできることで、人数が大きくなってしまうと、時間と場所の確保がどうしても必要になり、インスタントに話し合うことが難しくなってしまいます。

少人数の開発だからこその悩み

しかし、少人数で開発していると、チーム全体での “思い込み ” が起こり、本当に必要だった機能の見逃しや、思いがけないパターンでの考慮漏れといったことが起きやすくなります。そうならないように、B ルートプロジェクトではリリース毎に、品質評価を行う部隊にサービスの評価･テストを行ってもらっています。

お客様視点でサービスの評価･テストを専門に行う品質保証課

IIJ には品質保証課 (以下、QM 課) と呼ばれるサービスの評価とテストを専門に行なう部署があり、日々様々な IIJ サービスの評価・テストを行いノウハウを蓄積しています。

QM 課ではこのノウハウを活かして、開発チームが気がつなかった機能の抜けなどを指摘し、IIJ のサービスとしての一定レベルの水準を担保しています。
QM 課でのテストの特徴として、お客さま目線でテスト・評価を行なうため、お客さまが目を通すサービス資料書からテスト項目を作成するブラックボックステストが基本であったり、実際にサービスを触ってみて感じたユーザビリティなども評価の対象に含まれている点などがあります。

また、お客様視点ではなく第3者のエンジニアとして、サービスを俯瞰的に見て機能追加時に発生するデグレーションについてもテストします。
テストの結果、修正する必要があるものに関しては、バグの再現方法などの情報と合わせて開発チームの方へ連絡されます。開発チームではバグを修正し終わると、QM 課に連絡し再度その項目についてテストしてもらいます。バグや不明箇所の連絡は基本チケット管理システムを利用して行われますが、チケットを起票する前に実際に開発チームの席まで行き、状況の確認や不明箇所を聞くといった光景もよく目にします。

これらのテスト最終的な結果は、「評価報告書」としてまとめられ、リリース判定会議で使用する資料となるため、QM 課で実施するテストは非常に重要なものになります。
日々お客様視点でテストを行っているので、IIJ の中で1番サービス利用者のことを考えて仕事をしているのは、開発者ではなく QM 課の方々だろうと私は思っています。

おわりに

拙い文章で、内容も飛び飛びな箇所もありましたが、B ルートプロジェクトの開発チームの雰囲気や開発サイクルなどがお伝えできたと思います。

私達と一緒に B ルートプロジェクトの開発チームに参加して、よりワクワクするようなサービス開発を一緒にやっていくことに興味がある方は、ぜひ下記までご連絡ください。
https://js01.jposting.net/iij/u/job.phtml?job_code=80

執筆者プロフィール