業界横断的グループウェア構想と未踏社団でのkintoneの活用事例について解説しました。

1. 未踏社団でのkintoneの活用
2016-04-26
一般社団法人未踏 理事 / サイボウズ・ラボ
西尾泰和

2. 未踏社団の目的
業界横断的ネットワークを作ることで
イノベーションを加速する
2

3. 業界？
未踏卒業生の構成比
起業家：アカデミア：大企業
１：１：１
多様性が高い！
3

4. コミュニティのハブ
起業家とアカデミアと大企業の
それぞれのコミュニティを繋ぎたい
4
このギャップを埋めるものは何か？

5. kintoneとは
世界中のチームワーク向上
をミッションとするサイボウズ
が提供しているグループウェア
5

6. グループウェアの効果
・物理的に離れている *
・同時にオフィスにいない **
などのコミュニケーションの障害を
オンラインサービスで解消する
6
* 席が離れている、オフィスが異なる、など ** 内勤と外勤、時差、など
部署の壁を超えた
コミュニケーションの活発化

7. 業界横断的グループウェア構想
ここにグループウェアを入れればよいのでは？
という社会実験
7

8. アカウント発行完了
4月19日時点で全会員に
kintoneアカウント発行完了。
既にいくつものプロジェクトが
公開/非公開で走り始めている。
9

9. 集まるのが最初の一歩
一緒に居続けるのが進歩
一緒に働くのが成功
10
Coming together is a beginning; keeping together is progress; working together is
success. Henry Ford
一緒に居続ける場としてのkintone

10. 事例紹介
• 運営会議
• 未踏名鑑
• みんなのひろば
11

11. 事例紹介：運営会議
未踏社団の運営はkintone上の
秘密スペースで行われている。
12

12. 8/31 運営をkintoneに移行
それまではFacebookの秘密グループだった。
Facebookの良いところ:
既に通知を見る習慣が付いている人が多い。
Facebookの悪いところ:
後から「以前議論したアレはどこだっけ？」
となった時に発掘しにくい。
→「情報を整理できる場所」のニーズ
→そこでkintoneに移行
13

13. 移行がうまく行った理由の考察
・Facebookでは苦痛を感じる通知流量だった
→通知の読み落とし、何が緊急かわからない
→kintoneは「自分が名指しされている通知」
が優先的に表示されるので移行で苦痛が減少
・緊急性のあるタスクが進行中だった
→メンバーが毎日通知をチェックする
→「kintone上で言えば伝わる」という安心感
14

14. スペースのポータル
15

15. スペースのポータル
「スペースのポータルと複数のスレッドを使用する」
で書き換え可能なポータルができるので、そこを
長期的に重要な情報を記録する場所として使った。
16

16. 雑談スレッド
なんでも書いてよい
「雑談スレッド」を
明示的に用意することで、
思ったことがすぐ気兼ねなく
共有されるようにする。
17

17. スレッドの「本文」
スレッドのコメント投稿欄より
上の部分(本文)はグループの管
理者が書き換えられる。
コメントで一過性の議論をして
から、重要な部分だけまとめて
本文に反映させる運用が可能。
18
本文

18. スレッドごとの発現頻度
ヒートマップ*を観察してみると
36個のスレッドが作られて、
8件ほどが継続的に使われ続け、
他は1～2ヶ月で使われなくなっ
ていることがわかる。
使われなくなったスレッドはイ
ベント準備や、一過性の議題。
使われ続けているのは継続的な
タスクと雑談・TODOリスト。
19
* これはkintoneの機能ではなく筆者による実験的な可視化です。

19. 議題アプリ
物理的「運営会議」が毎週1時間行われていた。
しかし議論すべきことが大量にあって、
事前の整理が必要であった。
そこで初回会議後(9/5)、
kintoneアプリ(データベース的なもの)を用いて
議題の整理をする仕組みを実装した。
20

20. 議題アプリ
21

21. 議題アプリ
議題(1行)、内容(複数行)、提案者、
添付ファイル、決定日、からなる。
決定日が空欄なものが「未決定の議題」だから
その条件でフィルタした一覧を用意している。
22

22. 使いながら調整
初期の議題は「議論予定日」フィールドがあって
「緊急性の低いものは遠い予定日にする」として
いたが自分も含めて誰もその機能を使わなかった
ので削除した。
「決定内容(可決/却下)」というフィールドもあっ
たが、使われなくなった。(詳細は次ページ)
添付ファイル機能は4月になってからつけた。
今日レコード番号昇順でソートするようにした。
23
先に登録した議題が上に来たほうが議論しやすいと今更気づいたので。

23. 評決機能の削除理由
9/16の雑談から引用：
• 「アレ議論しなきゃな」と思ったタイミング
で書いておけるのは脳の負担が少なくていい
• ほとんどの議題が「賛成か反対か」よりは
「どうしたらいいか相談させてください」な
ので評決部分は役に立たない感じがする。
• 事前に議論が進むケースがあり、会議の負荷
軽減に役立っている
24

24. 事前に議論が進むケース
議題ごとのコメント欄でオンラインで議論が進む
25

25. 議題の総数
9/5～4/20の運用で
総計217件の議題が登録された。
その間の物理的運営会議は30回だったので
1回あたり7件の意思決定が行われた。
意思決定の生産性がかなり向上したはず。
26

26. 議題アプリのまとめ
物理的会議での議題を事前にオンラインで共有し
ておくことで会議の効率を改善。
複雑な運用ルールは誰も使わなくなるので、
最初はシンプルにスタートしたほうが良い。
必要を感じてから改善していく。アジャイル。
27

27. 議事録の公開
「社団が何をやっているのかわからない」
公開できないもの以外は原則公開すべき
→議事録を社団kintone内で公開(10/9～)
28

28. 議事録公開フローの設計要件
議事録には「公開できないもの」が含まれる。
事後的に公開できる形に整理する必要がある。
これまで議事録はOffice365で取られていた。
議事録の取り方を変更する余裕はない。*
29
* 議事録を取る人が慣れたやり方を捨てて新しいやり方に移行するために
説得と教育のコストを掛けるべき状況ではないと筆者が判断して移行を求めなかった。

29. 議事録公開フロー
• Office365で議事録を取る。
• 終了後、それをkintoneの運営スペースにある
「公開準備」アプリに転記。
この時、明らかに公開できないものは除く。
• オンラインでレビュー。コメント欄で議論。
必要に応じて修正を加える。
• 過半数の公開OKが出た後、
会員全員が参加している「みんなのひろば」
スペースの「議事録」アプリに転記。
30

30. 公開準備アプリ
「会議名称」と「議事録」だけのシンプルなもの
31

31. 公開準備アプリ
議事録以外にもたまに流用される
32

32. ミニマムな実装
公開承認フローを実装したり、kintone APIを
使って承認されたものを自動で転記したりも
可能だと思うがやっていない。
たかだか週に1～2件の作業であり自動化の実装
コストの方が高いと判断したから。
公開済みのものは頭に「(済)」を付ける運用に
なってるけど、チェックボックスを用意しても
良かったなと(この解説を書いていて)思った。
33

33. 議事録公開用アプリ
34
アプリの目的やアクセス権、記法・使い方などの情報を
アプリの説明文に記録しておくことで、未来の自分が
わからなくならないようにしておく。
プログラムのコメントのようなもの。

34. アプリの説明
一般設定からリッチテキストで設定可能。
作った人が突然死しても仕事が止まらないように
平時から引き継ぎを意識して記載していく。
35

35. 運営のサイクル
議事録の公開と提案窓口の明示* で
運営のサイクルが回り始めている。
今後このサイクルを回して改善していく。
36
* いまは head-office@mitou.org へのメールだが、いずれkintone上にも作りたい。

36. 事例紹介：未踏名鑑
社団の目的「ネットワークを作る」のためには
既に作られているネットワークを可視化し
更に強化される機会を作る必要がある。
しかしそのためのデータが存在しなかった。
個人的に2015年の4月から色々やっていたが、
8月6日から社団の公認プロジェクトとなり、
社団が予定していたインタビュー・アンケートの
プロジェクトに合流した。
37

37. 未踏名鑑の設計
• 個人だけではなく、
協働関係のデータを収集する
• 未踏期間だけではなく、
その後の活動のデータを収集する
• 色々な可視化を試しやすくするために、
データは機械可読な形にする
• データの鮮度を保つ仕組みを作る
38

38. 人材アプリ
会員誰でも編集・検索・CSV書き出しが可能
39

39. 人材アプリの設計
• 「氏名」「備考」「タグ」「社団内備考」か
らなる。
• タグはCSV形式でスキーマレスに色々な情報を
入れられる。これをCSV書き出しやAPI経由で
取得して色々な可視化を試せる。
• 今は報告書のデータ(当時の所属含む)や
各種イベントの講演プログラムから
4633行のタグデータが集まっている。
40

40. 可視化の例
人材アプリのデータから、各人を所属ごとに表示
することで、同じところに所属したことがある人
を可視化
41
http://www.mitou.org/people/affiliation.html

41. いま説明したところ
42

42. Wikipedia的共同編集
未踏社団の会員ならばデータを直接編集でき、
この変更履歴は変更者付きで管理される。
ロールバックもできる。
つまりWikipedia的な改善サイクルが回せる。
43

43. フィードバック
人材アプリの情報を元に各個人のページが自動生
成される。このページの末尾にフォームがあり、
会員にかぎらず誰でも*変更案や情報提供の
フィードバックができる。
このページはエゴサーチや、記者等の下調べで
ヒットするようになる。露出が高まれば、本人が
正しい最新の情報にしたいと思うようになる。
44
* 「更新提案アプリへの追記権限」を与えたAPIトークンを使い、kintoneに書き込む

44. いま説明したところ
45

45. 今後の予定
• まだ入力していないデータがある。
• 可視化の見栄えに時間を割けてない。
• 可視化の方法ももっと色々ある。
• 収集できるデータもまだまだある。
• システム自体の改善も。
現バージョンは最初の一歩であり
これから色々面白いことができそう。
46
興味のある人は未踏名鑑のスペースへ https://mitou.cybozu.com/k/#/space/17

46. できそうなこと例
松尾豊(2004年OB)らは「2つの人名を検索エンジ
ンでAND検索することでそのヒット数によって2
人の関係の強さがわかる」と提案*
未踏名鑑でも同じことができる。
さらにそのヒット結果から自動もしくは半手動で
未踏名鑑のデータの拡充ができたら、面白いので
はないか？
47
* http://ymatsuo.com/papers/jsai05.pdf
この研究のことは首藤PM(2006年上期OB)に教えていただきました。

47. 事例紹介：みんなのひろば
過去1年間で、未踏社団
には色々な研究会・
ワーキンググループ・
プロジェクトが提案さ
れたが、どんなものが
あるかの情報共有が不
足している。
そこで全員が所属して
いるスペースを作りそ
こに情報を集約する。
48

48. 研究会自治の原則
研究会によっては主たるコミュニケーションの場
所をFacebookの秘密グループにしている。
多様性は重要であり、ツールの選択をするかは各
研究会の自由。kintoneの使用は強制しない。
各研究会の長を管理者として各研究会のスペース
を作成し、運営会議が管理者である「みんなのひ
ろば」から一覧リンクを貼ることで。一覧性と自
治を両立した。
49
* “慣れていない人に無理に使わせるのは、猫に犬の鳴き声をさせるのと同じ”
アート・オブ・コミュニティ p.208

49. 通知による情報共有
10月21日以降、月1回ペースで活動報告を
メルマガ配信*してきたが、1ヶ月1回では
「一緒に何かをする」には頻度が低すぎる。
事が終わってから知って「知らない間にそんなこ
とをしてたのか」と疎外感を感じさせてしまう。
そこでなんでも速やかに「みんなのひろば」の告
知スレッドで告知し、それからどれをメルマガに
載せるかゆっくり考える形にしたい。
50
* http://www.mitou.org/mitoumagazine/

50. 事例を紹介した
• 運営会議
• 未踏名鑑
• みんなのひろば
51

51. 集まるのが最初の一歩
一緒に居続けるのが進歩
一緒に働くのが成功
52
Coming together is a beginning; keeping together is progress; working together is
success. Henry Ford
集まるためのイベント。
一緒に居続けるためのkintone。
一緒に面白いことをするために
機会を作り出し、情報共有をする。
これが未踏社団のやっていることです。