事例紹介
2018.03.16

ラボ型開発における開発スタイルをアイエンターさんに伺いました

システムソリューションからデザイン、マーケティングなどトータルでサポートする「IT総合コンサルティング企業」として展開する株式会社アイエンター。
スマートデバイス・IoT・Webサイトなど精力的に手掛けられ、今回のお話でも早速「スマートスピーカー」の話題が出てきました。
今後も新しいテクノロジーを追求し、お客さまに喜んでもらえる提案・コンサルティングができる”ITのプロフェッショナル”。
開発を進める阿部さん、風間さんをお訪ねしました。

阿部さんプロフィール:
氏名:阿部 光司(写真左)
業界経験19年、主にBtoB、BtoC系のWebシステム(ネイティブアプリ案件は管理のみ)開発に従事し、顧客提案~リリース迄対応していました。
2006年にアイエンターに所属してからは会社責任者として、開発部門の組織作り・運営、品質管理部門の立ち上げ、情報システム責任者としてISMS等も対応。
ここ2年は請負開発LABO開発に切替えのため品質管理のPMO活動強化に努めています。

風間さんプロフィール:
氏名:風間 陽介(写真右)
約15年の技術者でありながら、やってきた経歴はさまざま。以前の業務は、C++などのWindowsアプリケーションの自社サービスに従事してきました。
ここ4年間はiOSを中心としたモバイルアプリケーションの開発に従事しています。また、現在では社内のコーディングなどのルール策定もしております。

http://i-enter.co.jp/

昨年くらいからラボ型開発が増えています

大井田:

御社とは、「スマホ研究会」でお世話になっております。本日はよろしくお願い致します。

阿部:

もともと弊社は受託案件の多い事業体でもありますので、お役に立つお話ができるかと心配しております。ここ最近の傾向として、ラボ型開発が増えてきていまして、そのお話を進めさせていただければと思っています。

大井田:

はい、ラボ型開発についてはこれまで伺ってきていない分野なので、ぜひ。

阿部:

ラボ型開発の場合は、クライアントからの要望に応じてチームを組んで開発を進めることが基本です。その場合、スクラム開発あるいはアジャイル型の開発を要望されることはほとんどなく、基本的にはウォーターフォールに近しいスタイルになっています(小刻みな、反復型のWF)。もちろんそれも、ケースバイケースではあるのですが、、、

大井田:

その場合、スケジュールもクライアントさんの希望に沿ってということになりますか

阿部:

マスタースケジュールはクライアントさん要望に沿ってきちんと用意して、開発内部ではうまく進められるように機能ごとなどにスケジュールを切って管理するというのが社内的には定番手法となっていますね。
割り込みタスクなどが発生しても、個別スケジュールをうまく調整できるようにするのは、プロジェクトを進める上で必要かなと思います。

もうひとつ、ラボ型開発で大きなポイントなのは生産性についての担保を契約時にしているということ。クライアントとの約束でもあるので、その点は重要ですね。

大井田:

開発規模の大小とか、チーム構成とかどのようなものが多いんでしょうか

阿部:

規模の大きいものでは、20名強のメンバーでスマホとWebと任されているプロジェクトがありますね。このプロジェクトに関してはスクラムっぽいスタイルではありますね。全体的には、3〜6人で進めているプロジェクトが多いかもしれません。

もう少しラボ型開発のことを説明すると、必要なスキルを持ったエンジニアを必要な人数、必要な期間、クライアントさんの専属チームとして契約する開発モデル。つまり、クライアントさんが作成した仕様書通りに開発するプロジェクト型開発(請負型開発)とは違って、準委任委託を受けて仕様を固めていくステップから始めたり、サービスにに必要な一部システムを切り出したうえで必要なシステムを開発していく体制を築き、時に仕様を適宜変更するなどクライアントの要求に合わせて、柔軟に開発を行なえることが特徴です。

つい最近では、スマートスピーカーを活用したアプリ開発という案件が決まったばかりです。

大井田:

それは旬ですね。それも詳しく伺いたい気がしますが、ラボ型開発ではその各チームのプロジェクト管理というのは、ずばりどのようにされているのでしょうか

阿部:

キーマンと呼んでいる役割を持つリーダーがいて、他のメンバーの進捗やタスクをRedmineで管理しているというのが決まったスタイルですね。キーマンは、クライアントとの折衝も行ないます。

大井田:

そのチームのキーマンというのは、各プロジェクトの専任なのですか? それとも掛け持ちされる場合があるのですか?

阿部:

それは完全に専任担当にしていますね。おそらくそうしないと、プロジェクト進行に影響がでます。

大井田:

各メンバーのアサインはどのようにされるのですか

阿部:

そこの方法そのものは従来の請負型と大きな差異はないように思います。が、今回ラボ型開発にしたことで、「もっと違う方法があるのではないか?」という
エンジニア自身ののめり込み度というか積極性を喚起できるのではないかと感じています。

というのも、ラボ型開発ではエンジニアもクライアントと直接やりとりをし、サービス提供の目的を共有されることがメリットであるとも言えます。仮に直接やり取りの機会がなくとも、キーマンを通して目的共有できる体制は大切にしていますので。

大井田:

では、開発期間はいかがですか

阿部:

スマホの場合だと早いものは2ヶ月、Webも含めて概ね半年くらいではないでしょうか

PMOが開発の交通整理をするようになって

阿部:

もうひとつ、弊社の開発全体に言えることなのですが、「品質管理」セクションを設けています。これは、プロジェクト横断的に、各プロジェクトの進行の不具合を発見して改善を行なうPMOと言えばわかりやすいでしょうか。受託開発では、「管理定着型PMO」と呼んでいます。

このときは、定期的な会議を行ない、タスクリストを共有して問題発見・改善を進めていました。現在は、週次にPMOがヒアリングを行なって問題発見・改善ができるように指導をするという体制になっています。というのも、ラボ型開発の場合、プロジェクトごとの要件がそれぞれ異なるので平均化できないということがわかっているためです。

大井田:

その場合の、コミュニケーションはやはり対面ミーティングになるのですか?

阿部:

「Microsoft Teams」というチャットツールを使っています。

また、管理ツールとしては、Redmineを使っていますので、これのプラグイン機能を利用して、「チェックリスト」をエクスポートして項目を1つずつつぶしていくというような作業をしていますね。また、彼らには各プロジェクトのチケット管理が共有されているので、動いていないチケットがすぐに分かるように体制化できています。

何かアラートを発見したら、即キーマンに連絡を取って改善を促すということになりますね。

さらに、 この「品質管理」という点から大きな問題を抱えているのが、先ほども少し申し上げましたが、やはり取り扱う開発分野が広いということで、あるプロジェクトでは「デザイン」だけ、他のプロジェクトでは「要件定義」から担うことになりました、、、と決めごとがまちまちで管理側からすると非常に標準化しづらい。「ラベル」にしろ「ステイタス」にしろ「トラッカー」と言ったほうがいいのかな、それを個別に設定せざるを得なかったりします。

大井田:

お話を聞く限り、御社のプロジェクトにはいまや欠かせない役割となっているのではないかと感じられるのですが、この仕組みを導入して変化を感じられたのはどんなところですか

阿部:

まず第一に言えるのは、「キーマン」の負担が減ったということです。具体的に、稼働時間がかなり減ったというデータが表れました。それでも、導入当初はかなり面倒がられたりしたんですよね。

大井田:

それはやはり、PMOの方々が優秀だということなのではないでしょうか。 そのPMOはいま何人いるのですか?

阿部:

3人で動いています。が、彼らの機能が属人化してしまう、単純に彼ら自身の能力に依存してしまうということから、それを標準化する方法というのを模索している最中です。現在は、上記に紹介した「チェックリスト」を事業分野別だったり、ケースを想定して用意するということを進めてもらっています。

各ツールの使われ方を解説します

風間:

では、キーマンが各メンバーとどのようにコミュニケーションを進めるか、チームメンバーをまとめているか、というところを私からお話しましょう。

進捗はすべて、さきほどもお話が出ましたがRedmineで一括管理します。メンバー管理で重要なことがありまして、それは弊社の各拠点、遠隔地もありますので、そうしたリモートメンバーも少なくないということです。

ミーティングスペースには、Webカメラを搭載したモニタが設置され、どこでもHangoutで「顔を見ながら」リモート会議ができる環境にしています。リモート会議の進め方は皆うまくなってきているのではないでしょうか。

大井田:

進捗は、Redmine一択ということですが、プロジェクトごとに、メンバーの経験も力量も異なってくるかと思うのですが、その生産性だったり、各メンバーのスキルの管理だったりという点では、どのようにされているのでしょう

風間:

Redmine のチケットに「開始日」と「終了日」を必ず記載するようにして、その進捗を追いかけていくという方法になります。

大井田:

ということは、そのチケット発券時に「○○なら、これくらいでこのタスクを終えられるだろう」という判断をしているということですよね。つまり、そこはリーダーの力量に依存する理解で大丈夫ですか

風間:

Redmine では、ガントチャートを表示させてそれを追いかけていきますね。その点では、ある特定個人によって頭を切り替えるというようなことはなくて、ある程度割り切ってこの方法にしているということになるかもしれません。早く終わった、あぁやはり遅れちゃったか、というようなことはえてして発生しますし。そこはガントチャートの進捗から判断して、個別にコミュニケーションを取っていくことだと思います。

大井田:

なるほど、シンプルですね。「鉄は熱いうちに打て」ではないですが、問題はその時々に都度解決を図っているということですね。Redmineですが、御社独自でカスタマイズはされていますか

阿部:

そういう使い方は、現状していないですね。ですが、チケット発券時にはクライアントと共有しているExcelベースのスプレッドシートをRedmine APIを活用して同期させてチケット化するという方法を取っています。

大井田:

それは、なかなか大変ですね。やはり、顧客側はどうしてもExcelになっちゃいますねぇ。ガントチャート管理の場合、スケジュールが遅れたりするケースが想像もできるのですが、その場合はどのように管理されるんですか

阿部:

それも、Excelを変更して、インポートですね。運用コストがかからないようにするには、やはりそれしかないかと。

風間:

お話をしながら思い出しましたけど、Redmineのプラグインは時々利用するケースが発生しますね。アジャイルプラグインを使ったプロジェクトもありました。

阿部:

私も、思い出したのですが、最近始めたばかりのもので、プラグインの「ナレッジベース」というものがあります。これを活用して、クライアントさんとの情報共有を進めてるという動きもあります。確定した情報と作業チケットの関連がわかりやすくなって、これはいいかなと思っています。

大井田:

チケット発券のルールというのも、全社的に統一されている状態で運用されてますか、それとも個別プロジェクトによってリーダーに委ねている状態ですか

阿部:

「品質管理」の点からも、統一しようという動きはありますが、現状は「統一」とまではいかないですね。今後は、きちんと全社ルールを定めていこうという機運はあります。

大井田:

ツールに関して、ちょっとまとめると、プロジェクト管理の旗艦としてはRedmine、Teamsではコミュニケーション機能が主で、Office 365との連携ができるので、ドキュメントのリアルタイム編集などにも用いられる。ソース管理は、Gitlabということですね。リモート会議には、Hangoutが使われる。

風間:

付け加えると、UX/UI設計にはProttを使いますね。

今後の展望は

大井田:

今日はラボ型開発のことを中心に伺っていますが、最近ならではの開発傾向ってありますか、あるいは注目技術など

風間:

スマホの場合だと、ネイティブアプリがまだ主要ではありますが、今後この流れにも変化が起きそうです。Webベースでの新しい試みも増えてきています。当然、クライアントさんのニーズに合わせて提案をして、ということになりますね。

コミュニケーションのあり方もまだまだ改善の余地はあるのかと思っていますが、お伝えした通りリモートメンバーも多いので、全員が顔を合わせて定期的にミーティングをするということができにくい状態でもあります。一丸となって取り組んでいることは、

– Teamsを使ったコミュニケーションで共有漏れが発生しないように心掛けること
– 必要に応じて、顔を見て話ができるようにすること
– 共有ドキュメントは、Redmineのwikiに残すこと
とまとめられるのかと思います。

大井田:

率直に言って、ラボ型開発を進めていく過程でのクライアントさんからの反応はどうですか

阿部:

「品質管理」体制としてのPMO機能も含めて、こういう新しい体制でチームを作ります、というような説明はきちんとして契約に臨むので、好意的に進めていただいている実感があります。

コストコントロールもしやすいですしね。

大井田:

開発のドキュメントは残るものなんですか?

阿部:

実際は、クライアント要件によりますね。もちろん、簡単なドキュメントはWikiに残したりしていますから。ただ、この点もやはり共通化・標準化が必要なポイントかなと考えていまして、それも検討しているところなんですね。やはり、プロジェクトごと個別対応でとしてしますと、場合によってはクライアントに対して不誠実なことになってはいけませんから。

直近では、ドキュメントの「ひな形」化ということにも取り組んでいますが、何度もお伝えしてますように取扱領域が広いためにこの「ひな形」がうまく収まるかどうか非常に懸念もある状態なんです。
あとは、さきほどご紹介したRedmineのプラグイン「ナレッジベース」ですね。

大井田:

エンジニアの成長機会を会社の仕組みとして作っているという試みは何かありますか

阿部:

R&DグループはQiitaを書いてますね。ブランディングの一環としても重要だと感じていますので。

取材を終えて

会社に到着して目に飛び込んできたのが、エレベータを包むように壁一面に書かれていた社員のみなさんの「夢」でした。
社員一人ひとりの夢を叶えることができる会社でありたい!と考えるこの会社の一面を表していると印象づけられました。
例えば、「シリコンバレーで働きたい」「世界的に有名なエンジニアとプロジェクトを担当したい」など会社を通して実現できることであれば何でもいいのだそうです。
ほかにも、「笑顔の絶えない毎日」「宇宙旅行」「素敵な家庭を築く」などの夢も。

一人ひとりの生活も人生も豊かになるよう、またその夢を実現することで会社を発展させていく・・・そんな会社。

考えてみれば、経験を重ねるということは夢を奪われていくことなのかもしれないと思いました。今回お話を伺ったお二人は既にベテランの領域のエンジニアでいらっしゃいます。お話をしながら考えたのは、優れたプロジェクトチームは目標を共有しているものだ、という事実でした。
その目標を夢と言い換えてもいいのかもしれません。

TeamHackersでは、これから数回にわたってスクラム開発事例を個社インタビューを通してご紹介していきます。引き続き、ご購読をよろしくお願いいたします。

この記事が気に入ったら
いいね!しよう

最新情報をお届けします

同じタグのついた記事

同じカテゴリの記事