April 2016

April 29, 2016

ブラッド・ミュージック

キーワード:
 グレッグ・ベア、パニック、パンデミック、細胞、救済
パニックSF小説。以下のようなあらすじとなっている。
伝子工学の天才ウラムは、自分の白血球をもとにコンピュータ業界が切望する生体素子を完成させた。だが、会社から実験中止を命じられたウラムは、みずから創造した“知能をもつ細胞"を捨てきれずに、体内に注射して研究所からもちだしてしまった……この新細胞ヌーサイトが人類の存在そのものを脅かすことになるとも知らずに! 奇才が新たなる進化のヴィジョンを壮大に描き、新時代の『幼年期の終り』と評された傑作
(カバーの裏から抜粋)
久しぶりにSF小説を読みたいと思っていたところ、年初に読んだ『戦略読書』にお勧めされていた本書を買って読んでみた。

あらすじは↑に示した通りで、研究者が偶然作成してしまった知能を持つ細胞、ヌーサイトがパンデミックのように世界中に蔓延していくというお話。前半戦は徐々に感染が広がっていくパンデミックものパニック映画的。主人公は特に限定されておらず、いろいろな登場人物に視点が変わる。その一人がスージーという若い少女で、家族全員が感染して別の存在に成り替わったのだが、スージーだけは元の生身の状態で誰もいない都市部を歩き回り、崩壊前のワールドトレードセンターのビルにまで行く。

この誰もいない街を闊歩していく描写は、ウォーキングデッドや28日後などのゾンビパニック映画的でもある。とはいっても感染者は別に襲ってくるわけではなく、ヌーサイトと同化して別次元の存在になりつつも元の人格を保持し、同化するように対話してくる。

結末は『幼年期の終り』的と評されているが、幼年期はオーバーロードによる世界の変革に巻き込まれる人類を描いており、あまり救いがない結末だけど、こちらはミクロの世界で人類そのものの救済のような結末になる。それが抽象的で精神的な描写が多く、情景を脳内再生するのが若干難しいのだけど。

テーマ的にも情景的にもデジャブ感いっぱいな感じがしたのは、これを元にしたと思われるアニメ、映画などが多いからのような気がする。なので、あまり驚きや新鮮味がなかった。描写はそこまで難しくはないのだけど、登場人物の視点がころころ変わるので、一気に読まないと全体像がぼやけてしまうなと。

面白くないわけでもなく、テーマ性もよいのだけど、ところどころの抽象的な描写、ヌーサイトとの対話の部分が若干かったるい感じがした。しかし、『幼年期の終わり』とともに傑作と評されるSF作品なので、読んでおいて損はないかなと思う。




読むべき人:
  • パニック映画が好きな人
  • 生物的なSFが好きな人
  • 人類の救済について考えたい人
Amazon.co.jpで『グレッグ・ベア』の他の作品を見る

bana1 ヌーサイトクリック☆  にほんブログ村 本ブログへ


April 24, 2016

リーン・スタートアップ

キーワード:
 エリック・リース、MVP、仮説検証、ピボット、スタートアップ
リーン・スタートアップというビジネスの開発手法について解説されている本。以下のような目次となっている。
  1. 第1部 ビジョン
    1. 第1章 スタート
    2. 第2章 定義
    3. 第3章 学び
    4. 第4章 実験
  2. 第2部 舵取り
    1. 第5章 始動
    2. 第6章 構築・検証
    3. 第7章 計測
    4. 第8章 方向転換(あるいは辛抱)
  3. 第3部 スピードアップ
    1. 第9章 バッチサイズ
    2. 第10章 成長
    3. 第11章 順応
    4. 第12章 イノベーション
    5. 第13章 エピローグ ― ムダにするな
    6. 第14章 動きに参加しよう
(目次から抜粋)
リーン・スタートアップというのは、『リーン(lean)』、つまり「余分な肉がなく細い」意味の語源からきているビジネス上の開発手法であり、元シリコンバレーのエンジニアである著者によって提唱された。詳細については以下参照。ソフトウェアの世界では開発手法としてアジャイル開発手法がある。本書そのものは、どちらかというと著者のアジャイル開発経験をもとに、プロダクトそのものの開発や企業の在り方までに対象を広げ、起業という分類にとどまらず、企業の規模や発展段階を区別せずアントプレナー的に何か製品開発をする人に向けてリーンスタートアップとして再定義されたものとなる。

著者はインスタントメッセンジャーの開発をするときに、事前に練った事業戦略と製品開発の無駄をなくせるはずだ、と信奉していたアジャイル開発手法で作っていった。しかし、そもそもの仮説が間違っており、実際の顧客となる人に使ってみてもらったところ、顧客が欲しいと思っている機能ではなく、6か月分に及ぶコード量は無無用の長物となってしまった。その経験から、リーン・スタートアップの中核として以下が示されている。
リーンな考え方における価値とは顧客にとってのメリットを提供するものを指し、それ以外はすべて無駄だと考える。
(pp.69)
言われてみれば、まぁ、そうだよねと思うのだけど、実際に製品開発時の始まりでは何が顧客にとっての価値か、メリットか?などは分かるものでもない。なので、以下のように仮説と検証を随時やっていくことが重要になるようだ。
 一番のポイントは、どのような業界であれスタートアップは大きな実験だと考えることだ。「この製品を作れるか」と自問したのでは駄目。いまは、人間が思いつける製品ならまずまちがいなく作れる時代だ。問うべきなのは「この製品は作るべきか」であり「このような製品やサービスを中心に持続可能な事業が構築できるか」である。このような問いに答えるためには、事業計画を体系的に構成要素へと分解し、部分ごとに実験で検証する必要がある
(pp.79)
検証には定量的にデータを取っていく必要があるようだ。

そして、次のステップで構築フェーズに入り、実用最小限の製品(minimum viable product)、通称MVPを作っていく。これは、最小限の労力と時間で開発できるもので、最低限必要な機能のみを実装し、すぐに顧客に見せて反応を得るというフェーズである。XPなどの開発手法ではYou Aren't Going to Need It.(必要なことだけ行う)やオンサイト顧客ですぐ見せられる状況にしておくなどが近いプラクティスとなる。

そもそもなぜ本書を読んだかというと、転職してそうそう所属部署での新規事業プロジェクトの中核要員としてアサインされて、このリーン・スタートアップの考え方で行こう!!となったので、プロジェクトメンバーの共有認識としての必須図書となったからである。2011年提唱なので、あまりまだ一般的に浸透していないのもあって、あまり知らなかった概念ではあるが、XPベースのアジャイル開発を少し経験したことがあり、ケント・ベック本を読んだことがある身としては、割とすんなり受け入れられる概念だったと思う。

ただアジャイル開発手法は、ある程度要件が固まっているもの(もちろん変化を受け入れつつ柔軟に対処するのが前提だけど)に対して『どう作るか?』に主眼に置いているが、リーン・スタートアップはどちらかというとビジネスモデルやアイデアの部分の『何を?』をメインで扱っているのが異なる。そのため事業がある程度進んでスケールできず収益が見込めないとなると、思い切って『Pivot(方向転換)』が必要になってくる。そういうソフトウェアの開発とビジネスの開発の微妙な違いがあったりする。

本書の内容自体は著者の実体験やその他シリコンバレーのさまざまな企業の事例が載っており、その辺は参考になるが、ボリュームが多く、一気に読まないと内容を忘れてしまいがち。あとは図解が少なく、全体像を把握するのに若干時間を取られる気がする。

まだ転職して2ヵ月も経ってはいないのだけど、こういう新規事業に携われるチャンスが巡ってきた。転職活動中に『Yコンビネーター』を読んでいたのも影響してそこに引き寄せられていったのかもしれない。さらにもっと言えば、Yコンビネーターを読むきっかけとなったのは今年の年始に読んだ『戦略読書』であり、ここからリンクして今に至っている気がする。ちなみに『戦略読書』にも本書『リーン・スタートアップ』が起業・応用編として取り上げられている。

まだプロジェクト自体は始まったばかりで、要件定義や仮説を設定している段階で、MVPを回すまでに行っていないのだけど、いろいろな経験が積めそうで不安よりも期待のほうが上回っている。社内ベンチャー的でもあり、大変なのは間違いないが、ここでビジネス観点でもシステム開発観点でも経験値を積んでおきたい。

類似のリーン・スタートアップ本はいろいろあるが、オライリー社から出ているものがより実践的、システム開発よりの内容のようなので、こちらも合わせて読んでおきたいところ。

直近1年、このリーン・スタートアップを基本に新規事業を回せていけるかどうか、確かめていきたい。



リーン・スタートアップ
エリック・リース
日経BP社
2012-04-12

読むべき人:
  • リーンスタートアップについて知りたい人
  • アジャイル開発を経験したことがある人
  • スタートアップビジネスをやりたい人
Amazon.co.jpで『リーン・スタートアップ』の他の本を見る

bana1 リーンクリック☆  にほんブログ村 本ブログへ


April 15, 2016

【祝】ブログ10周年

本日でブログ開始から丸10年経過しました。つまり、10周年記念となります。

はじめから10年も続けるつもりなど毛頭もありませんでした。そもそも、このブログの開始時期、ちょうど社会人になりたてのころは、おそらく人生で一番どん底であった時期でもありました。社会人になりたての頃、初めての東京生活、若干の不安もありながら未来に対する希望を抱いていたときに、父親との死別と同時に腎臓病の発覚、そしてそれが不治の病の宣告であり、食に付随する各種イベントに制限がかかって、何もかもが暗転してしまいました。当時思っていたことは、これからどうやって生きていくべきか?そもそも僕には未来がないのではないか?という茫漠とした不安に飲みこまれていき、自分自身も未来も見失っていたときでした。

もともと読書ブログ自体はやってみたいとは思っておりました。そのときに日記的な雑記ブログと分けることを意識しました。ブログを始める動機づけの一つの理由は、アフィリエイトで儲けようと思っていたことでした。結果的に10年続けてみて、お金にはほとんどなりませんでした。そもそもアフィリエイトはアクセス数がすべてであるので、この弱小ブログでは普通に働いたほうが効率がよいということがわかりました。それでも、この10年、辞めずに本を読んで、書いてということを繰り返し、今日までに806冊更新することができました。

10年で約800冊という数字については多い、少ないといった基準は人それぞれあると思われます。単純に読むだけであれば、そこまで多い数字でもなく、難しくもないでしょう。しかし、振り返ってみると800冊について書くというのは、やってみると案外大変だったなと思いました。毎回1000〜3000字ほどの文量で書いておりました。少し難解な本になると、何をどう書くべきか?とキーボードを打つ手が止まることも多かったですが、なんとか書き続けられました。

続けられた理由には、本が好きだったというのが第一にあり、また書くことも好きであり、得意だと思い込んでいたからだと思います。それでも、更新し続けられた一番の理由は、一冊読んで書くごとに自分を生かし続けることにつながったからだと思います。心身共にぐちゃぐちゃになって破綻しかけていたときに、生きることそのものが苦行のように思えて仕方なく感じ、そのために本に救いを求めていた側面がありました。やはり本に救われたというのがって、それと同じ経験をネット越しのどこかの誰かに届いたらいいなという気持ちもありました。アフィリエイトではまったく儲かりませんでしたが、このブログのおかげで何とか生き続けられたことが一番よかったことだと思います。

他にも続けてよかったなと思ったことは、このブログをきっかけにリアルの世界でも人間関係が大幅に広がったことでした。25歳ごろに結成した同世代の集まりである83年会であったり、スゴ本オフに参加しはじめたりしたことによって、普通に会社と家の往復をしていたらまず出会わなかった人たちと関係を築くことができ、自分の生活が精神的に豊かになったというのは間違いありません。この部分に関しては、ブログを続けて人生が好転したと言っても過言ではないでしょう。リアルで会う人の刺激を受け、読む本もだいぶ変わっていきました。その点に関しては本当に感謝しております。

そして、何よりもbookdiaryとURLに設定している通り、このブログは個人的な読書日記でもあり、社会人になりたての22歳からの10年間の成長記録でもあります。10年前の自分と比べて何かが劇的に変わったという実感はあまりありませんが、いかに生きるべきか?に思い悩み、迷い、途方に暮れて、自分の抱える内在する不安と向き合って、読んで、考えて、書いて生き延びてきたという自負はあります。この10年があるから、今後のどんなことが起こっても何とかサバイバルしていけるだろうという自信のようなものは得られたかもしれません。

そして10年書き続けたことによって文章力も大分向上したのではないかと思います。今でもうまく書けたと思うことは少ないですが、それでも一般的な人よりも書いた絶対量は多いだろうと思います。また、仰々しく『賢者』とブログタイトルに設定しておりますが(一応名前が賢なので)、そのような存在になれたとはとても言えません。それでも10年前よりも教養や知恵を身に付け、賢くなったと思い込んでおきたいところです。

このブログはlivedoorのサービスが終了したり、僕が死んでしまったりしない限りは続く想定です。そして今後のこのブログの可能性の一つとして、物理的に具現化するという構想(妄想)もあったりします。それはおそらく早くて次の10年後くらいに実現できたらいいなと思う次第です。どうなるかはわかりませんが、それも将来の楽しみの一つとして、淡々と更新し続けられたらいいなと思います。

また、10周年記念パーティーのようなものをやれたらいいなと思ったりもしますが、人が集まらない可能性があるので微妙なところであります(笑) もし開催されたら参加したいという人がいたら※欄などにでも表明どうぞ。実際にやるかはわかりませんが。

最後にこのブログが誰の役に立っているのかあまり実感がありませんが、それでもウォッチしてくれている読者の方々。そしてリアルの人たちに感謝いたします。ありがとうございます。

1458914214165

bana1 10周年クリック☆  にほんブログ村 本ブログへ


April 03, 2016

はじめよう! 要件定義

キーワード:
 羽生章洋、要件定義、開発、画面遷移図、システム
システム開発における要件定義のやり方がわかりやすく示されている本。以下のような目次となっている。
  1. 第1部 要件定義って何だろう?
    1. 要件定義=要件を定義すること
    2. 要件定義の基本的な流れ
    3. 定義すべき要件の内訳
    4. 3つの要素の定め方
  2. 第2部 要件定義の詳細
    1. 要件定義、その前に
    2. 企画を確認する
    3. 全体像を描こう
    4. 大まかに区分けしよう
    5. 実装技術を決めよう
    6. 実現したいことを整理整頓しよう
    7. 利用者の行動シナリオを書こう
    8. 概念データモデルを作る
    9. UIを考えよう
    10. 機能について考えよう
    11. データについて考えよう
    12. 要件定義の仕上げ
    13. 要件定義、その後に
(目次から抜粋)
要件定義をやろう!!と思い立った時に、今まで下流工程メインでしかやってこなかったので、要件定義のような上流工程は未経験で、はて、何をどうやればいいんだろう?と思ったので、買って読んでみた。

要件定義ってそもそも何?というところから始まって、要件定義の基本的な流れ、定義すべきことなどがイラスト付きで170ページほどでコンパクトにわかりやすくまとまっている。

そもそもシステム開発での要件として必要なことが以下のように示されている。
プログラマがソフトウェアを完成させるために必要な情報
(pp.18)
そして、これの元ネタがUI、機能、データとなり、それらを決めることが要件定義でのやることと示されている。なので、完成させるシステムのゴールから逆算して以下の順番でそれぞれの内容を決める必要がある。
  1. UIを決める
  2. 機能を決める
  3. データを決める
しかし、要件定義の準備段階が重要になってくる。何をやるべきかは省略して、それらを実施していれば、その成果物と以下が手元に揃っている状態であると。
  • 企画書
  • 全体像(オーバービュー)
  • 利用する実装技術
  • 実現したいこと一覧(要求一覧)
  • 行動シナリオ
  • 概念データモデル
3月に転職してから受注側から開発ベンダーに依頼する発注側の立場となった。僕の事業室の内部IT要員は実質自分1人だけなので、内部の要件とベンダーの橋渡しをうまくやらなければいけないという状況。要件定義が重要なのは身に染みているので、なんとなくこんな感じでよろしく!!と言ってベンダーに丸投げしてまともなシステムができるわけがないことは言うまでもない。

なので、自分である程度要件定義に近いことを内部でやっておく必要がある。まずはこの準備段階をきっちり決めることだな。案外ないものがある。企画書とか全体像とか要求一覧とか行動シナリオとか概念データモデルとか、というかほぼ全部ない!!wこのあたりをしっかり分析して用意しておいて、そこからようやく外部ベンダーにこんな感じで、と依頼できるかな。

発注側も要件定義の内容としてのUI、機能もある程度洗い出し、完璧とはいかないまでも考えるネタとして資料化、そんで外部ベンダーに引き渡して、外部ベンダーにブラッシュアップしてもらうことで要件漏れや手戻りもある程度防げるのではないかと思う。まぁ、ビジネススピード優先でかつ内部のIT要員が自分1人の状態というのもあったりでどこまでできるかはわからないけど、ここまでは意識としてやっておきたい。

理想は発注元もデータを決める、つまりDB設計までやればよいが、ここまでになるとUI、機能を決めるよりもより複雑になってくるので、外部ベンダーに投げてもいいのかなと思ったり。理想は完全内製化でDevOpsで行きたいところなのだけど、実際そんなことができないから外注するしかないのだけどね。

また、以下のDainさんの記事がとても勉強になるので、一度読んでおくとよい。本書は著者の携わった案件から、最近はやりのアプリやゲーム開発も考慮された内容となっている。要件定義の漠然としていた内容がすっきり整理されて、明日からの自分のタスクが明確になった。受注側の特に上流工程をやる人は読んでおくべきだし、発注側のベンダーとのやり取りをする人も絶対読んでおいた方がいい。すべては糞システムにしないために。




読むべき人:
  • 受注側の上流工程要員の人
  • 要件定義についてわかりやすく知りたい人
  • 発注側でベンダーとやり取りする人
Amazon.co.jpで『要件定義』の他の本を見る。

bana1 要件定義クリック☆  にほんブログ村 本ブログへ