アプリの連携プロセスの見直し

・業務に合わせた変更

構築・運用が始まった「日常生活自立支援事業」のアプリ群。使い始めて見えてきた修正ポイントがまとまったとのことで確認に入った。

50項目を超えるリストを本部担当者と1件ずつ確認し、
①すぐに修正できるもの
②修正できるが、運用の見直し等影響があるもの
③kintoneの仕様で現状では対応できないもの
の3つに整理した。

取り急ぎ、①については期限を設けて順次対応。簡単なものは本部担当者にも作業してもらい、慣れてもらうことにした。
同時に③に該当するものは、現場の担当者にフィードバックした。

悩ましいのは、②となったもの。kintoneは即時に変更が反映されるため、更新作業も計画的におこなう必要があった。特に、アクションやルックアップで連動している項目については、アプリを順番に修正し、動作に問題が無いかの確認作業が必要になる。既に稼働しているため、利用中に動作が突然変わるのは避けたかった。結果、土日に（こっそり）作業することになった。

また、見直しが必要となるものは、当初設計したプロセス自体を見直さなければならないものもあった。現場に合わせて柔軟に対応したいと思う一方で、対応しすぎると、本来必要な手順が崩れ、情報の不足や齟齬が生まれる恐れがあるため、数ヶ月に渡り調整しながら整理していった。

・「昔は良かった」という思い

中には、「従来の流れに戻して欲しい」というものもあった。従来の流れとは、全て紙で処理していた時の流れだ。kintoneで構築することになったのは、その柔軟性からだったが、紙での処理を全て再現するつもりは当初から無かった。導入前の説明会でも「システム化で業務の流れが変わる」ことは伝えていたが、運用から一定期間がたち、システムに慣れない中でこういった「よりもどし」の意見が出るのはよくあることだった。

システムになじめない人ほど「昔はよかった」と戻したくなる。そして、紙での処理に精通していたベテランほど、その気持ちが強い事が多い。そして、ベテランに影響され、いつの間にか新しいシステムが悪者になり、骨抜きになっていくのは今まで何度も経験してきた。

では、本当に「昔はよかった」のか。
システム導入してまだ数ヶ月。ただ単に「慣れていない」中での意見を受け入れることはしたくなかった。
「現場からの意見だから」と本部の担当者も感情的に流れそうになる瞬間があったが、kintoneが柔軟に修正できるからこそ「もう少し様子をみて、システムに慣れても課題が残ったら対応しよう」と提案し、なんとか持ちこたえることができた。

結果的に、あえて変更しなかった課題も現在は受け入れてもらっている。幾ら柔軟でも人がシステムに合わせることで合理化されることも多分にある。それを感じてもらうためには時間が必要で、その時間を含めて導入プロセスを考えることの必要生を感じた。

・kintone hive TOKYO

この作業中、新木場で開催されたkintone hive TOKYOに参加した。
自身としては2度目。前回の六本木ヒルズでは、会場の雰囲気もあり「事例発表とセミナー」という印象だったが、今回はライブ会場ということもあり、音響や照明の演出がレベルアップ。完全に「ショー」になっていた。

もちろん、内容も凄かった。自分より後に導入した人達が堂々と発表していたことに少しだけ悔しさを感じつつ、どの取り組みも参考になるものばかりだった。
（余談だが、このときの「チェア」が大きさ・インパクト共に最大のノベルティだと思う。）
今回もまた、大きな影響を受けて次の取り組みを進めたい！と思っていたが、担当業務的にITはオマケであることは変わりなく、Garoonの利用拡大や翌年に迫ったWindows7サポート終了体制準備を優先させざるを得ない状況になり、アイデアだけが溜まっていく日々がしばらく続いた。