サービスの企画段階からプロジェクトに参画し、「試作」を作って顧客の要望を可視化しながら、圧倒的なスピード感でサービスを作り上げていく。
テクノロジーが発達し、モノづくりの現場で取りうる選択肢が格段に多様化してきた現代社会だからこそ、従来のQCD（Quality=品質 Cost=コスト Delivery=納期）に沿った形とは違った開発の進め方が注目されています。

今回は、株式会社SHIFT（以下、SHIFT）が立ち上げた「DAAE（ダーエ）」という新しい概念と開発スタイルについてお話を伺いました。
ドキュメンテーションは最小限にして、コードで仕様を決め、都度試しながら開発していくスタイルをいかにして実現しているのか。DAAEチームの責任者と、メンバーであるフルスタックエンジニアの方に、それぞれお話を伺いました。

プロフィール

 

品質保証こそ、上流工程から入るべき

――SHIFTさんと言えば、品質保証を軸としたソフトウェアテストの事業をされているイメージなのですが、今回はまた別の新規事業領域ということで、お話を伺うのを楽しみにしていました。

白畠：おっしゃる通り、よく「テストの会社さんですよね」と言われます。
確かにテストからスタートした会社なのですが、弊社は品質保証というものをもっと広い意味で捉えています。

――その点について、まずは詳しく教えてください。

白畠：品質保証と聞くと、どうしても開発プロセスの中の「下流工程」で捉えられることが多いと思います。ですが弊社としては、本来的には「上流工程」の企画段階から設計すべき領域であると認識しています。

そもそも、多くの企業ではRFPなる要件定義書を作成して開発プロジェクトをスタートさせるわけですが、往々にして要件定義フェーズって盛り上がるんですよ。話が大きくなり、それに伴って下流工程の品質保証対応の工数が増え、開発プロセスの難易度も上がるわけですが、「品質保証のことを十分に考えられていない要件増大」が多く見受けられます。

それの何が問題かというと、いざサービスリリースをしようとなったときに、品質保証フェーズが終わらないという事態が発生します。当然、リリースするものは全てのテスト計画を終える必要があるので、予算追加してスケジュールを延伸させるか、限定的な範囲でサービス稼働をさせるか、それとも頑張ってテストを短縮化させるかのいずれかの対応を余儀なくされるわけです。

――開発プロジェクトならではのあるあるですね。

白畠：だからこそ弊社では、要件定義フェーズでしっかりと品質保証フェーズのシミュレーションをすることで、今お話ししたような事態を未然に防止し、品質保証の工数も含めた適切なプロジェクト進行を進める役割も担っています。

最初は「品質保証フェーズ要員」としてお話をいただくことも多いのですが、そこで今のようなお話をすると、大体のお客様は進め方を後悔なさるんですよ。そして、次回からは要件定義フェーズからの対応が必要とのことで、いわゆる「品質コンサルタント」や「テスト推進PMO」、「自動化エンジニア」など、プロジェクトに応じた様々な役割でのアサインを打診されることになります。

「DAAE」のキッカケは、「UIの改善から始めよう」だった

――SHIFTさん自身が開発案件を請け負うような事業はされないのでしょうか？今伺ったように、品質コンサルティングのノウハウがあるのであれば、そういうニーズも必然的に増える気がするのですが。

白畠：おっしゃる通り、ソフトウェア開発はしないの？ともよく聞かれます。
過去に検討したこともあったのですが、RFP作成からコンペに参加して案件を獲得していく、という流れに乗った提案フローはメジャーですよね。その領域に今から踏み込むには、他社とは違う開発プロセスが必要だと考えていました。

――なるほど。

白畠：日々、様々なテストを実行していると、色々なソフトウェアの画面や機能を見ることになります。
例えばインターネットが登場するずっと前から商いをされている企業のソフトやWebサービスって、インターネットがない時代の名残があるものも多いんですよ。なんでこんな仕様にしているんだろう、と。テストをやりながら、そもそものUIの部分で改善すべきことが山のようにある、と感じることが多々ありました。

UI、そしてUXを整えていかないと、利用者自身の価値も高まっていかない。そうだ、UIを世直ししていこう、という発想が生まれ、そこから部門の設立へと発展していったのが、今私がいる「DAAE（ダーエ）」になります。

――DAAEって、何かの略称ですか？

白畠：Design（デザイン）、Agility（迅速性）、Assembly（組み合わせ）、Economic quality（経済品質）の頭文字をとった、当社の「コト」づくりの概念になります。
元々のきっかけは今お伝えした通りなのですが、現在ではさらに考え方を拡張させ、お客様に「売れるサービス」を提供することをミッションとしています。

――具体的には、どんな事業内容なのでしょうか？

白畠：端的に申し上げると、「試作」を作って、βテストを実施し、市場の良い反応を確認できたものを「量産・本格開発」を進める、というアプローチを採用しています。

なぜ、このようなアプローチを採用したかと言うと、QCDが最優先され、エンドユーザが得る利益を評価することの優先順位が下がっているように感じているためです。

日本のIT業界では、QCDの概念を大切にしながら、ウォーターフォール型で進めることが未だに圧倒的に多いです。この傾向は企業規模の大きなお客様に多く、プロジェクト費用は数十億から数百億、開発期間も数年などと年単位で計画されている場合もあります。

――IT大手が扱うプロジェクトって、規模の大きなものが多いですよね。

白畠：ここに、大きな問題が3つあると考えています。
1つ目に、そんな大きなウォーターフォール型プロジェクトをDXの名の下で進めようとしても、それを円滑に進めることができるマネジメント人材は、今の日本にそう多くいないのが現状です。PMの中でも、とりわけ優秀層は4％程度と言われていますが、僕が見る限り、ニーズとしては明らかに4％を超えて必要とされていると感じます。

2つ目は、先ほどお伝えした要件定義です。開発を1年ほど進めると、少しずつ重要な機能の姿が見えてくるようになるわけですが、それをお客様に確認してもらうと、「実際に見てみるとイメージと違った」とネガティブなフィードバックがあげられるケースもあります。また、年単位の開発スケジュールですと、途中で要件に対する考えが変わるなど、ウォーターフォールが苦手とする「後戻り」が発生することも往々にしてあります。

そうなると、部分的な後戻りが発生してしまい、結果としてスケジュール管理どころではなくなってしまうわけです。整理するだけでも莫大なコストがかかることになります。

――ソフトウェア業界にいた身として、非常によく分かります。

白畠：そして3つ目は、アジャイル経験者の少なさです。
今お伝えしたウォーターフォールの欠点を補う進め方として、アジャイルでプロジェクトが組まれるケースも最近では多いのですが、今日の日本にはそもそも経験者が少ないという状況です。プロジェクトオーナーやスクラムマスターなど、本などを参考に見よう見まねで参画するわけですが、本質が腹落ちしていないので、期間を短く区切ったウォーターフォールみたいなアジャイル編成になっていることが多い印象です。

またこれについては、スピード感についていけないエンジニアもいたり、アジャイルなのに少数精鋭でもないプロジェクトも多く存在します。スクラムは、せいぜい5〜6人で組むものだと思うのですが、50人のスクラムもあったりします。

――なるほど。今のIT業界のリアルな現状が鮮明に伝わってきました。これに対する貴社のアプローチが、DAAEということですね？

白畠：はい。DAAEは、今お伝えした中でも特に後者2つ、「要件定義がブレやすい」ことと「アジャイルと言いつつ、実質はウォーターフォールになっている」ことについて、解決しようとする試みです。

また、「風呂敷を大きく広げて一気にスタートするのではなく、優先順位をつけて小さくスタートすることで、プロジェクト遂行の難易度を下げる」こともDAAEの狙いです。つまり、マネジメントの難易度が下がるわけですね。

マネジメントの難易度が下がるということは、1つ目の課題も解決が可能ということ。「DAAE」は、3つの課題全てを解決出来る取り組みであるということになります。

アジャイルに「試作」を作り、「量産・本格開発」を「後戻り」のリスク少なく進める

――先ほど、「試作」を作って、βテストを実施し、市場の良い反応を確認できたものを「量産・本格開発」を進める、というアプローチを採用しているとおっしゃっていましたよね。こちらについて、より詳しく教えてください。

白畠：お客様抱える課題を解決するために、ビジネスモデルのデザイン、サービスのデザイン、UIUXのデザインを行い、これに基づき高速に試作するのが弊社の役割です。

それに欠かせない「試作」フェーズで活躍するのが、DAAEチームのフルスタックエンジニアです。単なる紙芝居のモックではなく、必要最低限の機能を実装させて、実際に動くものをお客様に見てもらい、まずビジネスとして有効な手段かどうかを確認してもらっています。
私たちはこれを「動いて触れる要件定義」と表現しています。

――これによってどんなメリットがあるのですか？

白畠：一番は、お客様の空想を排除し、関係者全員が共通認識を持つことが可能になることですね。従来の「動かない」「触れない」要件定義では、目に見えない範囲を各々で脳内補完してしまい、認識にズレが生じ、「実際に見てみるとイメージと違った」や「後戻り」が起こりやすいと考えています。

完成物のイメージを開発前にしっかりと捉えて、かつ、認識を共有いただけることで、開発途中のイメージギャップによる大きな後戻りのリスクが大幅に減り、より適切なシステム投資をしていただけることになります。

――そのほかのメリットはいかがでしょう。

白畠：そうですね、「試作」には売れるサービスか否かを確認する目的がありますので、「システム構築」ありきの開発は行っていません。
「量産・本格開発」に進む前にあたりが出るまで何度も「試作」を作りβテストを行っています。アジャイルに「動いて触れる要件定義」を作成して終わりではないのです。

1つ目のメリットとゴールは一緒なのですが、「売れるサービスを作ること」が私たちからお客様に提供できる価値だと考えています。

――なるほど。この「試作」を作るチーム編成は、どうなっているのでしょうか？

白畠：基本は、それぞれの人数はプロジェクトに応じて変動しますが、ディレクターとデザイナーとフルスタックエンジニアの3ロールでチームを組みます。アジャイル形式でプロセスをまわして、早ければおよそ2〜3日のスプリントで、実際に動くものを作って顧客に見てもらうことが可能です。

――それは相当早いですね！「試作」でイメージが固まりさえすれば、「量産・本格開発」の段階はウォーターフォール型でも「後戻り」のリスク少なく進められそうに思うのですが、そのあたりはいかがでしょうか？

白畠：そうです。私たちはなにも、ウォーターフォールが絶対的に悪い、とは思っていません。「試作」により要件が固まっている場合の「量産・本格開発」段階については、アジャイル、ウォーターフォールどちらかが良い悪いは無い。プロジェクトにより適している手法を選択すれば良いのではないか、と思っています。

フルスタックエンジニアとして様々な案件へとアサイン

――お話を伺っていると、ものすごくスピーディーで柔軟な動き方をする部署なんだなと感じました。実際に開発現場のお話も伺いたく、まずはナさんのこれまでのご経歴や、現在のお仕事内容について教えてください。

ナ：現在はDAAE推進部のフルスタックエンジニアとして動いています。
2年前に日本に来まして、当時はスタートアップにジョインしていたのですが、昨年SHIFTのフルスタックエンジニア募集の求人を見て応募し、2020年8月に入社して現在に至ります。

――どのようにお仕事を進めているのでしょうか？

ナ：サービスディレクターとUXデザイナーの3ロールでチームを組んで、お客様にヒアリングをしながら提案内容を固めていきます。
通常のアサインもあれば、気になる案件に自分からアサインを申し込むやり方もありますね。

――その仕組みは面白いですね。これまではどんなプロジェクトに携わったのですか？

ナ：入社してから大きく3つのプロジェクトに関わりました。最初は、モバイルアプリの開発に途中参画して、その次はJavaライブラリの開発でした。今はスタートアップの案件に入って、スプリントごとに機能をリリースしています。実は今日もリリース日なんです。

――そんなお忙しい日にありがとうございます！案件の幅が広いですね。

ナ：はい。僕以外のチームメンバーも、例えば大手インフラ系企業のC向けサービスプラットフォームのシステム設計から有名人のオンラインサロンの企画まで、様々な案件に携わっています。

基本的にドキュメンテーションは最小限にして、コードで仕様を決めつつ、試しながら開発を進めています。コード自体がドキュメンテーションになれるように、読みやすさを意識して書いています。

お客様と向き合っているのが自分なので、自分ごと化せざるを得ない

――特に印象に残っている業務は、どんなものがありますか？

ナ：例えばつい先日、機能のアーキテクチャ設計からCI/CDの設定まで、全部で2日でやってほしいというスピード感の依頼がありまして、これはさすがに1人では大変だと思って、外部の専門企業と協力して進めた案件がありました。

DAAEチームだけで完結するのではなく、社内のリソースや、関連するグループ会社と広く連携して進めることができるのは、良い点かなと感じます。

――いいですね。DAAEのフルスタックエンジニアとして働く魅力は、他にどんなところがあると感じますか？

ナ：入社してまだ6ヶ月ですが、携わるプロジェクトによって必要な技術が全部違ったのは、とても面白いなと感じています。フルスタックエンジニアとしての腕の見せどころですね。
あとは、自由度の高さも魅力だと思います。

最初は、受託開発なので自由度が低いのかなと思いましたが、むしろここにきてから色々と自由にできるようになりました。権限も多いと思います。

――それはDAAE事業部だからなのでしょうか？

ナ：一緒にやっているテストチームを見る限り、テストをするという業務についても自由度高く業務設計をして実行していて、それを見て感動したことを覚えています。

また、社内だけではなく社外とのやり取りについても、自由度が高いことに驚きました。お客様に何をしたいのかをヒアリングして、それを持ち帰って自由に組んで、自分で提案することができる。なかなかそういう環境ってないのかな、と感じます。

白畠：お客様と向き合っているのが自分なので、自分ごと化せざるを得ないんですよね。
そもそも、代表が下請け構造が嫌いで、案件をお受けするときのポリシーとして基本的に請負案件は受けないようにしているんです。お客様が困っている課題と直に向き合えるので、それに対する解決策も、イコール開発とは限らないものもあるわけです。

「攻めのDX」として、アジャイル型で提案をし続けていく

――これからのおふたりの目標について、教えてください。

白畠：基本的にはDXの名の下にお客様を支援していきたいと思っています。DXには攻めと守りがあると思っていまして、DAAEは「攻めのDX」として、アジャイル型で提案をし続けていくつもりです。
一方で、「守りのDX」として弊社にはマイグレーション部隊もいるので、攻めと守りの両輪で取り組んでいきたいなと思います。

ナ：お客様のサービスを立ち上げるにあたって、効率的な技術を使い、しっかりエンドユーザーへと届くところまでを、一気通貫で見てみたいなと思っています。

――それらを実現するにあたって、どんな課題があると感じますか？

白畠：少し広い視点になりますが、日本ってフルスタックエンジニアが育ちにくい環境だと感じています。新入社員として入社すると最初にプログラムを学ぶことになって、そこからポジションが上がっていくにつれて、現場から離れていきます。マネジャーになると、プログラムを作る人はいなくなって、部長に至っては触ることもなくなるでしょう。

コンピュータからどんどん離れていき、エンジニアとして採用した金の卵が、段々別のものになっていってしまうのです。
ここに大きな課題感を感じています。

――なるほど。DAAE推進部として、今後どんなメンバーにジョインしてもらいたいですか？

白畠：基本的には日本人にこだわっていません。外国人エンジニアと話をしていると、日本人とは違うアプローチや発想に触れることも多くて、最初は理解できないこともあるのですが、よくよく聞くと「なるほどな」となることも多いのです。

日本人よりも合理的に考える人が多いんだなと思ったと同時に、色んな考え方に触れる大切さを改めて知りました。
もちろん、日本人の方もウエルカムですよ！

――ありがとうございます。最後に、読者の皆さまにメッセージをお願いします！

ナ：フロントエンド でもバックエンドでも、面白いフィールドだと思うので、ぜひ一緒に働きましょう！

白畠：残念ながらITに関しては、日本は世界から大きく遅れをとっています。それゆえに、国内だけで活動しようと思っている企業も多いので、DAAEとしては、世界に打って出ていけるようなお客様をどんどんと増やしていきたいと思っています。
小さな一歩かもしれませんが、夢を持ちながらやっているので、興味あればぜひご一緒しましょう！

編集後記

お話を伺っていて非常に印象的だったのが、おふたりとも目の前のクライアントはもとより、その先のエンドユーザーを強く意識して、各プロジェクトを捉えていらっしゃったことでした。
より適切なシステム投資をすることで、結果としてエンドユーザーへの提供価値も高まる。まさに、品質保証のエキスパートとして数々のシステムUIに触れてきたSHIFT様だからこそ、文化として持てる視点だと感じました。
まだまだ立ち上がったばかりのDAAE事業部の、今後の動きに期待したいと思います。

取材／文：長岡 武司
撮影：太田 善章