スポンサーサイト

    上記の広告は1ヶ月以上更新のないブログに表示されています。
    新しい記事を書く事で広告が消せます。

    このエントリーをはてなブックマークに追加

    アプリ開発にはファシリテート型リーダーが必要 その2

    ファシリテート型リーダーは何をやるのか


    ファシリテート型リーダーは何をして、それがどうアプリ開発に活かされるのか?

    私の考えを簡単にまとめてみようと思います。

    メンバーの考えを聞き出す


    ファシリテート型リーダーは、メンバーの
    ・やりたいこと
    ・やりたくないこと
    ・問題だと思っていること
    ・アプリの成功に必要だと思っていること
    などをあの手この手でうまく聞き出します。

    人間というのは不思議なもので、普段無口な人も、聞いてみると驚くほど多くの意見を持っているものです。

    そして、ただ「聞かれた」「話した」
    だけであっても、自分の意見が尊重されている、ひいては自分が尊重されていると感じてくれるものです。

    議論を通じて、合意を形成する


    様々な意見を引き出したら、ファシリテート型リーダーは次にそれぞれの意見について議論を促します。
    チームには様々なメンバーが集まっていますので、当然ぶつかり合う意見もあるのですが…

    ファシリテート型リーダーは、自らその意見について優劣をつける事は基本的にしません。
    メンバー同士で議論し、納得して合意形成するのを促し、待ちます。

    そうすることで、その合意は
    『させられたもの』ではなくなり、
    当事者意識が芽生えていきます。

    チームの声に応え続ける


    全員が当事者意識をもったチームが作れれば、
    基本的にリーダーが引っ張らなくてもチームは自走しますし、
    より良いものが作られていきます。

    コンセプト、設計などに問題や矛盾が見つかっても、メンバーが自発的にその問題を解決していきます。

    ファシリテート型リーダーがやることは、チームをこの状態に保つこと、チームのさらなる要望に応え続けること。

    そして、新たな挑戦のきっかけを与えることだけです。

    このチームに可能なこと


    この形のチームが出来上がれば、アプリ開発にありがちな以下の問題は解決されていきます。
    ・作るものの全体像がイメージしきれない
    メンバーが自発的に、それぞれのイメージを語り合い、よりユーザーに求められる形をイメージしていきます。

    ・急な仕様変更
    そもそも、仕様変更はイメージのズレから主に発生するので、この問題の発生頻度も下がります。
    また、仮に発生したとしても、それが必要だという共通認識があるので、全員が最適なリカバリー方法をすぐに考え出します。

    ・信頼関係のないチーム
    十分に意見交換をし、互いに理解を深め合ったメンバーですので、チームは自然と信頼関係で結ばれていきます。

    まとめ


    以上のような観点から
    アプリ開発にはファシリテート型リーダーが必要
    だと考えるわけです。
    皆さんの意見はどうでしょうか。
    このエントリーをはてなブックマークに追加
    スポンサーサイト

    アプリ開発にはファシリテート型リーダーが必要

    アプリ開発にありがちな罠


    もう結構長いことアプリ開発の仕事をしてきていて、様々な失敗を見てきたので
    こういう事ってありがちだよなという事をまとめてみます。

    そしてそれを解決するにはファシリテート型リーダーが必要だという文脈で
    最近の考えをまとめてみようと思います。

    ゴールのイメージを誰も持っていない


    特に、大規模なゲーム開発にありがち
    「あのゲームとあのゲームとあのゲームとあのゲームの…良いところを合わせて…これは面白いはず!」
    とプロデューサーは言うのだが
    周りは「?…」状態で実感がわかない
    蓋を開けてみるとメンバーそれぞれがてんでバラバラなイメージで作業を進め
    「こうじゃない!」「違う!」「俺が言ってたのはこれじゃない!」
    という感じで手戻りが大量発生し
    現場は疲弊し生産性は落ち
    スケジュールは遅延しマネジメント層は焦り
    プロデューサーは無理矢理人員調達するが教育コストがかさみ進捗は一向に改善せず
    プロデューサーが雷を落とすももう誰にも響かない
    それでもなんとかリリースしたアプリはバグとクラッシュのオンパレードで
    「バグを出したのはお前だから直せ、機能追加も遅らせられないから頑張ってね」
    という状況で休まる暇もなく
    最終的には人が辞め出し
    メインメンバーがいなく、メンテ性の悪いソースコードに後任が四苦八苦し
    そうこうするうちにユーザーが離れ
    プロモーション費用だけが垂れ流される。

    結局振り返ってみるとプロデューサーも最初と言ってること違うし
    「あ、結局最初はあの人も当たるかわからないけどハッタリで言ってたんだね」
    ということに気付くのだが後の祭り…


    結局モノのないものを想像だけで良し悪し評価できるはずはなく
    誰もイメージできていないものを作るという超絶難易度の作業になってしまうという話

    対立が始まり、議論の結論がいつまでも出ない


    全体イメージの共有ができていないので、そこから派生する枝葉の要件についても捉え方がバラバラになる。

    この機能、こっちの方がいいんじゃない?
    この実装すごい大変だけどこんなの誰も使わなくない?
    いや、もっとこういう機能作ったほうがいいよ

    ゴールイメージが違う状況で議論しても、全員が納得する結論になるはずはなく…

    いいよ、言われたもの作るから早く決めといて
    このアプリ絶対売れんわ。本気出しても仕方ないや
    なんか他の人の意見ばっか採用されるし面白くない…
    発言しても長引くだけだし何も言わなくていいや


    そして末端の仕様はディレクターお願いねという話になり

    この仕様技術的に実現できないよー(いまさら)
    これ、矛盾してるじゃん、ちゃんと決めてよー
    え、決まった仕様がプロデューサーレビューで変わった?もう作りかけてるんですけど。スケジュール遅れますけど。
    うちのディレクター質低くね?言うこと聞きたくないー

    という話になっていきます。
    結果…

    信頼関係のないチームが出来上がる


    ・プロデューサー
    うちのチームは伝えた要件実現できないし、勘違いして手戻りばかりだし
    ディレクターは進捗管理できてないし
    エンジニアも能力高いの集めてるって言ってた割に結果出てないし
    締め付けが足りないのかな、やっぱり俺がカツ入れないとダメか…

    ・エンジニア、デザイナー
    プロデューサーは雰囲気でしか話さないし、それだけじゃ仕事進まない
    ディレクターが決めた詳細に従っても、プロデューサーチェックでNG出るし
    そもそもこんなアプリ自分使わないし
    この人達の下でやってて大丈夫かな…

    ・ディレクター
    超詳細に仕様作らないと動いてくれないし
    一生懸命作ってもプロデューサーはよく読みもせずに雰囲気でダメだしするし
    そもそもあの人丸投げし過ぎ
    会議は集めても自分しか話さないし
    上の人達は毎日会議ばかりで確認も遅れるし
    ていうかなんの話してるの?
    コキ使われるだけって、これ俺じゃなくてもいいんじゃ…

    チームがこの状況になったら、もういくら頑張ってもいいものは作れません。

    ただ、大小あれどこういうチームは多いというのが自分の経験からの感覚です。


    このような状況を防ぎ、チームを良い状態に保つのがファシリテーション型リーダーだと思っているのですが、ちょっと長くなってきたのでそちらの話は次回に回そうと思います。
    このエントリーをはてなブックマークに追加

    プロジェクト管理って

    職場でプロジェクト管理のような仕事をやらせてもらいながら考える事は
    人を動かすことがいかに難しい事かという事です

    企業という組織には様々なバックボーンを持った、様々な人々が
    様々なモチベーションを抱えて集まって事業を推進していきます
    また、各々の性格やタイプなどもあり

    プロジェクト管理
    プロジェクトマネジメント

    という仕事に、セオリーや定石のようなものは存在しないな
    メンバーが変わればそれぞれ違った最適解があるものだなと痛感します

    ただ、それでもいくつかの勘どころのようなものはあるのかなと思ってはいて

    最近特に思っているいくつかの
    コツのようなものを書き留めてみます

    アナログに可視化する
    可視化することの大事さは色々な所で言われていますが、
    私の場合は特にアナログにというところにこだわっています。

    アナログに、ホワイトボードに書き出したり、模造紙に貼りだしたりすることの利点は
    メンバー全員の目に触れる事が担保できる
    ということです。

    意外と、デジタルな資料を作ったり、WEB上で共有したりしても、それを見ないメンバーが出てきたりします

    いや、ちゃんと見ようよと思うのですが、パッと目につくところに貼りだしてあげたほうが管理しやすいのであればその方が良いという事で…


    会議では聞き手に回る
    会議をしても、発言のないメンバーっていると思うのですが
    大体不満が出てくるのはそういうメンバーからだったりします、経験上

    熱く語って結論を出して、よし、これでまとまったと思ったら
    大分後になってから
    「実は全然納得してなかった」
    みたいなことってよくあることだと思います


    会議というのは種類にもよりますが、プロジェクトの意思を決定する場です
    その場において自発的に参加できる、自分の意見が受け入れられるというのは即ち
    プロジェクトを自分ごとと捉えてもらえることに繋がります

    当事者意識が強いメンバーで構成されたチームは心強いものです

    メンバーに積極的に参加してもらえるように、意思決定の場ではなるべく聞き手に回った方がうまくいく感覚があります


    相談する
    会議の話とも通じますが、とにかくメンバーが積極的に参加できるチームにすることが肝心なので
    何か決めなければいけない時には個々のメンバーに個別に相談します
    意見を求められ、頼られる事で
    個々がチームの課題やプロジェクト自体を自分ごととして捉えていけるようになります

    これはまた、多面的思考がプロジェクトにもたらされるので
    アウトプットの質も自ずと上がっていきます



    最近考えているのはこんなところです
    意見や助言などあれば是非コメントを…
    このエントリーをはてなブックマークに追加
    プロフィール

    ブムブム

    Author:ブムブム
    しがないサラリーマンですが、
    ベンチャーにいるので日々は充実しています

    最新記事
    最新コメント
    最新トラックバック
    月別アーカイブ
    カテゴリ
    検索フォーム
    RSSリンクの表示
    リンク
    ブロとも申請フォーム

    この人とブロともになる

    QRコード
    QR
    上記広告は1ヶ月以上更新のないブログに表示されています。新しい記事を書くことで広告を消せます。