« 2014年6月 | トップページ | 2014年8月 »

2014年7月の記事

プロダクトバックログを創ってみた!

少なくとも現時点でのアスペアでは、「こんな商売の為に、こんなコンセプトでこんなお店を開いて、ここはこんな感じに仕上げて...」みたいな、「大元になるビジネス的なゴール設定と、そこに至るための具体的な個別要件(ユーザーストーリー)」そのものを考えて決める、
...という事はなかなか有りません。

現時点で企画・開発しているサイクル・スポーツ(http://www.cyclesports.jp/)/クチコミ機能(その他諸々)が、辛うじて自社でユーザーストーリー群を作成している例となっています。

その他では、例え要求・要件定義工程から入ったとしても、基本的なビジネス的ゴール/ユーザーストーリーはお客様側が持っているものです(何処まで具体的で整合性が取れているか?、開発スコープに入れる事が出来るか?、は、また別の話として)。

こういったお仕事を常態的に繰返していても、「要求自体から考え出す」視点・思考習慣は身に付きません。

まあ、それはそれとして、そういったビジネス形態を続けて行くというのであれば構わないと思います。

しかし、アスペアとしては、「自社でビジネスを創っていきたい」!!
(それが、売上の100%にまではならなくても良いから...)
(自社企画・開発には、それはそれでビジネス的な危うさとか、技術的な広がり難さを伴ったりもしますので)

だからと言って、「それじゃあ、皆で1つづつ、ビジネス案を考えて来い!」
...と言ったところで、土台も無しにいきなりヒット・ビジネスの案がポコポコ出てくるはずも無く。

「要求そのものから考え出す」為のアプローチは様々に有ると思います。
最もフツーに考えたら、マーケッティング・リサーチで得られた情報から、各種の分析アプローチでビジネスチャンスを考える、とかでしょうか...。

でもこれは、リサーチ自体のコストも掛かるし、分析手法の習得と、その結果からビジネスチャンスを見つけ出す「勘」(経験値)が必要です。
残念ながら、現時点でのアスペア(の開発者達の中)にはこれらの要素は無い。

社長を中心に、独自の情報収集・分析・アイデア出しは行われていますが(サイクルスポーツもその1つです)、出来るものなら開発者もビジネス案を出せた方が良い!

と言うか、もう「開発者が開発だけやっていれば一生食っていける」時代は終わりかけているんじゃないでしょうか?

まあ、超絶的なアーキテクトとか、データストアとかネットワークに徹底的に詳しいとかのスペシャリストは生き残れるんでしょうが。

それじゃあ、どうしよう?

「要求自体から考え出す」ことを、ワークショップで疑似体験してみよう!

Pict2622_2Pict2623_2Pict2624_2今までにやった事の無いワークショップなので、旨くいくかどうか?、そもそもどうやってやる?
...とか、悩み所ではありましたが、
Scrumワークショップhttp://www.slideshare.net/youandi060219/scrum-17880241)の中で「プロダクトバックログを創る」部分があります。

ここだけを抽出して、やってみちゃあどうかね?
...という無茶な独断で、定例会の日に90分の時間枠を取って実行してみました。

目標とするビジネスは、敢えて「Webサイトの構築により実現するもの」以外としました。

こだわりの喫茶店、何らかのショップ、何かの乗り物とかの建設でも構わない。

Pict2625_2Pict2626_2Pict2628_2とにかく、チーム分け(3~4人)、各チーム毎に目標とするモノを決めてもらってから、
前述のスライド:p.42~44に従ってブレインストーミングを行ってもらいました(「どんなふうなモノにしたいのか」を)。

基本的に付箋ベースで、アナログツールをフル回転です。

各人がどんどん、思い付いたことを付箋に書いて、机上に並べる、ドアに貼る、書籍棚に貼る。

出来たら、近似したものを並べ直して、1つに集約するか、少数のいくつかに絞り直すかします。

Pict2629Pict2630で、次に、出来上がった(少し整理された)アイデアに基づいて、前述のスライド:p.49~60のような流れで「ユーザーストーリー」作りをします。

出来上がったユーザーストーリー群を、優先順位に従って並べ替えたモノが、「プロダクト・バックログ」となります!

実際にこれを開発に渡す前に、(スライドにも記述が有りますが)「INVEST」(下記)、

Independent (他のストーリーとの独立性が有るか?)
Negotiable  (交渉の余地を残し適切な粒度か?)
Valuable   (顧客にとって価値が有るか?)
Estimable  (見積可能か?)
SizedRigth / Small (適切なサイズか?)
Testable   (テスト可能か?)

...を満たしているか?
ユーザーストーリー毎にチェックを行います

実際に開発側がこのプロダクトバックログを受け取った際には、開発側も「INVEST」のチェックを行わなければいけません!

現実的に達成しようの無いユーザーストーリーを、「はいは~い」と受け取ってスプリントに入ってしまったら大変なことになりますから。
リスクの芽は、少しでも早い段階で摘み取るのが大前提です!

上記のようなステップを、実際にはもう少し細かく段階を踏みながら、時間を区切って進めました(私がタイムキーパーになって、開始・終了を告げる)。

はてさて、どんな結果になったか?........

チームは3つ。 それぞれの「ゴールのモノ」は、
多目的トレーニングセンター (健康的ですねー!!)
オシャレで落ち着いた喫茶店 (ほうほう...)
豪華客船 (どこから出て来たんだ?)

Pict2631Pict2632一番最後の「豪華客船」は、写真撮影(私)のミスで内容が判読不能になってしまったので掲載できませんが、宜しかったら拡大してご覧下さい。

ワークショップの最後に、お互いのプロダクトバックログを発表しようと思ったのですが、その時点で既に大幅にタイムオーバー。

仕方なく、社員専用Webサイトに、付箋群の写真をアップして共有とさせてもらいました。
苦渋の選択ですが、既にメンバーの多くに結構な疲労感を感じ取ったので、敢えて無理な時間延長は行いませんでした。

Pict2634定例会の最後に振返りを行いました(本当は「プロダクトバックログ創り」自体の振返りも行いたかったのですが、前述のような状態だったので、全体の振返りに集約させました)。

Keepとして、「発注者側の視点で考える機会が得られたのが良かった」、「いつもと違った頭の使い方が出来た」などが有りましたが、一方で、

Problemとして、「コンテンツの中身まで含めて一回お試しのターンが必要だと思う(その後に本番を行った方がスムーズだっただろう)」、「進行上で迷った時(あるべき考え方・進め方など考察したい時など)にディスカッション時間が欲しい」、
...といった意見も有りました。

今回は、Scrumワークショップ(http://www.slideshare.net/youandi060219/scrum-17880241)の一部を無理やり?切り出して実行しましたが、
不慣れなロールでのワークで、方法論や実行方法に選択肢が多い中、迷いながらも無理やりタイムテーブル通りに進めてみたという感覚が、メンバー内にも強かったようです。

特に、知識や経験が比較的多いメンバー、日頃から様々な視点で周囲の観察や勉強をしているメンバーほど、ストレスが強かったように思えます

.....といった感じで、課題満載の実験コンテンツでしたが、
これに懲りず、「要求自体を考える」アプローチ/機会は、繰り返し設けていこう!
やっていかないと、いかん!
と改めて考えています。


★クリック1つでブログランキングにご協力戴けます! m(_ _)m

| | コメント (0) | トラックバック (0)

Oculus Rift DK2!

7月の定例会は、社内技術者の半数を占めるメンバーが一斉納品とぶつかってしまったため、開催を月末の方に押しやる結果になりました(来月、8月も、別グループの稼働のピークを避けて月の後半での定例会開催になりそうなので、まあ丁度いいか!、ということで)。

で、予定していたIT-Tips候補者(順番に回ってくるので、候補者リストを社内専用Webサイトに公開しています)が、皆、納品関連でバタバタしていたのでネタの仕込みをしていないっ!!?

社内唯一のデザイナー・ロールであるトミーも、社内企画と顧客側から提示された複数イベントの両方に挟まれて身動きが取れず、やっぱりネタの仕込みどころではなかったようです...。

う~~~~ん、まあ、仕方がないっ!
お客様のビジネスに支障をきたしてはいけません!(自社の売上と信用にも影響するし!)、ここは業務優先ですよ!(定例会運営の責任者としては、泣きたいところではありますが.....

じゃあ、「ネタの準備をしといてね~」リストには入っていなかったけど、「その内、順番が回ってくるよー!?」リストの中から、誰か話ができる人はいないか???

...と、声を掛けたところで、しっかりキメてくれるのが山内さんですねー!
さすがです!(自画自賛ならぬ、自社メンバー自賛です)。

Pict2619
社員専用Webサイト上でも発言のあった、「Oculus Rift DK2」の紹介と、関連の話題を聞かせてくれました(当然、DK1を持っていて、DK2も発注済み)。

DK2はスペック的に様々な向上が成されている事、
※ディスプレイ部分がハイビジョン化され、高精細になった(元々、1画面で左右の眼の両方分の画像を表示している(物理的に左右半分づつ))。
※画像の表示遅延時間を、従来は0.1秒かかっていたものを更に短縮して違和感を軽減した。
※しゃがむ(視点の垂直移動)と、仮想世界の視点も下がる(追従できる)ようになった。

日本への出荷を最優先してくれている事も、初めて知りました(ちょっと裏話も幾つか出たんですが、ここには書けません...)、

公式には、創業者であるパルマー・ラッキー氏が、日本のユーザーからアウトプットされるコンテンツ発信率の高さ(大抵の他国では、デモ用のVR画像を見ただけで、それ以上は使わないとか...)、コンテンツの魅力(妄想度の高さ?!)・可能性を高く評価したから、ということになっています。

同氏は、SAO(ソードアート・オンライン)や初音ミクの大ファンでもあるとのこと。

Pict2621
あ、ちなみに、SAOがアニメになる数年以前に、「SAOV」(Sword Art Online Voice [ソードアート・オンライン ボイス]; SAOを音声(Voice)のみで(声優さんの卵に声を掛けて集めてマネージメントして)プロデュース・作成・編集まで行った作品!)をポッドキャスト配信したのが、この山内さんなんですね。

当然のことながら、原作者である 川原礫 氏の許諾を得ています...。

あ、DK2のお話でしたね。

当然のことながら、山内さん自身もDK2を使ってコンテンツ制作に臨むとのこと。

既に知人が開発した(開発中?)プログラム(&コンテンツ)を、近々事務所に持って来てくれるとのこと(OculusRift以外の、「動き」を入力させるデバイスを組み合わせたらしい...!?)。

ここには書けない内緒の話になってしまうかも知れませんが、今から楽しみです!


★クリック1つでブログランキングにご協力戴けます! m(_ _)m

| | コメント (0) | トラックバック (0)

お客様と一緒にブレインストーミングっ!

自社企画サービス(事業開発部)のメンバー(事業開発部の部長:青柳さん、技術&開発主幹:蓑方さん、デザイナー:トミー)が、顧客先に訪問してブレーンストーミングを行ってきました

大抵の請負案件や、特にSES案件の場合にも、顧客要求:外部仕様ってのは大体が(少なくともほぼ)形を成したものが「上の方」から降って来ます。

なので、「その要求自体が、現在の顧客のビジネスと狙う方向性に対して望ましいものか否か?」・「他の選択肢は無いのか?」などの検討の余地は、開発側の?我々には殆ど残されていません。

要望の発信者と近い場合は、現実的には公のロールを超えて調整が出来たりもしますが(予算の縛りは厳しいとしても...)、事前に提示された要求の方向性自体を大きく変えることは、先ず対象外です。

しかーし、自社企画サービスサイクルスポーツhttp://www.cyclesports.jp/)の場合は違います!

確かにお客様からの提案・要望で「是非!、これを!」というケースも無いという訳ではありません(特に、コンテンツ系の提示を戴けるのは大歓迎です!)。

しかし、「仕組み」(導線とか顧客への訴求法とか)・「デザイン」系の提案はアスペア側から行うのが基本です!

が、しかーし!

「実は顧客側の頭の片隅に眠っているイメージ」とか、「こんなん出来たら良いんだけどな」的なモノが、お客様担当の方の意識下に眠っているかも知れないっ
(何より、エンドユーザーの性質傾向とか市場をよく知っているのは、お客様の方ですから)

という訳で、アスペア側から、ビジネスサイドの企画・判断ができる者、技術者、デザイナー、全部まとめて顧客訪問させて戴き、ブレインストーミングを行って、今後のサイトの方向性/コンテンツの展開などの話をしてきました。

小さくて具体的な話題に至った場合には、その場で検証環境に改変を加えて、お客様に見て戴く、というアクションも行ってきました(言うまでもなく、エンドユーザーには明かしていないサイト・アドレスです(公開前の検証用ですからね))。

今後はもっと頻繁に顧客サイドに訪問し、色々な仕組みやコンテンツの展開をしていければと思います!!

さてさて、ここでハタと思うところあり!

現状では、SI案件の中で業務分析やシステム化提案を行うような機会は、他のグループでは非常に珍しいと言えます(これは残念なことですが、コンサル系まで範囲に含めて受注できないと、現実的には難しいのかな...)。

確かに、「要求仕様はお客様が考えて責任を持つモノ」という考え方も有りますし、それで望ましい結果が得られているケースも有るかも知れません。

が、それは珍しい(比率的に非常に少ない)ケースなのでは?

公のロールとしては「基本設計から」とかになっていたとしても、要求仕様自体が顧客の目指しているビジネスを成功・成長させる方向に適合しているとは限らない。

要求を分解・分析してみると、矛盾していたり、実現不可能だったり、検証不可能だったりという事もあり得ます(←この辺に関しては、最近アップした記事「「"Readyの定義" を使う」当り前の話...ですよね?」でも触れています)。

そこで!

近々の定例会で、「プロダクト・バックログ自体を考える」(それ以前のコンセプトから考える)ワークショップをやってみることにしましたーっ!!

さて、どうなることやら?!.....結果が楽しみでもあるし、盛上らなかったら冷や汗ものですねえ、ウフフフフフフ・・・・・・・・・。

しかし、発注者側の立場を経験する(一種のロールプレイ)機会を設けるというのは、悪くない発想のはずです!!!  うん!


★クリック1つでブログランキングにご協力戴けます! m(_ _)m

| | コメント (0) | トラックバック (0)

時には辛い別れも有るさ!

このブログを読んでいる方で、町田をご存じない方も多いかも知れませんね。

特に、関東外の方は「町田?、何処なのそれ?、なに県?」と思う方が多いでしょう…。

実は…、実は、紛れもなく「東京都」なんですーっ!!
「東京都・町田市」なのですよ!!

関東の方でも(東京や神奈川県の人でも)、「えーっ?町田って、神奈川県だと思ってた!」って人は少なくないと思います(私自身も、正直を言うと、感覚的には未だに「東京都内だ」という感覚に馴染めないでいます。 いや、本当に…)。

まあ、そんなことはどうでも良いのですが、町田にはJR:横浜戦と、小田急線が交差しており、乗り換えを含めて乗降客数は結構多いんです。

ビル群と繁華街、ちょっと怪しいエリアなども含めて、結構「都会」してるような気もします。

で、飲食店(飲み屋も含め)も多く、オシャレなお店も結構あります(お店の新規開店・潰れる、のサイクルも結構早い場所も有ります)。

さてさて、そんな町田に事務所を構え続けている(町田内では、何度か引越しました)アスペアに、2007年の4月に新卒で入社してきた鈴木さんが、2014年の6月末日で退職することになりました。

どんなプロジェクトに、どんな工程から入っても立上りが早く、常に全体を俯瞰しながら現実的にベターな選択肢を考え・アクションし続けてくれた鈴木さん。
本当にお疲れ様でした!
ありがとう御座いました!!

アスペア社内には結構なゲーム好きが多いのですが、鈴木さんもご他聞に漏れず。

で、一時期、あるお客様のネットワーク・ソーシャルゲーム開発に、アスペアから多くのメンバー(要求水準が高かったので、特にレベルの高いメンバーばかりが集中)がお手伝いさせて頂きました。
その中に、鈴木さんも含まれていたのです。

土日出勤はほぼありませんでしたが、平日の稼動は結構高かった.....。
納期に分単位で追われるし、変更も直前まで頻発する厳しい現場でした。

現場の各メンバーと、1.5ヶ月に1回程度の間隔で私と本音で話し合い、どんな状況なのか?、これからどうしていくべきか?、顧客への提案事項は無いか?(現場と並行して、或いは別の角度から)、個人のキャリアプランとの整合性は取れてるか?、今後どう動きたいか?、等々.....
敢えて各人個別とで会話してました。

そんな中で、厳しい状況の中、前向きに、かといって闇雲に走るわけではなく、全体を俯瞰しながら自分が出来ること・やるべきことを自律的に判断して、かつ周囲との協働で結果を出し続け
気が付いてみれば、ある括りでのサブリーダー(実際には能動的に横断的な情報共有や調整も行っていた)に、公式につくことが出来ていました!

厳しい状況でのリーダー格というのは、場合により・人により、必ずしも喜ぶものではありませんが、彼に関しては、その役割を「光栄」なものとして受け止め、従来よりも更に厳しいプロジェクトを無事にリリースまで漕ぎ着けたという、正にツワモノです!(漢(おとこ)ですね!)
(別に、精神論で対処した結果ではないことは、敢えて記しておきたいと思います)

さて、そのプロジェクト/お客様への対応が、いろいろと訳あって区切りの良い所で終了となりました。
決して彼自身の評価が下がったわけでは有りません。

その後、アスペア社内にてSIの請負:自社持帰りのインクリメンタルな開発プロジェクト群の中に入ったのですが、そんな毎日の中からなのか、どうやら「自分が本当にやりたいこと」(少なくともSI系の案件ではない!)に気が付いたようなのですね。

そして、その「やりたいこと」は、当面のアスペアでは実現が難しそうであると判断されたようです。

と言うわけで、アスペアにとっては非常に、非常~~~~~~~~~~~に痛いっ!!!、
残念で、残念で、残念で、と~~っても残念!!な結果なのですが、鈴木さんの退職という事になりました。

残念とは言え、自身のやりたいモノ・方向を見付けた、その方向にキャリアを伸ばして行けることは、彼自身にとっては喜ばしい・望ましいことです!

今後の彼の動きの中で、アスペア内で身に付けてくれた・様々な機会で共有してきた形式知暗黙知が役に立てば、こんなに嬉しいことは有りません!
これからの更なる活躍を、楽しみにしたいと思います!

Pict2617
と言うわけで、イタリアンのお店:カレット(http://machida-italian-caretto.com/)を急遽予約し、定例会の後に送別会を設定しました。

お店の総席数の6割程度の人数が参加したので、まあ貸切に近いと言えば近い感じでした(「座敷席」は完全に占領しましたー!)。

と、あれ?、肝心の鈴木さん本人がいない???

実は、その送別会当日が、仕掛りプロジェクトの納品日だったんですね!
(別に嫌がらせじゃありませんよ!(念の為...))
早めに言ってくれれば、定例会&送別会(セットにした方が参加できる人が増えるので)の日をずらしたのに.....。

でも、何とか途中から合流できました!!
良かったです! (送別会と言いながら、その対象となる本人がいないんじゃ、ただの飲み会ですからね.....)

Pict2616_2


あれ?、お店の飲み放題メニューに、アスペアの会社のロゴとか、自社サービスやツールのロゴが印刷されてます!

いやー、こんなのは初めてです!

140704_144203
飲み進めていく内に、ちょっと失礼してトイレに行きたくなりました...。
で、トイレに入ってみて........おおおお~~~っ!!

洗面台の鏡に、アスペアのロゴが書いてあります!

そこまでするか?、やるのかそこまで?、って感じでした。

これで、お店を完全貸切にしたらどうなっていたんだろう?、と、ちょっと怖いような、楽しみなような感じです。
どうしても来られないメンバーが数人いたので、その辺が集められれば、お店全部を貸切出来たのに!

まあ、いいか。

さてさて、話題の主は、転職する鈴木さんだあ!

これから、丁度、新規プロジェクトの立上げから入るとのこと。
プロパーとしてバリバリ活躍していけること間違い無しでしょうっ!!

ビジネス的に、常にスピードが要求され続ける、休む暇など許されない(?)、そんな中でも一定以上の品質を担保し続けなければならない。
そして、何よりも稼ぎ続けなければならない!

非常に難しいミッションです。

敢えて修羅の道(?)を選んだ鈴木さんですが、きっと効率的で楽しい開発が出来るように、全体最適と部分最適のバランスをとりながら、改善を重ねていけるものと思います。

これからも、頑張って下さい(無理し過ぎない範囲で)!


★クリック1つでブログランキングにご協力戴けます! m(_ _)m

| | コメント (0) | トラックバック (0)

かんばんボードをバージョンアップ!

自社企画・提案(&デザイン)でサービス開発(http://www.cyclesports.jp/ の「クチコミ」他・機能)を行っているプロジェクトでは、昨年の立ち上げ移行、ずっと「かんばんボード」を活用しています。

Pict2556
ソフトウェア的な「かんばん」(見に行かなければ見られない)ではなく、アナログのかんばん(視界の中に自然と入る)を使い続けています。

これは、自社企画モノである点、顧客の反応(提案・試作を見て頂いた結果の感触)・感想⇒要望などからバックログ・グルーミングを行い、優先度の見直しを図ることも珍しくない点とか、
技術的な要調査・評価事項が作業途中で発生したり、などの変動要因を確実に可視化したい!

でないと、タスクが迷子になってしまう(情報共有しているはずのメンバー間の認識が一定しない)...等の点を改善する為にも必須です!

余談ですが、アナログツールのみで運用できるのは、開発側(デザイン含む)のメンバー全員が物理的に同じ場所にいる、という点が効いています。
離れた地点にいるメンバーとの協調が必要な場合には、二重管理を避ける為にも、デジタルな「かんばんボード」(相当の仕組み)等を活用することになります。

でもやっぱり、アナログの方が圧倒的に直感的で共感し易いっ!!

さて、同プロジェクトのマネージャ的な立場の青柳さん(クラウド関連の技術調査・環境立上げ・運用等にも活躍してます)が、『リーン開発の現場』(http://www.amazon.co.jp/%E3%83%AA%E3%83%BC%E3%83%B3%E9%96%8B%E7%99%BA%E3%81%AE%E7%8F%BE%E5%A0%B4-%E3%82%AB%E3%83%B3%E3%83%90%E3%83%B3%E3%81%AB%E3%82%88%E3%82%8B%E5%A4%A7%E8%A6%8F%E6%A8%A1%E3%83%97%E3%83%AD%E3%82%B8%E3%82%A7%E3%82%AF%E3%83%88%E3%81%AE%E9%81%8B%E5%96%B6-Henrik-Kniberg/dp/427406932X)を読み、触発されて、大きなマグネットシートを買って来ちゃいました!

Pict2618
それを利用して、「かんばんボード Ver.2」が出来上がりました!!

これで、現実の実務・実態に合わせて、各タスクがより現実的に枠に分けられるようになったし、顧客側との連携状況も視覚化できた!
準備段階的なタスク(技術調査やデザイン面のワイヤーフレーム作成、顧客の反応・評価待ち等)も可視化(分類)できたし、直近の課題も同様。

未だタスクという粒度に落としていない、これから着手したいバックログ(と言うよりアイデア段階のモノの内、優先度の高いもの)も可視化できた。

リリースの段階も、ローカル環境動作確認済み、検証・評価環境で顧客による確認済み、本番環境への展開済みも区別できています。

「シンプル・イズ・ベスト」のケースも有るかも知れませんが、現時点まで運用した限りでは、新しいかんばんボードの方が有用なようです。

プロジェクトの性質に応じて、かんばんボードの項目や並べ方はカスタマイズ・工夫をするべきですし、ボード&運用自体の改善もなされていくべきでしょう。

全社横断的に、良い結果も、要改善点?も(有れば)共有したいと思います。

また、逆に他チームメンバーからの質問・意見出しにより、別視点での改善の機会も設定できればと思っています。

定例会で時間枠を設けて、(毎度の事ですが)なるべく多くのメンバーが参加できるよう調整したいと思います。

納期とか客先テストとか、複数チームでたまたま衝突すると、共有の意味を失ってしまいます。

やっぱり、ライブで共有して、感じて、対面で質疑するのが最高ですから!


★クリック1つでブログランキングにご協力戴けます! m(_ _)m

| | コメント (0) | トラックバック (0)

データ移行について

6月の定例会の中で出し物の枠をとっていたJinさん(6月末で業務を終了して、産休&育児休暇に入る予定だった)が、ドクターストップで定例会にも出られなくなってしまいました~~!

さあ大変!、先ずはしっかりお休みして頂くのは当然としても、定例会で空いてしまった枠はどうしよう?
.....と、まあ、それはどうにかしました...。

で、後日、本人が当日の出し物での説明用に用意していた電子文書(GoogleDocs)を、社内専用サイト上に公開してくれました!

今回は、その内容をかいつまんでアップさせて戴きます。

お題は「データ移行に付いて」

「データ移行」とは、「システムの刷新や統合などに合わせて、旧システムで使っていたデータを新システムに移すこと」と定義しました。

データ移行の主たるところはRDBMS上のデータ、という前提になります。
(これからは、或いは既に?段々と変わっていくと思いますが。
クラウド上のままで契約構成の変更、クラウドのベンダー変更、NoSQL(KVS)上での別種のストアへの移行、等々...)

RDBMSで、同じプロダクトで同じOSで、かつデータ構造が変わらないならば、当然ながら簡単な話です(スケールアップを必要とする場合などを別として)。

ただ、現実問題としては、「データ移行までして運用を続けたい(相応に儲けのある)サービスだから移行する」のだから、アプリの寿命は短くはなく、様々な負の遺産(この話の中では、特にDB周りの中で)を受け継ぐ場合が多くなります。

「小さく立ち上げて、着実に稼ぎながら大きくしていく」パターンが多いかと思いますが、特に最近の場合ほど「低コストで早々にサービスを立ち上げる(当たるかどうか分からないので)」場合が多いと思います。

当たらなかったら、早々に捨てる

当たったら、バンバン拡張していく

拡張に耐えるように、アプリもDB構造も(&テスト駆動とかリファクタリング等も含めて)考慮してあれば良いのですが、「将来を見据えてキレイに作る」のには初期コストも時間もかかります

システム寿命が長くなるのであれば「小さい内にキレイに作った方が、トータルで安くて品質も担保し続けられる」はずなのですが、「当たってしまったら、ドンドン突っ走らないといけなくなる」。

他社に真似されたら先行メリットが活かせなくなりますから、ここでリファクタリングがどうのこうのとか言い出す&実行に移すのには、相当の信念と覚悟が必要です。

しかし、「当たりまくって、システムもひたすら巨大化の一途をたどった」場合には、不毛にメンテナンス工数は食うは、システムの様々なナレッジが担当技術者依存になってしまい、人の流動(様々な要因によるでしょうが...)に合わせて、どんどん品質担保が怪しくなっていきます。

作業効率もどんどん落ちて、小手先の改善ではとても追い付かなくなってしまいます。

「ドンドン売り上げが上がる!」んだけど、「メンテ工数で巨費を食いまくるので全然儲からないー!」というケースは、業界内で結構多いのでは??...という気もします。

移行時に負の遺産を捨てる」!
これにしっかり工数をかけるべきですね(←「このシステムで儲け続けよう!、と考えるのであれば」)。

そこでチェックすべきこと、として、
・旧データ定義で表現できていた事を、新データ定義でどう表現するのか?
・表現できなくなった情報は、本当にそれでいいのか?
・新データ定義で新たに現れた情報は、何を入れればいいのか?
・アプリとデータ、両方移行が終わった時点で、ユーザが違和感を感じる部分がないか?
・新アプリでトラブルがあった場合、旧アプリへの切り戻しはあり得るか?

つまりは、
アプリの仕様も知ってないとデータ変換できない!
.....当然と言えば当然のことなんですが、場合により意外と軽視されがちな部分です。

長く実務運用されたシステムほど「隠れ仕様」や「特例処理」がたんまり存在し、困ったことに、大抵の場合にそれらは全く(もしくは殆ど)文書化されていません

なので、「仕様を理解した上でのデータ変換」と言うのは(書くのは)簡単なんですが、実務上は意外と(非常に)大変な場合が多いです。

では、このような要求に対しての見積(工数)はどのようにして行うのか?
主なキーとなるのは下記の項目になると思われます。
・テーブル数
・テーブル定義の変更量
・不正データの量とバリエーション
・関連するアプリ機能数(新・旧)
・切り戻しを考慮するか

実際の社内的な例で見ると、オリジナルのアプリケーション開発の、大体2/3~同等くらいの工数を要しています!

ここで、少なからずのお客様から「何でそんなにかかるんだ!?」という反応が返って来ます。

そんなときは、相手の方の知識や立場・関心事に応じてではありますが、
上記を順を追って説明するか、過去の事例を挙げるか、可能ならば一部分に絞って移行作業を行ってみて(或いはテーブルデータの解析&関連機能の調査・確認を行ってみて)各種の数値化をした上で実工数を測定&総工数を推測してみる、という手を使うこともあります。

このような初動を行わずに安請合いしてしまうと、会社の経営にまで影響を与えかねない痛い目を見る場合も有り得ますので、怖い・怖い!

「データ移行」をなめて掛からずに、慎重に対応しましょう!
.....というお話がされる予定なのでした!

Jinさん!、資料の作成&社内公開、有難う御座いました!


★クリック1つでブログランキングにご協力戴けます! m(_ _)m

| | コメント (0) | トラックバック (0)

« 2014年6月 | トップページ | 2014年8月 »