ふくだ学習録とは？
ふくだが学習したことの備忘録。
目に見える形で残すことによってやる気を出す個人的な作戦です。
他人に見せるように書いているわけではないので、すごく読みにくいです。
読了した本
データベースエンジニア養成読本 [DBを自由自在に活用するための知識とノウハウ満載!]
ゼロから作るDeepLearning
PHPフレームワーク CakePHP 3入門
SQLアンチパターン
Docker入門
PHPフレームワーク Laravel入門
今読んでいる本
第8章 所有から利用へ - あらゆるビジネスに広がる成長機会
金融業界
これまでの銀行では、顧客との関わり方はリアルな銀行の窓口ぐらいしか考えていなかった。
そのため、デジタルのみで完結するサービスは全業務の内7%ほどしかなかった。
今は様々な業務をデジタル内で完結させるサービスが多く出てきている。
第9章 企業がサブスクリプション・モデルを選択するとき
サブスクモデルへの移行時は、社内で批判・不安の声が上がる
企業としてサブスクリプションモデルへ移行するとき、社内からは批判・不安の声が上がることになる。
例えば、マーケティング部門は発売日に向けた集中的なキャンペーン告知方式をやめなくてはならないし、開発部門は制作スケジュールを一から立て直さなくてはならない。IT部門も、多額の資金を投資したシステムを作り直さなくてはならないかもしれないから。
サブスクモデルを根付かせるには
ゲームプレイヤーが「顧客」となることを認識させ、チーム体制や意思決定方式を変更しなければならない。
開発チーム
「作って売る」という考え方をやめなければいけない。
「ユーザーが必要な体験を提供する」という考え方を持って、それに徹していくことが求められる。
財務チーム
顧客獲得コスト、生涯顧客価値、年間定期収益、顧客1人あたりの平均収益をメトリクスとし、プライシング（価格設定）、パッケージング、アクセス解析などのオペレーションメトリクスを行なっていくことが求められる。
ITチーム
これまでのITチームは、業務の標準化による効率向上を求めてきた。
サブスクモデルとなることで、顧客との情報を管理するだけの部門から、イノベーションを起こすためのアイデア源と変わっていくことが考えられる。データを活用しイノベーションを起こせる様になろう。
営業・マーケティングチーム
見込み顧客から優れた情報を多く手に入れることができると認識して行動していくことが求められる。
チームの壁を壊すことが重要
これまでの製品ファーストでのビジネスでは、製品ラインを中心にしているため、本来一丸となる各チーム（開発、財務、IT、営業など）がバラバラになってもある程度機能していた。
ただしこれからの顧客ファーストのサブスクモデルへ移行していくには、各チーム全てが「顧客に素晴らしい体験を産むためにはどうすればいいのか？」という視点で行動していくことになるため、チームを1つにまとめ直さなければいけない。
第１０章 イノベーション 永遠のベータ版にとどまれ
BETA版の概念を変えたGmail
今までBETA版とは「最終的な準備が整う前に、顧客利用を通じてフィードバックを集める、未完成のプロダクト」という認識だった。しかしGmailは「最終的な製品」という概念を無くしてしまった。Gmailチームは「自分たちが作っているものは静的なものではなく、生きて呼吸するもの。最終的な製品というものは無い」という考え方に気づかせてくれた。
アジャイル・ソフトウェア開発宣言
２００１年にユタ州に集まった開発者グループによってまとめられたもの。
①プロセスやツールよりも個人と対話を
②包括的なドキュメントよりも動くソフトウェアを
③契約交渉よりも顧客との協調を
④計画に従うことよりも変化への対応を
今日の一言
特に最後の、アジャイルソフトウェア開発宣言の②は刺さった。
ソースコード自体も完成品が無いのだから（常にBETA版なのだから）ドキュメントを完璧に作ることを求めなくていい。それよりも製品を動かすことが重要。って感じかな？
ドキュメントは最低限にして開発していこう。