見出し画像

【仕事遍歴】地方自治体の内部統制システムを開発したときの話・2(開発)

前回の記事の続きになります。前回まではデザインアセット(オンプレミス環境のシンプルなソフトウェアであり、初回リリースなのでデザインシステムのような規模ではない基本ルールまでとしています)をどう作ったかというところまでだったので、今回はその続きです。


今回のソフト開発では、大きな機能を2つ搭載する予定だったので、事業部のマネージャーと相談して開発フェーズをメイン機能ごとに分け、通称「前半/後半開発」と呼んでいました。
前半開発は「コンプライアンスチェック機能(アンケート・通達事項閲覧・コンプライアンス文書閲覧)」
後半開発は「業務手順書機能(業務手順書の文書作成&自動フローチャート生成)

です。前半開発は社員のみのコンパクトなメンバー構成で単体テストまで行い、後半開発は複雑性が上がることから、海外のパートナー企業と協業して実装を行いました。私の拙い仕様に対して実装観点から丁寧なレビューやFBをいただけた海外エンジニアの皆様には本当に感謝しかありません。

開発の中で大事にしたこと

ユーザー権限による画面の切り替えをできるだけシームレスなシーケンスで行いたいと考えており(モードレス)操作感については、エンジニアにかなり面倒な動きのお願いをしたと思います。(あたりまえ機能としてはトランジションでモードチェンジする、でも満たせていたので)
自分のUI設計思想としては、管理アカウントもロールの前に組織のメンバーの義務(組織より告知されたコンテンツ学習など)が上位に存在するという形であり、まずメンバーとしてログインしてから各ロールに入り口を分けるという設計をしました。

その流れでシームレスな遷移は一元的品質だと考えたのですが、ここで「それは魅力的品質なので、今実装する必要はない」という反対が出てもおかしくなかったと思っています。
実際、疑問として挙がってきてもいたので、前述の設計意図と、ユーザーがモードレスに感じられる導線だとどのような体験になるのかということをWFのプロトタイピングで実際に見てもらって説明した流れで決定しました。

開発時に大変だったこと

テスト設計とQAです!
どちらも今まではエンジニア任せで自分が主体になって設計することがなく、今回初めてがっつり勉強しつつ各所に教えを請いながら、テスターに色々説明しつつ…という感じで、ここでは常にMAXパワー以上に回転していた記憶です。コロナ禍で完全リモートの中、毎日出社してテスターの方とマンツーマンでテストしていた日々でした。
ただ、テスターがクライアント先のユーザーと条件がかなり合致していることもあり、丁寧に行ったテストは決して無駄にならなかったと思います。
私とテスターでマシンスペックがばらばらの端末なのも良かったし、いろんな条件でシナリオテストからモンキーテストまでやり切りました。

余談ですが、テスター(総務メンバー)は隠れた特技「文章校正(前職のたまもの)」があり、このスキルはヘルプページ作成に大いに貢献してくださいました!最高にありがたかったです!

推し機能①キー操作のレスポンスが良いアンケート機能

アクセシビリティ対応を考慮して、キーボードでの操作を入れるのは必須にしていたのですが、こだわったのが「スムーズなレスポンスと操作途中でマウスに持ち替えたくならないような快適な操作性」です。
ベンチマークをGoogleフォームとして、できるだけキーレスポンスを近づけるべくエンジニアと相談しながら調整しました。最終的にはタイトル入力を開始してからアンケートの発効までキーボードを使って最後までスピードを落とさずに操作できるようになりました。

アンケート機能の編集画面サンプル画像
アンケート結果のサンプル画像
グラフの項目が10を越しても20まではパターンで区別できます

推し機能②ドキュメントの編集と同時に作図される業務手順書機能

一言でざっくりいうと「文書を入力して成型したら、同時に図が作成されるよ」という機能です。

手順書入力画面サンプル画像
こうして……
こうじゃ!

文章で説明をうまくできないという諦めの心の元、一番わかりやすい画像を張りました。
このチャートに落とし込むアイテムなどを決めるために、クライアントがパートナー契約していた某国内コンサルタントの方々とMTGしたり資料をいただきながら(先に制度を策定するために彼らが先に動いていたため、すでに決まっていることを共有していただいた形です)、ソフトウェアにするとしたらどういう形で動くものが必要かということを決めていきました。

最後に

権限周りはExcelで表を作りながら設計したのですが、やはりココの解像度が甘いと全体に影響が出てしまう上に、修正が重たいので、それぞれのロールの業務内容の把握などが肝要になる部分だと思います。(めちゃくちゃ当たり前のことを言っている)
後半開発の手順書の自動生成については、権限はそれほど複雑ではないので、全力で機能にフォーカスできましたが、自治体やお役所では「紙で資料を残す文化・必要性」があるために、自動で広がったフィールドを印刷する場合の整合性に苦しみました……。
その部分も、クライアントに相談しながら許容できる形を模索し、本当に良い経験でした。

後半開発からは海外のパートナー企業のエンジニアたちに助けてもらいながら、頼もしい彼らのおかげで乗り切れたと思っています。
工作的时候,我给您添麻烦了,很抱歉!可是,我非常感谢您的帮助。

この記事が気に入ったらサポートをしてみませんか?