無料ブログはココログ

ポケモン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日の記事です。

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

SRA Advent Calendar 2016 に参加します

Advent Calendarというのは、クリスマスが来るのを待ち望むためのカレンダーのことです。最近はアドベントカレンダーにあわせて、みんなでブログを書くイベントになっています。

様々なコミュニティで行われているほか、比較的オープンな会社でもカレンダーを作る様です。

SRAでもだれか言い出さないかと思っていましたが、なんと隣の席の人が言い出してくれました(わーい)。

ということで、今年は SRA Advent Calendar 2016 に参加予定です。みなさん見てくださいね。

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

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

はじめに

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

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

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

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

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

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

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

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

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

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

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

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

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

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

状況を把握するには

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

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

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

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

おわりに

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

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

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

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

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

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

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

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

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

リスクマネージメント

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

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

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

オプション確保

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

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

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

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

スムーズな連携

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

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

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

おわりに

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

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

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

セミオープンという選択肢!ヘッドホン PHILIPS Fidelio L2BO

高級ステレオで良い音をガンガン鳴らして楽しみたいものですが、そうもいかないのでヘッドホンの部屋聞きで楽しんでいます。

と言っても普段使いのカナル型のインナーイヤホンは、断線する可能性のある消耗品と考えて程々の品質で我慢しているためか、圧迫感を感じて長時間だと疲れるので、いわゆるヘッドホンを使っています。

以前使っていたヘッドホン

気楽に聞くのでオープンエアーが圧迫感が無くてベストでした。大体1万円ぐらいから良い音になり、2万円ぐらいになると個人的にほぼベストの音で聞けます。とはいえ、いつかは壊れたり、劣化するので、コストパフォーマンスから中間の1万5千円程度のaudio-technica ATH-AD700を使っていました。

このヘッドホンはいわゆるドンシャリではなく、スーッと抜ける感じで音が広がって、耳への当たりも優しくお気に入りでした。でも、リビングの家族の近くで仕事をしながら音楽を聴いている時は音漏れが大きくて不評でした。

装着時の負担が少なかったので、あきらめがつくほど長期間使っていました。しかし、あるとき、片側の音が出なくなりました。ユニットの中で断線した様です。

密閉型の試聴

そこで、新たなヘッドホンを探す事になったのですが、オープンエアー型はお気に入りだったもののもう少し音漏れの少ないものを探す事にしました。

量販店で色々と聞いてみました。密閉式の数万円のものはとんでもなく良い音がしましたが、安価なものは少しこもったようなは感じのものが多い様でした。

1万5千円程度の中ではオーディオテクニカ USBヘッドホン ATH-D900USBが程々に良かったです。メーカーに愛着もあったのですが、本来はPCと接続するためのヘッドホンなので、使わない機能が気になって今回は見送りました。

セミオープン型

自宅で色々と調べていると、セミオープン型が目に留まりました。名前は知っていたのですが、実物は聞いた事がありませんでした。

セミオープン型は商品が少なかったので順番に見ていると、PHILIPS Fidelio L2BOは音の解像度が高いと良い評価でした。前のヘッドホンがオープン型で抜ける感じが気に入っていましたので、興味がわきました。

悪い評価としては、低音が弱め、苦手な曲がある、との事でしたが、点数はさほど悪くなく、買う事にしました。

かなり良いヘッドホン

商品が届いたので開封すると、オス・オスのヘッドホンケーブルが長短2本ついていました。ヘッドホンにはイヤホンと同じ形状のジャックがついていて、外出時にはリモコン付きの短い方を使う様です。

装着感はATH-AD700に比べると強めですが、コンパクトなので周囲にぶつかる事が少ないです。最初はスピーカ部分を端まで伸ばしてしまって強い圧迫感を感じましたが、頭にあわせて短くすると程良い感じになりました。比較的頭が大きい方なので、よほど頭が大きい人でなければ大丈夫でしょう。

楽しみにしていた音はとても良くて満足です。解像度が高く、抜けるような感じです。いわゆるドンシャリの感じは無く、フラットに近いと思います。曲との相性はあまり感じません。ごくまれに低音が「トン」高音が「ジャリ」と感じる事がありましたが、すぐに慣れてあまり感じなくなりました。

良い音で音楽を聞きたかったので、とても良い買い物をしたと思っています。

おわりに

そもそも試聴にいく必要もなかったのかも知れませんが、色々と聞くと自分の好みの音がわかると思います。今回はその好みを基準として選んだので、自分にあった商品と出逢う事ができました。

このヘッドホンは音が良いだけではなく、ケーブルが取り外せるので断線の不安も少なく、長くつきあう事ができそうです。

Photo_2

おまけ:ケーブルレスでの利用

家の中でウロウロする時はL字コネクタとオス・オス変換コネクタを使ってBluetoothレシーバをつないでいます。

見た目はB級SFに出てきそうなデザインですが、ケーブルレスにできるので重宝しています。iPhoneを買い替えたら役立ちそうです(オス・オスのL型コネクタがあれば少しはマシかもしれません)。

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


Redmineが得意なプロジェクト

Redmineの機能を考えると、どのようなプロジェクトに向いているかがわかります。

プロダクトライン

Redmineのチケットは全てのプロジェクトで通番になっています。他のプロジェクトのチケットを容易に参照できますので、プロダクトラインの開発時の様に過去のプロジェクトの参照が必要な場合に有利です。
参考:『Redmine実践ガイド』に書き忘れた事 - 管理を容易にするチケット番号の一意性 -

System of Systems あるいは トップダウンに分解できる

Redmineのプロジェクトとチケットは、それぞれの親子関係を持つ事ができます。 System of Systems と呼ばれるような、複数のプロジェクトから構成されるシステムも小さな単位に分割して管理できます。
参考:[#TiDD] チケットによる情報の関連付け(チートシート)

多様なコミュニケーションが必要な大規模システム

Redmineには他のITSにもあるWikiのほか、フォーラムやニュースなどの情報共有の仕組みがあります。また、ガントチャートによる可視化やREST APIなどシステム連携機能もあります。大規模システムにも対応できる多様な機能が標準で用意されています。(大規模な開発が多いので参考にある様に「説明会を開くべし」と言う意見が多いのでしょうね)
参考:[#redmine] Remineを活かしたプロセス支援 - 失敗しないプロセス支援 - #rxtstudy

作者のJPL(Redmine.jpブログ)は、このような開発をしているのかも知れませんね。

ちなみに上記に当てはまらない、一度限りのプロジェクト、単独システムあるいは構成が変わり易いシステム、チケットで十分あるいは小規模な場合は、Redmineにこだわらなくて良いプロジェクトと言えるでしょう。

なお、Redmineの特徴を説明しましたが、ITSの導入には知見者あるいは導入意欲を持った人の存在が必要になります。また、過去の資産をどうするかということも、ITSを選択する際の重要なポイントの一つでしょう。

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


[#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回目の議論ではグループの全員が「そりゃそうだ」と賛同しましたので、議論というよりは意見交換になりました。

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

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

おわりに

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

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

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

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

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

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


iPad mini 2(Retina) 充電不可(Lightning コネクタ故障)顛末記

iPad mini Retina(3が出たので2と呼ばれています。以下 iPad mini2 )で電子書籍を読む(電車でPDFが読める! iPad mini retinaモデル WiFi C?)だけではもったいないので、「ひかりTVどこでも」を見たり、「アマゾンプライムビデオ」をTVで見る際にも使っています。

トラブル発覚

先日、プライムビデオを見ようとHDMIアダプタを接続すると、反応がありません。他のケーブルをつないでみたりしましたが、反応がありません。

同じケーブルにiPhoneをつなげると反応しますので、どうもiPad mini2のコネクタが壊れた様です。

修理価格を調査

AppleCare+に入っていませんし、入っていても2年以上経っていますので、全額自費になります。調べてみると、iPad mini2 の修理費が表示されているのは、大阪市内のお店が12,000〜15,000円、東京なら郵送ですが1万円弱でありそうでした。

地元の京都は表記が無かったですし、会社が大阪なので大阪でも構わないのですが、すでに買い取り価格が 1万5千円程度なのに、郵送したり1万円以上かけるなら、中古のAirかKindleでも買った方が新しい経験ができて楽しいかも、と考えていました。

Smart Doctor PROFESSIONAL

たまたまスマートドクタープロ 京都河原町店の前を通ったので、冷やかし半分で聞いてみると9,800円。ただし、半田作業になるので、(これまではないが)最悪の場合は壊れることがあり、その際は使えなくなるが無料とのこと。

修理費が高いから捨てようとしていたので、それだったらと持ち込みました。1時間半ほどたって修理完了の電話で伝えられたのは、「クラック」だったので部品交換せずに済んだので、7,800円とのこと。予想外に安くつきました。

ただし、部品交換していないこと、コネクタは使い方次第なので修理後の保証期間はないとのこと。ただし、なにかあればチェックはしてくれるとの事ですので、良心的だと思います。

原因の考察

クラックということで、たぶん半田が浮いてきたのでしょう。思い当たるのは、アマゾンプライム再生機としてHDMIアダプタをずっと付けていた事です。

少しぶら下がるような状態だったので、負担になったのでしょう。今後は気をつけたいと思います。

おわりに

1万円以上も出すのだったらと捨てるつもりでしたが、現状なら中古で売っても差し引き7,000円のプラス。元々、気に入って買ったものですし、色々と使い道もありますので、本当に壊れるまで使っていきたいと思います。

今回、勉強になったのは、金額が表示されていなくても修理できる事があるという事です。部品の在庫まであったので不思議な感じがしますが、全国展開しているので難しい修理は相談してください。という事なのでしょう。

ということで、動く様になりました。よかった、よかった。

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

«『Redmine実践ガイド』に書き忘れた事 - 管理を容易にするチケット番号の一意性 -