非営利団体スタッフとシステムの作り手、その間にある大切なこと ～システム開発のときに最初に考える３つ～

このところ、システム開発プロジェクトにお声がけをいただいて参加しております。第3者として、要件定義や設計フェーズに参加させていただき、論点を整理したり、導入を進めるにあたっての注意点を明確にしたりする役割を担っています。第3者だからこそ出来ている切り分けもありますが、今回はどのような点を意識しているのか、もしも団体内で悩まれていることがあれば、部分的にでも参考になればと思い、記事にします。

最初に考えること：システムの対応範囲、内容を明確にする

多くの場合、「会員管理が大変」「領収書の発行でミスが多い」「使っているサービスが割高」などの問題意識から、新しいシステム導入を検討されているようです。ただ、問題と感じている事象の原因は、周辺業務に要素が含まれている場合がありますので、システムを導入するにあたっては前後の業務も確認する必要があります。領収書発行機能開発のつもりだったが、実は寄付データを作る部分が非効率でミスが発生し、領収書発行に手間がかかっていると判明したなどがありました。この場合はデータをインプットする部分の自動化を目指して、システム化を検討することが高い効果を生みます。

システム対応範囲を決めるには、次の点が重要です。

• 実際に行っている人の業務内容をしっかり聞く
• 問題とされている業務だけでなく、その前後の業務も聞く

そのうえで、それぞれの業務が一般的な業務か独自性の高い業務か分けていきます。現時点で独自性が高くても、標準に寄せていくことができるのか、という視点でも検討し、以下に分けていきます。

• できるだけ業界の標準に合わせて、既存のパッケージアプリを活用する
• 業務（手作業）で対応する
• システム開発する

その上で、こだわりポイント（業務を変えられるのか独自性を維持したいのか、等）で評価します。

長期的にその業務がどうなっていくかという目線も必要ですし、作業の頻度と難易度で決まってきます。
分けたものをこだわりポイントの目線で評価して、最終的なシステム化の範囲を決定します。

次に考えること：システム導入の方法

次に考えるのは、どのようにシステムを導入していくか、という点です。

例えば以下の方法があり、それぞれメリットがあります。

• ベンダーに任せる→規模が大きい、難易度が高い場合に採用。長期的に保守メンテナンスしてもらえる。
• フリーランスの人に依頼する→規模が小さい～中規模の場合に採用。小回りがきき対応が早い。
• 社内対応→難易度が低く、規模が小さい～中規模の場合に採用。小回りが効き、安い。

実際にプロジェクトに参加する場合は、ベンダーに任せることが決まってる場合もありますが、「こういう業務課題があるけどどうすれば良いのだろう」というお悩みから始まる場合も多いので、この３つの方法から状況に合った方法をご提案していきます。

状況を、こだわりポイント（優先したいのは安さなのか導入スピードなのか業務品質なのか、等）で評価して方法を決めます。

このポイントは、団体が持つリソースとシステムコストのかけ方によって決まってきます。

ここでも時間軸の視点も絡んできて、長く使いたい場合は、フリーランスの方に任せる場合や社内スタッフに任せる場合には、バックアップ人材を考えておく必要もあります。作れる人のバックアップというよりは、「システムを維持していく」という視点で、プログラムがわからなくても何をやっているのか概念がわかっていることが必要です。システムをたった一人で構築且つ維持する体制でなく、プログラムがわからないとしても、概念を理解している人が複数いる体制がおすすめです。

そして開発時の進め方

導入プロジェクトをどのように進めるか、という点は、選べるものではないので、自団体らしさを自覚することが良いでしょう。

例えば、以下のような特徴があります。

• 業務全体を把握できている人がリードして進める
• リードできる人はいないけど、聞き合ってみんなで進める

社内プロジェクトが得意、またはメンバーが専門特化タイプである、などという文化的要素もあると思います。全体把握できている人がいればもちろん良いですが、いないからできないというわけでもありません。

そして、こだわりポイント（作り手の言いなりになっていいところとしっかり確認すべきところの区別）を押さえます。

具体的には、起こっては絶対ならない動作の特定を行います。例えば決済データの作成で二重引落が発生する、などのような事象です。このような業務にかかわる部分は、具体的な決済日と入金のカレンダーやデータを使って、明確に確認していく必要があります。このようなことを、誰が納得することが重要なのかを見極めて進めていくか、というのを自覚的に行うと、大切な視点の漏れが減り失敗が減ります。

また、NPOやNGOのシステム開発に慣れているベンダーであれば良いですが、そうでない場合、寄付金管理や支援者管理としてのUIや項目名のこだわりを、進める中でしっかり伝えていく必要があります。ここは遠慮するところではありませんので、システム開発に慣れていない団体さんは控えてしまいがちですが、こだわりポイントについてはくどくなるくらいしっかり伝える必要があります。

業務要件、難易度、業務の煩雑さ、頻度、団体が持つリソース、などに応じて、上記のリソースの選択が変わってきます。

実際には、以上の視点をそれぞれ構造的にヒアリングするというよりは、要件定義やもっと手前のご提案フェーズの中で、あぶり出して自然に整理して進めています。自分たちで行う場合は、あえてカテゴリごとに書き出して整理するのも良いかもしれませんので、参考にされてみてください。