2020/08/11
西日本技術部 第二技術室

はじめに

スクラッチ開発って楽しいですね。止められません。
顧客要件を確認し、要件を満たすために一から設計し、頭を抱え四苦八苦しながらコーディング。
顧客要件が変われば設計に立ち戻りまた一からコーディング。頭を抱え四苦八苦しながらコーディング。
ブラックボックス、ホワイトボックス試験もなんのその。プログラミングって楽しいですね。
技術や流行りのフレームワークもころころ変わるので、変化に富んだ刺激的な毎日が送れています。

・・・・・・・・・・・・・嘘です。超大変です。

エンジニアは日夜最新の技術動向にアンテナを張り、知識を付けるため精進するのはもちろんのこと、セキュリティ対策、品質の向上に向けて切磋琢磨しております。（正直しんどい。）私もそんなエンジニアの一人です。
ただ・・・・ここ数年で潮流が変わってきている。そんな気がしております。

・如何に顧客要件に柔軟に対応出来るか。
・如何にスピーディーにシステムを導入出来るか。
・如何に品質の高いシステムを提供出来るか。

通常のスクラッチ開発では実現しづらい要求が増えており、私たちエンジニアはそれらに応えるため最適なソリューションを選択しなくてはなりません。
今回のコラムではそうしたソリューションの一例をご紹介させていただきます。

きっかけ

ある顧客から

・既存の業務を撤廃し、新たな仕組みを構築する
・要件が決まり切っていないため柔軟な対応が可能であること
・商用サービスであるためユーザビリティの高いインタフェースとすること
・短期間でPoC可能な状態とすること
・機微な情報を取り扱うためセキュリティを担保すること

といったシステム開発の要求がありました。通常のスクラッチ開発では要件が決まり切っていない状態ではなかなかスタートすることが出来ません。ましてや短期間でセキュリティを担保するとなるとかなりハードルが高くなります。
このソリューションにどう取り組むべきか社内のナレッジを結集し次の結論に達しました。

アジャイルという選択

まずは以下２つの要求を実現するためアジャイル開発を選択しました。

・既存の業務を撤廃し、新たな仕組みを構築する
・要件が決まり切っていないため柔軟な対応が可能であること

アジャイル開発はご存知かと思いますが改めて説明させていただきますと、システム及びソフトウェア開発におけるプロジェクト開発手法のひとつで、大きな単位でシステムを区切ることなく、小単位で実装とテストを繰り返して開発を進めていきます。このくり返しをイテレーションと呼びます。従来の開発手法に比べて開発期間が短縮されるため、素早い＝アジャイルと呼ばれています。

本プロジェクトでは、そのアジャイル開発の主流である「スクラム」を採用しました。
スクラムはチーム一体となってシステム開発を行うフレームワークのことです。スクラムでは顧客も開発チームの一員となり、コミュニケーションを重視した開発を行います。
デイリースクラム（朝会）、プロダクトバックログ、スプリント計画、スプリント、スプリントレビュー、振り返りの６つのアクティビティを通じて柔軟性と短期間でのアウトプットを実現します。

クラウド製品の複合という選択

問題は残りの要求です。

・商用サービスであるためユーザビリティの高いインタフェースとすること
・短期間でPoC可能な状態とすること

ユーザビリティの向上と短期間での開発はスクラッチ開発ではなかなか両立し得ない要求となります。そこで我々はOutSystemsという製品を使用しこの課題を乗り越えました。OutSystemsはポルトガルのOutSystems社によって開発されたローコード開発ツールで、このツールによりユーザビリティの高いインタフェースを短期間で実現できます。

残る１つの要求

・機微な情報を取り扱うためセキュリティを担保すること

に対しては、商用サービスのデータメンテナンスはそれほど高いユーザビリティが求められなかったこともあり、Salesforceを選択しました。Salesforceは皆さんご認識の通りかと思いますが、世界シェアNo.1のCRMアプリケーションとなります。※セキュリティに関しては言わずもがなです。

変化する顧客要求の実現のため

OutSystems(クラウド版)　＋　Salesforce

といったクラウド製品の組み合わせが必要となってきたわけです。
両製品ともアジャイル開発に適しており、品質を高く保ち、セキュリティを担保しながら素早くシステムを提供することが出来ます。

見えてきた課題

実際にスクラム開発を進めるうちにいくつか課題も見えてきました。

■スクラムの課題

スクラムのスプリントを進めていくと、顧客の機能に対する要望や要件が途中で膨らむ事が多々あります。そのたびにスプリント計画を立て直すのですが、次第にプロダクト最終目標が見えにくくなり、終わらないスクラムの罠に陥ることが課題あります。
スプリント計画はもちろん大事ですが、スプリントの全体計画の方がより重要であり、かつ、プロダクトの最終目標を見失わないことが最も重要となります。プロダクトの最終目標がブレた場合は一旦スプリントを止めてでもプロダクトの最終目標を整理し直す必要があります。

■クラウド製品の複合における課題

クラウド製品を組み合わせる場合は、製品間をAPI等で連携する必要があります。
ただし、連携にあたり、例えばSalesforceのガバナ制限等、クラウド製品の制限により期待したパフォーマンスや同時接続数、同時実行数等を担保出来ない事が課題として発生しました。
対策として、APIコール数や製品特有の制限等の理解等、製品選定時に熟知しておく事が求められます。

これからの開発主流

「はじめに」でも述べましたが、現在の開発では

・如何に顧客要件に柔軟に対応出来るか。
・如何にスピーディーにシステムを導入出来るか。
・如何に品質の高いシステムを提供出来るか。

が求められています。これは目まぐるしく変化する市場やニーズ及び社会情勢に対し顧客のシステムを柔軟に対応させるためです。我々はクラウド製品の複合とアジャイル開発を組み合わせることにより、このニーズに応えられると確信しています。

もちろんスクラッチ開発の環境は以前に比べ各段に良くなっており、開発スピードも各段に上がりましたが、クラウド製品とアジャイル開発のスピード感には劣ります。

これからはクラウド製品とアジャイル開発によるソリューション提供が開発の主流となります・・・・というか既に主流となっております。今後はクラウド製品の熟知はもちろん、クラウド製品同士を繋ぐ技術について如何にナレッジを保有しているか、顧客ニーズを超える価値を提供出来るかがキーとなると感じています。

おわりに

このコロナ禍において、サーバ構築やネットワーク構築、オンサイトでのアプリケーション開発といったプロジェクトの中には停滞、遅延するものが複数ありました。一方でクラウド製品を用いた開発プロジェクトは何の問題もなく開発が進められており、情勢に左右されないクラウド製品の強さを実感しました。
また、ここ数年でクラウドシフトする顧客が多いように感じ、クラウド製品のランニングコストに関するインパクトはそこまでハードルが高くなくなって来ました。（実際に以前はランニングコストを気にしてクラウド提案を断っていたお客様が一にも二にもクラウド！と思考が変わってきております。）
そういった事情も踏まえると「これからの開発主流」で述べた内容は言い過ぎでは無いと思います。

一口にクラウド製品と言っても深さ、広さが果てしなく、ついつい既知のシステム言語や開発手法を提案したくなることもあります・・・・・・ですが、社会、お客様はもとより、自分自身の変革のため、また、三井情報としてのナレッジ蓄積のため、新しい事にどんどんチャレンジしていきたいと考えております。

関連ページ

おすすめコラム：

ノーコード/ローコード開発への取り組み

関連ソリューション：

顧客管理・営業支援｜Salesforce