一つにまとめてみました
目次
目次
- はじめに
- プロジェクトの課題
- プロジェクトの課題の対策
- プロジェクトの課題の解決方法
- まとめ
1.はじめに
IT企業で、エンジニアとしてプロジェクトへ携わっている方たちへ二つ質問があります。
あなたの参画しているプロジェクトは、計画通りに進んでいますか?
私が想像するに、遅延の発生している作業があると予測しています。それでも、最終的に折り合いがついて、サービスインに間に合えば良い、とそう考えていますが、プロジェクトの終盤にいくにつれて、家に帰る時間が遅くなり、休日出勤が多くなっていませんか? [I]20年この業界にいますが、筆者も変わらず、こんな感じです
では次に、そのプロジェクトは楽しいでしょうか?
好きな作業工程と、嫌いな作業工程、そもそも仕事が好きではなかったり、折り合いのつかない人が居たりと、常日頃、楽しくプロジェクトを遂行できているというケースはまれではないでしょうか。もし、いつも楽しく、プロジェクトを完遂できている、ということであれば恵まれています。その幸せをかみしめて、これからも業務に励んでください。
一般的に、プロジェクトの計画は遅延し、つらい想いをするものと認識している方を多く見かけます。個人的見解ではありますが、プロジェクトの様々な要因から、プロジェクトは不健全に運営されていることがほとんどではないでしょうか。そして、プロジェクトは不健全に運営されることが「当然」とお考えではないでしょうか。
もし、貴方たちがプロジェクト管理ツール、と呼ばれるものの一切合切を使わずに、Excel で工数や進捗の管理をされているのでしたら、少し考えてみて欲しいことがあります。正しいプロジェクト管理ツールを使いましょう。それだけでもプロジェクト運営が改善されます。今までのしがらみからの脱却は難しいでしょうし、どのようなツールを使えば良いか、選ぶこともむずかしいです。実際、プロジェクト運営のためのツールは多岐にわたり、どれを選択すれば良いのか、私自身も「これだ」といったものを推薦するには至っていません。それに、そもそも「何を指針にしたら良いか分からない」ことが何よりも、選択を難しいものにしています。
具体的にプロジェクトを管理・運営するための方法論があれば、そこからプロジェクトの運営方法を導きだし、その機能に合った運営・管理ツールを使えば良いというのが、私の考える筋道です。
ところで、2011年から、”Gamification”(ゲーミフィケーション) という言葉を聞く機会が増えてきました。2012年に入って、多くの書籍も出版され、”gamification.jp” という専門のサイトも立ち上がっています。「ゲーミフィケーション」とは、ゲームの要素を仕事に取り入れることで、これまで解決できなかった業務上の課題を解決するための、新しい方法論です。実際に導入している、またはそれとは知らずに導入していた国内の企業もあります。会社の仕組みを変え、社員に楽しく業務を遂行してもらうことが主な目的です。
抜本的な企業の仕組みを転換するために、ゲーミフィケーションを採用しているものをよく見かけていますが、これをもっと小規模なもの、例えばプロジェクトにも適用することができないか、と私は考えました。
プロジェクトの全ての課題を解決することのできる方法論ではありませんが、プロジェクトの抱える課題のいくつかを、根本から解決し、楽しくプロジェクトを遂行することのできる、そのような方法はないか。
その方法について、私は一つの仮説を提言します。
それは「ゲーミフィケーションによる、プロジェクト運営の改善」です。
「ゲーミフィケーション」をベースにプロジェクト運営の品質を向上させることを目的として、プロジェクトのどのような課題を解決することができるかを考えていきます。
まず、現在、プロジェクト運営で抱えているそもそもの課題とはなんでしょうか。
そして、その課題を解決するためには、どのようにしたら良いか。
最後に、そのプロジェクト運営をするために、ゲーミフィケーションを活用し、どのようなツールを使えば良いのか、の順番に私の仮説をご説明します。
今現在、結局どのツールを使えば良いのか、またはどのようなツールを作れば良いのか、決定的な答えは出ていません。ただ、この提言を元に、新しいプロジェクト運営を作っていきたいと考えています。
2.プロジェクトの課題
さて、そもそもプロジェクトの抱える課題とはなんでしょうか。
ここに有名な一冊の本があります。 [II]実は後輩に貸しているので、ここにはない←どうでもいい
エドワード・ヨードン著「デスマーチ・プロジェクト第二版」です。失敗プロジェクトを指す言葉として、一般的に使われている「デスマーチ」という言葉を提唱したことでも知られています。この本には、ITプロジェクトの抱える根本的な課題と、解決の糸口となるヒントが山盛りに書いてあります。多少、古い書籍ではありますが、ITプロジェクトの根本は変わっていないと言うことも認識できる内容となっています。まず、この書籍から、プロジェクトが失敗していく課題をひもといてみましょう。
p.008 に「デスマーチ・プロジェクトの発生原因」と明記されている部分があります。ここが、失敗プロジェクトの課題とひもづくのではないでしょうか。本編から抜粋して引用します。
- 政治、政治、政治
- 営業部門、経営陣、プロジェクト・マネジャーの天真爛漫な将来展望
- 若者のカワイイ楽観主義:「土日に出てくればできますよ」
- ベンチャー企業立ち上げ時の楽観主義
- 海兵隊方式:本物のプログラマは寝ずに働く!
- 市場の国際化による競争激化
- 新技術登場による競争激化
- 予期せぬ公的規則
- 予測不能の事件、事故。たとえば、ベースにする予定のハードウェアやソフトウェアのベンダーが倒産したり、中心となるプログラマ3人がペストで死亡するなど。
何か、お気づきになりましたでしょうか。
そうです、プロジェクトの失敗する原因は「人」に起因するものがほとんどです。政治、他部門、若者、楽観主義、海兵隊、予測不能の事件・事故、これらは「人」の行動に起因して発生するものです。その他、市場や技術、公的規則などは、プロジェクトに対する「制約」となり、「運が悪かった」ケースとなり対処も困難です。
実際、p.095 にも記述されている「解決すべき三つの問題」として、
- 人
- 人
- 人
と記述されていることからも、とにかく、「人」を制したものがプロジェクトを成功に導き出せるのではないか、ということが伺えます。
では、人が起因する原因から、実際にプロジェクトで発生すると予測される課題を考えてみましょう。大きく分けて、二つの課題があるのではないでしょうか。
- プロジェクトが可視化されていない
- メンバー間で、情報が正しく連携できない
これらは特に Excelなど、手作りで管理されているプロジェクトには特筆すべき事項ではないでしょうか。皆様のプロジェクトを思い浮かべてみてください。
まず、「プロジェクトが可視化されていない」とは、プロジェクトの状態・状況が、健全なツール・スキルにより目に見えるようになっていない、ということです。プロジェクトの進捗を進捗管理表などによって把握したつもりになっていても、実際はその項目が完了していなかったり、そもそも項目が不足していたり、いつまでたっても進捗が 90%のままで停滞していて、そのワークがどのような状況にあるのか分からない。そもそも、プロジェクトの進捗状況は各人の想いによって(良いように)申告され、プロジェクト・マネージャの想いによって進捗を(悪い方へと)管理されています。
この、プロジェクトの状態が可視化されていない状況により、各メンバーとも正しく情報を連携することができない状況におかれてしまいます。作業場所、作業環境、作業者のスキルレベルなどから、コミュニケーションがうまくとれない、といったケースが生まれてきます。コミュニケーションが正しく取れない場合、プロジェクトの状況を可視化することもできなくなる、といったように、各々の原因には相互の関係があります。ですから、片方の原因だけを解決してもうまくいきません。両方の原因を解決するための方法論が必要となります。
3. プロジェクトの課題の対策
それでは、これらの原因を解決するたまには何をすれば良いのでしょうか。
文章で示すことは簡単です。次の 2つです。
- プロジェクトを可視化する。
- メンバー間で情報を正しく連携する。
これだけです。さぁ、実践してみましょう。
とはいっても、これだけでは何を解決すれば良いのか分かりませんね。では、もっと具体的に解決すべきポイントを考えていきましょう。
- プロジェクトの全メンバーが、プロジェクトの進捗状況、問題・課題、作成した資料など、プロジェクトに関わる全ての情報へアクセスできること。
- プロジェクトメンバー間で、いついかなる時でも、誰とでも、情報の齟齬なく、報告・連絡・相談と行った意思疎通ができること。
ということになります。これらを実現できれば、プロジェクトの大半の問題は解決すると言っても過言ではありません。
では、もっと具体的に解決すべきポイントを考えていきましょう。
3-1. プロジェクトを可視化する
まず、プロジェクトを可視化しましょう。
プロジェクトで可視化すべきものはなんでしょうか。
各工程で作成される成果物でしょうか。要件定義書、設計書、テスト計画書、など、これらは納品物としてたしかに必要です。ただ、製作途中のものも完成したものも、その内容は可視化されており、可視化が大事ではなく、品質を問うべきものであって、プロジェクトの運営自体には直接影響してきません。プロジェクトに不要というわけではなく、あくまでもプロジェクトを運営するにあたっては、その進捗と品質の状況が分かれば良いものです。
では、プロジェクトの運営上必要なもので可視化されていないもの、とはなんでしょうか。
進捗管理表です。
「え、進捗管理ならガントチャートやWBS(Work Breakdown Structure) などを、Excelで進捗状況を確認しているよ」とおっしゃるかもしれません。では、それらを使って管理されているあなたへいくつか質問をします。
- そのツールには全ての作業項目が記述されていますか
- そのツールで明記されている各作業項目は、他のどの作業項目に影響があるか分かるようになっていますか
- 各作業項目を実施する人は明確になっていますか
- その作業項目の完了基準は明確になっていますか
- 作業項目の「状況」を示す欄に「進捗状況90%」となったまま、数週間経過している項目はありませんか
- 今日、各メンバーは自分がなにをすべきか、正しく理解され、徹底されていますか
- そのツールを更新・管理している人は誰ですか
他にもまだ聞きたいことはありますが、これらの質問に正しく、自信を持って回答できる人は少ないのではないでしょうか。「ツールで管理している」という事実だけがあるだけで、それらのツールによって、プロジェクト自体を正しく管理されているわけではないのです。そのため、ツールは使っていてもプロジェクトの状態を一目で分かるような状況にはなっておらず、プロジェクトの健全性を把握することができない状況となっているのです。
「デスマーチ・プロジェクト第二版」p.111 コミュニケーションの重要性、において、プロジェクト運営において、プロジェクトの状態がどのようにあるべきか、次の3点で示されています。
- プロジェクト・マネジャーに秘密の無い状態。
- プロジェクト・チーム全員がプロジェクトの全てを知っている状態。
- メンバー全員がプロジェクトの現状、優先度、リスク、制限条件、政治的要素を全て承知している場合。
プロジェクト運営の可視化、とは、プロジェクトの状況を「全てのメンバーが」把握することのできるツールを持つこと、が大事とも理解することができないでしょうか。
では、それはこれまでの既存のツールでは何が不足しているのでしょうか。
先に示した質問をまとめると、その答えになります。
「すべての作業項目が、一人一人の具体的な作業内容に紐づけられ、納品物の状態や作業の完了基準が明確となった上で、いつ・誰が実施すべきかが明確となっているもの」
です。
WBSを例に、どのようになっているべきかをお話ししましょう。
WBSは、「大項目」「中項目」「小項目」などの階層構造によって、作業項目を分類しています。最も詳細な項目となる作業項目は、最小の作業単位として定義されるべきです。最小の作業単位であれば、その作業項目は唯一の「誰か」に紐づけされますし、この作業項目はなにをしなければならないのか、と考え込む必要がなくなります。作業者は、今日、実施する予定の作業項目を眺めて、まちがいなく作業を進められるようになることが理想です。
例えば、「Webサーバーの設定」という作業項目ではなく、「/etc/apache/httpd.conf ファイルの修正」と示し、参照元として「Webサーバー詳細設計書」、納品物として「Webサーバー構成パラメートシート」など、インプットとアウトプットまで明確にできれば、まちがいが無いでしょう。
そして、このWBSは全てのメンバーが全体も詳細も一任できるようにしていれば、各々のメンバーがプロジェクトの進捗状況を理解することが可能です。
このように、進捗管理のためのツールを正しく準備することで、プロジェクトを可視化することができます。
「そんな理想なんて分かっているけど、できるわけないじゃないか」
とおっしゃるかもしれません。では、その話は 4章で示すものとして、ここでは、もう一つの「2. メンバー間で情報を正しく連携する」について、先にお話ししましょう。
3-2. メンバー間で情報を正しく連携する
ここまでの話を見てきたあなたなら、このような気づきがあるかも知れません。
「理想のWBSを作成することで、情報を正しく連携できるようになるのではないか」
はい、それだけでうまく行くことが理想でしょう。
しかし、情報といってもプロジェクトの進捗状況を示すものだけではありません。今、私が思いつくだけでも、お客様から伺った要件、制約、プロジェクト運営で発生した課題、リスク、アーキテクトが設計したアーキテクチャと、その設計内容、などなど多岐に渡ります。これらは、WBS上の作業項目の内容へと影響を受けますが、WBS上に記述すべきものとは考えられていません。
では、WBSと同じように、受領した資料や作成資料、課題管理表も正しく理想どおり管理できれば良いのではないでしょうか。
しかし、これまででご理解いただけるように、残念ながら我々人間は、理想どおりに活動することができません。
プロジェクトに参加するメンバーは、性格・環境・知識など異なる感情を持った人間です。その日の気分や気持ちで、常に理想どおり行動することはできません。むしろ、その理想に反発して、一切、理想どおりに行動してくれないメンバーもいることでしょう。
「仕事だから」と命令したところで、そのメンバーが気持ちよく作業と活動をできるわけではありません。むしろ、各メンバーが、円滑に、楽しく、気持ちよく作業でき、メンバー間のコミュニケーションがうまく進められるような環境を準備することが大事なのです。
「そうは言っても、基盤の作業者はデータセンターに引きこもってるし、プログラマは頭を抱えながら、朝から晩までプロジェクトルームのPCを叩いているし、プロジェクトマネージャもアーキテクトもお客様の情シスに入り浸っているような状況じゃないか。どうやって、各メンバーが交わってコミュニケーションすることができるの?」
私もそう、ずっと考えていました。
場所も時間も活動内容も異なる、各々のメンバーが交流できる方法はないだろうか。みなさんも、考えたことはあるでしょう。
その解決策の一つに、SNS (Social Networking Service) があります。
あなたもTwitterやfacebookという名前を聞いたことはありませんか、そして、実際に使ったことはないでしょうか。mixiなどもそうです。少し毛色が異なりますが、GREE や mobage などの携帯ゲームも SNS を主体にしています。この SNS を利用すると、情報の連携、メンバー間の交流など、コミュニケーションを促進し、支援するはたらきがあることが分かってきています。
「なるほど、コミュニケーションの支援に SNS も利用することは分かるけれども、それだけで解決するようなものなの?」
お気持ちはよく分かります。私もここまでの内容だけでは半信半疑です。しかし、先の課題対策と含めて、ゲーミフィケーションを活用すれば、光明が見えてくると言うわけです。
では、具体的にどのような方法を使えば良いか、次の章で説明します。
4. プロジェクトの課題の解決方法
冒頭の話を思い返してください。
私は、プロジェクトの運営課題に対して、ゲーミフィケーションを適用すれば解決できるのではないだろうか、と考えました。
これからお話しする内容は、残念ながらまだ実績のない、机上の空論です。ですが、私は一つの確信を持って、この解決方法を推進していきたいと考えています。
それは、「みんなでするゲームは面白い」と言うことです。
思い出してください。子供の頃でもいいです。家族旅行でも、修学旅行でも、友人らとの旅行でも何でも良いです。そこで、なにかしらのゲームをやりませんでしたか?
定番のトランプ、双六、人生ゲーム(R)、uno(R)、それから、TVゲームの対戦でも、多くのゲームをする機会があったのではないでしょうか。そして、負けてしまって悔しい思いもしたでしょうが、ゲーム自体は楽しく、面白くありませんでしたか?
もしかすると、「TVゲームなんてくだらない、楽しいとも感じない」とおっしゃる方もいらっしゃるかも知れませんが、TVゲームはやらなくても、ボードゲームやじゃんけん、すくなくとも運動会でかけっこや騎馬戦などのゲームはしているはずです。みんなで集まってするゲームは面白い、楽しい、そう言った記憶がよみがえってきませんか? [III]よみがえらなかった人はゴメンね
ゲーミフィケーションでは、このゲームの要素を基に、企業や交流を「楽しく」改善していくための方法論です。ゲーミフィケーションを採用して、企業風土がよくなり、業績があがっている事例も多くあります。
なにより「楽しく」仕事をすることで、様々な改革が生まれてくると確信できます。アイディアは楽しい時間から沸いてでてくるもので、つらい状況下でいくら頭をひねったところで良いアイディアが出てくることは少ないでしょう。
私はこのゲーミフィケーションを採用することで、これまでのプロジェクトを改革し、楽しく仕事をするきっかけになり得ると考えています。
では、まず、具体的な解決方法を提案する前に、ゲーミフィケーションについてご説明しましょう。
4-1. ゲーミフィケーションとは何か
ゲーミフィケーションと言う言葉自体は 2010年に生まれたばかりの新しい思想・方法論です。そのため、定義のはっきりしていない部分もあり、今後の運営で変わっていくこともあるかも知れませんが、”ゲーミフィケーション – Wikipedia” にうまくまとめられているので、そちらから、まとめられたものを拝借します。
ゲーミフィケーションの定義
(a) 最広義: ようするに、ゲームっぽくて役に立つものなんでも。
(b) 狭義: 「コンピュータゲームのなかで特徴的に培われてきたノウハウを現実の社会活動に応用する」こと。アドバゲームやシリアスゲームは含まない。
(c) 最狭義: そのなかでもとくに「強化学習プロセスやフロー体験を成立させるための最適なフィードバック設計のノウハウ」を応用すること。
要するに、ゲームの要素を取り入れて、現実社会の課題を解決するための方法ということになるでしょう。それであれば、現在は広義でも狭義でもゲーミフィケーションと定義された内容に合うと認識しています。
具体的な事例を示します。
一番ありふれているのは、ポイントカードでしょう。
あるお店の商品を、いくら以上購入すると、その金額に従ってポイントがつくシステムです。そして、ある程度ポイントがたまると、そのポイントに応じて、景品がもらえたり、サービスを受けたりすることができます。
販売店側から見ると、ポイントカードを渡したお客様にリピーターになっていただき、売上活動に貢献してもらいたいということになり、顧客側からすると、ポイントをためていくことによって、報酬を得られることで、嬉しい、楽しい気持ちとともに、商品やサービスを手に入れることができます。
この顧客側が、「報酬を得る」ことのできる点がゲーミフィケーションによる要素です。
もう一つ、別の事例を示しましょう。
facebook の「いいね!」も、人間の持つ承認欲求を得ることのできるゲーミフィケーションの要素の一つです。
ユーザーは、facebook へ写真を公開したり、その日に起きたできごとや、思いついたことを記述したりして公開していきます。facebook 上の友達は、その内容を見たときに「いいな」と感じたときには、「いいね!」ボタンを押すことで、その意思を示すことができるようになっています。とても簡単な仕組みですが、この「いいね!」がカウントアップしていく仕組みにより、公開したユーザーは承認欲求を得ることができ、嬉しい、楽しい気持ちになります。要するに、人と交流したことで、ちょっとした報酬を得ることにあたります。
これにより、「よし、次はもっと良い写真を公開するぞ」「次はもっと面白いことを書いてやろう」という想いを抱き、また facebook のシステムを利用したいという気持ちになります。
facebook 運営側はこういった機能を提供することで、システムを使い続けてもらうようにしているわけです。
これら、ポイントカードや「いいね!」の機能は、売買機能やfacebookの根幹が提供する機能とはまったく必要のないもの、おまけの機能のように思えますが、実はこれはとても大事な仕組みとなっています。
どちらのケースにおいても、「ユーザ(顧客)に何度も利用して欲しい」という課題に対する解決策になっています。ポイントカードや「いいね!」の機能を提供することで、ユーザ(顧客)へ報酬を与え、リピートしてもらうための機会を増やしているのです。
また、人は次の6つの段階を経て、何かを学び、習得する知的好奇心をもち、その結果、「やりがい」を得ているものと考えられています。特にゲームでは「報酬」「習得」に対する快楽的要素を高めることで、「達成感を得る」効果が発生し、くりかえしゲームを継続するような「ゲームにはまる」といった現象を生むことに繋がっています。
- Desire(欲望)
- Incentive(インセンティブ)
- Challenge(チャレンジ)
- Achievement/Reward(達成/報酬)
- Feedback(フィードバック)
- Mastery(習得)
では、やみくもにゲームの要素を取り入れていけば、社会の課題が解決できるのでしょうか。
答えは「NO」です。
ゲームの要素があれば、人はそのために活動をするわけではありません。
人間がモチベーションをもって活動をするためには、相応の報酬が必要となります。プロジェクトの完遂とは、そもそも仕事ですので、それを実行することで対価となる給与を得る、すなわち金銭的な報酬を得ることに繋がっています。ですが、そのような将来に約束されたような報酬だけではなく、精神的な報酬というものがあります。
人間の活動は精神活動をベースにしていますので、金銭面だけではなく、作業者のニーズに合った心理的な「報酬」が必要となります。
また、人は交流することによって様々なものを得ることができます。例えば、プロジェクトや会社へ貢献することによって、他の社員から、感謝や承認されることで満足感を得ることができます。その結果、自ら意見を相手に伝えるようになります。このように社員が求めていく「交流」を考えることも、ゲーミフィケーションの重要な要素の一つとなります。
このように、ゲーミフィケーションでは、「課題」、「報酬」、「交流」、のサイクルをうまく巡らせて活用することで、課題にあわせた解決策を見つけることができる、と 岡村健右氏は「ゲームの力が会社を変える -ゲーミフィケーションを仕事に活かす-」の中で記述しています。
ゲーミフィケーションがどのようなものか、ご理解いただけたでしょうか。
では、実際にどのように、このゲーミフィケーションを実現していくか、”gamification.jp” の運営をしている 深田浩嗣氏が自著「ゲームにすればうまくいく」内で 、図1. の 9つのフレームワークを提示しています。
これを「g-デザインブロック」と呼んでいますが、これらのブロックは、課題を見つけて改善するために必要な内容を順番に示している、デザインプロセスに当たります。ゲーミフィケーションを実装するにあたっては、これらブロックを順番に進めていくことで、課題の解決ができるということを示しています。
各ブロックについて、私の理解した範囲で簡単にご説明します。詳しくは、著書をご覧いただければ幸いです。
- 可視化
- 効果・進捗を具体的な数値などによって、見える化すること。自分の成長度合い、進み具合が全体のどこまできているか、目標に対してどこに位置するかを明確にすることで自分が成すべきコトを理解するために必要です。昔のゲームには「スコア」がありましたが、切磋琢磨、競争をするための指針は何だったかというと、この「スコア」でしたよね。これも単純に「可視化」の効果が見込まれるものです。この「スコア」を競って、日々、ゲームを続けたのではないでしょうか
- 目標
- 「可視化」できると、次に見えてくるのは「目標」です。数値化して見える様になったことで、目標を明確に定めることができるようになります。「英語が話せる様になりたい」では、どこまでいけばゴールかサッパリ分かりません。「TOEICで730点を超えること」とすれば、自分の成長度合いを正しく把握することができます。730 が話せるかどうかはおいといて、「目標」を明確に定義できることは、自分の進むべき立ち位置がぶれない、ということも指し示します
- オンボーディング
- 提供する商品・サービスの基本的な利用方法や価値は、説明書やヘルプを見なくても、使いながら分かるようにする手法です。パッと見て分かりやすいボタンの配置や、ウィザード形式のプロセス、操作に悩まないUIなどの実装を意味しています。これは、「まず使ってもらう」ことでハードルを下げ、利用者を増やすことが目的です
- 世界観
- ファンが、よりファンとなっていく仕組みの仕掛けです。一度入り込んだら出て行かない、練りに練られた「世界観」を準備することで、一度、その領域へ入ったものを外へ出て行かない様にします。昔のパソコン用のRPGでは、パッケージのマニュアル装丁がとても凝ったものが多く、ゲームとはまったく別の場所からその世界観を準備していました。ゲーム自体では多く語られなかった時代背景や、歴史を準備することでゲームを盛り上げる効果を作るとともに、その「世界観」をユーザへ与えていたと考えられます。
- ソーシャル
- 「世界観」が良いと次に起こす行動は「交流」を望みます。居心地の良い世界観について、共感してくれる仲間がいれば、同士を感じ、同じように語り合いたくなるのはゲームの世界でも同じです。ちょっと思い出していただきたいのですが、ゲーム自体はその世界の中で閉じていたとしても、同じゲームをやっている仲間と、情報交換であったり、熱く語らったことなどなかったでしょうか? よき「世界観」をもったゲームの中では、人との交流が重要な要素となり得るわけです
- チューニング
- ゲームを継続してもらうための調整です。オンボーディングで敷居を低くしてとっつきやすくして、世界観に酔いしれ、良き友人と語り合っていただいている間は良いのですが、その作りが途中でおかしなポイントがあると、最悪、もう二度と継続してもらえない様なことがあります。RPG で、素直に進んでいくとLV30で出会うボスがいたとします。ただ、そのボスはLV45以上なければ、倒せないとした場合、どんなに世界観が後押ししてくれたとしても、15もLVをあげるだけのモチベーションを保ってもらうことは限りなく難しいです。そこで、こういった、ゲーム難度などの調整をすることで、途中で投げ出すことのない様な仕組みを準備することができます
- 上級者向け
- 更にその先、いわゆる最後までクリアーした人などの超越者向けへの対応です。「やり込み要素」などとも言われる部分です。ゲーム自体はクリアしたけれども、その後もゲームはできるし、より強い、珍しい武具や、より強い敵、より難度の高いものを準備して、ある程度のレベルを超えた人たちを救済する、その先を見据えたシステムを準備することです。一通り決められた仕組みがすんだ後、始めたばかりの人とはちがう、より効率の良い仕組みを利用することができる何かを提供することで、やりこんだユーザを確保しておくことが目的です。上級ユーザは、初級ユーザや、利用していない人への広告媒体としてとても価値の高い人たちになり得るという黒い目的がメインです
- ゴール
- それを使ったことで得られる価値そのものです。先に出てきた「目標」を積み重ねたことによって、到達できるものです。「TOEIC730点」という目標に達成したとして「英語を話せる」というゴールには近づきますが、それだけではゴールできません。多分ドコまで行ってもゴールできないとは思いますが、このように、目標をいくつもいくつも定義し、それらに向かって進んでいくことで「ゴールが近づいてくる」感を得られることが重要なポイントとなるわけです。近くの目標を達成したら終わりではなく、限りなく先にある夢を叶えるため、それらの目標はそこに存在するのです。
- おもてなし
- 日本人に古くから根付く文化ですが、日本のゲームの根底にもこの「おもてなし」文化の花が開いています。「おもてなし」とは、相手を深く理解し、何を求めているかを察知した上で、その時々で臨機応変に対応することを示しています。冬の寒い日に外からいらっしゃった客人に、ストーブの前の席や、温かいお茶を提供することは「おもてなし」の心そのものです。ゲームの手法は「おもてなし」を体現することそのものでもあります
このデザインブロックを元に、ゲーミフィケーションは課題、報酬、交流のサイクルをもち、ゴールを明確にしたフレームワークに従った考え方に基づいて、理論で裏付けされたゲームの要素を取り込んで、課題を解決するための方法論です。
では、このゲーミフィケーションを利用することで、先の二つの課題について考えてみましょう、と言いたいところですが、もう一つ、ゲーミフィケーションを語る上で、もう一つの大事な理論が必要だと考えています。それは、人が満足のいく体験をなす上で重要な鍵を握る「ゲームニクス」という理論です。
4-2. ゲームニクスとは何か
「ゲームニクス」とは、サイトウ・アキヒロ氏が提唱している理論で、「ゲームへはまり込ませる技法」と一言で言い表すことができるでしょう。
ゲームの要素をもつゲーミフィケーションでは、より楽しくゲームをさせるための技法、考え方も重要な要素です。ゲームニクス理論をベースにして、ゲーミフィケーションの方法論を組み立てることで、「楽しく」体験することのできる必要不可欠な要素なのです。
先に示した、「g-デザインブロック」の一つ「オンボーディング」とは、まさにこの「ゲームニクス」であると著者の深田浩嗣氏も伝えています。私個人の考えとしては、この「ゲームニクス」の考え方は「おもてなし」の心が背景にあった上で、初めて意味をなすものと考えています。ですから、ゲーミフィケーションを支える上で、このゲームニクスは切っても切れない関係であると、私も図2.のように考えています。
では、「ゲームニクス」の目的とはなんでしょうか。
二つあります。
- マニュアルがなくてもすぐに理解し操作できるようにする
- 難しいことでも自然とできるようにする
一見、ゲーミフィケーションの要素とは関係なく感じるかも知れませんが、ゲーミフィケーションで提供されるインタフェイスの考え方としては、特に重要です。とにかく「相手を思いやる心」が必要なゲーミフィケーションにおいて、利用者視点で使い勝手を考えることが「おもてなし」に繋がると考えられています。
プロジェクトの運営とは、一筋縄ではいかないものです。WBSとEVMを管理・運用するだけでも、一朝一夕でできるものではありません。数日かけたそれ専門の研修コースもあります。しかし、せめて、ツールだけでも簡単に操作ができて、難しいことも自然とできるようになるといかがでしょうか。プロジェクト運営の敷居が下がり、利用者のミスも少なくなりはしないでしょうか。また、ツールを使いやすくなれば、現場のメンバーでも、マネージャと同じように情報の共有も簡単にできるようになるとは考えられませんか?
それでは、ゲームニクスは、どのように実現されるのでしょうか。サイトウ・アキヒロ氏は、自著「ゲームニクスとは何か」に次の四原則を掲げています。
- 直感的なユーザー・インターフェイス
- マニュアルなしでルールを理解してもらう
- はまる演出と段階的な学習効果
- ゲームの外部化
各原則に従ったゲームをデザインすることで、より楽しい、「ハマるゲーム」を作ることができると伝えています。
では、具体的に、各原則ではどのような点を考慮すれば良いのでしょうか。各原則における考慮点を確認していきましょう。
4-2-1.第一原則 「直感的なユーザー・インターフェイス」
- 入力デバイスと操作性
- デバイス特性に合わせたメニューデザイン
インターフェイスとは、ユーザーの入出力に直接関与する部分のことです。通常、PCを使って利用される場合では、キーボードやマウスが入力となり、画面がアウトプットとなります。ですから、キーボードやマウスからではない、タッチパネルなどの入力を強制することは問題外として、キーボードやマウスで、何をどこでどのように使うべきか、画面を一見しただけで、「利用する誰もが」分かることが第一原則です。
4-2-2.第二原則「マニュアルなしでルールを理解してもらう」
- ボタンの信頼性
- 導入部でルールを理解
- レベル設定
- ヘルプの工夫
第二原則は、想定外の動作が行われないことが重要です。
例えば、マウスは通常二つのボタンを持っています。右利きの場合、左クリックが決定、右クリックがキャンセルやメニュー表示というのが一般的な使われ方です。このような、一般的に利用されている方法を使わず、決定する効果を持つボタンが、特定の画面で逆になるようなインターフェイスが存在していたらどうなるでしょうか。最後の決定を司る画面だけ、右クリックが決定となっていたら、利用者は戸惑うことなく利用することができるでしょうか。
もし、こういった原則から外れるような場合が生まれてしまう場合でも、チュートリアルを準備し、画面にヘルプを表示して、まちがいの無いように従わせる方法も一つです。また、使い方が複雑になってしまうような場合でも、ヘルプが表示されるような仕組みは必要となるでしょう。
また、利用者のレベルによって、使える方法を複数用意することも良い方法です。使い始めの利用者には、画面で見たとおりのボタンを押すようにマウスで操作できるようにしておきますが、慣れてきた利用者のためにそれらをショートカットできるようなメニューや、ショートカットキー(アクセラレートキー)などを準備して、より効率よく操作できるようなインターフェイスを準備することも一考に値します
そして、これらはマニュアルを見ずとも、利用者が分かるようになっていることが大原則です。
4-2-3.第三原則「はまる演出と段階的な学習効果」
- ゲームテンポとシーンリズム
- ストレスと快感
- 目標設定
- 学習効果
だんだんと業務とは関係のない、ゲーム固有の話になってきているのでないか、とお思いかも知れませんが、これらも重要な要素になります。
特に業務系のシステムで多いのですが、機能を満足させることが優先して、テンポの悪い仕組みを採用しているものが見受けられます。テンポが悪いとは、例えば、ボタンを押した時に、反応が分からないようなものや、処理されているのかどうか分からないようなことで、利用者のリズムがそがれてしまうことです。ボタンを押したら、へこんで欲しいですし、それっぽい音が鳴るのもいいでしょう。なんらかのリアクションがあることで安心します。
理想的なのは、例えば、打鍵で進んでいくような場面で、ストレスなく、テンポ良くキーを打鍵できるようにすることです。店舗が良いと気持ちが良いですよね。ある程度、同じリズムを取ってキーを打鍵できるような画面遷移やテンポあるインターフェイスを準備することが特に重要です。
また、多少処理のかかるようなものの場合、プログレスバーを表示したり、マウスが砂時計マークになったりと、状況を指し示してくれることでも安心することができます。
このように、使っているコト自体がストレスとならない、快感を得るような仕組みをつくることで、飽きさせない、また使いたい、と感じられるインターフェイスになります。
そして、だんだんと複雑な利用方法も使えるような段階的な仕組みを準備し、だんだんとそのツールを使いこなせるようになっていけるようにすることも必要でしょう。たくさんの機能を提供されているシステムに、最初から全ての機能を画面上に並べるのではなく、だんだんとなれてきたら、少しずつ必要な機能を使えるように促していくのです。もちろん、最初からハードな利用者もいるでしょうから、使えないようにしておくのではなく、徐々に使い方を理解できるような仕組みにしていくことが重要なのです。一度の多くのことを学習していくことは難しいので、一つ一つ、利用者に必要なことから順番に使えるように、段階をもって利用可能な仕組みを提供することが重要となります。
4-2-4.第四原則「ゲームの外部化」
- ゲームの外部化
- リアルな世界を、ゲーム内に誇張して再現する
ゲームの外部化とは、ゲーム以外のところでもゲームを体感できるような仕組みや、現実世界の内容をゲームに取り込んでいくことです。
まず、ゲームの世界の中で得た経験値や体験したことを、現実世界でも体感できる仕組みとはどのようなものかというと、流行ったものでは「脳トレ」があります。ゲームをすることで、脳を活性化させ、実際に脳に良い影響を与えています。また、あまり良い例ではないかも知れませんが、ゲーム内で得たアイテムを RMT (Real Money Trading : ゲーム内でのアイテムを現実のお金で売買する) するようなものも、ゲームの外部かの一つかも知れません。他には Wii Fit によって、ダイエットの効果を示すようなものもあるでしょう。
現実世界をゲームに取り込む仕組みは、シミュレーションに代表される、ドライブゲームや野球ゲームなどです。現実として存在するスポーツを、ゲームで体感させる仕組みです。飛行機のパイロットが、実際の飛行機を操縦する前には、フライトシミュレータを使って、何百時間も練習をして、はじめて操縦するよう仕組みができあがっているものもあります。
では、ゲーミフィケーションにおけるゲームの外部化、とはなんでしょうか。
私はソーシャルネットワーキングを指すと断言します。ツールの中で閉じた仕組みではなく、そのツールをベースに、他の利用者とやりとりができるようになること、それをゲームの外部化と考えます。
4-3. プロジェクトを可視化する方法
ここまで説明に終始してきましたが、内容はご理解いただけましたでしょうか?
これからやっと本題に入ります。まずは、プロジェクトを可視化しましょう。
ゲーミフィケーション・ゲームニクスに照らし合わせて、現在のWBSの課題点を抽出しましょう。
[課題点]
- WBS には「報酬」制度がない
- WBS だけでは「交流」することができない
- プロジェクト監理者の視点でしかインタフェイスが作成されていない
要するに、管理に主眼がおかれすぎているため、作業者は WBS を元に自分の TODOを明確にすることができていなかったわけです。
では、これを受けて、新しい WBS に必要な機能はなんでしょうか。9つのフレームワークも考慮に入れて検討してみましょう。
[WBSに必要な機能]
- 進捗状況を一目で分かるようにすること (目標/可視化)
- 作業の因果関係を一目で分かるようにすること (可視化)
- EVM と連携し、コストを明確に、一目で分かるようにすること (可視化)
- 作業の完了や、作業項目の詳細化や修正などのプロジェクトへの貢献作業により、ポイントを付与させること (上級者向け)
- 作業者の視点で、今日の作業/残りの作業数/完了した作業数、入力と出力、誰の作業に影響するか、など必要な情報を一目で分かるようにすること(可視化/おもてなし)
- 監理者、作業者など利用者により、メニューや画面を分離して実装すること (オンボーディング/おもてなし)
- 全体の操作、画面などインターフェイスを統一させ、利用者のテンポを崩さず、まちがいを抑制するようにすること (おもてなし/世界観)
作業する側が、何をしないといけないかが分かるように一見できるようにして、監理者側はプロジェクトの状況を一見できるようにすることです。一見できなければ、ほとんど意味がありません。必要な情報にスマートにアクセスできなければ、そのツールは利用されません。
監理者側と作業者側とでは、基本的な画面を別にすることが良いと考えていますが、どちらもシームレスにアクセスできて、情報をメンバー全員に知らせる機能も必要と考えています。
ご想像いただけますでしょうか、このような仕組みを提供するためには、これまでによく使い古されたExcelでの提供は困難であると考えています。その代わり、Web化や、専用のアプリケーション化することで、ネットさえ繋がっていればどこでも利用が可能になり、各作業者が、タイムリーに進捗報告をすることができるようになる仕組みになればと考えています。
各作業者は、朝の出勤時にアクセスをして、今日、実施すべき作業を確認し、その作業に没頭します。必要に応じて、追加の作業や、修正があれば、その時々で対応します。プロジェクト・マネージャは、各作業の進捗状況をリアルタイムに確認しながら、プロジェクトの課題やリスクの対策を検討します。
このように、利用者側の視点に立って、今まで使ってきたWBSを見直していくことが、プロジェクトの可視化に繋がっていきます。
4-4. メンバー間の情報を正しく連携する方法
それでは最後に、メンバー間の情報を正しく連携する方法を具体的に検討していきましょう。
[課題点]
- プロジェクト・マネージャは全てのメンバーと個々に対話すること、状態を知ることが難しい
- メンバーが感じた小さな課題を拾い上げることが難しい
- プロジェクト・マネージャと実際の作業者が常に同じ場所にいられることは少ない
このように、プロジェクトの全ての状態は、全てのメンバーと共有され、理解し合わなくてはならないにも関わらず、プロジェクト・マネージャは現場の作業者とは、距離が離れ、一緒に居る時間が減り、心が離れていきます。定型的になった定例会議では、ありきたりの進捗の情報だけがやりとりされ、本当は必要な小さな課題を拾い上げず、今、起こっている大きな課題だけが取りざたされ、プロジェクトは遅延します。
メールのようなツールを使うことで、直接、現場のメンバーがプロジェクト・マネージャへ進言することは可能でしょうが、メールを書いて相手へ進言することはとても労力のいることです。ちょっとした思いつきのたびにメールを出していたら、メールを送る方も受け取る方も情報の整理が難しいでしょう。
もっと、簡単に、直接ではなくても間接的に、しかし、思いついたことを思いついたときに、作業項目とで紐付いて書き留めておければ良いと考えられはしないでしょうか。
今、プロジェクトのメンバーたちが情報を連携する上で必要な機能とはなんでしょうか。関係するフレームワークも思い描きながら検討してみましょう。
[情報連携に必要な機能]
- WBSを軸に、利用者間のコメントのやりとりができること (ソーシャル)
- WBSの作業項目に紐づけて、作成物のアップロード/ダウンロードができること(可視化)
- 必要なグループ・メンバーに連絡を取る手段が提供されていること (ソーシャル)
- 「いいね!」のような機能により、利用者のコメントの評価可能なこと (おもてなし)
お気づきかも知れませんが、先の WBS の改善と、この情報連携の仕組みをあわせることで、9つのフレームワークに必要な機能を網羅することができるようになります。課題としては二つに分かれていましたが、ゲーミフィケーションの観点で見た場合、二つの課題を一つの解決策としてまとめることができるということになります。
課題を提示したときのことも思い返してみてください。この二つの課題は相互に関係し合っていて、お互いを解決できなければ、良い解決策にならないとお話ししました。
このように、ゲーミフィケーションを採用したことで、運営上の課題を一つの解決策で導き出せる可能性を見いだすことができました。
それでは、先の WBSツールと含めて、情報連携機能について考えていきましょう。
プロジェクト運営は、WBSを中心に実行されますので、WBSツールを軸にしてソーシャルネットワーキングを構築することは理にかなっていると考えられます。作業単位、作成する資料の単位、参加するグループや担当者の単位はWBSの作業項目と紐づけられるからです。
たとえば、作成された資料は、それだけで一見できることはもちろん必要な機能でしょうが、作業項目単位で、作成された資料ができあがっているかどうか、その資料へリンクされていれば、WBSを見ているだけで資料の内容にもアクセスすることができるようになります。
ソーシャルネットワーキング機能も、WBS の作業項目単位でコメントを見られる方法と、それとは別に一覧してみることのできる、専用の画面もあったほうが良いかもしれません。他チームの状況を確認し、全員向けのコメントなどは専用の画面からのほうがアクセスしやすいと考えられます。
また、細かい機能かも知れませんが、重要なコメントや、個別のメッセージが届いた場合には、メールで通知されたり、画面でポップアップされたりと、アクティブに意思表示される方が見逃すこともないでしょう。
このように、プロジェクト運営に必要なWBSツールに、ソーシャルネットワーキング機能を組み合わせた仕組みを準備し、プロジェクト運営でそのツールだけを利用するようにします。これにより、複数のツールの使い方を学習することもなく、余計な手間暇をかけずに作業に没頭することができるようになるのではないでしょうか。
今回は、ツールの提言までにとどまっていますが、今後、このツールを作成して、プロジェクトの運営を効率化する仕組みを提供して、この仮説を検証していきたいと考えています。
みなさまも、同じようにゲーミフィケーションの観点で、小さな仕組みから改善されていくことに利用されてはいかがでしょうか。
5. まとめ
ここまで、プロジェクト運営における課題を改善できないか、ゲーミフィケーションを用いて仮設を立てて考えてみました。現実的な課題とあわせて一緒に考えることで、よりゲーミフィケーションの考え方が理解できたのではないでしょうか。
ゲーミフィケーションの考え方は古くからあるものですが、最近になって体系化されつつある、発展途上の方法論でもあります。根底にあるのは、利用者に楽しんでもらおう、という「おもてなしの心」です。使用するツールもアプリケーションも、実際の利用者は人間です。人と人との関わりをもって関係をしていくためには、相手を思いやる気持ちが必要不可欠です。
そして、そのおもてなしの心は、人と人との交流をへて、相手の心理的な報酬へと繋がります。
報酬とは金銭的なものばかりではなく、もてなしたことで得ることのできる精神的な報酬のモチベーションが重要です。人を動かすためには、お金も重要ですが、行動すると良い結果に繋がる、精神的な報酬がそこに生まれることが必要です。そのためには、相手を思いやる気持ちをもって、課題の解決につなげていくことです。
課題を解決するための「報酬」と「交流」、根底にある考え方は「おもてなしの心」であることがゲーミフィケーションの重要な考え方となります。
- プロジェクトは「人」により失敗する
- プロジェクトは「可視化」されない
- プロジェクト運営を改善するには「可視化」と「正しい情報の連携」が必要
- プロジェクトを「楽しく」運営するにはゲーミフィケーションが必要不可欠
- ゲームを楽しくする「やりがい」を得るには 6つのプロセスが必要
- 欲望
- インセンティブ
- チャレンジ
- 達成/報酬
- フィードバック
- 習得
- 「ゲーミフィケーション」では課題、報酬、交流のサイクルを繰り返す
- 「ゲーミフィケーション」の実現に「ゲームニクス」理論に支えられた「おもてなしの心」が重要
- 「ゲーミフィケーション」でプロジェクト運営ツールのユーザビリティ改善と、プロジェクトの可視化をサポートすれば、きっとうまくいく
プロジェクト運営の改善だけではなく、どのようにして「楽しく」仕事をしていくか、ゲーミフィケーションの考えもとりいれて、日常に変化を求めてみてはいかがでしょうか?
[tmkm-amazon]4822282716[/tmkm-amazon]
[tmkm-amazon]4881668579[/tmkm-amazon]
[tmkm-amazon]4140815361[/tmkm-amazon]
[tmkm-amazon]434498045X[/tmkm-amazon]