無料ブログはココログ

« 2015年11月 | トップページ | 2016年1月 »

サーバントリーダーシップを否定すると嫌な上司になっちゃう件

2回ほど続けてサーバントシップの記事(サーバントは革命の言葉。ビジョンを示せ! - サーバントリーダシップ私論 -古くて新しいサーバントリーダシップ)を書きました。

今回は、サーバントシップに対するイメージを、どう表現するかを考えました。その結果、サーバントリーダーシップのない上司は嫌だという結論になりました。

サーバントシップの個人的なイメージ

初めに思いついたのは、学生の自治を尊重する学校の先生が近い様に思いました。場を作り、必要な情報を提供し、目指す方向を示し、それぞれの成長も考える。そして、いざとなったら生徒と一緒に考えて行動してくれるそんな先生です。

では、具体的に何をすれば良いか、チームを立ち上げ、見える化を推進し、ビジョンを示し、必要なコーチングをする。もちろん、実作業もいとわない。そんな感じです。

そこでの「サーバント(奉仕者)」の意味を問われると、チームの将来を見据えて必要な事なら何でもするという事だと思います。CASE文のデフォルトのようなものです。

サーバントリーダは状況に合わせて行動しますので、場を作ったり、なごませたりする様々なプラクティスはあるとしても、メンバーや対象業務によって大きく変わるものだと思います。結局、何をすれば良いか簡単に説明できません。

サーバントリーダーシップではない行動

そこで発想を逆転させて、こんなのはサーバントリーダシップではないと思える行動を挙げてみました。

  • 場を提供しない
  • ビジョンを示さない
  • モチベーションを高めない
  • 問題が生じると怒る
  • 相手にあわせた対応をしない
  • 現場の状況を把握していない
  • 細々と指図する
  • 部下の成長を考えない
  • 意見を尊重しない
  • 調整しない
  • いわれたままに伝達する

こんな上司は嫌ですよね。そこで、サーバントリーダシップに期待していろのです。

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


[#benkyoenkai] 古くて新しいサーバントリーダシップ

IT勉強宴会でビールを片手にLTをしてきました。

サーバントリーダーシップには多くの誤解があります(サーバントは革命の言葉。ビジョンを示せ! - サーバントリーダシップ私論 -)。日本人には理解が難しいのかもしれません。

サーバントリーダシップの本を読むとキリスト教的な内容が多く出てきます。とはいえ、酒の席で宗教と人種の話は御法度ですので、文献として聖書を引用しながら私的な解説をしました。

一人称としての僕

サーバントの意味である僕(しもべ)という表現が一人称でいつから使われているかを調べると、なんと1800年前のアブラハムに息子イサクの誕生を予言されるところまでさかのぼります。

この場面はアブラハムの宗教(Wikipedia)と言われる3宗教の分岐点です。ユダヤ教、キリスト教のルーツはこのイサクで、イサクの前に召使いとの間に生まれたイシュマルがイスラム教のルーツと言われています。

この神に対する僕という概念が、平等主義につながって革命が起こり、日本では天皇(帝:みかど)に対する僕(ぼく)という一人称になり、明治維新に繋がったのは前回書いたとおりです。

いにしえのサーバントリーダーシップ

リーダーシップをとる人が自らを僕とする有名な言葉では、サムエルの「僕(しもべ)は聞いております」(サムエル記上3・9)というひと言です。サムエルはユダヤの預言者・指導者ですが、神様に向かって僕と言っています。これは紀元前11世紀頃のようです。

よりサーバントリーダーシップ的な表現は、新約聖書の「上に立つ人は、仕える者のようになりなさい」(ルカによる福音書 22・26 )です。イエス・キリストの言葉とされていますので西暦30年頃になります。

この言葉はカトリックの叙階式を画像検索すると、教会の指導者がうつぶせになって体現されているのがわかります。以前、海外のサーバントリーダシップの説明でスクラムマスターがうつぶせになっている写真が紹介された事がありますが、この辺りを知っていて悪ふざけしていたのでしょう。

サーバントリーダーシップとは

さて、日本サーバント・リーダーシップ協会によれば、サーバントリーダーシップはロバート・グリーンリーフ氏(1904~1990)が1970年に提唱した「リーダーである人は、まず相手に奉仕し、その後相手を導くものである」というリーダーシップ哲学だそうです。

サーバントリーダーは、奉仕や支援を通じて、 周囲から信頼を得て、主体的に協力してもらえる状況を作り出すとされ、サーバントリーダーシップの10の特性として、傾聴、共感、癒し、気づき、納得、概念化、先見力、執事役、人々 の成長への関与、コミュニティづくりが挙げられています。

特に グリーンリーフ氏の「リーダーがするべき最も重要な選択は、奉仕することだ。それがなければ、人々をリードする能力は恐ろしく限定されたものになる」という言葉は、サーバントリーダシップの可能性を良く表しています。

コマンドコントロールにより成立するトップダウンな組織では、言われた事しか実施せず、自己中心的になりがちです。これに対してサーバントリーダシップによれば自律的な組織が実現でき、工夫してやり遂げようとしますので、組織の能力を最大限に発揮できる可能性があります。

サーバントリーダーシップの前提

とても魅力的なサーバントリーダーシップですが、単にリーダーだけが変わってもうまくいくと思えません。自律的な行動を組織に促してもメンバーが自主的・主体的な行動をしてくれなければ、仕事が進まないからです。

2015年に大活躍したラグビー日本代表のエディヘッドコーチは、選手に自主的・主体的な行動をうながすことで、大きな成果をだしました。そのために五郎丸選手が失敗した後に書けてきた電話に出ないなど、自分で考える様に仕向ける様々な工夫をされていたそうです。

積極的なラグビーの選手でさえそうなのですから、コマンドコントロールに慣れた開発者では簡単にはいかないような気がします。

文化の違い

特にキリスト教にはタレント(能力)の語源になった「タラントンのたとえ」(マタイ福音書25章)といって、神様からあずかったタラントン(お金の単位)を増やさなかった人間が天国から追い出されるお話があります。そんな話を「嘘をつくとエンマ様に舌を抜かれる」のように聞かされていれば、(日本人が正直な程度には)自然とそれぞれの能力を発揮しようとするでしょう。

そのような文化を持つ欧米で生まれ、サーバントリーダーシップで効果を出しているといえるアジャイル開発においても「誰もがこの働き方を気に入るわけじゃない」(アジャイルサムライ, p. 7)と、責任を持って価値ある成果を届けることを誰もが好まないとされていて、常にうまくいかない事が示されています。

日本でもアジャイル開発では、初回はうまくいっても続かなかったり、業界が大きくなると難しく、コーチを雇わないとうまくいかないという話も聞きます。特に日本ではサーバントリーダーシップを根付かせるのはなかなか難しいのかも知れません。

問題を見いだして文化を変えよう

そもそもサーバントリーダーシップが必要であるか、よく見極める必要があります。

上に書いた様にサーバントリーダーシップを実践するには、メンバーが自主的・主体的である必要があります。組織にもよりますが、まずは文化を変えて根付かせなければなりません。(チケット駆動開発の相談を受けた時にも言うのですが)イメージできないのであれば、強引に導入してはいけないと思います。

ただし、トップによるコマンドコントロールが限界に近づいているなら、サーバントリーダシップの実践から逃れる事は難しいでしょう。必要に応じて、コーチを依頼してでもアジャイル開発の案件を徐々に広める、チケット駆動開発の導入を通じて徐々に文化を変えていく、など時間をかけて文化を変えていく必要があるでしょう。

(チケット駆動開発は期待する文化に応じて運用を変えることができます。書籍「チケット駆動開発」12章「チケット駆動開発のテーラリング」が参考になると思います。)

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


サーバントは革命の言葉。ビジョンを示せ! - サーバントリーダシップ私論 -

サーバントリーダは雑用でなく、プロデューサあるいはコーディネータのようなセクシーな仕事、新しい時代を切り開く改革者だと思います。

サーバントリーダは雑用?

インターネットラジオのRebuild: 123: The Grail Dialogue (Naoya Ito)を聞いていると、サーバントリーダシップには「良いアニキ問題」があるとのこと。雑用しかしないで、答えが出せず、ビジョンがないとのこと。

このようなリーダだと仕事はやり易いものの、部下が成長できない罠にはまりがち。ビジョンがないので、大事なところを忘れがちだとのこと。

たしかにサーバントは僕(しもべ)ですが、そんなつまらないサーバントリーダにはなりたくない!、、ということで、理想とするサーバントリーダシップについて書きます。

サーバントは革命の言葉

「僕(ぼく)」の語源をご存じでしょうか?無血革命といわれる明治維新の直前、幕末に生まれました(人称代名詞「僕」は近代の始まり - 前田吉之輔の我楽多日記)。

階級社会であった幕末いおいて「君主の下においては平等である」という意味で使われました。竜馬がゆく等の司馬遼太郎さんの小説においても、土佐では上士と郷士、長州においては全ての階級において「ガラガラポン」された様子が描かれています(「神の下の平等」から西洋で革命が起きた事と似ていますね)。

サーバントリーダは革命の志士

サーバントリーダが起こす革命は自律的組織の実現です。トップダウンのコマンドコントロールでないと動けない人を増やすのではなく、共に考え、共に成長する組織の実現を目指します。

サーバントリーダは常にチーム全体を見ていますから、直接開発に携わる事は少なくなるかも知れません(ものづくりは楽しいですから、その意味ではやや犠牲的)。

しかし、それは犠牲的に雑用をする負債的管理職ではなく、将来のビジョンを示し、道を示し、各自が進んでなすべき作業を分担する中で、リーダ自身もなすべき仕事を果たします。

リーダ自身がシャカリキになるよりもうまくいきそうだったら、調整が中心になるかもしれませんが、「ここは俺の出番だ!」と言う時は調整から開発まで何でもやるでしょう。

リーダであるからには責任を持っていますから、ビジョンや方向性を示して導かないといけません(調べてみると日本サーバント・リーダシップ協会のWebページにもビジョンという言葉が出ています)。

リーダは未来を見通し、チームの協力を得て、共に成長し、リスクを見極め、問題を的確に攻め、ゴールを達成します。そういうセクシーな仕事だと思います(チームを守り育てる - セクシーな中間管理職 -)。

奉仕は犠牲でなく喜び

サーバントというと奉仕者という意味があります。奉仕だから犠牲的と思われるかも知れません。しかし、奉仕というものはその先に喜びがあるからする行為です。

多くの奉仕者で実現されるオープンソースの開発においも、何らかの喜びがあるから多くの奉仕が行われます。利己的ではないですが、その作業を担う事によって喜びというメリットがあります。

リーダの喜びはプロジェクトの成功です。自分の思い通りのソフトウェアではなく、自分も含めてチームの持てる力を最大限に発揮することでより大きな喜びを得るのです。

おわりに

ソフトウェア開発は常にリスクとの戦いです。なまぬるい開発はほとんどなく、新たな挑戦の連続です。そこでは、幕末の坂本龍馬のように大局を見極めて、問題を的確に攻める必要があります([#TiDD] アジャイルは戦略 - 「竜馬がゆく」にみる坂本竜馬のアジリティ -)。

初めに書いた様にサーバントリーダーシップという言葉は、それまでの経験で色々な捉え方がある様です。そこで、今回は私が敬愛する坂本龍馬からイメージするサーバントリーダーシップの私論を書きました(坂本龍馬のリーダーシップ)。

サーバントリーダシップに限らず、成功のイメージができなければプロジェクトは成功しません。この記事がプロジェクトの成功に向けた新しい時代の夜明けに向けた参考になっていれば幸いです(古くて新しいサーバントリーダシップにつづく)。

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


美しさは変化の中にある - パタンランゲージ - #agileto2015

ワンパターンというと単調な繰り返しですが、パタンランゲージのパタンは継続的な繰り返しです。

Agile Tour Osaka 2015でうかがった建築家の中埜さんのお話は良い意味で期待を裏切るものでした(つぶやきのまとめ牛尾さんの講演の感想)。

お話を聞き終わってから思い出したのは奈良先端大の研究棟でした。

まっすぐの方がシンプルなのに

奈良先端大の研究棟は地球防衛軍のような建物ですが、各棟の中央に通路があり左右に大小の部屋が並んでいてまあ普通です。棟が2つに分かれてその間にエレベータがあって、エレベータホールを介して行き来できる様になっていました。

設備等は公立の小学校などと変わらないのですが、作りが何か違いました。エレベータホールから全体が見通せないのです。写真でもわかりますが、エレベータホールのある接続部分がずれていたのです。

「まっすぐの方がシンプルなのに」と九州芸工大出身の友人にいうと、「デザイナーは工夫をしたいいんだ」といわれ、そんなものかと思っていました。

合理性を求めると無機質なものになってしまいますが、通路をまっすぐにしないことで各研究室のプライバシーを守るというパタンだったのでしょうね。

デザインパターン再考

中埜さんいわく、パターンはパタンランゲージの考えから抜き出したもの。継続的な変革、多様化だといわれます。それは街中でふと気付く木漏れ日のような、心から出る美しいものだそうです。

単語や言い回しを知っていても普通の人に良い小説が書けない様に、パターンをパズルの様に組み合わせても良いものはできません。全体と部分をわかる事はできず、センターとなるものから、街づくりの様に少しずつパターンを調和させながら広げるものだそうです。

産婆術

では、色々工夫しながら調和したシステムを作れば良いのかというと、「我々は産婆だ」と言われます。

そもそもものづくりはユーザが行っていて、それを作り手に頼む様になった。やがて販売や製造の専門化が進み、ユーザから作り手に意見が届かなくなったとのこと。子供を産むのはユーザ、ユーザの意見を良く聞いてものを作らないといけないとのこと。

UI/UXなどではユーザの意見をそのまま取り入れてはいけないなどと言いますが、取り入れないことと聞かないのは違うのだと思いました。

お話を聞いていてソクラテスの産婆術を思い出しました。開発者は「それがしかるべく生まれてくるべく、その誕生の手助けをする」仕事を担っているのでしょう。

おわりに

SF映画を見ていると、灰色の同じような無機質な建物が並ぶ中を人やロボットが行進する絶望的な未来と、曲線を含む多様な建物が自動化された交通手段でつながれる夢のある未来が描かれています。パタンランゲージで、美しい多様な未来を目指したいです。

中埜さんは福島でも活動されていて、寄付が被災者にまわらないで整地ばかり勧められている事を嘆かれていました。そこには合理的な判断や法律などの障害があるのかも知れませんが、現状を変革して新しい仕組みが必要です。

「お金儲けが社会のためになる事が資本主義の前提だったが、崩れてしまった」友おっしゃっていました。パタンランゲージのパタンとは制約の中で生じる問題を解決するものです。変化を恐れず改革しないといけません。

ものづくり、システムづくりをする際には、経済的な判断やルール的な判断だけでなく、これまでのやり方を打ち破り多様な未来を気付くべきか、ユーザと共に考えて作り上げないといけないのでしょう。

中埜さんのお話はパタンランゲージとその背景を知るだけでなく、技術者としてどうあるべきかを考えさせていただきました。企画していただいた懸田さんのお話が聞けなかったのは残念ですが、仕事のあり方を考え直す良い機会になりました。

ありがとうございました。

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


DevOpsの前提とマイクロサービス #agileto2015

Agile Tour Osaka 2015に参加しました。今回のテーマはDevOpsとパタンランゲージ。どちらも示唆に富む内容でした。

まずは、アジャイル王子と言われた牛尾さんの講演DevOpsの感想をまとめます(つぶやきのまとめ中埜さんの記事)。牛尾さんは現在、USのマイクロソフトでエバンジェリストをされています。お話の内容はエバンジェリストらしくきれいなストーリにまとめられつつ、刺激的でした。

DevOpsとは

アジャイル開発にはマニュフェストがあったが、DevOpsの定義は存在せず、バズワードであるとのこと。 DevOpsが普及するきっかけになった1日10回のデプロイが実現可能かどうかで判断すると良いとのこと(必ずしも実施は必要でなく、できる能力があるかということ)。

DevOpsを一言で言えば「アジャイル開発を運用に広げる」ということ。シンプルでわかり易い定義です。(フェニックスプロジェクトの本「The DevOps 逆転だ!」を参考に示されていました)

DevOpsに必要なもの

アジャイル開発の繰り返しによって短い期間で価値が提供できる様になりました。しかし、そのままサービスを開始できないので、品質保証(QA)がテスト自動化の形で繰り返しに取り込まれました。

品質が良くなっても、インフラの構築ができないとサービスできないので、Infrastructure as Codeが繰り返しに取り入れられました。パソコンのOSを再インストールすると調子が良くなる様に、 クラウド技術によってimmutableな環境が提供できる様になりました。

でもサービスをドンドン提供するにはそれだけでは不十分で、監視を含めた運用技術も必要です。ブルー・グリーン(新旧の切り替え)、カナリアリング(一部分からの段階的導入)、フィーチャーフラグ(昨日の容易な停止)といった技術があります。

さらにDevOpsに必要なのは

ではツールなどを導入して、テスト自動化、Infrastructure as Code、運用監視、ができれば良いかというと、それだけでは不十分です。

その一つがルールです。サービス開始に管理職や担当部門の許可が必要で1週間もかかるなら1日10回でプロイできません。技術だけでなくルールの変更も必要です。

また、楽天さんでは50時間以上かかるテストをJenkinsで並列にテストして2時間で実行しているそうです。一方、クックパッドさんは単体テストを重視せず、そのかわりに8秒でロールバックできるようにしているとのこと。

これはお金を扱うかどうかというビジネスの違いです。両者に共通するのは、Lean Analyticsに書かれている様に「戦略は仮説に過ぎない」という考え方です。

マイクロサービス

講演の中で一番インパクトがあったのは、「マイクロサービス」の説明です。1日10回のデプロイをするには必要な技術であるとのこと。

マイクロサービスの説明を読むと「自動化が必須である」とされていて、マイクロサービスのためのDevOpsのように考えていました。しかし、DevOpsのためのマイクロサービスと考えると、その価値がよくわかります。

マイクロサービスなら、小さな単位で開発し、小さな単位でテストし、小さな単位でデプロイできるからです。DevOpsを容易にする方法の一つとして、積極的にマイクロサービス化を考えるべきでしょう。

おわりに

エバンジェリストとは宣教師のことで、どうしても一方的な話になると思います。しかし、ソフトウェア業界のエバンジェリストの方たちは牛尾さんのように、会社を背負いつつも業界の未来を信じて、そこへの道を示されているのだと思いました。

ソフトウェア業界にはよくわからない言葉や技術がたくさんあって、時には踊らされ、時には混乱させられます。その中で道を示していただけると、技術が整理され、とてもわかり易くなります。

今回のお話でも、多くの示唆と刺激をいただきました。ありがとうございました。

また、今回も開催をしていただいた細谷さんにも感謝しています。そして、スポンサーのテクノロジックアートさん。控えめな宣伝で今回も楽しめました。ありがとうございました。

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


[#プロセスプログラミング] 探索アルゴリズムとソフトウェア開発

アルゴリズムという言葉を初めて聞いたのは高校のとき、物理の先生と「図書館のレイアウト変更とか大変そうですね」と雑談していると「わしらは大学でアルゴリズムを学んだから効率よくできる」と言われていました。

オスターワイル(Leon J. Osterweil)氏が「ソフトウェアプロセスもソフトウェアである」とプロセスプログラミングを提唱して、ソフトウェア工学が大きく進歩しました。しかし、そもそもアルゴリズムは、現実世界の問題の解決法だったのです。

今回は探索アルゴリズムを基にソフトウェア開発を考えてみたいと思います。

ソフトウェア開発の可能性を探索する

ソフトウェアの実現方法には様々な可能性があり、開発を決めた時点をルートととし、実現する機能を横方向に、下に行くほど具体化する木構造で表す事ができるでしょう。

ソフトウェアの可能性を示す木構造からどのような実現方法が良いか探索するには、2つの基本的なアルゴリズムがあります。幅優先探索(Wikipedia)と深さ優先探索(Wikipedia)です。

幅優先探索は従来(ウォータフォール)型開発の他、アジャイル開発の初期に行われるアーキテクチャの決定、ストーリーの抽出、イテレーション0など、イテレーティブな開発にあたります。

深さ優先探索はアジャイル開発のような反復開発に置けるインクリメンタルな開発にあたり、機能やストーリー毎に実現していきます。

これらの2つの方法は木構造全体を探索する場合の効率は同じですが、途中で最適解が見つかる場合は深さ優先探索の方が効率的だと言われています。ウォータフォール型開発とアジャイル開発の関係ですね。

ボードゲームの判断

より効率的な探索法を参考に、効率的にソフトウェア開発する方法を考えてみます。

オセロのようなボードゲームでは状態の組合せが多いので、全ての手を計算して最適な答えを得る事が難しいとされています(すくなくとも昔は、、)。

次の手は一定時間内に打たないといけませんので、時間内に全数を探索できるような局面までは探索する手数を限定した上で、なるべく効率的に探索します。効率的な探索法としてアルファベータ法(何もないから何かみつかる: オセロゲーム開発 ~アルファベータ法(alpha-beta search)~)が有名です。

具体的には、今後の展開を時間内で計算可能な木構造で表現しておき、かどのマスを狙う、数を狙う、など局面に応じた評価関数に基づいて、負けそうな枝を削除(いわゆる枝刈り)して、より有効と思われる方法を実施します。

ここまでのアルゴリズムから学べる事は、全てを探索しない場合は幅優先探索よりも深さ優先の方が効率的と言われているものの、一定時間内に結果を得るには深みに入らない、局面に応じて判断や枝刈りをする、必要があるという事です。

では、ソフトウェア開発に当てはめて考えてみましょう。

深みに入らない

全体に影響を与えそうなアーキテクチャの決定や技術的な課題は早めに見通しを立てるべきです。深みに入らない様にプロトタイプやスパイクと呼ばれる技術検証を実施します。

少なくとも最低限価値が提供可能なMVP(minimum viable product)に至る重要成功要因(Critical Success Factor:IT用語辞典)の技術的課題は、確認しておくべきでしょう。

もちろん、従来型の開発におけるマイルストーン、アジャイル開発ではイテレーションのタイムボックスが守れるなら、正式な開発を実施する事も可能です。ユーザビリティの確認などがそれにあたります。ただし、全体に影響を当てる課題が残らない場合です。

局面に応じて判断や枝刈りをする

ゲームの評価関数は局面によって変わります。ソフトウェア開発においても、完了までの期間や業務、体制、使用する環境によって、判断を変えないといけません。

とはいえ、ゲームにおいてのゴールが、最終的なコマの数や王将の獲得など、局面によって変わらないように、ソフトウェア開発においても価値のある動くソフトウェアの実現である事は変わりません。そのゴールに至る可能性を高める、逆に言うとゴールを達成できないリスクを下げる判断が局面によって変わるのです。

ある事を実施するなら、その時間分だけ他の作業ができません。実現可能性が高まる様に、実施するリスクと実施しないリスク、ある方法と別の方法のリスクを見極めて、ゴールに向けてリスクが低減する様に判断や枝刈りをすべきでしょう。

つまり、その時点、その時点で、残りの工数と実施しない作業を考慮して、それぞれのリスクに対してどこまでリスク低減のための作業を深くまで実施して良いかを考えます。

木を小さくする

このようにプロジェクトの初期は難しい対応が求められます。これをより簡単にするには、自由度を下げて木を低くする、コードを減らして木を小さくするという方法があります。

自由度を下げる方法の一つは、いわゆる標準化です。確立された技術を用いる事で、考えないといけない事を減らします。お客様から与えられる制約も同じ様に自由度を減らして、検討する内容を減らす事ができます。

コードを減らせば実装範囲がへりますので、 木を小さくできます。ライブラリやフレームワーク、ミドルウェア、などが考えられます。もちろん、初めて利用する際は技術的な検証が欠かせません。

プロセスの特性も忘れずに

探索アルゴリズムで考えるとソフトウェア開発のポイントをうまく説明できますが、プロセスの特性も忘れてはいけません。プロセスを実行するのは人間ですので、情報や知識の共有、技術の習熟に時間がかかります。

開発中に得られた情報や知識は、その人数によって対面、レクチャ、文書などふさわしい方法で効率的に伝える必要があります。伝える人数は全体の規模のほか、増員タイミングや担当の割り当てなどによって変わります。

また、技術の習熟の考慮も必要です。顧客・開発者・技術共に経験者ばかりなら1度だけのリリースでもうまくいく可能性もあるかも知れません。しかし、未経験者や初めての要素があるなら、経験値が向上する様に複数回のリリースも検討すべきでしょう。

まとめ

探索アルゴリズムを基にソフトウェア開発プロセスを考えてみました。ソフトウェア開発は、業務、ソフトウェア、環境、納期、チームの構成、など、様々な要素の組合せがあり、ゲームで用いられる探索アルゴリズムも参考になるでしょう。

いわゆる90%シンドロームや動かないコンピュータなど、古くから語られる失敗プロジェクトは、 プロセスをきちんとプログラミングできないことから生じています。

たとえば進捗を管理しているから大丈夫と思っていても、リスクがコントロールされていなければうまくいきません。見た目の進捗を求めて、わかるところだけ深く探索しているかもしれないからです。

プロジェクト管理者に求められるプロセスプログラミングは、簡単ではありません。様々な要素を考慮しつつ、プロジェクトに関わる人たちが不幸にならない様に、より良い方向に導くセクシーな仕事なのです(参考:チームを守り育てる - セクシーな中間管理職 -)。

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


プレゼンテーションの時間を調整する方法

先日のredmine.tokyoの発表(裾野が広がるRedmine「チケット駆動開発導入のヒント - 自律と規律 -」)後に「時間を合わせるのはどうすれば良いか」と聞かれました。

当日は予定時刻までは良いだろうと勝手に考えて、持ち時間を過ぎて終了の鐘を連打された発表者です。偉そうには言えませんが私のやり方をまとめておきます。

基本的にはプロジェクト管理と同じです。単位当りの見積もりを積み上げること、そしてマイルストーンを決めることです。

単位当りの時間の基本は、スライド1枚当りの時間です。昔のOHPの頃は1枚3分と言われましたが、最近は見易いサイズの文字サイズなら、書いてある事だけを話すなら1枚1分、書いてない事も話すなら1枚2分ぐらいで見積もります。

そして、見積もりに合わせてスライドの内容を調整します。話す事が多すぎるなら簡潔になる様に構成やテーマを見直します。性能や予算にあわせて、方式やスコープを調整するようなものです。

また、1枚当りの時間から所々にマイルストーンを決めます。◯枚目で何分ぐらいのはずと決めておき、進捗に応じて話すスピードを調整します。

時間調整には、あらかじめ時間調整用のスライドを入れておいて、時間がない時は飛ばす様にする方法もあります。逆に時間が余った場合にだけ話す事をきめておくこともあります。いずれにしろ、オプションを残しておいて調整する訳です。

なお、写真や図が多い場合や、LT並のペースでドンドン進める場合、デモをする場合などはある程度練習を積まないとなかなか安定しないかもしれません。そのような場合も、基本的な考え方は役に立つと思います。

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

« 2015年11月 | トップページ | 2016年1月 »