
How to Build an App with OutSystems
An idea for an app is only as good as your ability to bring it to life, and we all know software development is far from simple. In this blog post, we'll show you how to build an app using using low-code.
ソフトウェアとは、コンピュータに何をすればよいかを伝える一連の指示です。また、ソフトウェア開発とは、コンピュータプログラマーがテクノロジーを通じて消費者や企業に価値を提供するプロセスのことです。
ソフトウェアは、プログラマブルコンピュータという概念の中核をなすものです。この概念は、1936年にAlan Turing氏によって初めて提起されました。その7年後、IBMの社長だったThomas Watson氏は次の有名な言葉を残しています。
「コンピュータは全世界で5台ぐらいしか売れないと思う」
2020年に約2億7,500万台ものパーソナルコンピュータが出荷されることになろうとは、当時は誰も想像していなかったに違いありません。
多くのユーザーが使用するソフトウェアには2つのタイプがあります。
ソフトウェアアプリケーションを作成するユーザー向けの3つ目のタイプとしてコンピュータプログラミングソフトウェアがあります。これは、一般ユーザーが日常的に使用するアプリケーションを開発者が作成する際に必要なツールです。
既製のソフトウェアは、必要とする機能をすべて(またはほとんど)備えています。そのため、消費者や企業の多くはそれを購入することを選択します。最近まで、こうしたソフトウェアは企業が所有・管理するハードウェアデバイス上でアプリケーションを使用してホストされていました。
現在は、サービスとしてのソフトウェア(SaaS)を利用する企業が増えています。このデリバリーモデルでは、クラウド上でホストされているソフトウェアにブラウザでアクセスすることになります。SaaSを利用すると、企業はユーザーあたり/月あたりの料金を支払うだけでよくなり、所有コストや保守コストをゼロにすることができます。
一方、固有のニーズがあったり、デジタルテクノロジーを利用してビジネス上の優位性を獲得しようと考えたりする企業もあります。そういった企業は、独自のカスタムソフトウェアを社内チームで開発するかもしれません。開発したソフトウェアは、オンプレミスでもクラウドでもデプロイできます。
ソフトウェアの作成には様々な職種が関わります。
それをリードするのが、アプリケーションの全体的な設計を担当するソフトウェアエンジニアです。ソフトウェアエンジニアは、ソフトウェアの作成やテストにエンジニアリングの原則を適用します。
コンピュータプログラミングの大部分は開発チームが行います。開発チームは主なステークホルダーと連携し、ニーズを把握します。その後、開発ツールを使用してアプリケーションを実装し、設計に沿ったものになるようにします。
いずれのグループでも、ソフトウェア開発ライフサイクル(SDLC)を利用します。SDLCは、高品質なソフトウェアを効率的に作成するための構造化されたプロセスです。長期間にわたる複雑なソフトウェア作成タスクを、個別のステップに分割しています。
SDLCには数多くの幅広いメリットがあります。一番のメリットは、最大限のスピードと最小限のリスク/コストでソフトウェアを作成できることです。これを可能にするのが、すべての作業と成果を定義する標準のフレームワークです。
SDLCには複数のプロセスモデルがあり、それぞれ長所と短所があります。不適切なモデルを選択すると、プロジェクトが失敗するリスクが高まります。そのため、この決定は慎重に考えたうえで行う必要があります。よく利用されるモデルは以下のとおりです。
通常、このプロセスには6つの段階があります。
SDLCの基礎となる最も重要な段階です。目的やプロセスが明確になっていないと、プロジェクトのコストとリスクがいずれも高くなりがちです。ソフトウェアベンダーがソフトウェアを作成する場合、この段階で広範な市場調査を行う必要があります。ソフトウェアを内製する場合、プロジェクトリーダーは主なステークホルダーとコミュニケーションをとり、プロジェクトに期待される成果を把握する必要があります。いずれの場合も、この段階でのゴールはソフトウェア要件仕様書(SRS)の作成です。これには、ソフトウェアに実装する予定の機能と想定される動作を記載します。
ニーズを把握したところで、ソフトウェアの設計を開始します。これが、アプリケーションの大まかなアーキテクチャを示すソフトウェア設計仕様書(SDS)となります。この中で、使用するハードウェアプラットフォーム、OS、プログラミング言語を規定します。また、製品のすべての主要モジュールと、外部要素やサードパーティ要素との通信およびデータフローを定義します。その後、プロトタイプやPoC(概念実証)を作成し、大きな問題を洗い出したり、要件を具体化したりします。
この時点から実際のソフトウェア作成が始まります。ここで重要なのが、SDLCで事前に定義した計画にコーディングチームの各メンバーが従うことです。このチームには様々なスキルを持つメンバーがいます。フロントエンドエキスパートはユーザーインターフェイスを取り扱います。データベース管理者(DBA)はデータの適正化を担当します。ソフトウェア開発者はコードの作成と実装を行います。
ソフトウェアが完成したら、コードが所定の要件を満たしているか確認することが肝心です。ここで作業は品質保証(QA)チームに引き継がれます。QAチームは完成したソフトウェアをテストし、バグにフラグを設定してコーディングチームが修正できるようにします。ソフトウェアが必要な機能・品質水準を満たすまで、このプロセスが続けられます。
コードのテストと承認が完了したら、本番環境にリリースすることになります。市販ソフトウェア製品の場合、このときにカスタマイズや追加テストを行うこともあります。この段階で、トレーニングやサポートについても検討します。適切に使用できなければ、ソフトウェアの良さを活かしきることができません。また、どのソフトウェアであっても実際の環境に応じて調整を続ける必要があります。新たなセキュリティの問題が発生したり、新たな(または見逃していた)ユーザー要件が見つかったりするからです。ソフトウェアを適切な状態に保つには、絶えず開発を続けることが大切です。つまり、小規模でもよいので継続的にSDLC全体を繰り返す必要があります。
プログラマーにとって、信頼性の高いドキュメントは不可欠なものです。ドキュメントがあると、完成したソフトウェアの様々な要素を監視する際に役立ちます。また、更新や改善がしやすくなるため、長期的な品質を向上させることができます。優れたドキュメントにより、情報へのアクセスや知識移転がスムーズになります。新しいユーザーが必要な知識をすばやく習得できるため、サポートコストの抑制にもつながります。ドキュメントに含まれる内容としては、ビジネスルール、データベースレコード、サーバープラットフォーム、インストールとデプロイなどの情報などが挙げられます。
「実装後レビュー」と呼ばれることもあります。すべての企業が正式にSDLCに含めているわけではなく、保守の一環と考える企業もあります。様々な意見がありますが、評価が重要であるということは間違いありません。評価段階では、システムが最初のニーズや目的に対応していることの確認や、システムの安定性の証明を行います。欠陥の特定と修正もこの段階で行います。さらに、開発プロセス自体の有効性を調べる機会にもなります評価を行うことで、今後のプロジェクトの改善につながる重要な教訓を得られるかもしれません。
ソフトウェアの作成は複雑であるため、SDLCではプロジェクト管理が重要になってきます。プロジェクトマネージャーの役割は多岐にわたります。プロジェクトに関わるすべての人員やチームを管理し、安定性と目的への適合性を備えたアプリケーションが完成するよう、品質の確保に努めます。また、プロジェクトの成功を支えるすべての関係者に常に最新の情報が行き渡るようにすることも大切です。
セキュアSDLC(SSDLC)は、ソフトウェアの作成にセキュリティを組み入れ、セキュリティが後付けにならないようにするアプローチです。既存のSDLCアプローチにセキュリティを追加するためのベストプラクティスが集約されています。SSDLCは単なるプロセスではありません。開発チームの意識改革が求められます。機能のことを考えるだけは不十分であり、SDLCの各段階でセキュリティを重視していく必要があります。このアプローチでは、セキュリティ上の欠陥を早い段階で特定できるため、修正に必要なコストを削減できます。
長きにわたり、ソフトウェアといえば「プロプライエタリ」か「クローズドソース」でした。これは、ソフトウェア作成者の知的所有権を保護するものです。一方で、開発者が固有のニーズに応じてコードを調整することの妨げにもなっていました。法律上、クローズドソースソフトウェアのコピーや変更を行うことができるのは元の作成者だけだからです。
ユーザーは、コードの改ざんを一切行わないことを誓約するライセンス契約に署名することを求められます。Microsoft WindowsやApple macOSはいずれもクローズドコードソフトウェアの例です。
1990年代半ば、多くの企業で利用されていたUnixプラットフォームの代替として、オープンソースのLinuxが普及し始めました。それを皮切りとしてオープンソースの気運が高まり、やがてソフトウェア作成の基盤として幅広く受け入れられるようになりました。opensource.comによると、オープンソースという用語は次のように定義されています。
「誰でも調査、変更、改良を行うことができるソースコードを使用したソフトウェア」
オープンソースは自由に使用できますが、条件もあります。オープンソースを改良した場合、コードの作成元であるオープンソースコミュニティにそれを還元する必要があるのです。
現在、オープンソース製品の数は180,000にのぼり、企業の9割に利用されています。多くの企業が、プロプライエタリコードをオープンソースコミュニティに寄付することを選択しています。たとえば、Googleはコンテナ化されたワークロードを実行するプラットフォームであるKubernetesをCloud Native Computing Foundationに寄付しています。このようにして、Kubernetesのテクノロジーが業界のデファクトスタンダードになったのです。
実のところ、ある企業にオープンソースソフトウェアとクローズドソースソフトウェアのどちらが適しているかを断言することはできません。それぞれメリットとデメリットがあるからです。クローズドソースソフトウェアの最大のデメリットはコストが発生することです。しかし、クローズドであることで、代替となる無償の製品よりも優れた機能が提供されると考える人にはデメリットになりません。たとえば、Microsoft Office 365は世界中の100万社の企業で利用されています。無償で利用できるGoogle G Suiteがあることを考えると、これは興味深いものです。また、プロプライエタリソフトウェアは他のIT資産との高度な連携を備えている傾向にあります。
オープンソースソフトウェアの熱心な支持者は、世界中の数千万人の開発者で構成されるコミュニティを重視しています。この大規模なリソースがあれば、ほぼ制限なくイノベーションを実現することが可能です。ただ、オープンソースソフトウェアは、使いにくい場合や、他のソフトウェア製品との互換性がない場合があります。また、保証やサポートといった面で問題がある場合もあります。
ソフトウェア開発の最大の課題は、開発そのものの難しさです。時間(そして忍耐)を要するうえ、パブリッシュしてもそれがゴールではありません。変化し続けるこの世界では、ユーザーのニーズに応じてソフトウェアを進化させ続ける必要があるからです。
幸いなことに、今はアプリ開発を高速化し、アプリケーションライフサイクルの大部分を自動化できるツールが組み込まれた、最新の開発アプローチがあります。
OutSystemsは、本格的なアプリケーションを迅速かつ効率的に構築できるソフトウェア開発ソリューションです。
ビジュアルモデル駆動開発環境と業界最高水準のAI支援によって、アプリの開発期間を数か月や数年から数日や数週間まで短縮します。また、プラットフォームサービスにもAIが組み込まれ、アプリケーションライフサイクル全体の強化が自動化されています。そのため、アプリをワンクリックでデプロイでき、これまで以上に簡単に管理できます。ぜひサインアップしてOutSystemsの無償版をお試しください。