コメント_2020-03-08_195459

#44 福kin　kintoneおじさんの会 Vol.1をおじさんが語る

ほそぼそと業務改善

おじさんの会、きっかけ

去る令和2年3月4日、kintoneおじさんの会 Vol.1がオンラインで開催されました。

開催のきっかけは、どりぃさんの「業務フロー図書ける？」とのつぶやきに安藤さんが反応し

それに共感した私のつぶやきを松田さんがひろってくれた事により開催に至りました。

実際の座談会の場では久米さん・飯塚さん・星名さん・中島さんも加わり大変学びの多い会となりました。

私はシステム開発のプロでは無いので、常に手探りで開発している所もあり、また開発が進んだところで致命的な構造上の失敗がみつかったら自力では解決できない…なんて不安に苛まれたりもします。

そんなところをきっかけにkintoneおじさんの会はスタートしました。

どうやってシステム構築の仕組みを学んだのか？

久米さん
情報系の学校は出たけども、実際はソフトウェア会社に就職して社会人になってから本格的に学んだ。3ヵ月ごとに炎上プロジェクトに配属され底力がついた。
松田さん
原動力は
「やりたい事」発進+面白い+(あいつには負けたくないという気持ち)
飯塚さん
1人力では回せない世界に突入した時、まだ見ぬAさんに伝えるという視点が持てた。また20年前はITに触れことのない人が当たり前に存在していたので、そのような人にどう伝えるかという視点が鍛えられた。その際に業務フローを作成する機会が多くもてた。
ここで久米さんから、
20年前と比べ今はITに触れている人がほとんど。道具として要求されるレベルが上がっている

との発言あり。

たしかに今は全くICTに触れていない人って探すのが難しいかもしれません。
当たり前のようにネットでニュースを見るし買い物もする。LINEも使う。
システムを使う側にとってはその普段目にしている画面の見た目や使い勝手がシステムの基準になるので、システムに対する要求レベルが上がっていると。つまり使いづらいシステムには拒否感がでてしまう危惧がある。

ここで抽象的な話へ

私常々思うんです、１つ１つの課題を解決するアプリを量産していていいものか？1部署の課題に注力して開発を続けていていいものか？
後々会社から「kintoneってイケてるから会社全体で使おうよ！」と言われたときに、その要求に耐えうるシステム構成になっているのか？

ここでは抽象的な例えで話が進んでいきます。

私の頭の中では

家具→1つ1つのアプリ　部屋→各部署　家→会社全体のシステム

というイメージです。家具を個別に作っていても、部屋に収まりきらないかもしれないし、部屋の視点で各部署のシステムを作っていても、いざ家を作る時に、どこにも繋がってないハシゴがあったり、開けたら行き止まりのドアがあったら家として機能しません。

かと言って自分の会社にピッタリと合うオーダーメイドのシステムなんて市場では手に入りません。専門家に注文したら何千万円の世界でしょう。

でもkintoneには自前で作れる可能性がある。でも知識と技術と経験がないのがもどかしい。正直言うとそんな気持ちです。

久米さん
業務改善は家を作る事が目的ではなく、どんな生活がしたいか？何が幸せか？をとらえる事が大事

その通りです。そこが抜けてしまう改善は意味のない改善になってしまいます。ただ、目指すべき生活や、辿り着きたい幸せの先に全社的なシステム(家)があったら、対応できるようにしたいというのもまた本音です。

「家が作れる人が作る家具」と「家具しか作った事の無い人が作る家」は違うものなのでは？という疑問が湧いてきました。

ここで、エンジニアから見るkintoneとユーザーから見るkintoneの違いについて触れていく時間となります。

質問！プロがユーザーと触れ合う事の意味

思い切って質問してみました。
システムの専門家がコミュニティでユーザーと触れ合う事の意味は？

久米さん
kintoneのコミュニティは成功していると思う。
真摯な姿勢で開発に向き合っている人の話は単純に面白いし、開発に加えてマネジメントを行い現場にシステムを浸透させようとしている人の話は業務改善のエッセンスが詰まった濃縮果汁。ギューッと内容が詰まっている。その果汁を多く取り込み、他の現場で困っている人に飲みやすい濃さにして話すだけで共感を得られる。専門職として引き出しを増やせる。
飯塚さん
専門職がユーザーに対してわからないと言える貴重な場。それは生の現場で業務改善している人だから聞ける。
SEはシステムをリリースという形で手放す事が多い。その後現場でどんな形で回しているのか、経営にリーチできているのかを知れる機会は少ない。Kintoneでユーザーと触れ合う事でそこまで踏み込んだコミュニケーションをとる事ができる。

この質問してよかったです。普段私は専門職の方から得るばかりで何もお返しできていないとの思いでしたが、なるほど、私たちの日々の活動一つ一つを生きた業務改善情報としてお二人は認識してくださっていた。

急性期病院の外科の先生の中には「自分が治療した患者さんが自宅でどう過ごしているのか気になる」とお話される方もいます。
飯塚さんの意見はその感覚と近いのかなとも思いました。

何を学ぶ　どう学ぶ？34分～

久米さん
楽になるにはどうするか？という視点は大事。困りごとをそのままにすることなく、工夫しながら解決していくという発想。
そのためにDBを学ぶことは有効。kintoneも裏ではDBが動いていると想定しながら開発する。
また、データを構造的にとらえるようになることが大事。
ここはアプリを分けて関連レコードで見せるか、テーブルで構築するか見極める必要あり。

松田さんからプルダウンかマスタ化するかとの問いかけあり

目安としては値が増える、変化する場合はマスタ化してルックアップで構築。増えないし変わらないもの(都道府県等)はプルダウンで構築するかは一つの目安。

久米さん
データが増えても対応できるように、変えたくなった時に変えられるようにシステムを作るのがコツ。
変えてもいい、間違ってもいい、3割でも6割でもリリースできる、ということは変え続ける前提で使ってもらっているということ。kintoneはそれが出来る。また、データ構造は後からでも頑張れば変えられる。

安藤さんから、「他の社員が頑張ってシステムを作っているけど、明らかに破綻しそうだなと気付いたときに、うまく成功に導くためにもデータ構造や業務フローの知識が必要と感じる」との意見。

ここで久米さんからデータ構造についてのアドバイス

久米さん
データ構造を今まで使い慣れたエクセル的に考えてしまいがちだが、エクセルは縦にも横にも伸びていき、さらにシートを用いれば３方向にデータが伸びていく構造。
だが、DBは基本的に縦にしか伸びない。ここを意識しながらシステムを作る必要はある。

詳しく記載すると、レコードを追加するというのは、縦に伸ばしていくこと
フィールドを増やすというのは横に伸ばしていく事

例えばエクセルで社員毎の毎月の売り上げ管理を行う際は、縦の行に社員名、横の列に年月(2020年1月等)をとる事があると思うが、これは月が経つ毎に横に増えていく構造。

画像1

これと同じことをkintoneでやろうとすると、毎月該当月のフィールドを１つずつ増やしていく事になる。

画像2

画像3

これはフィールドの数が限られている事もあり、破綻するデータ構造になる。

DBは縦に伸ばしていく事を意識するというのは肝に命じたい。

↓久米さんが詳しく記事にしてくれてます。

松田さん
エクセルでいえばピポットテーブルを学ぶことでデータ構造を学ぶきっかけになる。
飯塚さん
入力しやすさと見やすさを実現できるのがKintoneであるが、そこがプロから見て気持ち悪くもある。krewDataはそこを補完できるソフト。ある程度自由に作って、後で繋げる事が実現できるようになった。
星名さん
エクセルは美しくあるべくという風潮から、データが縦持ちにならずに帳票めいたものになってしまう。
中島さん
出張旅費に関するアプリを作成した際に、帳票にかかわるプレイヤーが多かったが、一人ひとり話を聞くことで解決した。今までそんな役割の人がいなかったので実現しなかった。

縦持ちのデータを横持ちにするには？
(2020年12月30日追記)

いくつか方法はあると思いますが、標準機能でやるならば、グラフ機能の中にあります「クロス集計」で実現できます。

クロス集計ですと、項目が限られて、ビジュアルもなんとかしたい…そんなニーズも出てくると思います。

そんな時はTISさんの「日程・工程・稼働表作成プラグイン」を試してみてください。

週ごと、月ごと、年ごとにガントチャート方式でデータを見る事ができます。
他にもカレンダーPlusプラグインでも同じような事が実現できます。

縦持ちのレコード郡を、標準機能やプラグインを活用して色々な見た目で表現できるのもkintoneの魅力です。

業務フローについて　1時間11分～

安藤さん
要件定義や業務フローが書けないと予算を割いて欲しいと社内で言いづらい　業務フローはどう学べばいいか？
星名さん
最終のアウトプットが紙になるので、そこから逆算してデータ構造を考えアプリ作成していく。

そんな疑問に対して久米さんから違った視点の解決策がもたらされます。

久米さん
設計や要件もそうだが、目の前の困りごとを解決し続ける視点も大事。この人に言えば変わるかもしれないと感じてもらい、小さく変わり続ける事に意味がある。農業の現場で報告をレコード単位でしてもらう仕組みを作成したが、農家には時間がない。すぐにテーブルに入力する運用に変え、テーブルからレコードに変換する仕組みを作った。実務に合わせてすぐ変えるのが大事。

ここで私から相談。私は今「医事課の業務改善」を行っているが、課題やその改善案を出して欲しいと言っても現場からは出なかった。

そこで広島のkintonecafeで拝見した檜谷さんの利用しているシートをヒントに改善するぞシートを作成しました。

↓この動画の1時間20分あたりから檜谷さんのセッションです。

実際に清水が使った改善シート

画像4

このシートの活用でだいぶ現場から意見が出てきました。

次に出た意見を一つ一つカードにして、手作りのシートにペタペタと貼っていく予定です。

画像5

そして改善効果が高くすぐできるもの(左上のエリア)から取り掛かると。
(ちなみに右の改善効果を「中」にしたのは「低」だとテンション下がると思ったため)

そうすることで、久米さんの言う変えられる存在として現場から認められるのではないか？

しかし、このやり方でうまくいくのか？私自身が手探り状態なので聞いてみました。

飯塚さん
このシートで聞き出しているのは使う側の要求
要求と要件はきちんと分けて考える必要がある。
私たちが日々現場で聞き出しているのも要求。

ここで捕捉。要件の定義

画像6

飯塚さん
DBに落とし込むためにも要件化する必要がある。
要求を要件ととらえるとシステム開発の時に失敗する。
何故なら相手の要求はぶれていくので、開発が終わらなくなる。
きちんとDBに落とし込めるほど突き詰めればシステムまで持っていける。
が、ここでまたまたアドバイス。
現場から出た課題を何故何故分析して原因に辿り着き課題解決を目的にするのがコンサルの仕事と思われがちだが、本丸はそこではない。
課題が残り続けると何が困るのか？を考え言語化する必要がある。
例えば
①毎日100枚の書類処理に追われて困る
②何が困るのか？
→採用がうまくいかず、残業も嵩む
③困る理由を反転する
→採用が出来て、ワークライフバランスが保てるのが理想
④それを実現する具体策を考える
→３人採用できて等
あるべき姿を具体的にするのが本丸。
久米さん
あるべき姿を目指すという視点もそうだが、今よりもステップアップするという視点も大事。チームワークが向上し売り上げが向上する仕組みを目指して盛り上げていく。困りごとの可視化には要件定義は有効。

ヒアリングについて　1時間35分～

松田さん
人のいう事を聞くことが大事
でも、人のいう事を聞いたらだめ

人の要求を吐き出させるのは大事だけど優先順位つけて取り組むのは良くない。人のいう事を丸々聞くのも良くない。
業務改善職で大事なのは「想像力」
どうゆう風に皆が仕事しているのか、誰が誰に仕事を流しているか観察眼がいる。
ただ課題を解決するのではなく、1ランク上の改善提案ができるのが業務改善職
想像力を磨くために他社の事例や人の話を聞くことに意味がある。

ここは矢内さんの言う1石３鳥理論に通じるものを感じます。人は一つ楽になる程度では動かない。今まで３ステップ以上かけていたものが、１回の操作で終わると実感した時に、「これは凄い！使おう！」となる。

久米さん
元気、笑顔重要　なぜなら雰囲気が大事だから。
業務改善職が楽しそうに働く事で心の障壁が下がる。

業務フロー図を書く　1時間46分～

松田さん
実際の作業の流れをプロセスにまとめそれをKintoneのレコードの状態に落とし込んでいく。
ポイントは実際の業務フローとレコード遷移は１対1ではない
それをしようとすると、業務フローにイレギュラーが多いのでなかなか落とし込めない。
松田さん
プロセスの概念は業務の「節目」
節目を付ける際に、始まりと終わりがある業務か、循環する業務なのかを意識する。究極的にはプロセス管理ボタンを、通知ボタンとして活用する。節目となる際にプロセスボタンを押し、チームメンバーに通知を飛ばすという運用。
久米さん
人ってめっちゃスゴイ！そのめっちゃスゴイ人間という存在を活用しようという視点でシステムを構築している。
日常的にコミュニケーションがどれだけできてるかが助け合いの土壌。
kintoneは満ち足りてないシステムなので人が介在する余地が生まれる。

終わりに

話しが尽きませんという事でいったんここでお開き！となりました。

2時間15分ほどお話したでしょうか。非常に楽しくためになる時間でした。

改めてKintoneコミュニティってスゴイな…と実感できた「kintoneおじさん+おねえさんの会」でした。

業務改善職って深くて広い。

リーダーシップ+マネジメント+システム開発+ムードメーカー+人間性

松田さんいわくスーパーマンになれ!ですよ。

そしてこれを身に着けるのは一人では無理です。だから現場で苦しんで悩みながら、それでも前に進んでいる人たちが集まるコミュニティが大事なんだと感じます。

参加した皆さん、見てくださった皆さん、ありがとうございました。

次回は現場にシステムを普及させるためのアイデア、苦労話をテーマに開催するかも!?

後日談

その後、おじさんの会での内容に触発されて早速データ構造の見直しを行いました。

やったのは破綻する構造だったテーブルデータをレコード化した事

学んだら行動です。

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