業務部門の非エンジニアによるローコード／ノーコード内製化のポイント
目次
はじめに
システム内製化の手段として、ローコード開発が注目を集めています。
米国の調査会社ガートナーの調査によると、2024年までにアプリケーション（以下、アプリ）開発の65％はローコード開発が担うようになるそうです。
ローコード開発は、可能な限りソースコードを書かずにアプリを開発できるため、プログラミングの専門知識がない方でも利用することが可能です。
そのため、簡易的なものであれば自分たちの手でアプリを作成する企業が増えてきています。
また、ローコード開発を行うローコードプラットフォームはクラウド型で提供されているものが多く、開発に必要な環境がすべて用意されているため、アプリケーションを素早く開発できるのもメリットの１つです。
しかし、こうした現場主導で作成されるアプリを使い続けてもらうためには、少し工夫が必要です。
そこで、この記事ではローコードの導入や開発等を実際に現場で行った経験から、現場担当者である非エンジニアが現場で使い続けてもらうアプリを作成・運用するためのポイントについて解説していきたいと思います。
※ローコードとは別に、全くプログラミングを必要とせずにアプリ開発を行う「ノーコード」も存在しますが、本記事ではノーコードもまとめてローコードと呼ぶことにします。
ローコード開発が企業に注目されるワケ
そもそも、なぜローコード開発が企業に注目されているのでしょうか。いくつかありますが以下が代表的な理由として挙げられるでしょう。
- 短期間かつコストをかけずに開発できる
ローコード開発のメリットとして第一に挙げられるのが、開発期間の短縮です。
あらかじめ用意されている部品を組み合わせて視覚的な操作でアプリを開発できるため、その分開発工数を削減できます。
また、従来のシステム開発の場合はベンダーに開発を委託することが大半でしたが、ローコードプラットフォームによる開発の場合は担当者の作業範囲が広がるため、外注コストの削減も可能になります。
- ビジネスニーズに素早く対応
ITシステムが業務に欠かせない今、企業をとりまくビジネス環境の変化が加速しており、よりタイムリーで、柔軟で、迅速な対応がシステムに求められる時代になっています。
その点で、ローコードプラットフォームは容易かつ短期間で開発可能で、素早く利用者のニーズを反映できるアジャイル型の開発手法と親和性が高く、ビジネス環境の変化にも柔軟に対応するため、企業の競争力向上にも大変重要な役割を果たします。
- DX推進の後押しとなる
昨今のトレンドワードでもある「市民開発」という言葉が意味するように、企業がデジタルトランスフォーメーション（以下、DX）を進める中で、ローコードプラットフォームを使って業務知識がある現場担当者によるアプリ開発の内製化を進めることで、DX人材不足の解消につなげることもできます。
また、業務部門主導によるデジタル化を進めることで、これまでのような専門家に任せておけばよいというスタンスではなく、自分事としてとらえるようになるため、現場のデジタルに対する主体性が向上します。
このように、ローコード開発を取り入れることで業務部門のみならず経営目線でもメリットが大きいことがわかります。
業務部門の非エンジニアがアプリを作成・運用する際の課題
多くのメリットがあるローコード開発ですが、一方でこれまでエンジニア経験のない現場担当者がアプリを作成・運用するがゆえに以下のような壁にぶつかることもあります。
汎用的な作りになっておらず、メンテナンスに時間がかかる
現場担当者によるアプリ開発を行う場合は、本業の傍らで開発・メンテナンスを行うケースが多く、アプリの作りが汎用的になっていないことで作業工数が多くなり本業に影響してしまうことは避けたいところです。
特にローコードによるアプリ開発では、限られた画面サイズの中に様々なオブジェクトを配置するため、オブジェクトが増加した場合にレイアウトが破綻するような作りでは、各オブジェクトのサイズや位置の修正等に多大な労力がかかることになってしまいます。
アプリの仕様に抜け漏れがあり、本来されるべき処理がなされない
アプリユーザーの要求は段階的に高度化していきます。
最初はうまく機能していたのに、ユーザーからの要求が高度化していくにつれ、アプリの機能にムラができるとユーザーからのアプリに対する信頼が下がり、結果として現場に使われなくなるアプリとなってしまいます。
アプリ管理が属人化しており、アプリ所有者がいないと業務が止まってしまう
アプリのメンテナンスが作成者しかできない状況等、アプリの管理が属人化すると、例えばアプリ所有者が休暇等で不在の際や退職・異動した場合はメンテナンスできる社員がおらず、最悪な場合業務が止まってしまうリスクがあります。
現場で使いつづけてもらうアプリを作成・運用するためのポイント
上で課題を３つ挙げましたが、今度は各課題に対する対策についてみていきましょう。
汎用的な作りにするためのポイント
汎用的な作りにすることでアプリの保守性が高まる（＝メンテナンスの作業工数が少なくなる）メリットがあります。
特に、将来的に取り扱い対象の増加等が想定できる部分は拡張できるように実装を行うとよいでしょう。
ここでは、MicrosoftのローコードプラットフォームであるPower Appsで作成したサンプルアプリ「自治体の更新情報配信登録アプリ」を例にしてアプリ作成の際のポイントをご紹介します。
- レスポンシブなレイアウトにする
レスポンシブなレイアウトとは、アプリを表示する端末の画面サイズに応じて、画面レイアウトを柔軟に変更する技術を指します。
Power Appsでは、レスポンシブデザインを実現する方法がいくつかありますが、ここでは①コンテナを使用する方法と②フォームを使用する方法についてご紹介します。
1.コンテナを使用する方法
レスポンシブなレイアウトを実現する方法の一つとして、コンテナを使用する方法があります。
コンテナとは複数のオブジェクトをその中に配置することでグループ化してくれるコントロールのことを言います。
このコンテナを利用することで、アプリ利用端末の画面サイズに応じて柔軟なレイアウトが実現できます。
サンプルアプリでは画面上部に都道府県名が記載されたボタンが並んでいますが、画面に収まりきらない場合は水平方向にスクロールすることが可能な作りになっています。
また、ボタンをコピペすると、コンテナ内でサイズ最適化されるため、画面内でのオブジェクトのサイズ修正などの細かな作業は不要になります。
2.フォームを使用する方法
フォームとは、SharePointリスト等のデータソースのデータを表示・編集・作成を行う際に使用されるコントロールです。
フォームを利用することで、オブジェクトの数や大きさに応じて画面レイアウトが最適化される他、アプリに接続されているデータソースのフィールドを動的に配置することが可能です。
例えば、サンプルアプリでは以下のSharePointリスト「宮城県」をデータソースとして利用していますが、市町村「富谷町」が追加になる場合（リストの列が追加になる場合）は、アプリ編集画面のオプション画面から簡単にフィールドを追加することができます。
- データの委任制約に注意
なお、Power Appsを利用してアプリ作成を行う場合は、データの委任制約に注意する必要があります。
データの委任制約とは、SharePointリストをデータソースとして利用する場合に5000件までのリストアイテムしかアプリの取り扱い対象とならないといった制約のことを言います。
5000件を超過した場合データの一部が処理対象として抽出されなくなるため、アプリを作成する際はこの点を考慮する必要があります（これを知らずに開発を進めると、上限を超過したときに大改修が発生する可能性があります）。
委任制約の対策としては①データソースを一定のカテゴリ単位で分けることで制約を回避したり、②上限数に達しないようにデータソース更新時にアイテムが上書きされる作りとするといった方法が考えられます。
仕様の抜け漏れを防ぐためのポイント
業務知識のない業務に対してアプリを作成するケースでは、あらかじめユーザーから要求を聞き出したうえで、開発するアプリの仕様を決めることが必要です。
ここでは非エンジニアの方が要件定義を進めていくうえで抑えておきたいポイントを紹介します。
- 複数回ユーザーとの打ち合わせ時間を確保しておく
ユーザーに業務内容や手順に関するヒアリングを行うことでアプリの仕様を固めていきます。
ヒアリングでは要件の抜け漏れが発生することを前提にしたうえで、複数回ヒアリングの時間を設定することをおすすめします。
ちなみにこれまで私が経験したプロジェクトでは、少なくとも２回はヒアリングをしています。
- アプリ作成前にこれまでの要件についてユーザーと合意形成しておく
アプリの仕様に関して、ユーザーとの「言った、言わない、聞いていない」といったやり取りはよく起こります。
原因はメモの取り忘れや説明不足等様々考えられますが、要件が漏れると場合によってはアプリの作り直しになるなど作成者にとっても致命的になることがあります。
これを回避するには、アプリ完成後に不満が出ないよう要求を事細かく合意しておく必要があります。
具体的にはアプリ作成前にユーザーとのレビュー会を設けることでこれまでの要件と実装機能等について認識を合わせておくことが重要です。
アプリ所有者が不在でも継続利用してもらえるためのポイント
アプリ所有者が不在でも業務停止が発生することを回避するためにいくつか工夫が必要です。
- 共同所有者を任命しておく
Power Appsでは、アプリの作成者（＝所有者）と、アプリ利用のみ可能なメンバの他に、アプリ利用に加えアプリの編集や共有を行うことが可能な共同所有者と呼ばれる権限が存在します。
共同所有者を置くことで、主担当／副担当のような関係でアプリ所有者が不在でもアプリのメンテナンスを行うことが可能となります。
- 不具合発生時の対応フローを決めておく
アプリの不具合対応において、復旧までにかかる時間をできるだけ短くすることは大切です。
あらかじめ不具合発生時の対応フローを決めておくことで、迅速な対応ができユーザーのアプリに対する信頼性が高まることでアプリの継続利用につなげることができます。
また、アプリの規模によると思いますが、対応フローに加えてユーザーからの問い合わせ先や関係者への周知方法や報告内容、障害対応を行うための体制についても標準化しておくことをおすすめします。
- 作業内容や手順をドキュメントに残しておく
将来的に要件追加が発生すると想定される部分などは事前にメンテナンス項目や手順をドキュメントに残しておくことも重要です。
例えば上のサンプルアプリでは、将来的にある都道府県が追加となるケースが想定できますので、作業項目として都道府県ボタンの追加作業手順であったり、対応する登録画面の作成方法等についてあらかじめ手順を明示しておくとよいでしょう。
おわりに
いかがでしたでしょうか。
今回は業務部門の非エンジニアによるローコード／ノーコード内製化のポイントについてご紹介しました。
ITシステムの内製化に舵を切る企業が増えている今、アプリ開発の敷居が低いローコード開発はシステム内製化とマッチしているといえます。
しかし、ローコードプラットフォームを用いて開発を進めていきたいと考えても、どのように進めたらいいかわからない場合や、社内にIT人材が不足している場合は、外部のリソースを活用して内製化を進めていく必要があります。
弊社では、これまでお客さまのローコードプラットフォームの検討・導入・拡大の各フェーズにおける支援を多数行ってきました。
- 高度なアプリ作成（画面数が膨大、処理ロジックが複雑なケース等）
- クラウドをはじめとする各種サービスとの連携による業務プロセスの自動化
- ローコードプラットフォームの比較・検討
- 社内推進体制作り
- 技術者の育成
- 運用定着化 等
現在ローコードプラットフォームの導入についてご検討中、または導入後の進め方についてお困りの方は一度実績豊富な弊社にお問い合わせください！
関連記事
最新情報をお届けします！
RPAに関する最新コラムやイベント情報をメールで配信中です。
RPA領域でお仕事されている方に役立つナレッジになりますので、ぜび登録してください！
- April 2024 (1)
- March 2024 (1)
- February 2024 (1)
- January 2024 (1)
- December 2023 (1)
- November 2023 (2)
- October 2023 (3)
- September 2023 (1)
- August 2023 (4)
- July 2023 (2)
- May 2023 (2)
- April 2023 (3)
