新規
編集
添付ベースページ
#
#
#
#
| 例え話 | 画像 | 今回の例 |
| 顧客が説明した要件 ちょっと機能過剰（？）なブランコの製造依頼。一度に3人乗るつもりだろうか。明らかにピントのズレたシステムを提案する顧客。どこかで似たようなものを見聞きしたのだろう、素人考えレベルのシステム提案といったところか。問題解決を求めている当事者でありシステムを使う立場なのだから、と自信を持って提案しているのかもしれない。もちろん金を払う立場でもあるのでシステム開発を請け負う側もあまり批判的なことは言えない状況が多いかもしれない。それでも顧客自身に最終的な問題解決策を提案させてはいけない。それは開発者側が行うべき仕事である。重要なのは、本当に解決すべき問題の本質とその理由が正しく見極められているのか何度も問い直すことである。だれかがいつの間にか提案した「解決策」らしきものに考えなしにいきなり飛びついてはいけない。 | ||
| プロジェクトリーダーの理解 木にぶら下がったブランコが欲しいという顧客の要求はなんとか理解できた。そして顧客の提案にある非現実的な部分は専門家として排除したつもりだが、それでもまだ動くかどうか疑わしいブランコの構想。ちょっと技術を知る人が側にいればその妥当性を検証できるのだがそういう体制はないようである。顧客にいちばん近い位置で開発に必要な情報を取り入れ、顧客のためのシステムを提案し、開発チームに完成品のビジョンを共有させる立場（のはず）。ここで既に顧客との意思の疎通に齟齬が発生している。また実際に動くかどうか分からないシステムが構想されているが妥当性を検証する手段を持っていないということなのか、検証している時間がないのか、それでなければ自信過剰というところか。 | 運営の理解 まさにここだな（＝Д＝； | |
| アナリストの設計 プロジェクトリーダーの構想のままではブランコが動かないことに気づいたのでブランコがなんとか揺れることができるように改良（？）されている。プロジェクトリーダーの意図はとりあえず反映するが、そもそも当初の見通しが間違っているため顧客の要求と両立させるために不自然な歪んだシステムが設計される。妥当性を検証し上流工程に差し戻してやり直しを要求することは立場として難しいのか、あるいは腕の見せ所と張り切った結果か。また、無意味に新技術を導入したがる設計者が多いのも問題かもしれない。 | ||
| プログラマのコード 木の幹にブランコが繋がれている状態。第三者の目にはかなり異様な光景に映るがさっさと仕事を終えたいプログラマは気にしない。一昔前なら「ステップ数でこれだけの進捗がありました」と報告するような職場での仕事ぶりだろうか。これがブランコの設置だからまだ見た目分かりやすいが、プログラマの労働の成果であるプログラムの構造や動作を第三者が手早く評価したり欠陥を見抜くのは容易ではない。 設計者の意図は正しくプログラマに伝わっておらず、まともに動かないシステムが生まれゆく状況である。木とブランコが「とりあえず繋がっている」ので、「間違ってはいない」レベルで設計が実現された状態。プログラマが顧客の要求を知る術もない。ここでも成果物の妥当性を検証する機会はないようだ。成果は見かけ上増えていくが後々捨てられる部分が大半を占める。 | ||
| 営業の表現、約束 ソファを搭載した無駄に豪華な光り輝くブランコ。第三者の目にはかなり異様な光景に映るが売り込みに熱心な営業担当者は気にしない。本質的でない上に過剰な機能の搭載を売り込む営業。製品はまだできていないんだから何とでも言える。また、顧客の要望が廉価なタイヤなど、枯れた技術の水平思考で代用実現できる可能性に仮に気づいていても、絶対に営業側から顧客に言い出すことは無い。顧客側から「もっと安く代替できるのでは？」と指摘されても「でもこちらのソファの方がお尻が痛くないですよね。」と誘導していく。なるべく高価で大量に機能を盛り込んだプランで契約を取るのが彼らの仕事だからである。顧客が技術的なことを理解できない場合はなおさら有効なのだろうか。ところで営業担当者たちは実際の開発現場とどんな交流があるのだろうか？ たぶんほとんどない。というよりも、営業本人が技術的なことを全く理解できてない場合も多く、マネジメントの知識すらないこともある。つまり、「こんな凄いことがたったこれだけの工数でできてしまうんです！！」「変更(追加)ですか？任せてください！簡単なことですよ！！」となんの根拠もなく豪語するのだ。競合他社がいる場合、知ってても投げ捨てることすらある。とりあえず取れれば自分の手柄になるのだから後のことは知ったこっちゃない。当然開発現場は阿鼻叫喚である。もちろん彼ら自身は定時後及び休日を有意義に楽しむ。 | ||
| プロジェクトの書類 ブランコの開発に関する記録が何もない。なにかしらそこに存在した痕跡はあるようだが・・・という状態。振り向けば開発に関するドキュメントの類が一切残っていない。仕様がコロコロと変わるため記録しても意味がないのかもしれない。しかも顧客から次々とやってくる追加要求を安請け合いして情報量的には膨らんでいるかもしれない。また開発スタッフも、仕様書を丁寧に書いたところで開発成果に直接繋がらない上に上司からもそんな仕事は評価されないため誰も書きたがらないのだろう。後々開発メンバーが交代したりするとシステム保守・改良がやり難くなる一因にもなるはずだが。仮に設計段階において綿密に仕様が検討されドキュメントがしっかり整備されていたとしても、当初の設計では想定していなかった振る舞いがシステムの動作試験の段階になってから発見されることがある。そうなると、システムは再設計を余儀なくされコードも書き直されていくため、オリジナルの設計書の内容は覆され陳腐化してしまう。そもそも「設計書、仕様書は物ができたあとに、物が動くとおりに書くものである」ということが、ごく普通に稀によくある。 | 仕様書 ユーザーには、どの様な代物が出来上がるか不明なまま実装された。 | |
| 実際の運用 ロープ一本だけが枝からぶら下がっている。とりあえず、枝からぶら下がって揺られて遊べる。辛うじて遊具の体をなしている状態。腕の力が弱い人・体重の重い人には厳しい遊具である。当初の設計案をすべて盛り込むには納期に間に合わないと判断され、予定よりも大幅に縮小された機能だけを載せて納期に間に合わせて顧客へ渡った状態。約束されたシステムとは程遠い不完全で使い勝手の悪い状態で顧客は運用を強いられることとなる。顧客の日常業務がこのシステムに依存・維持させるために、システム導入前とは別の手間とコストかかるものにならないか心配である。この時点で、一体何のためにシステム導入を検討していたのかを覚えている人も少なくなっているのではなかろうか。 | 士官名だけが並んでいる。とりあえず、士官名は判る。辛うじて一覧の体をなしている状態。基地名が全部基地の人には厳しい状態である。当初の設計案をすべて盛り込むには納期に間に合わないと判断され、予定よりも大幅に縮小された機能だけを載せて納期に間に合わせて顧客へ渡った状態。約束されたシステムとは程遠い不完全で使い勝手の悪い状態で顧客は運用を強いられることとなる。顧客の日常業務がこのシステムに依存・維持させるために、システム導入前とは別の手間とコストかかるものにならないか心配である。この時点で、一体何のためにシステム導入を検討していたのかを覚えている人も少なくなっているのではなかろうか。 | |
| 顧客への請求金額 ジェットコースターらしき遊具。ブランコの設置なのに遊園地のアトラクションの建造費用レベルの法外な請求額ということか。初期の設計にあった仕様すら満たしていないというのに。もしくは、『高速で乱高下する』ジェットコースターの様を請求金額に例えて、「別途料金追加の連続で、当初の見積額からうなぎ登りに上昇」→「運用開始した顧客や世間に実態がバレて叩かれだした途端、運用自体は何も変えてないのに急激に安くなる」という手の平返しを皮肉っているのかもしれない。 | ||
| 得られたサポート 切り株だけが存在する。あるいは、ブランコが設置された木が根本から切り倒されてしまった状態。「実際の運用」にあたって顧客からの「ロープに腕だけでぶら下がるのは余りにも辛いので、とりあえずは『腰掛けて』楽に使えるようにしてほしい」という要望に、サポート担当者が場当たり的に対処した結果にも見える。このように、システムの存在を根幹から台なしにするような不適切なサポートが行われた結果か。あるいは、顧客が実際に受けることのできたサポートの質や量・期間がこの程度のショボいものだったということか。もっと最悪の場合、「木画（企画）倒れ」「サポートの打ち切り」「システム運用自体の打ち切り・凍結・放置」という事態とも受け取ることができる。 | ||
| 顧客が本当に必要だったもの タイヤをぶら下げたブランコ。本物のブランコほどではないが、木にぶら下がって（腕に負担をかけず体重を預けた状態で）揺れて遊ぶという本来の要求を十分に満たす機能を持った遊具。おまけに本物のブランコよりも安上がりな実現方法である。もちろん材料のタイヤも新品である必要はない。顧客がパンダであろうと申し分ないはず。顧客には見えていなかった理想的製品像。ひょっとしたら開発者側も見えていなかった可能性も大きいが、開発者側が探り当てて提示すべき到達点。それでも現実問題として、タイヤを使ったブランコ型遊具（顧客に必要な機能は十分に盛り込んでいるシステム・最新技術とは言い難いがお値段お手頃）を顧客が、「これで十分、わが社に導入するには最適」ときちんと理解・納得して受け入れるのか？という疑問は残るのであるが。 | ||
どうすればよかったのか？
このように、「顧客が本当に必要だったもの」を実現するのはとても難しい。実際、この寓話が示す罠にハマって「失敗を達成」したり、デスマーチに陥るプロジェクトは後を絶たない。
システム開発の本質的な困難さは、関係者の意思疎通（コミュニケーション）にある。必ずしも、開発側の分析力や技術力の不足だけが原因ではないのだ。
では、どうすればよかったのか？
一つの回答は、「顧客が本当に必要なもの」をあらかじめしっかりと分析して顧客と合意すると共に、プロジェクト関係者の間でそれを共有すること。正しいゴールが設定され、共有されていれば、全ての関係者がそれに向かって作業すれば良いだけなのである。
しかし、現実には、その「正しいゴール」を見極めるのが最も難題だったりする。特に、予見可能性の低いビジネス分野においては、全関係者が一丸となって「誤ったゴール」に向けて邁進する、という羽目になる可能性は高い。また、過去の開発・運用経験や他者の成功事例の見聞に引きずられて、現在解決すべき独自の問題を（無意識に）それらに無理やり当てはめて解決を図ろうとする恐れもあるだろう。
そのため、もう一つの回答として、近年アジャイル開発と呼ばれる手法が提唱されている。一口に「アジャイル」といっても厳密な定義はないのだが、だいたい、以下のような原則に沿った開発手法の総称だと思ってくれればいい。
「顧客が欲しいもの」は、常に変化すると考える。
製品を短い周期（数週間～数ヶ月）で繰り返しリリースし、その都度計画を見直す。
顧客も、プロジェクトへ積極的に関わるよう努め、リリースした製品を元に開発者とコミュニケーションする。
「顧客が説明した要件」が製品になるまでの期間が長くなるほど、それが「顧客が本当に必要だったもの」とズレていた時の被害も大きくなる。そもそも、「顧客が本当に必要なもの」は、開発が進んで製品が形になってきた段階で初めて分かることも多い。
これを避けるために、機能を一つずつ完成させて短い期間でリリースしていき、その度に顧客からフィードバックを受けて方向修正していく。こうすることで、「顧客が必要としないシステム」を作ってしまうリスクを減らそうというわけだ。
余談だが、ニコニコ動画のようなウェブサービスの開発についても似たような議論があって、トヨタ自動車の「トヨタ生産方式」にインスパイアされた「リーンスタートアップ」という手法が提唱されていたりする。
だがこの意味する所は、顧客が望まない状況を作った原因は顧客自身にもあるという事であり、単に開発側を非難するのは好ましくないかもしれない。
（＝ω＝y-~~~ こんなだったらよかったのに
※以下 司書の妄想です。
| 基地名 | 座標 | 状態 | 士官名 | LV | 戦闘 | 知力 |
| しふぉん | 200,200 | 製鉄所 | 三月兎 | 30 | 80 | 80 |
| くりーむ | 156,132 | 移動中 | 帽子屋 | 30 | 80 | 80 |
| くりーむ | 146,172 | →テロ基地 | チェシャ | 30 | 80 | 80 |
| くりーむ | 146,172 | ←帰投中 | 女王 | 30 | 80 | 80 |
| くりーむ | 146,172 | 基地内待機 | 兵士 | 30 | 80 | 80 |
名前クリックで
| 基地内施設配属中 | アビリティーの着脱 施設ウィンドウ 一括アビリティ解除 |
| 基地内待機士官 | アビリティーの着脱 発令所の兵器装備・着脱ウィンドウ 一括アビリティ解除 |
| 移動中部隊 | →撤退・即時着弾等のあのウィンドウ |
| 資源地待機 防衛増援待機 | →撤退ウィンドウ |
士官訓練所VerUP
- 追加機能
- 一括アビリティー解除基地単位・全基地
- 他基地の士官のアビリティー解除
- 名前クリックでアビリティー装着画面
| 基地名 | 座標 | 状態 | 士官名 | LV | 戦闘 | 知力 | 着用中アビリティー |
| しふぉん | 200,200 | 製鉄所 | 三月兎 | 30 | 80 | 80 | ■■強制労働 解除 ■策略家 解除 |
| くりーむ | 156,132 | 移動中 | 帽子屋 | 30 | 80 | 80 | ■■強制労働 ■策略家 |
| くりーむ | 146,172 | →テロ基地 | チェシャ | 30 | 80 | 80 | ■■エトランゼ ■飛行機乗り |
| くりーむ | 146,172 | ←帰投中 | 女王 | 30 | 80 | 80 | ■■エトランゼ ■飛行機乗り |
| くりーむ | 146,172 | 基地内待機 | 兵士 | 30 | 80 | 80 |
アビリティーリスト
- アビリティー毎に非表示・表示機能を追加
- タブ 戦闘系
- タブ 乗り系、エトランゼ系…
- タブ 生産系
- タブ ・・・
おまけ
戦闘レポート
海賊Lv14 (322,153)
座標の表示と座標地点へのワールドＭＡＰ移動機能があったら、狩りが捗るのにと毎回思う
- あまりに、想定外なアップデートすぎて、こんな実装だったら素敵だったのに！と言う妄想炸裂しております。 -- 司書ありす? 2014-06-04 (水) 23:20:11
- このページ何なの？例え話のところとか、荒らしと変わらないような気がするんだけど -- 2014-06-10 (火) 04:22:57
