ファシリテーションとの出会い

ファシリテーション（※1）は促進するという意味があり，主には利害関係者の納得感を高める手法としても注目されています。著者は数年前から日本ファシリテーション協会に会員として参加し，運営委員も行っています。

ファシリテーションの勉強を始めたきっかけは，1冊の本でした。その本は「組織をファシリテーションで変革していく」というテーマで書かれていました。元々がドラマのルーキーズのような「熱い気持ち」が大好きで，「⁠お客様のためによりよい仕事がしたい」「⁠プロの心得を会社に浸透して，みんなが羨むようなすごい組織にしたい」といったものを目指していましたので，ファシリテーションの考え方に心が動かされました。

現在は，プロジェクトや組織にも意識的にファシリテーションを持ち込むようにしています。今回は，事例を元に，エンジニアのモチベーションが上がること（下がること）について，考えてみたいと思います。

※1

ファシリテーションの説明については，日本ファシリテーション協会のホームページで詳しく説明されています。人の気持ちを扱うもので，考え方だけでなく，色々なスキルがあり，大変奥が深いものです。

プロジェクトリーダとしてのデビュー

筆者がシステムエンジニア歴数年だった頃，初めてプロジェクトリーダ（※2）を任されました。プロジェクトの進め方などほとんど理解しておらず，経験も未熟だった筆者には大変な重責でした。

また，そのプロジェクトが開始した時，炎上プロジェクトがいくつか発生していたため，上級システムエンジニアすべては炎上しているプロジェクトにアサイン済みの状況でした。そのため，プロジェクトの体制は，色々な所から集められた特に業務に精通していない私を含めたメンバー4名という状況でした。

任されたプロジェクトは他と比べて大きくなかったため，「⁠そろそろ一本立ちしろ」「⁠これくらい乗り越えろ」という周りの空気を感じ，大きな荷物を背負っての山登りを行うかのような感覚を覚えました。

先輩方が作られたスケジュールや管理方法を見よう見まねでプロジェクト計画を立てたり，成果物をどのような形で整理すればいいのかを悩み，結局イメージが出来なかったりしたのです。「⁠こんなんでいいの？」「⁠カンベンしてよ」というのが本音でしたが，山を登るしかありませんでした。

※2

プロジェクトリーダは，プロジェクトの責任者であるプロジェクトマネージャ（筆者の会社では，プロジェクトマネージャとなっている人は複数のプロジェクトを兼務するのが通例）の元で，システム仕様の統括やお客様との調整を中心となって行う，プロジェクト実務のトップの事です。プロジェクトリーダを置かない会社はプロジェクトマネージャと同等と考えてください。

厳しい現実

プロジェクトを開始し，程なくして暗礁に乗り上げました。お客様の課題を解決できる案が分からず，会議の繰り返しとなったのです。

会議の出席者は役職も立場も違う方々で，現状の様々な問題点や解決案をあげていきましたが，あーでもない，こーでもない，とやっているうちに，落としどころが分からず議論はグルグルと回り始めました（近年は，要件定義をお客様がしっかりと行い，スコープを固めてからITベンダーが参加するケースがほとんどですが，当時は目標設定のみでプロジェクトが発足し，要件を決めるところからITベンダーが参加することも多くありました⁠）⁠。

筆者とプロジェクトメンバーは議事録をひたすらとり，議論にも参加しましたが収拾せず，そうこうしているうちに，明確な成果物もないまま，あっという間に半年が経過してしまいました。スケジュールも，その間に何度も書き換えられていきましたが，今思えば，そもそもスケジュールと呼べる代物ではありませんでした（※3⁠）⁠。

そんなある日，お客様の社長から状況報告をするように依頼がありました。まだ駆け出しでスキルが低いと自覚のあった筆者は，力量不足でリーダ交代を要請される覚悟をしました。既に疲れ果て，モチベーションも最悪になっていて「首にしてくれ」という気持ちも恥ずかしながらあったと思います。

※3

ある程度落としどころが分かっている場合は，スケジュールを作成しながらプロジェクトの流れや成果物のイメージがわくものです。上手に進行するプロジェクトの多くは，プロジェクトリーダが作成したスケジュールに意図が見えます。

厳しいプロジェクトがきついプロジェクトではない

著者は，1時間程度，プロジェクトチームが理解していること，そしてその現状と課題をお客様の社長に説明しました。また，これまで掛かっている費用の取り扱いについて話もしました。

そして，これから今後の対策方針について話を進めようとした時に，突然，その社長が話を始めました。「うちのメンバーが悪いんだろう。いや，自分が悪いんだろう。プロジェクト体制を変更する。方針は……」と切り出し，筆者をはじめとするエンジニアのスキル不足が指摘された後，「⁠お前は最後まで逃げるな。うちで育てる」と激励されました。真意は分かりませんが，直接の報告はしていなくても一生懸命やっている姿勢は評価してもらえていたようです。

その直後にお客様のプロジェクト体制が大幅に変更され，「⁠あの人の立場は大丈夫だろうか？」と思いながらも，プロジェクトは確かに持ち直しました。残されたプロジェクトメンバーの顔色も確かに変わったと思います。それまでは，お客様に対して「好き勝手言うな。もっと建設的な話をしようよ」と心の中で思いつつも，何も解決できずにいましたが，その出来事を期に「なんとしてでも稼動させる。最後までやりきりたい」という大きな意識変化がありました。

最後までゴタゴタし，大変厳しいプロジェクトでしたが，社長からの一言で最後まで逃げずに乗り切れ，今では大変な財産になっています。

モチベーションについて振り返る

モチベーションは，様々な出来事に影響を受け，上がったり下がったりします。それは本人が気付かない些細なことかもしれません。それは，お客様のちょっとした一言だったり，上司からの評価だったりします。しかしそれが，プロジェクトリーダに与える影響は計り知れないでしょう。

最初に述べた通り，筆者は，ファシリテーションをプロジェクトに持ち込む事に取り組んでいます。意識的にメンバーのモチベーションをあげる努力を心がけているのです。「⁠それがリーダの本来の役目だろ」と言われるかもしれませんが，意識せずにメンバーのモチベーションを上げる事は大変困難でしょう。

自分がモチベーションがあがった体験を思い出し，それをひとつひとつ文書にしてみてはいかがでしょうか？　モチベーションについては，別の機会に他の事例で紹介したいと思います。