無料ブログはココログ

メンバーに良い成績を付ける - リーダーのベンチマーク -

リーダーがメンバーに良い成績を付けることができたなら、仕事をしている証です。ゆるい評価を与えるのであれば簡単ですが、適切な評価ができないならリーダー失格です。

リーダーの仕事は、 プロジェクトに与えられたリソースで最大の成果を出す事です。メンバーそれぞれの能力や性格を見極めて、場を用意して、能力を活かし、不足している能力を育て、必要に応じて補ったりします。

そこにはリーダー自身のリソースも含まれますので、雑用に追いまくられてボトルネックになる事は許されませんし、(すでに得意な分野なら若い人より優先度は落ちますが)リーダー自身が成長する事も求められます。

そのような多くの努力すれば、プロジェクトは良い成果を出す事ができるでしょう。そして、メンバーに良い成績を付ける事ができます。

もし、メンバーに良い成績を付ける事ができないなら、やるべきことをやっているか、一度、振り返ってみると良いでしょう。そうなってしまったのではなく、そうしてしまったのです(リスクを考慮した段取りで成功に導く)。

リーダーの仕事は、リーダーが自分勝手に思い描くプロジェクトを実現する事ではありません。うまくいく場合もあるかも知れませんが、リーダーもメンバーもストレスの溜まる職場になるだけで、能力は発揮できないでしょう。

日本では誤解の多いサーバントリーダーシップですが、メンバーに良い成績を付けるというベンチマークを使えば、うまくいくのではないでしょうか?

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

ポケモンGOで考えるリスクマネージメント(3/3) WF、アジャイル、CCPM

ポケモンGOは様々な要素が含まれるゲームです。タマゴの獲得機会喪失をリスクとして考えましたが、リスクへの対応は簡単ではありませんでした。

ソフトウェア開発にも様々な要素があり、それぞれが関連しているほか、時間によってリスクが変化するので、対応は簡単ではありませんでした。

そこで、ソフトウェア開発ではリスクへの対応を単純化できる様に、ウォータフォール(WF)、アジャイル、CCPMといったモデルが提案されています。

しかし、そのモデルから外れ出すとプロジェクトは大きな混乱に陥ります。つまり、リスクへの対応を単純化するはずのモデルにもリスクが存在しています。

今回は、仕様(スコープ)、納期、リソースの観点で、WF、アジャイル、CCPMを定義して、そこに含まれるリスクと対策を考えてみます。

ウォータフォール

ウォータフォールモデルは、開発が進んでからの修正作業が膨大である事から、開発の早い段階で障害を取り除きます。その前提は「要求定義」という工程がある様に、要求仕様が定義、さらに言えば凍結できることです。

開発開始時には仕様のほか、サービスインの前提となる納期が固定され、リソースを状況にあわせて投入します。

しかし、仕様を凍結する事は現実には難しく、仕様がどんどん追加されて混乱します。 仕様が膨らんでも納期は基本的に変わりませんので、リソースをドンドン増やすしてしまってプロジェクトが混乱し、最終的には納期が守れなくなります(CCPMが説明される際に、WFは仕様が固定で納期とリソースが可変と説明されることがありますが、現実はもっと混沌としています)。

このようなリスクに対応するには、リリース計画を見直すことと、仕様を調整します。具体的にはリーンスタートアップでいうMVP(必要最低限機能:Minimum Viable Product))を考慮して複数回リリースにする。各リリースでは仕様を削減する方向で調整する。ということです。

また、仕様のブレを無くすにはプロトタイピングが有効です。作ってみないとわからない所のリスクを低減します。

かつて組み込みソフトウェアでは、販売時がソフトウェアの最終リリースでした。不具合を出した社員が倉庫に連れて行かれ「この商品をどうするんだ」と怒られるような事があったそうです。しかし、プログラムを後から更新できる様になり、製造業においても仕様を削減して予定通りリリースしておき、次のリリースで対応するといった施策が実施される様になっています。

参考:

アジャイル

アジャイル開発にも色々ありますが、ここでは固定期間のタイムボックスを繰り返すXPやスクラムを想定します。XPやスクラムでは、タイムボックスを最小のリリースになる様に仕様を調整して、同じチームで開発します。つまり、納期、リソースが固定で、仕様を可変にして調整します。

タイムボックスを節目として新しく計画されますので、世の中の変化やビジネスのニーズに対応する事ができます。

しかし、一定の機能が必要とされる定型業務では、繰り返し回数が増えて期待される機能の実現が遅れる可能性があります。また、タイムボックスあたりのリソースは固定ですから、繰り返し回数が増えればコストも増える事にもなります。

実現される機能で見れば、アジャイル開発にはこのような問題があります。しかし、その見方は本質的でなく、ビジネスにどれだけ貢献できたかで評価すべきだと思います。

つまり、単発的な開発だと考えているので、時間軸が延びて予算計画が狂います。ビジネスを継続的に発展させる長期的なプロジェクトと考えれば、ビジネスとして成り立たせるために必要な機能から確実に実現できるかどうかが重要でしょう。

つまりアジャイル開発のリスク対策は、本来アジャイル開発に向いたビジネスに対して、きちんと開発するということです。

参考:

【12/21追記】

普及の著しいスクラムは、組織パターンの門番と防火壁の仕組みが組み込まれています。こればスクラムの長所であるとともにリスクでもあります。

具体的には、プロダクトオーナーがボトルネックになる。SMがチーム作りに失敗するとコミュニケーションがうまくいかず情報共有に失敗する。といったことです。

対策は教育、コーチ、コンサルタントの導入などがあります。

CCPM

CCPMはサブチームや個人で取ってしまいがちなバッファに注目し、理想見積もりをベースに計画し、プロジェクト全体でバッファを取る。クリティカルチェーンにリソースを集中する。状況を可視化する。ことで効率的な開発を実現します。

バッファを取って時間軸の自由度を高める事で、個人やサブプロジェクトのバッファを無くして全体で最適化しますので、仕様とリソースは固定、 納期は可変になります。

CCPMを実施する事でプロジェクトの生産性が上がる事が知られています。しかし、バッファ削減の効率化は、必ずしも継続しません。CCPMは分散していたバッファを集中管理する事で効率化するので、一度適用すれば、習熟による生産性の向上以外は見込めなくなるからです。

にもかかわらず効率化を前提にリソースを削減して、クリティカルチェーンにリソースを補う事が難しくなり、CCPMが機能しなくなることがあるようです。

初めのうちは理想見積もりが難しいので、通常見積もりからざっくりと理想見積もり計算するかも知れません。しかし本来のやり方である、きちんと理想見積もりをした上でバッファを設定しなければ、いずれうまくいかなくなるかもしれません。

参考:

まとめ

新しい開発モデルがはやると「守破離」と言う言葉が使われます。まずは言われた通りにやってみる。ということなのでしょう。

しかし、現実はどのような開発モデルであってもリスクはあります。ここに挙げた3つのモデルも、仕様、納期、リソースのそれぞれが固定のものが可変になったり、可変のものが固定になるなど、本来のモデルを表層的にとらえただけでは理解できない問題が生じます。

ソフトウェア開発は複雑な仕事です。何かに書かれた通りに実施するのではなく、本質的な内容を理解し、想定されるリスク、そのバランスと時間による変化を考えないとうまくいきません。

ソフトウェアエンジニアリングがソフトウェア工学のテキストに書かれた事を実践するだけではない様に、リスク管理のテキストに書かれた事を実践するだけではリスクマネージメントできないと思います。

ポケモンGOのリスクに基づいてここまでの議論を進めてきました。ゲームの上手な人と下手な人がいる様に、ソフトウェア開発にも上手な人と下手な人がいます。その違いは、リスク特定、リスク分析、リスク評価からなるリスクアセスメントとリスク対応から構成されるリスクマネージメントへの理解かもしれません。

参考:

この記事は、SRA Advent Calendar 2016 の12月19日の記事です。

おまけ

ポケモンGOでは相棒ポケモンを選ぶ事ができ、歩いた距離に応じてアメをもらう事ができます。ついつい短距離でアメがもらえるポケモンを選んでしまいます。

しかし、無駄のないように相棒を選ぶなら、(1)アメをもらうのに距離が必要、(2)進化に多くのアメが必要、(3)なかなか出逢えないレアなポケモン、から選ぶと良いと思います。また、出逢う可能性を考えて必要なアメの数よりすこし少ない数まで歩くと良いでしょう。

ナップザック問題の様に距離の異なるポケモンを最適に進化させる事は困難です。グリーディアルゴリズムの様に距離の必要なものから選ぶと良いでしょう。また、ポケモンを捕まえられる可能性も考慮すると、少し少なめにすると良いことがわかります。

このようにポケモンGOとソフトウェア開発は、共通点がたくさんあります。真面目に考え過ぎて負担にならない様にしてください。ゲームなので楽しめば良いのです。仕事と同じです。

参考:

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

ポケモンGOで考えるリスクマネージメント(2/3) ソフト開発にあてはめる

前回はポケモンGOを題材にリスクマネージメントにおけるリスク対応の説明をしました(ポケモンGOで考えるリスクマネージメント(1/3) リスク対応の種類)。

リスクへの対応は問題の発生する確率と発生時の被害の積(リスクレベル)で考えられます。しかし、ポケモンGOのリスクをソフトウェア開発にあてはめると、それは簡単なものでないことがわかります。

共有(または転嫁) は難しい

ポケモンGOでタマゴの獲得機会喪失をリスクとして考えて、このリスクを家族に転嫁することを考えました。しかし、リスクを共有するには、スマホのパスワードを公開して操作してもらう必要があり、得られるメリットに相当する金品(あるいはサービス)を提供する必要があるでしょう。

ソフトウェア開発でも同じです。レベニューシェア契約(リンク先はWikipedia)など得られた収益から報酬を払う方法があります。発注側の利益は明確ですが、受注側が適切に利益を得るには計画だけでなく、より詳細な情報提供が必要ですし、運営に発言権が必要になります。

そこで、ポケモンGOで歩く事だけ依頼した様に、品質と納期へのリスク回避に対して一定のコストを払う契約が一般的に行われています。

では内製ならうまくいくかと言うと、必ずしもそうではありません。実は内製であってもゴールが共有できていなければ、担当者の価値観に応じて判断が行われる事になります。評価を気にしない社員もいますし、そもそもそれなりの職位でなければ、収益を評価にあまり反映できないでしょう。

結局、契約も大切ですが、それだけでは不十分なのです。業務を理解して、そこで生じるリスクの低減を共に考える事が必要になります。

リスクには依存関係がある

ポケモンGOのタマゴの獲得機会喪失を考えましたが、これを回避するには常に孵化装置を買う必要がありました。獲得機会を失う事がどの程度の金額に相当するかを考えて、一定のリスク低減であきらめる事になるでしょう。

このように、リスクレベルに応じた対応をすれば良いのですが、実は単純ではありません。

ポケモンGOには「しあわせタマゴ」という30分間得られるXPを2倍にするアイテムがあり、レベルアップ時にもらえたり、購入する事ができます。

Fukasouchi

進化させた時やタマゴをかえした時にもXPがもらえますので、アメが貯まったら同時に孵化装置をセットします。孵化の直前に「しあわせタマゴ」を使って一斉に孵化させ、貯めておいたアメでまとめて進化させると、多くのXPを得る事ができます。

しかし「しあわせタマゴ」を有効活用するには、孵化装置を使わずにタマゴを残しておく必要がありますので、(よほど運が良くない限り)タマゴの獲得機会を失わないとタマゴを揃える事ができません。

つまりリスクに依存関係がある場合は、いずれかのリスクの問題化による被害を 保有(または受容) する必要があります。

基本的には、それぞれのリスクレベルを計算して優先度を決めれば良いはずです。しかし、次に示す様にリスクレベルが時間によって変化するなら、単純に優先度を決める事ができません。

ソフトウェア開発でも、 スケジュール遅れを取り戻そうと残業を強いると品質の低下が生じる可能性が高まるなど、 リスクの依存関係が多く存在します。

時間によって変化するリスクレベル

ポケモンGOにおいて「タマゴを獲得できないことで時間を失うリスク」を議論してきました。ポケモン図鑑を揃えるにはタマゴをかえしてレアなポケモンを得る必要があるからです。

しかし、時間を失うようなレアなポケモンとは、図鑑に載っていないポケモンの事です。レアなポケモンをどんどん捕まえれば初めてのポケモンが減ってゆくので、たくさんのタマゴを獲得する必要があります。ソフトウェア障害の信頼度成長モデル(SRGM)のようにサチッていく(リンク先はgoo辞書)イメージです。

その一方で多くのXPを獲得してレベルを上げると、新しいアイテムが使える様になって進化したポケモンを捕まえ易くなります。実際は次のレベルに上がるのに必要なXPも多くなるのですが、新しいポケモンの減り方に比べると直線的な変化です。

参考:「ポケモンGO(Pokémon GO)」のレベルアップに対するユーザーの不満が噴出、課金なしでは難しいという声も - GIGAZINE

つまり、図鑑が埋まってくるとタマゴを得る価値が下がり、孵化させてXPを得る方が効率的になります。つまり、時間によってリスクレベルが変化して、対策の優先順序が変わるのです。

ソフトウェア開発でも同じです。関連するモジュールが多い機能は手戻りのが生じた場合の被害が大きく、開発初期では、手戻りのリスクレベルは開発が遅れてしまうリスクレベルよりも高いでしょう。しかし、開発が進んでくると手戻りのリスクレベルよりも開発が遅れてしまうリスクレベルが徐々に高くなるでしょう。

この2つのリスクレベルが入れ替わるタイミングが、いわゆる最終責任時点です。リスクレベルを下げられる様に、ギリギリまで選択肢を残します。

参考: リーンソフトウェア開発 - 決定をできるだけ遅らせる

おわりに

ポケモンGOにあてはめて、ソフトウェア開発のリスクマネージメントを考えました。ソフトウェア開発のリスクマネージメントも、決して簡単ではありませんでした。

それぞれに対応する状況の様に、請負開発や進捗管理だけでなく、そもそもリスクを考慮しなければ良い計画を立てる事ができません。

このようなリスクマネージメントの視点で考えると、ウォーターフォール型開発だけでなく、アジャイル開発やCCPM(Critical Chain Project Management)の弱点や対策が見えてきます。

次回は、その辺りを書いてみたいと思います。

この記事は、SRA Advent Calendar 2016 の12月11日の記事です。

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

ポケモンGOで考えるリスクマネージメント(1/3) リスク対応の種類

ポケモンGOとは

急に立ち止まってスマホの上で指をスライドしている人がいたら、たぶんポケモンGOです。世界中に存在するポケットモンスター(ポケモン)を集めて図鑑に登録する、博士に送るというミッションを実践しています。

ポケモンは、ポケストップに行くともらえる専用のボールを投げて捕獲します。ポケストップで丸い部分をクルクルすると、ボールだけでなく、ポケモンを手なずける事ができるズリノミや色々な道具、ポケモンのタマゴなどがもらえます。

ポケモンは博士に送ったり、連れて歩くとアメがもらえますし、 ジムでバトルやトレーニングすると星の砂がもらえ、ポケモンを配置するとポケコインをもらう権利が得られます。アメや星の砂をためると、ポケモンを進化や強化する事ができます。

このような様々な経験を積んでXPをためるとレベルがあがり、様々なアイテムをもらえたり使える様になります。このように、ポケモンGOはポケモンを捕まえたり育てたりしながら、ポケモンと共に成長するゲームです。

ポケモンのタマゴと孵化装置(ふかそうち)

ポケモンGOの特徴は、地理情報を使って話題になったイングレスというゲームの技術と、ポケモンのキャラクターやストーリーを組み合わせていることです。それ以外にもアイテムの購入が多いという特長があります。アイテムを購入する楽しさが理解され、他のゲームでも売上が増えたとニュースになっていました。

ポケモンGOのアイテムで最も人気があるのは孵化装置です。 孵化装置にタマゴを入れて、必要な距離を歩くとタマゴがかえってポケモンをゲットする事ができます。 もともと無限孵化装置(むげんふかそうち)という何度も使える孵化装置がありますが、購入できるのは3回だけ孵化できるものです。

タマゴには孵化に必要な距離が、2km、5km、10kmのものがあって、レアなポケモンや進化したポケモンなども含めて、様々なポケモンをゲットできます。

ポケモンGOにおけるリスク

ポケモンGOはレベルを上げながら図鑑を揃えるゲームです。隙間時間に遊ぶのにふさわしいゲームです。その反面、Pokémon GO Plusを使わないとスマホと多くの時間を占有されるゲームです。

かかる時間は楽しんでいる時間でもあるのですが、レベル20を超えてポケモンが100種類を超えるあたりから、ドンドン作業化してしまいます。早く終わりたいと思っている人も少なくないのではないでしょうか。

そこで、余分にかかる時間を損失と考えると、ポケモンGOに様々なリスクのある事がわかります。その中でもタマゴをうまく獲得して孵化させられないとレアなポケモンが得られませんので、多くの時間を失ってしまいます。

タマゴを獲得できないことで時間を失うリスク

とにもかくにもタマゴを獲得しないと行けないのですが、タマゴを得るには以下を満たす必要があります。

  • ポケストップでクルクルする
    ポケストップでクルクルすると3〜5回に1回程度タマゴがでてきます。とにかくポケストップにいかないとはじまりません。
  • 持っているタマゴが8個以下
    タマゴは最大9個しか持てませんので、孵化装置をセットしてドンドン歩いて、孵化させて8個以下にしておないといけません。
  • バッグが空いている
    バッグがいっぱいだと、ポケストップでクルクルしても何もでてきません。荷物を使う、捨てる、バッグをアップグレードするなどして空けておく必要があります。

ここでは持っているタマゴが9個になってタマゴ獲得ができず時間を失うリスクを対象にリスクマネージメントを考えます。

リスク対応

リスクへの対応は問題の発生する確率と発生時の被害の積(リスクレベル)で考えられます。孵化装置を買わないと1日に1時間、5kmほど歩きながらポケモンをしても、1〜2個程度しか孵化できません。4回に1回タマゴがでるとすると、1日に16回ポケストップに寄ったなら、1日当り約半分の確率で問題が顕在化します。1日最大1時間の被害ですからその積である30分はタマゴを獲得できないというリスクが発生します(実際はタマゴから孵化したであろうポケモンによって被害は異なりますが、単純化して考えます)。

この被害に対してどのような対応があるかを考えます。

  • 回避
    「ふかそうち」や「バッグのアップグレード」の購入、道具を捨てるなど万全の対策をとる事で、リスクをほぼ回避できます。購入した孵化装置で1日平均1.5個孵化させれば大丈夫だとすると、2日に1個の孵化装置を買うことになります。月に2,300円ほどかかる計算になります。
  • 低減
    あまりお金をかける事ができないのなら、状況に応じて孵化装置を買う事もできます。たとえば、10kmのタマゴに対してだけ孵化装置を使うだけでも1日1個は孵化させる事ができます(「むげんふかそうち」を短い距離のタマゴに割り当てると、費用を最適化できます。同じコストで多くの「たまご」をかえすことができます。他の対応方法でも有効です)。
  • 共有(または転嫁)
    家族や友だちとリスクを共有する事も可能です。散歩や買い物など出掛ける際に自分のスマホでポケモンGOをしてもらいます。でも、お願いする人に操作されたくないとか、操作までお願いできないのであれば、歩くことだけをお願いして距離を稼ぐという方法もあるでしょう。
  • 保有(または受容)
    遊びなのですから、買わないと決めて、そんなもんだとボチボチやるのもよいでしょう。ジムにポケモンを配置して得たポケコインで孵化装置を購入する事ができますので、時々は孵化装置を使えるでしょう。

おわりに

リスク対応はリスクレベル(問題の発生する確率と発生時の被害の積)に応じて選択されます。今回、リスクが顕在化した際の被害を時間としました。しかし、リスク対応の説明を書いているなかで、同じ時間の被害であっても、人によってその重要度が異なる事に気付きました。

これは、単に時間だけでなく、お金や楽しみの損失という別の被害との相対比較によって対応方法が決まっているからです。つまり、個々のリスクの問題ではなく、バランスの問題なのです。

ソフトウェア開発には様々なリスクがあり、プロセスモデルによってそのバランスが異なっています。次回は、プロセスモデルごとのリスクマネージメントを比較し、ソフトウェア開発の難しさを考えてみます。

おまけ

いわゆるスポットに行くと多くのポケモンが現れますが、バッテリーがすぐに消耗してしまいます。

そこでiPhoneの、設定 -> バッテリ -> 低電力モード を設定し、ポケモンGOの効果音と振動をOFFにしてみましょう。プチフリーズが怒り易くなりますが、バッテリーの持ちが格段に良くなります。

ただし、電車に乗っていて駅に着いても、停まっている事をなかなか認識してくれませんので、気をつけて下さい。

 

この記事は、SRA Advent Calendar 2016 の12月4日の記事です。

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

ランチェスターの法則にソフトウェア開発を学ぶ

はじめに

ランチェスターの法則(Wikipedia)はオペレーションズ・リサーチの数理モデルの一つで戦闘を2つのモデルで表現したものです。

この法則はランチェスター経営やグー・パー・チョキ理論などで知られていて、導入期などで力を一点に集中させる弱者戦略(グー)、 成長期の後半で多様な展開(ボリューム)で勝負する強者戦略(パー)、伸びが鈍化し衰退しだすと多様化を整理する(チョキ)。

ソフトウェア産業で考える

これはソフトウェア産業にもあてはまります。自分たちの立ち位置と世の中の情勢で戦略を考えます。

立ち位置は会社の規模ではありません。マーケットに対して強者であるか、弱者であるかの判断が必要です。

ソフトウェア産業は顧客の経営状況に影響を受けます。従来は新しい予算の切り替わるまでの期間が長く、半年から1年ほど遅れて影響が出ていました。

近年は世の中の情勢に応じて予算が変更される様になりましたので、これにあわせて利益重視(グー)、売り上げ重視(パー)、縮小(チョキ)を変更しないといけません。

参考:ランチェスターの法則と売り上げ、利益、利益率

ソフトウェア開発を考える

ソフトウェア開発においても同じような状況があります。プロジェクトの開始時期は、コミュニケーションや構成管理の基盤を作る、横展開の元になるひな形の開発し品質を向上させる、自動化を進めて手作業を減らす、など効率化を狙った施策を取ります(グー)。

やがて効率化の施策がすすむと、ガンガン開発するフェーズに入ります(パー)。しかし想定外の事象が起きた場合は見極めが必要です。

上司の視点で見ると、ついつい人を投入したくなると思いますが、状況をきちんと見極める必要があります。場合によっては戦略を転換して、必要に応じてスパイクやプロトタイピングといった「グー」戦略も必要でしょう。

ソフトウェア開発でも「チョキ」の戦略が最も難しいでしょう。プロジェクトが収束に向かう時、人を減らす必要もあるでしょう。あらかじめどのように引き継ぐか、誰を育てるかを考えて開発を進める必要があります。いわゆる「段取り8分」です。

参考:実装優先時の考慮点 その1 - プロトタイピングとスパイクソリューション -

状況を把握するには

いかにアンテナを張るかが重要です。顧客とのちょっとした会話が重要です。信頼を得て、関係を良好に保ち、時にはストレートに話して理解していただくと良いでしょう。

開発者の状況もよく見ておく必要があります。出勤時間や退勤時間、休み時間の過ごし方など、ちょっとしたことから、前向きに取り組めているか、負担になっていないか、を見極めます。

「現地現物」と言いますが、ほんの少しの時間であっても直に接して、状況を感じ取る事が重要です。

参考:[#TiDD] プロフェッショナルは本物で確認する

おわりに

ソフトウェア開発と戦略的な考え方は共通点があると思っていました。ランチェスターの法則を見直すと、そこにも戦略的な要素がありました。

グー・パー・チョキの分類はわかり易いので、今の状況を考える際にがどれに当てはまるか考えてみてください。色々と見えてくるかも知れません。

もし、上司がおかしいと思っても、それを愚痴のネタだけで終わらせないで下さい。あなたには、説得する、異動・降格を待つ、昇進して追い越す、転職する、といった選択肢があります。

ランチェスターの法則は様々なものに当てはめる事が可能です。現在のポジションと状況に応じて未来を選択してください。

参考:[#agileto2012] 『チェンジ!』の考え方 ~マネしやんと!~

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

バタバタするのは、リスクマネージメント、オプション確保、連携の失敗

プロジェクトマネージメントの旨い・下手は明らかに存在します。それは、数少ない大切なポイントを実践しているかどうかで、ほんの少しの判断ミスが徐々にプロジェクトを窮地に追い込んでいきます。

まじめに頑張っているのに、プロジェクトがバタバタしてしまう。仕方が無いのかも知れません。でも、ふりかえって考えるとこんなポイントを忘れていないでしょうか?

リスクマネージメント

今起きている問題は予見していたでしょうか?「あぶないなぁ」とは思っていたなんてことはないでしょうか?

リスクに対して「まぁ、大丈夫だろう」とか「問題が起きたら考えよう」などと思っていると、どんどん後手に回ってしまいます。

予想できるリスクは、発生する要素を避ける、発生確率を低減する、外部に転嫁する、許容して対策に必要なバッファを確保する事が可能です。

オプション確保

そんな事を言われても全てのリスクに対策なんてできない。それはそうです。ではどうするか?背水の陣を避ける事です。

対策できていないリスクや予見しえない問題が生じた際に、逃げ場が無くならない様に選択肢を残しておく事です。

あらかじめ計画できる事もありますが、なかなかそうもいかないかも知れません。でも、なるべく選択肢を減らさない様にする事はできます。

リーンソフトウェア開発で最終責任時点(リーンソフトウェア開発 - 決定をできるだけ遅らせる)と呼ばれるそれ以上決定が遅れると問題が生じるタイミングを見極めて、可能な選択肢を残す事で、プロジェクトを柔軟に運営する事ができます。

スムーズな連携

プロジェクトにマイルストーンを設定したり、タイムボックスを適用すると管理が容易になります。しかし、とりあえず目先の目標をこなしていただけではうまくいきません。

全体の作業を俯瞰して、より効率的なパイプライン([#agile] 「リーン開発の現場」を読んで その2 - パイプラインとスケールアップ -)を構成する必要があります。

それはマイルストーンに向かう作業間の連携だけでなく、より長期的な視点でのデシジョンです。今の報告を良く見せる事に執着せず、トータルで効率が良くなる様に作業間の連携を構成します。

おわりに

「あいつがやるといつもうまくいく」とか「頑張っているのにうまくいかない」という状況は、運だけではありません。大切なポイントを押さえているかどうかです。

このポイントは様々な事にあてはまります。プロジェクトマネージメントが旨い人は、他の事もうまくできるでしょう(何を大切にするかは対象次第ですが、、)。

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

[#UAS] Ultimate Agile Stories の寄稿5本を一挙公開!

Ultimate Agile Stories (UAS)は全5册からなるアジャイル同人誌です。

この本は、アジャイルのコミュニティの人達の熱い思いを綴った記事をまとめたものです。頒布による利益は、東北の震災の年から5年間寄付されてきました(まだ在庫があるので、寄付したぐらいの赤字だそうです)。

私もアジャイル関係のコミュニティに出入りしていましたし、日本XPユーザー会関西支部(XPJUG関西)でチケット駆動開発の分科会があったことなどから、全ての本に寄稿させていただきました。

これまで、次の本が出る度に1年前の寄稿を公開してきました。しかし昨年、とうとう最終号になってしまいましたので、これまでの寄稿をまとめて公開します。

UASには、アジャイル放談という飲みながらそれぞれの思いを熱く語り合った記事があります。そろそろ若い人に任せた方が良いのではないか、などと思いながら、なぜか全てに参加させていただきました。

この他にも有名な方々の記事がたくさん載っていますので、機会を見つけてぜひ購入してください(トップのリンク参照)。



UAS5の寄稿

<UAS5の紹介>
[#UAS] アジャイル開発とフィードバックそしてリスク - Ultimate Agile Stories Iteration 5 -



UAS4の寄稿



UAS3の寄稿

<UAS3の紹介>
[#Agile] 自己組織化あるいは自律的組織 #UAS3



UAS2の寄稿

<UAS2関連記事>
[#TiDD]ウォータースクラムフォールよりも五月雨WFの方が変化に強い!(かも)



UAS1の寄稿

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


そりゃそやろ! - 「アジャイルがダメだと思う7つの理由」について議論して -

「アジャイルがダメだと思う7つの理由」について議論する会を大阪でに参加しました。3年前の元ネタと最近の様子に関する鈴木雄介さんの講演のあと、グループ毎に議論しました。

元ネタについてはすでに書いています(アジャイルがダメだと思う7つの理由を前向きに考えてみる)が、今回はこれまでの経験を踏まえて議論をしてきました。

講演内容

まず、「アジャイルがダメだと思う7つの理由」についてのお話がありました。そして、当時はアーキテクチャとアジャイルのコミュニティが対立していたことからアーキテクトである鈴木さんがアジャイルをあまり良く思っていない事、最近はアジャイル風の繰り返し開発をされている事、をお話しされました。

私も、アジャイル開発の「考え方」と「やり方」を学べ[#TiDD]ウォーターフォール開発をアダプタブルにする(チケット駆動開発) - SQiP2015チュートリアル -で同じような開発方法を書いてます。

ウォーターフォール開発をベースにアジャイル開発を参考にすると言う話は昔から書いてますが、最近はウォーターフォールがベースに開発する多くの人が工夫しているのでしょうね。

変化ヲ抱擁スルために固定化している

講演の後は7つの理由のグループに分かれて2回の議論しました。というか、賛成と反対の意見に分かれてディベートをしました。1回目は「 変化ヲ抱擁スルために固定化している」です。

元記事では暗黙知の事を書かれていますが、アジャイル宣言の背後にある原則

動くソフトウェアを、2-3週間から2-3ヶ月というできるだけ短い時間間隔でリリースします。

を取り上げて、プロセスを固定化として、最適化できないとの議論を展開しました。関連するシステムがあり、期限が限られているので、定期的なリリースにあわせる事はできません。

反対意見では、スプリント中にリリースするタスクを作って実施しているとのお話がありました。実務的にはそうでしょうけど、それは原則に従っているのか、1週間ごとのリリースや1日に何度もリリースして、アジャイルというのと同じではないかと言いました。

この他にも2ヶ月ほどの短期開発では、タイムボックスごとのふりかえりなどもあまり効果的でなく、期間内で最適化する方がうまくいくのではというお話をしました。

どこまで原則を守らないとアジャイルと言えないかとの議論はありましたが、それ以外の反論はありませんでした。

なお、そういったシステム間の連携があったり、短期間のプロジェクトが一部の例外と呼べる組織なら、アジャイル開発を標準とすることもアリだと思います。

アジリティはアジャイルだけのものではない

2回目の議論ではグループの全員が「そりゃそうだ」と賛同しましたので、議論というよりは意見交換になりました。

アジャイル開発はアダプティブ(適応型)であるのが基本で、アジャイル(機敏)というのは風呂敷が大きすぎるのではないかと言いました。機敏を実現するには高速開発等の環境やツールなどもあるからです。

ただ、アジャイル開発があったからリーンスタートアップが生まれたんだよね。という意見には賛同しました。そういう意味では、「 アジリティはアジャイルだけのものではないが、アジリティの本家だ」ということだと思います。

おわりに

この記事を書き出してからゆっくり考えました。

私自身はアジャイルに反対している訳でなく、向いている所で実施すべきものだと思っています。

そもそもアジャイルソフトウェア開発宣言は、当時のソフトウェア開発の解決すべき問題点を示しており、誰もが考慮すべき事であると思っています。

しかし、厳密な定義を元せずアジャイル開発の議論をすると、きちんとした技術論にならず、いつもながら不毛になりがちだと思いました。

アジャイル開発であるかどうかは開発者の関心事ではなく、顧客に価値を提供するより良いソフトウェアの実現が関心事です。アジャイル開発に対する議論はもう終わりにして、どのような現場の問題をどのように改善したかを議論したい思いました。

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


標準化やタイムボックス管理ではできない具体的な支援をするプロジェクトランゲージ - カレーの作り方から考える -

第65回 SEA関西プロセス分科会&RxTStudy #15 「チケット管理システムによるプロセス支援と今後の課題」で発表しました。

プロセスはモデリングすることで知識を 伝達、理解、改善、管理、 支援、自動化できますが、現状の扱われ方はカレーの作り方で言うなら、重量やカットした結果を測定したエビデンスを求める。あるいは、分担を決めたり、定期的な味見をする事が決められているだけです。



たとえば顧客向けのデモを実施する必要があった時も現場が考えることが求められるだけで、過去の経験を参照したり応用する方法は支援されていません([#TiDD] パタンランゲージで経験を活かしたプロセスを構築する)。

建築分野などで用いられるパタンランゲージはそのドメインで解決が求められている(要求されている)問題とその解決策等を整理したカタログです。

プロジェクトランゲージはパタンランゲージを元に、ワーキングマスタープランを用いて、顧客と共に段階的なプロジェクトを構成していきます。そのドメインで求められているパタンを具体的な制約を踏まえて組み合わせるので、ノウハウを活用する事ができます。

このような方法をとるには、まずDDDのユビキタス言語にも似たパタン(=対象ドメインで求められているもの)の素(言葉)を集めないといけません。そこで、過去のチケットを分類して、チケットを活用できないかを考察してみました。

なお、スライド中の航空写真は奈良先端大(NAIST)付近の北大和住宅にある地区センター付近のものです。パタンランゲージとプロジェクトランゲージは当時の様子を回想して独自に考えたものです。

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

アジャイルのレフトウィングには壁がある - 自律的組織実現への考慮点 -

アジャイルには開発環境のライトウィングとチーム環境のレフトウィングがあると言われます(アジャイルの「ライトウィング」と「レフトウィング」:An Agile Way:オルタナティブ・ブログ)。

この中でも難しいのがレフトウィング、特に自己組織化されたチームです。アジャイル開発を始めたからといっても簡単には実現できません。自己組織化されたチームを実現するにはチームのメンバーの価値観を変える必要があるからです。

注:筆者はすでにイテレーションの実現あきらめていますが(ミーティングに同期するタイミングはあります)、それ以外のアジャイル開発の要素には重要な内容が含まれていてなるべく実現しています。特に自己組織化はマネージメントの重点であり、20世紀からネットワーク組織とか新しいリーダーシップ(支援者としてのリーダー - 「リーダーシップ3.0」を読んで -)として語られている重要成功要因です。

すでにアジャイル開発への壁は価値観の壁で、基本的な考えを書きましたが、今回は具体的にどう言う点に注意しているかを欠きたいと思います。

自己組織化され他チームは自律的であり、従順ではいけません。それぞれが考え、能力を発揮し、貢献することが求められています。そういったチームの実現には3点への考慮が必要です。

  • オープンな議論ができる
  • 互いにリスペクトできる
  • 話が噛み合うこと

それぞれにどのような注意点があり、どのように対応しているかを整理したいと思います。

オープンな議論ができる

基本は序列を気にしないで技術論を戦わせる事ができることでしょう。上の人はサーバントリーダーシップを心がけて、対等な関係を築かないといけません。

ピラミッド型の組織を経験した人は従順で自分の意見を言おうとしません。なぜそう考えるか、どうやると良いと思うか、と聞いてみると良いかも知れません。

時には最終判断を迫ってくるかもしれません。「聞いて答えたらそうするの?」と言った事もあります。まずは考えてもらい、議論する事が大事だと思います。

やらないとわからない事はやってみたら良いと思いますし、考えてないなら考える様にアプローチしないといけません。それは上に従うのではなくてチームで考え、みんなでゴールを達成し、共に喜ぶために必要な道のりです。

互いにリスペクトできる

偏差値教育の弊害でしょうか、それとも頑張れば神や仏になれるという宗教の影響でしょうか、日本では一つの基準で人が評価されがちです。立身出世という言葉からは昇進する事が成功で、できない人はダメという印象を受けます。

しかし、人それぞれに特長があり、存在価値があります。能力が低くても努力して貢献した人は賞賛すべきですし、能力があっても協調せず、貢献しない人は評価されるべきではありません。

アジャイル開発では多能工、いわゆるフルスタックなエンジニアが揃うとうまく回し易いでしょう。しかし、それぞれの特徴的な能力が生かせる環境も大切だと思います。

書籍SCRUM BOOT CAMP THE BOOKでは、それまで目立たなかったバッチ君が後から活躍します(日本でスクラムを実践するなら読んでおきたい本(SCRUM BOOT CAMP THE BOOK))。このバッチ君のように自分の能力を生かして貢献し、能力を生かせたことを共に喜ぶような価値観の焼き直しが必要だと思います(日本文化に仕立て直した実践書 - SCRUM BOOT CAMP THE BOOK の意義 -)。

人それぞれ、多様な価値感や経験、事情があります。それらを考慮してプロジェクトを運営し評価する必要があります。その多様な評価が、互いのリスペクトに繋がり、対等に議論できる環境の実現すると思います。

話が噛み合うこと

チームで意見を交換するには、全体のゴールを共有できている必要があります。もちろん個人の目的は違っうでしょうが、全体としては同じ方向を向かないと議論ができません。

時間精算だからサボったほうが売上が増えるとか、時間精算がないから変更はなるべく受けない、など自分勝手な基準ではなく、ゴールを把握した上で互いのビジネスモデルも理解してWin-Winになれないといけません(アジャイルかWFかの議論はやめよう。大切なのはWin-Winの実現)。

おわりに

アジャイル開発宣言はソフトウェア開発に必要な要素をまとめたものです([#Agile] アジャイル宣言と原則の私的まとめ)。なかでも自律的な組織に関してはソフトウェア開発だけでなく、変化の激しいビジネスでも必要とされているものです。

かつての追いつけ追い越せの時代は進む方向が明確でしたから、トップダウンにコマンドコントロールする事が効率的でした。しかし、すでにトップグループに入ってしまった日本は、変化する状況に追いつくだけでなく、日常的にイノベーションを起こせる自律的な組織が求められています。

今回は自律的組織の実現に必要な考慮点と取り組んでいる内容をまとめました。少しでも皆様の参考になれば幸いです(他に良い方法があれば教えてください)。

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


より以前の記事一覧