はじめに

こちらの投稿は個人的な見解であり、所属する組織とは関係なく、またMicrosoftなどの公式見解をもとにした記載でもありません。

私が個人的に感じていることをつらつら無責任に記載したポエムみたいなもんだと思って「こんな考えもあるんだなー」程度に見てもらえればー

また、なるべく多くのノーコード/ローコードを利用した市民開発が対象となるように記載しますが、私が最も知っているPower Platformが基礎となって記載されてしまっている点にご留意ください。

市民開発を行う上で意識したいこと

開発全般

対象業務の選定

DX化を行うにあたり、どの業務を対象にするのか。優先順位はどうするのか。を明らかにするために現行の業務の洗い出しをまずは行うことになるかと思います。
対象の決め方や優先順位の付け方はその組織での状況によって変化してくるかと思いますので、ここでの詳しい言及は控えたいと思います。

ただ個人的な意見を述べておくのであれば、業務重要度がそこまで高くなく、また影響する範囲もそこまで広くないものを対象にして、スモールスタートで始めるのがいいのではないかと思っています。
重要度高いやつや影響範囲広いやつをいきなり対象にするのがあまりよろしくない。というのはなんとなく感覚でわかるかもですが、逆に低すぎるのもあまりよくないです。
折角作ったのにあまり利用されないとなると、開発者のモチベも下がりますし、フィードバックの収集や協力者の巻き込みも上手くいかないからなどなどの理由があるからですね。

システム化する際に気を付けたいこと

システム化する際に絶対に意識してもらいたい点として、現行の業務をそのままシステム化することは絶対に辞めてください。

経験上ほぼ確実に不都合がでます。

対象の業務が決まったら次はその業務のタスクを今一度見直してください。
そしてそのタスクの必要度を話し合ってください。

タスク整理が為されておらず、無駄なフローがあるようであればここで見直します。
必要/不要の判断がつかないタスクがあるようであれば、一度要件から外してみるのも一つの手です。(これをやるためにも重要度が高くないものをまずは選んでいます。)
外して運用してみて、あとから必要なことが分かった場合はその際に機能追加する。というのもありです。
これができるのも市民開発(内製開発)の一つの利点です。
自分たちで開発・運用しているわけですので、比較的はやくアップデートが行えますよね。

また、必要なタスクだったとしてもシステム化(または特定のサービスで市民開発)を行うには不向きなタスクなんてものもあります。
そういったものを知識ゼロから判断していくのは大変だと思いますので、社内の有識者や情シス。もしくは知見のある会社に依頼するなどして、初期展開は一緒にDX化を行っていく。というのがおすすめですかね。

それらができない状況であれば、、、失敗から学びつつ頑張って知見を貯めていくことになりますかね、、、

端的にいうとお金を取るか。時間を取るか。になってしまうかと思います。

将来的にCopilotなどでこれらができるようになるといいですが、それをするためには業務要件の言語化ないしは図解が必要になってきますし、それを理解したうえでの提案をCopilotに求めるのは現行の技術ではまだちょっと厳しいかなぁ、、、と思っています。

データソースの用意

システム化を行うにあたってデータソース(DBのことです。マスタデータやトランザクションデータを貯める場所のことです。)は高確率で必要になってくると思います。

ここで作成するデータソースはできる限り有識者に相談することをおススメします。
そして、市民開発を推進する立場の人はデータモデリングの基礎についての社内学習コンテンツの展開など、市民開発者がデータ設計について学ぶことができる機会をきちんと用意してあげてください。

データ設計がぐちゃぐちゃだとデータをCRUD処理する際に非常に苦労することになってしまいます。
これは市民開発でも一般的なコーディングによる開発でも同じことです。

そして一度動き出したシステムのデータ設計を変更することは非常に手間です。

従ってデータ設計は有識者の知見を仰ぐことをおススメします。
そして、市民開発を推進する立場の方は市民開発者のデータ設計に関する基礎知識をあげるための教育機会の提供や、有識者の育成にも力を入れてあげてください。

少し難しいのはPower Platformなどで扱うデータソースは、一般的なコードを用いた開発で行われるようなデータ設計を行うのが必ずしも正解ではない。ということですかねー

例えばPower Appsですと、INNER JOINなどを行うのはちょっと(大分)めんどうなんですよね。
できないこともないですが、よく利用するデータソースがJOIN前提の構成だとちょっときついかも。

次に意識するのはデータの置き場ですね。
現行踏襲でExcelという選択肢も、、、まぁ、、、ダメとはいわないですけど基本的におすすめはしないですかね。

Excelはデータの型設定ができなかったり、アクセス許可管理が難しかったりなどなどの問題があったりします。
その他にもPower Pltformでの利用を考えるならいくつかの制限事項があったりします。

learn.microsoft.com

他データソース(例えばMicrosoft List(SharePoint List)やDataverseなど)がどうしても使えない。という理由がない限りは基本的にデータソースには向かないので避けた方が無難です。

稀によく「Excelでの編集を引き続き行いたいので...」というような話を聞いたりしますが、その運用は諦めてください。
データ編集を行いたいのであればそれようのアプリを開発してそこから利用させましょう。

よっぽどのことがない限り基本的にデータを直で弄るなんてことはしないです。
辞めましょう。

市民開発を行う

"市民開発"っていってるぐらいなので、基本的にはその業務を行っている。もしくは担当しているチームで開発を行うようにしましょう。

初期導入中で該当チームの知見が足りない。という場合は、他知見のある人に頼ることになってしまいますが、その場合でも絶対に他人事として俯瞰するようなことはしないように or させないようにします。

「最終的には自分たちで運用を行うことになるんだ」ということをきちんと理解したうえで一緒に開発を進めるようにしましょう。
間違えてもお客様になってはいけません。
市民開発を行う上で"お客様"という登場人物は登場しません。

スキルレベル

次に開発に利用する技術ですが、開発者だけでなく運用保守を行うメンバーのレベルにも併せて開発を行いましょう。
作成されたシステムは今後一生一人で面倒見るわけではないかと思います。

Power Platformを例に挙げると割と頑張ればある程度のこともできちゃいます。ゲーム作れるぐらいですからねw

ただそうして作成されたシステムは他の人も理解できるような作りになっていますか？
もしくは他の人も理解できるようになるための教育コンテンツが用意されてる or 用意される予定ですか？

自分ひとりしかわからないものを作っちゃうと、厳しい言い方をするとそれは塩漬けシステムとなりやがて技術的負債となってしまうこととなります。
したがって自身のメンバーのレベルに合わせた開発を行うようにすることをおススメします。

やる気のある方でしたら、今後の開発も見越して自身及び周囲のスキルアップのためにも開発中や開発後に尽力してもらっていいと思います。

ここまで読んでいただいて流れ的になんとなくわかってるかと思いますが、市民開発を推進される方はこういった問題を解決するためにも学習コンテンツをちゃんと用意して、市民開発者がスキルアップする機会を用意するようにしましょう。
チーム全体のスキルレベルの底上げは非常に重要です。

こうした開発の面で役立つことはもちろんのこと、市民開発により作成されたものに対する理解も増しますので、頑張っている方への無理難題や、理解に欠けた発言をする方を減らすことができる。ということも期待できます。

いきなり100点を目指さない

市民開発を行う上で以外と重要になるのは、いきなり100点のシステムを目指さない。ということです。

これを行うためにも既存業務のタスクの重要度を選定してもらった感じですね。

初回リリースの際は最低限の機能が満たせるレベルのもので正直充分だと思います。
そこから少しずつアップデートしていって優先度の高い機能を展開していくようにします。

他社に発注していたこれまでの開発とは違い、業務を理解した自分たちが、自分たちの思うように、自分たちのスケジュールで開発を行うことができる。というのが市民開発のメリットですのでそれを活かした開発を行いましょう。

担当者と責任範囲を決める

小さいプロジェクトであればまぁいいかもですが、ある程度の規模になってくると登場人物も増えてくるかと思います。
そうなったときに最悪なのが、「これ誰のタスク？」となり、皆が責任の押し付け合いをすることですね。

社内の閉じたプロジェクトなんだから仲良くやろうぜ。とは思うものの、担当者と責任範囲の明確化は開発・運用保守を行っていくうえで割と重要です。

このようなタスクにおける担当者と責任範囲の明文化を行う手法の一つして"RACI Matrix"などのやりかたがあります。

こうした既存のモデルを活用して担当者と責任範囲を決めておきましょう。

RPAに関して

こちらはあまり記載すると喧嘩になりそうな気もしますが、、、

DX化のひとつとしてRPAの活用が挙げられますが、こちらは対象システムがモダナイズされるまでの繋ぎとして利用するようにすることをおススメします。
なにがいいたいかというと、RPAの開発で時間を取られ過ぎないようにしましょう。(RPAダメとはいってないよ！)

RPAのUI認識機能も年々アップデートされており各社性能は上がってきてはいます。
しかし、そもそも画面構成が変わってしまったり、キー入力待ちでエラーが発生してしまったりと色々と上手くいかない点などが散見されます。

正直そこの対応に時間掛けるぐらいなら、該当システムの改修、乃至は乗り換えを検討したうえでAPI連携が可能なようにして、そこから業務改善や効率化に本腰入れた方が総合的な投資対効果高いんじゃないかなぁ、、、と思っています。(ちゃんと算出してない)

目指す姿は"ハイパーオートメーション"ですね！

www.oracle.com

マインド全般

市民開発者へ

市民開発は基本的に業務内容を理解した業務部門のメンバー自身が、自分たちで業務効率化や改善を目指して開発を行うことを指します。

開発に関わるすべてのタスクを自分たちでやれ。ということではないですが、主役となるのはエンジニアではなく、業務チームの皆さんです。

まずその点を理解したうえで市民開発やスキルアップを行っていただくようにするとよいかな。と思います。

とはいえ、専門外な領域も多々出てくることかと思いますので、その際は社内のエンジニアや情シス、もしくは社外のそういった業務を専門に行っている会社にサポートを依頼しましょう。
エンジニアは敵ではありません。
お互い歩み寄って相談を行いましょう。

またノーコード/ローコードツールは万能のツールではありません。
従来のコードを記載したりインフラ構築したりするような開発を比較すると圧倒的に簡単に開発を行うことはできますが、開発を行うにはある程度のスキルがどうしても必要になってきます。

自分のしたいことを形にするためにもある程度のスキルアップを行うようにしましょう。
その知識は今後IT化が進む社会での財産と成り得ると思います。

市民開発推進者へ

ノーコード/ローコードツールを導入して、市民開発しろ！と圧力掛けるのが、市民開発の推進ではありません。
ちゃんと組織で行うのだから、市民開発者がスキルアップできる環境を整えたうえで、市民開発を行うBenefitを用意するようにしましょう。

必要となるものをざっくり記載すると

教育コンテンツ
社内コミュニティ
評価制度

の3つですかね。

教育コンテンツはこれまで記載してきたのでなんとなくわかりますかね。

社内コミュニティは、困ったときに気軽に相談ができる場を用意したり、一緒に頑張っている他部署の仲間と交流を持ってもらって意見交換などをしてもらうためですね。
ネガティブな捉え方をすると"馴れ合い"みたいにみえるかもしれませんが、「自分しか頑張っていない」みたいな状況は結構精神的にくるものがあります。
そうした孤独感を和らげるためにも社内コミュニティは結構大事になってきます。

最後に評価制度ですね。
「自分の業務を改善するためにやってるんだから、市民開発をやっただけでは特別な評価に値しない」みたいな意見ももしかしたらあるかもしれません。

ただ人は頑張ったら頑張った分だけ評価してもらいたいですし、よくある「改善してもその分だけ他の業務が押し付けられるだけ」という不信感からなかなか改善に踏み出せない(踏み出さない)ことが考えられます。現行の業務をわざわざ変えるといのもまぁまぁのハードルですしね。

そこでここまで頑張ったらこういう評価(ご褒美)があるよーというのをなるべく具体的に、そして事例として取り上げてあげることをおススメします。

そうすることで市民開発に取り組んでくれる社員も増えてくれるようになると思います。