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

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

原文

日本語

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

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

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

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人からはじめて、「越境」するチームをつくるまで

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

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

Vue.jsでHighchartを使う(しかもビルドシステムなしで）

サンプルとかあまり見つけられず、苦労したので備忘録としてメモしておこうと思います。

highchart vue.jsラッパーを入手

まず、Highchart公式GitHubリポジトリから、highcharts-vueを入手する。リポジトリ丸ごとダウンロードかcloneするが、使用するファイルは、 「highcharts-vue-master/dist/script-tag/highcharts-vue.min.js」だけです。 ※dist/module/配下にあるやつは、モジュールとしてロードする用です 　（普通はこっちを使うと思いますが、今回はタイトルにもあるとおり、ビルドシステムを使わず、htmlファイルからscriptタグで読み込むので。。。）

GitHub - highcharts/highcharts-vue

index.html（本体のHTML）

bodyタグの最後で、以下の順でスクリプト読み込み。

new Vue() する前に、Vue.useでプラグインを登録する。書き方に注意が必要です。

Vue.use(HighchartsVue.default);

※HTMLのscriptタグで読み込んでいるので、Vue.use(HighchartsVue)ではダメです

グラフ描画に関して。 Highchart公式には、さらっと1ページ書いてあるだけ（しか見つけられていない）。

Highcharts Vue Wrapper - Highcharts

こんな感じになるらしい

data() {  
  return {  
    title: '',  
    points: [10, 0, 8, 2, 6, 4, 5, 5],  
    chartType: 'Spline',
    seriesColor: '#6fcd98',
    colorInputIsSupported: null,
    chartOptions: {
      chart: {
        type: 'spline'
      },
      title: {
        text: 'Sin chart'
      },
      series: [{
        data: [10, 0, 8, 2, 6, 4, 5, 5],
        color: '#6fcd98'
      }]
    }
  }
},

ここで、chartOptionsが、チャート描画に使用するデータです。 ただし、vue.jsラッパーのポイントとして、pointsと、chartOptions.series[0].dataとに同じ値が入っている。 使い方としては、直接chartOptionsを触らずに、いったんpointsにグラフデータをセットする。pointsの変更をwatchして、変更後の値をseries.dataに代入することで、リアクティブにチャートが更新されます。。 この辺は、Chart.jsのVueラッパーであるvue-chart.jsとはアプローチが異なるので、最初は少し悩みました。 vue-chart.jsでは、mixinしたうえでreactivePropやらを使うので、どっちが分かりやすいかというと人それぞれかなぁ。

認定スクラムマスター(LSM)になりました

Scrum Inc. 認定スクラムマスター研修というものを受講してきました。さらに、そのあと受験できる試験に合格して、認定スクラムマスターとなることができました。

動機としては、独学オンリーのなんちゃってアジャイルなままではなく、きっちりと理解したものを社内外に導入したかったからです。

2023/08/04 追記: スクラムガイドも新しくなっているし、当時の僕の理解レベルで書いたものなので、ちょっと違うかな、って記述もあります。

認定スクラムマスター

スクラムマスターの認定資格には、Certified Scrum Master(CSM)というものと、Licensed Scrum Master(LSM)があります。他にもあるかも知れません。CSMのほうが昔からあるようで、日本ではスクラムマスター資格というと、こちらの方が多いようです。これからはLSMが多くなりそうですが。

LSMは、スクラムの創案者のひとりであるJeff Sutherland博士により設立されておりScrum Inc.という会社が提供しています。

https://scrum.esm.co.jp

スクラム

用語説明や詳細はたくさんサイトがあるので、簡単に自分のリマインドとして書いておく。

スクラムチーム

プロダクトオーナー(PO)、スクラムマスター(SM)、チームメンバーで構成する。

スクラムチームにとって大事なことは、自己組織化と機能横断的である、ということ。

自己組織化

チームが誰かに管理されているのではなく、自らを管理できていること。進捗や課題の管理、プロセス改善などの活動を自分たちで適切に行えていること。

スクラムマスターは、プロジェクトマネージャやプロジェクトリーダーのように管理をするのではなく、チームメンバーが自分たちで管理できるように促す。

機能横断的

スクラムチーム外の誰かに頼らずにバックログをDONEにできるチームであること。また、チーム内での役割も完全な縦割り専任主義ではなく、T字型に役割を担えることが理想(コーディング担当、テスト担当とか専任にしない)。

これは、現実はなかなか難しいなーと感じました。やっぱりコーディング出来ない人はホントにできない(やろうともしない)ので。。

ただ、機能横断的であることが理想的なことは理解、共感できる。

プロダクトオーナー

プロダクトの仕様決定者。複数人いないほうがよい。どうつくるか、ではなく『何が欲しいか』をプロダクトバックログとして定義する。

自社プロダクトではない受託開発の場合、顧客側の人間がプロダクトオーナーになるか、もしくは顧客側の要求を深く理解しているメンバーが担当する。スクラムマスターとの兼任は避ける。

スクラムマスター

スクラムがうまく機能するように支援する役割。スクラムについては一番詳しく、プロダクトオーナーやチームメンバーをコーチする(開発そのもののコーチではなく、スクラムのコーチ)。

スクラムマスターはメンバーを兼任しても良い。

プロセス

スクラムでは、スプリントいう単位で価値創造をくり返しながら漸進的に開発を進める。各スプリントの期間(長さ)は固定化する。最長でも一カ月。チームによっては、半日スプリントという短さでやっているところもあるらしい。

スクラムでは、さまざまな活動にタイムボックスという概念で制限時間を設定している。

スクラムイベント(活動)

スクラムにはいくつかのイベント、活動が定義されている。さらに、それぞれについてタイムボックスが決められている

1. スプリントプランニング
2. デイリースクラム
3. スプリントレビュー
4. スプリントレトロスペクティブ
5. プロダクトバックログリファインメント

• スプリントプランニングでは、そのスプリントで実現するバックログをピックアップする。選択したプロダクトバックログアイテムと、それらを届ける計画を合わせてスプリントバックログという。
• デイリースクラムは、前日の作業、本日の作業の確認を行う。抱えている課題や、乗り越えた課題なども共有する。毎日同じ時間と場所で行い、リズムをつくることが大事。
• スプリントレトロスペクティヴ(振り返り)では、改善案を出し合い、次のスプリントで実施する案を決める。さらにそれをスプリントバックログに加える
• プロダクトバックログリファインメントとは、スクラムガイドに以下のように定義されている。

プロダクトバックログに含まれるアイテムに対して、詳細の追加、見積り、並び替えをすることを、プロダクトバックログのリファインメントと呼ぶ。これはプロダクトオーナーと開発チームが協力して行う継続的なプロセスである。プロダクトバックログのリファインメントによって、アイテムのレビューと改訂が行われる。いつどのようにリファインメントをするかは、スクラムチームが決定する。リファインメントは、開発チームの作業の 10%以下にすることが多い。

タイムボックス早見表

スクラムガイドでは、タイムボックスは一カ月をベースに記載されている。そこから計算して、1週間の場合、2週間の場合も含めて一覧表にしたものがこちら。ここに書かれている時間は、「使って良い時間の最大値」であることに注意すること。かならずタイムボックスいっぱいまで使わないといけないわけではない。目的が達成できたらすぐ終わっても良い。逆に、タイムボックス内に収まらないときは、なぜ収まらないのかを分析しカイゼンしていくことになる。

スプリント期間ごとの早見表

イベント	配分	1週間	2週間	4週間
デイリー	15分	15分	15分	15分
プランニング	5%	2時間	4時間	8時間
レビュー	2.5%	1時間	2時間	4時間
レトロスペクティブ	1.875%	1時間	1.5時間	3時間
リファインメント	10%	4時間	8時間	16時間

リンスタの革新会計を考える

リーンスタートアップの中で、革新会計というものがいまいちイメージ出来ていなかったが、グロースハックやファネル分析について学ぶうちに、少し自分なりに腹落ちした(しかけている)ので整理しておこうと思います。

リーン・スタートアップ

まず、ファネル分析について

ターゲットが特定の行動をとるまでのプロセスを分解して考え、どこで離脱しているかを明らかにする分析手法。

"特定の行動をとる"ことを、成果達成とかコンバージョンといい、その達成率をコンバージョンレートという。

よくあるのは、webサービスのサイト訪問者が会員登録するまで、の流れをファネル分析で最適化したりする。

この場合、例えば以下のようなファネル構造と考えることができる。

1. サイトの存在を知る
2. サイトにアクセスする
3. 会員登録ページに移動する
4. 会員登録に必要な情報を入力する
5. 確認メールを受信する
6. メール本文にある認証完了URLをクリックする

このステップのどこを開始とし、どこを達成(=コンバージョン)と考えるか、はケースバイケースだが、ビジネス的な価値につながるステップをコンバージョンと置くのが良いと思う。

これらのステップのどこで離脱している人が多いかを計測することで、適切な打ち手を考えることができる。

さらに、ターゲットごとにトラッキング(追跡)できればなお良い。離脱している人たちに共通する特徴が見えるかも知れないからだ。

革新会計

リーンスタートアップでの革新会計(innovation accounting)という考えは、このファネル分析を新規事業の成長計測に使おうというものだと理解しています。

ポイントは、"数"や"売上"ではなく"率"でみるところ。ビジネスの成功につながる注目すべきコンバージョンは何かを考え、その達成率を向上させることを目標にする。つまり、"〇〇率"をKPIにする。さまざまな施策を打ちながら、KPIが狙った方向に上昇(もしくは下降)していく傾向があるかどうかで、新規事業の成長が上手くいっているか否かを判断するということ。

リアルな世界での話

上記の考え方は、リアルな世界でも適用できると思う。

例えば、サービスを売り込むときを例に考えてみる。

1. メールでアポを申し入れる
2. 日程を確定する
3. 訪問して説明する
4. 後日、問い合わせが来る
5. 契約につながる

みたいなプロセスだとして、メールの文面を変えながら、アポの成功率が上がる文面にチューニングしていく、送信相手を変える、という事が当てはまる。さらに、訪問したときの説明の仕方(プレゼンのみ、資料渡す、movie見せる、など)による変化を計測するということもやれそう。

まとめ

要は、ちゃんと指標を定めて、それをモニタリングしましょうね、という事ですね。

リクルートさんのリボンモデルについて書かれた書籍でも、『勝ち筋』や『価値KPI』という言葉が出てきていましたが、同様の考え方なのだと理解しています。

リクルートの すごい構“創"力 アイデアを事業に仕上げる9メソッド