どうしてこうなった？マイナポイント予約サイトから考えるシステム開発の怖い話
先日こんなツイートをしました。
政府のITリテラシ・・って声が多いけど、多分コレ
— たねいち🇻🇳 | システム開発トラブル解決110番 (@tane1_takafumi) July 6, 2020
・全世帯で問題なく利用出来る事
・ブラウザ1つに付き見積もり数千万プラス etc
とかな無理くりな要件があるんじゃないかなぁ
これが完成するに至ったプロセスにフォーカス当てたほうが根源的な問題が出てきそうな気がするhttps://t.co/RsJRxo1zzk
総務省のマイナポイント予約サイトがIE11のみ対応となっており
今どきIE11のみって、、、とネット民がざわついたというのがこのあらまし。
その他にも
・今どきChrome非対応とか、、、
・使えないシステムすぎる・・・
・日本のIT周りは本当ダメだ・・・
とネガティブな反応が多く見受けられました。
でもこれ、実は、他人事ではないのです。
あなたの会社のシステムもこのようなシステムが生まれる可能性が十分にあるのですから。。。
今回は、そんな
「どうしてこうなった？システム開発の怖い話」
です。
経験上、こういったシステムが出来上がるのには幾つかの要因があるように思います。
(マイナポイントがこういう背景だったかは、中の人のみぞ知るですが。。）
要因1：極度な忖度が働く。
これはとある案件で、社内ポータルシステムを作っていた頃のことでした。
社内ポータルへログインした後、各部署の情報を見れるようにしたい、と言われて
各部署からの情報掲示板的な機能を創りました。
しかし、その後に、他部署に見せてはいけない機密情報もあるから、一度人事側でチェックしてから公開できるようにしたい。
と要件が加わり、更に人事側でチェックしていることを悟られたくないから、システムで自働チェックしているようにしたい。
という要件が更に加わり。
非表示にされていることが分かると、不信感を持つから、その部署では表示されている状態にしてほしい。
と更に要件が加わりました。
・・・・そして、謎の情報統制機能が入った社内ポータルが生まれました。。。
他部署の人がログインすれば情報が見えないことは明らかなので（そこは何故か塞がなかった）
結局、見れる情報見れない情報があるなら、入力してもしなくても同じ。。となりこの機能は作られなくなりました。。。
要因2：想定範囲が広がりすぎて複雑になりすぎる
利用対象を増やせば増やすほど、想定する見せ方が増えてコレ誰が使うの？システムになりがちです。
これもとある開発であったことなのですが
勤怠システムの有給処理を開発していたときのことでした。
そこの要望にはこんな事が書いてありました。
要望「入社したばかりの社員が休むことも想定し、有給を前借りし、付与時に相殺出来る機能が欲しい」
要望「取得有給を将来、時間単位でも取得できるように管理画面側から最低取得単位を変更出来る機能が欲しい」
要望「有給以外にも、社内の特別休暇を新規に設ける可能性があるので、管理画面側から追加出来るようにして欲しい」
勤怠の状況から考えると、確かにそうだな、と思う反面、開発側から見ると、相当に複雑な処理が必要になるのです。
（わからなかったらごめんね・・）
当時、若かった私はこの要望通りに開発を進めましたが、条件分岐や場合分け、実装工数もさることながらテスト工数も膨らみ
当初の予定を数ヶ月もオーバーすることになりました。。。
ちなみに一生懸命作った、有給単位の変更機能や特別休暇の機能は、リリースから一度も使われることはなく
システムのリニューアルを迎えることになりました。
要因3：リテラシーのターゲットを広げすぎる
ハンバーガーメニューというものがあります。
モバイルサイト等でみる ＝ ←こういう感じのメニューのことです。
日頃からネットに触れ合っている人間からすると、ああ、コレがメニューなんだな、ってわかるのですが
あまり触れていない人からすると、これなに？設定画面がないんだけど、みたいな問い合わせを受ける事があります。
先ほど上述した社内ポータルでも似たようなことがありました。
社内掲示板に文章を書く時に、「投稿」ってボタンだけじゃわからない人もいるかもしれないから
ボタンを押した時に、
「投稿しますがよろしいですか？」ってアラートを出すようにしよう。
「キャンセル」だとわからないから「取り消し」にしよう。
「OK」だとわからないから「投稿する」にしよう。
「ログイン」がわからないと思うから「入る」にしよう
と、IT用語を極力排除した文言設定にしていきました。
結果、、、見慣れない文章で何が起きるのか逆に分からない。
「入る」ってあるけど「どこに入るんだ？」といった問い合わせが頻発することに。。
では、どうすればいいのか？
上手くいくシステム開発はこんな感じかと思います。
ポイント1：利用ユーザーと利用シーンを明確に定義する。
この人にこう使ってほしい！が明確でシンプルであればあるほど、運用に乗りやすいです。
まず、使ってもらわなければ、利用され続けないので、まずは、利用するターゲットと利用シーンを限定し
習慣レベルにまで運用を持っていくことが大事です。
そして、シンプルであれば、あるほど、リリーススケジュールが早まるので、投下コストを早く改修出来るメリットもあります。
先の社内ポータルでいけば、社内通知だけを載せる機能だけを創り、出勤後にニュースを見たら「いいね」を押してね
くらいのシンプルな機能でリリースしたほうが良かったのではないかと思います。
ポイント2：例外パターンは(なるべく）盛り込まない
日本では社内の業務にシステムを合わせますが、米国では、システムに社内の業務を合わせます。
とよく言われていますが、まさにそのとおりで。
自社の複雑なパターンを考慮するとなると、開発工数が伸びバグも多くなり手に負えないシステムが生まれがちです。
ここは運用側との折衝が必要ですが、なるべく例外パターンを盛り込まないシステムにするほうが
未来は明るいことを粘り強く説明してください。
ポイント3：納期を短く切ってその中で作れるものをまずは作る
社内開発でありがちなのが、スケジュールが伸びやすくなってしまうことです。
社内で使うからこそ使いやすいものを、、と思い、納期をズラしてでも開発を進めることがありますが
基本オススメ致しません。。。
令和におけるシステムは、リリースされて終わりではなく、リリースされてからこそ”始まり”なのです。
目に見えないシステムだからこそ、使ってみないことにはわかりません。
リリースしてからこそ、要望が出てきます。
ですので、（勿論無理のない範囲での）納期ありきでまずは形にして、そこから継続で手を加えていくほうが良いと思います。
まとめ
マイナポイントのサイトが実際にどのようなフローで開発されていったのかわかりませんが
・手続きに際して、極力新しいソフト等を入れずとも利用出来るブラウザであること
・マイナポイントの手続きに必要な処理が出来るブラウザであること
・セキュリティも担保し、ブラウザがバージョンアップされても追随出来ること
・それらを満たした中でリリースは2020年7月1日とすること
みたいないろいろな要件が重なった結果、こうなったんじゃないかなぁ、と思います。
どういう意図でこのシステムが作られたのか、もし公表されるとしたら
エンジニア界隈のみなさんで議論され、よりより方向が指し示されるのではないかな？と思います。
このままだと、IE11だけでなくChromeを対応ブラウザとすることという条件だけが、儀礼に乗っかって
今後のシステム開発コストとスケジュールが更に大変なものになりそうな未来がチラ見えしています。。
プロセスも含めて皆さんで議論出来るようになると日本のITリテラシも上がっていきそうですね！
それでは、本日も最後までお読みいただきありがとうございました。
また次回の記事でお会いしましょう。
この記事が気に入ったらサポートをしてみませんか？