面白かった話

Takramの田川さん

・サブスクリプションビジネスは、結婚のようなモノ。離婚しないために頑張る。つまり、"離脱させないこと" が大事なので、相手からのフィードバックを得て打ち手を変えていく。

・イノベーションは新結合で生まれる。複数コミュニティに所属することで、新結合が起こりやすくなる。

・イノベーションは新結合と社会浸透。浸透していないのはイノベーティブなモノどまり。

2018度の収穫（完全に自分メモ）

ふと振り返ってみた。この１年で何か成長できたか。

自身のスキルアップとしては豊作でした

・スクラム導入

・swagger

・初めてのフロントエンド開発。SPA

・Vue.js

・Buefy(Bulma)

・Highcharts.js

・リーンスタートアップ

・AWS S3とCloud Frontでhttps静的サイト

・Docker

・Dockerハンズオン企画

・ピクト図解ハンズオン企画

・Node.js交流会企画

・グロースハック手法導入(ga gtm MixPanel)

・ファネル分析

・顧客開発、インタビュー

スクラムの進め方補足

認定スクラムマスターになり、社内でも実践したり勉強会を開催したりするなかで気になって調べたこと、勘違いしていたことなどを整理して備忘録として残しておくことにした。

スプリントレビューについて

プロダクトオーナーにお披露目するのではない。プロダクトオーナーがステークホルダーにお披露目する場。

受入条件（Acceptance Criteria）の確認はすでに終わっていて、Doneの定義を満たしているものをお披露目することになる。

プロダクトオーナーによる確認は、スクラムチームの一員として、随時行っているべきもの。

（スクラムガイドにちゃんと書いてありました。よく読まないといけないですね、、）

品質について

社内でよく聞かれるのが、｢品質はどう確保するのか？」ということです。

アジャイル開発は品質が悪くて、ウォーターフォールなどの重量プロセスは品質が良いモノができる、というのは誤りです。これは、Doneの定義を明確にして、ちゃんと運用しておけばよい。

とりあえず動くレベルのものをスプリントのインクリメンタル（成果物）としてしまうと、この問題が起こる。もちろん、プロダクトのフェーズや特性によっては、とりあえず動くレベルをスプリントのインクリメンタルとすることもあり得るが。

受入条件と完成（Done）の定義について

受入条件は、個々のバックログアイテムの満たすべき要件（主に仕様面）。完成の定義は、プロダクトバックログやインクリメンタルが、何を持って「完成」とするかプロジェクトルールとして定めたもの。つまり、バックログに関していうと、“受入条件を満たしていること”とか、“受入条件を満たしていることをプロダクトオーナーが確認済みであること”とかが含まれる。それに加えて、“ソースコードと、対になるテストコードがコミットされていること”だったり、“〇〇仕様書に仕様が反映されていること”なんかを完成の定義に含めることもある。

つまり、完成の定義をどう定めるか、がスプリントのインクリメンタル（および付帯するドキュメントなど）の品質に大きく影響する。

単に作るだけ、を考えたときと、完成の定義を満たすレベルを考えたときとでは、スプリントで実装できるバックログの量が大きく違ってくるので注意が必要。

スクラムのはじめ方

プロジェクトでスクラムを採用した場合、実はいきなりスプリントが開始することはない。なぜかというと、初期のプロダクトバックログがまだ無いはずだし、完成の定義も定まっていないから。

まずは、準備期間やスプリントゼロ、という位置づけで、これらを整える必要がある。

こちらのブログエントリでも少し触れました。アジャイル開発における初期設計について - jiigのREDOブログ

最低限やっておくべきことには、以下のようなものがある。

• プロジェクトの目的の明確化
• 開発言語や開発環境の選定
• プロダクトバックログ作成
• 完成の定義を決める
• ステークホルダーの洗い出しやスプリントレビューへの参加要請
• システム全体のアーキテクチャの設計
• 使用するミドルウェアやライブラリ選定
• 概念データモデリング
• スクラム未経験メンバーの教育

他にも出てきたら書き足していきたいと思います。

アジャイルソフトウェア開発宣言をかみくだく

アジャイルソフトウエア開発宣言は短い文章で完結に表現したがゆえに、ともすると誤った理解につながるため、自分なりに補足したメモ。

原文

日本語

私たちは、ソフトウェア開発の実践あるいは実践を手助けをする活動を通じて、
よりよい開発方法を見つけだそうとしている。この活動を通して、私たちは
以下の価値に至った。

プロセスやツールよりも個人と対話を、
包括的なドキュメントよりも動くソフトウェアを、
契約交渉よりも顧客との協調を、
計画に従うことよりも変化への対応を、

価値とする。すなわち、左記のことがらに価値があることを認めながらも、
私たちは右記のことがらにより価値をおく。

Kent Beck,Mike Beedle,Arie van Bennekum,Alistair Cockburn,
Ward Cunningham,Martin Fowler,James Grenning,Jim Highsmith,
Andrew Hunt,Ron Jeffries,Jon Kern,Brian Marick,Robert C. Martin,
Steve Mellor,Ken Schwaber,Jeff Sutherland,Dave Thomas
© 2001, 上記の著者たち
この宣言は、この注意書きも含めた形で全文を含めることを条件に自由にコピーしてよい。

英語

We are uncovering better ways of developing
software by doing it and helping others do it.
Through this work we have come to value:

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

That is, while there is value in the items on
the right, we value the items on the left more.

Kent Beck,Mike Beedle,Arie van Bennekum,Alistair Cockburn,Ward Cunningham,Martin Fowler,James Grenning,Jim Highsmith,Andrew Hunt,Ron Jeffries,Jon Kern,Brian Marick,Robert C. Martin,Steve Mellor,Ken Schwaber,Jeff Sutherland,Dave Thomas

© 2001, the above authors
this declaration may be freely copied in any form,
but only in its entirety through this notice.

かみ砕いてみた

個人的に気になるのが、より価値をおくことがらの4行の部分。

Individuals and interactions over processes and tools

『個人と対話を』となっているが、withではなくandなので、individuals との interactionではなく、〜およびとか〜やというニュアンス。interactionも対話というより、(対話も含む)交流とか相互作用とかのほうがしっくりくる。

Working software over comprehensive documentation

『動くソフトウェア』という訳について、誤解してしまいそうだが、executableとかrunningではなく、workingなソフトウェアです。なので、きちんと動く、機能するという意味合いが含まれていると思います。イテレーションの途中では、『なんとなく』動く、『とりあえず』動くソフトウェアで確認をしつつも、イテレーションの成果物としてはきっちりと『working』ソフトウェアに仕上げるということだと、思っています。

というわけで、“アジャイル開発では、とりあえずでいいから動くものをどんどん作って、品質は後回し”、という誤解（私の周りにはそう思っている人がいる）は、日本語版の訳から生まれているかも、という話。

アジャイル開発における初期設計について

ほぼ自分向けのメモ。

アジャイル開発と設計

もともと、アジャイル開発（私の場合はスクラム）やるとき、データベース設計っていつやるんだろう？と思ったのがきっかけです。 データベース設計も、スプリントのたびに考えるのかなぁ、でもそれはさすがにやばそうだなぁという感触があって、実際のところ答えは無いけど今の見解、というか個人的な気持ちを書いてみた。 高リスク制約という考えがあるらしい。それによると、以下のようなことは「とりあえずやっておいて、あとから考えよう」とした場合に高くつくよ、ということ。

• 言語
• レイヤ分割
• ユーザビリティ
• セキュリティ
• スケーラビリティ

データモデリングは最初に考えておくべき。ただし、完全なデータベース設計というよりは、概念データモデルレベル。 エンティティと関連、多重度のモデリングすることで、対象ドメインの整理・理解を助けることにもなる。

スプリント0

で、スクラムではスプリントを開始する前に、準備期間としてスプリント0（ゼロ）という期間を設けて、上で述べたような意思決定をしたり、技術的な調査（スパイクという）をしたり、初期のプロダクトバックログを用意したりすることがプラクティスとして存在している。 スプリントゼロで明らかにすること、決めておくことはプロジェクト問わずある程度共通にできそうなので、リスト化しておくと良さそう。

余談。ER図作成ツールだと、そもそも論理モデルと物理モデルを分けることができないものが多く（私の使った事のある範囲では）、RDBMSの制約によって必要になる「関連テーブル」まで定義することになるので困る。

これからはフルスタックエンジニアとマルチロールエンジニアになりたい

自分自身のキャリアについて、何かにすごく特化した専門分野があるかって考えたとき、個々のスキルで見たらどれも超一流では無いかもなって悩んだ。

でも、IT系の新規事業開発を考えたら、霧が晴れた気がした、そんな話です。

エンジニア→フルスタックエンジニア→マルチロールエンジニアという道です。

フルスタックエンジニア

フルスタックエンジニアとは？

システム開発のすべてを自分ひとりで行えるエンジニアのこと。

システムエンジニア、ネットワーク、データベース、サーバー構築、アプリケーション開発(フロントエンド+バックエンド)

要件定義から設計、実装、テスト、リリースを、すべてやれるエンジニアのこと。

自分に当てはめてみる

要件定義から設計、実装までひととおりやれる。スペシャルでない部分もあるができないフェーズはない。

フロントエンド開発→Vue.js、Bulma

バックエンド→ Node.js 、AWS Lambda

データベース→大好物。OracleMaster、データベーススペシャリスト

インフラ、ネットワーク→AWS、ネットワークスペシャリスト

モバイル→Android開発

デスクトップアプリ→C#.NET

うーん、ハードに近いところは難しい(RaspberryPi、Arduinoにセンサーつなぐレベルが限界)が、わりとカバーしている気がします。

マルチロール

エンジニアという職種を越えた活動。

企画、マーケティング、ユーザーインタビュー、営業、+エンジニアリングと、なんでもやれる人。

自分に当てはめてみる

• デザイン思考
• リーンスタートアップ
• スクラムマスター

これらの実践する中で、必然的にマルチロールになってきた。

単一のスペシャリストでは無い道。

新規事業をやろうとすると、最初のうち、Product/Market Fitまではコスト的にもコミュニケーション的にも、小さいチームで進める方が良い。スピードも出る。

意思決定に関わる人、邪魔する人、説明をしなければならない相手が少ないほど早く進めることが出来る。体制×期間が人件費やらの形でコストに直結するので、同じコスト内でより多くの仮説検証を回せる。

そう考えると、新規事業開発にこそ自分のスキルセットや経験が活かせると思うし、そこに必要な知識とスキルを備えれば、それはそれでスペシャリストだなぁという結論で腹落ちできた。これからの当面はそこを目指して必要なスキルを獲得していこうと思います。

同じような話を、私が一方的にリスペクトするi2keyさんのブログで見つけました。

ビジネス貢献するためのエンジニアリングの話をデブサミでしてきた #devsumi - @i2key のBlog

読書記録

せっかく読んだ本を少しずつ記録として残しておこうと思います。

2019/01/19 更新

ユーザーストーリーマッピング

ユーザーストーリーマッピング

新規事業をリーンスタートアップを参考に進めていて、プロトタイプやらMVP開発なんかのシステム開発をスクラム導入後し始めたとき、ユーザーストーリーの書き方とかもやもやしたので読んだ本。

すごく良著。

amazon 世界最先端の戦略がわかる

amazon 世界最先端の戦略がわかる

Amazonのビジネスについてはある程度知っているつもりだったが、まだまだ甘かった。意図してなのか結果的になのかは分からないが、事業戦略としてすごく興味深い示唆がたくさんある。

アントレプレナーの教科書

アントレプレナーの教科書[新装版]

リーンスタートアップ関連をざっとまとめて勉強した。そのうちの1冊。

いろいろ読んで自分なりに理解を深めるのが１番だとは思っているが、最小限で、となると、この本＋『RUNNING LEAN』を読んだあと、『起業の科学』に進むのが良いと思っている。

起業の科学

起業の科学 スタートアップサイエンス

なんというか、リーンスタートアップ全部入り、とい感じである。著者もそう言っているとおり、いろんな本を読んだが、スタートアップの全体を体系的に網羅したモノが無かったので、スライドにまとめた、とある。この本はそれらスライドの書籍版。

概念よりも、かなり具体的なやり方を中心に記載されているので、何度も参照しながら社内の新規事業開発を進めている。

リーンスタートアップシリーズ

リーン・スタートアップ

Running Lean ―実践リーンスタートアップ (THE LEAN SERIES)

リーン顧客開発 ―「売れないリスク」を極小化する技術 (THE LEAN SERIES)

Lean Analytics ―スタートアップのためのデータ解析と活用法 (THE LEAN SERIES)

最初にRUNNING LEANを読み、興味を持ったのでその他シリーズも読み進めた。

青本のリーンスタートアップと、RUNNING LEANで全体像をつかんだあと、顧客発見あたりは『リーン顧客開発』を参考にインタビューを実施し、Problem/Solution Fitを達成してMVPを有償で提供するあたりから、『LEAN ANALYTICS』を参考にKPIを追いかけるイメージで考えている。

正直、初めて読んだときはLEAN ANALYTICSは理解できなかった。だが、リーンスタートアップを読んで革新会計を学んだあとで再読すると、しっくりきた。

カイゼン・ジャーニー

カイゼン・ジャーニー たった1人からはじめて、「越境」するチームをつくるまで

アジャイル開発(スクラム)を社内で少しずつ導入した著者の経験に基づくリアルなストーリー。すごく共感できるし、これを読んで、自分もまずは小さいところから始めないと、と思うきっかけになった。

あと、ギルドワークスさんのサイトにいろいろ共感