カイゼンにっき。

@hyokota です。主にtwitterに呟いていますが、twitterに書ききれない事をここに綴って行こうかと。

人が陥りやすい罠と闘うために、ルールというベースラインを 〜 横浜道場番外編 「Challenge our Product Development's Assumption Change! ~ adapt PDAC to PDCA ~」に参加して〜

こちらに参加しました。

横浜道場 特別編 「Challenge our Product Development's Assumption Change! ~ adapt PDAC to PDCA ~」 - アジャイルサムライ読書会 横浜道場 | Doorkeeper

プロジェクトを円滑に進めることを、かなり高い視点から考える機会になりました。江端さん、皆様ありがとうございます！

以下に私なりの解釈をまとめます。
# もはや聞いた話と若干違う気も。。。

人が陥りやすい罠と闘う

「プロジェクトの成否ってのはなァ・・・仕組み次第なンだよ」

スクラムは人が陥りやすい「罠」の解決を目指すフレームワークとも言える。
スクラムを選択しない場合も、下記の罠と闘う仕組みを考えよう。
そして、他にも罠はたくさんあるので、日々の中で見つけていこう。

◇考えを知り合おう！

自分と相手の「当たり前」は違う。そして、考えの違いを知ることは成長の鍵だ。
だが、自分と相手の考えをどう知り合えばよいのか？
人は、「相手に確認してみる」ことをしない傾向がある。

※スクラムには、確認し合うための仕掛けがたくさんある！

◇常識を疑え！

皆が「常識」と思っている部分を工夫できれば、 劇的な改善が得られるかも。
でも、「常識」は中々再考しないもの。

◇改善をしていこう！

改善の重要性は誰でも知っている。
だが、日々の雑務（改善以外の行動）に忙殺されがち。

我々にとっての成功とは何だろう

プロジェクトの成功とは何か？一緒に考えよう。

黒字化？納期内にシステム完成？顧客の要求を満足すること？それとも、メンバーが楽しむこと？成長すること？

そしてその中で、本当に大切なものはどれ？*1

ルールというベースライン

ルールはプロジェクトの成功に必要か？答えはYes。
ルールを作らないこと = 柔軟 ではない。
ルールはベースラインになる。適切なルールは、柔軟に改善していくために必要。

特に、働き方のルールは、話し合われることは少ないが、プロジェクトの最初に決めるべき。働き方を話合うベースラインになる。

プロジェクトの成功の定義を満たすため、人が陥りがちな罠の解決するために、ルールを考えよう。

◇気をつけよう：常識を疑え！

…いつの間にか、ルールが常識になってしまっていないか？本当にそのルールは必須か？
人の陥りやすい罠がここにも！

Challenge our Product Development's Assumption Change!

*1:1か0かで言えるものでないので、トレードオフスライダーとか便利ですね。

価値創造の迷路から抜け出すために 〜独創はひらめかない を読んで〜

共通部門に在籍しているものの、何をやれば価値を提供できるだろう、と思考の迷路にいる私が、「独創はひらめかない」を読んで琴線に触れた点の一部をまとめてみる。

以下は、一番心に残った部分の引用。

そのアイデアを同僚やスポンサーに説明する場面を想像する。
皆が「すごいこと、考えたなあ」と驚いた顔をする。
その場面が鮮やかに思い浮かんだら、いいアイデアだ。
しかし、「説明しても、あまり納得する人はいないだろうな」
と思うときは、あまりいいアイデアではない。

いろいろ見直せて、やる気も出て、よい本だと思います。

独創はひらめかない―「素人発想、玄人実行」の法則

独創はひらめかない―「素人発想、玄人実行」の法則

素人発想

ごく身近にある問題に対して、純粋にこうあってほしい、という思いをスタート地点にする。アイデアは出やすくなるし、具体的な目標があるので、「研究が有用な場面を探し求める」必要もない。

思い切って簡単化

本質的部分を除いて「省略」する。最も価値がある研究は、価値ある部分問題を解決する、ちょうど十分な研究である。本質理解の試金石として、論文のメッセージを1つに絞り込めているか確認する。現在の部分問題をちょうど示す、よい例題を作れるとよい。

やりきってみる

周りの目を気にせず、楽天的にやりたいことをやってみる。ためらわずにやりきることで、「何が困難か」わかるようになる。

私がアジャイル崇拝をやめてウォーターフォールを愛するようになった7つの理由

アジャイルがダメだと思う7つの理由 - arclamp
にインスパイアされて、自分なりの考えをまとめてみました。一部SI前提で書いています。

制作（および詳細設計・結合テスト）フェーズの全体スケジュールを見通しやすい

確かに、全体スケジュールの完全なコミットメントは不可能です。しかし、少なくとも、信頼性の高い見通しは必要です。そもそも予算が下りません。顧客側組織の予算編成・執行体制を変えるべきだ、何て寝言を言えるはずもありませんし、見通しもなしに予算を出すべきだとも思えません。

ウォーターフォール型の開発プロセスでは、開発プロジェクトの大部分を占める制作（および詳細設計・結合テスト）フェーズの全体スケジュールを、先行する計画・設計のフェーズでじっくりと吟味します。

ウォーターフォール型の開発プロセスは、問題があった時に調整が効かないかのように言われています。しかし、ウォーターフォールにはフェーズゲートがあります。想定よりも制作が難しいようであれば、単に制作フェーズに進まなければよいだけです。もし技術的な不確定要素があるならば、設計フェーズにおいて「スパイク」を行ったり「重要なユースケースを1, 2個実装」したりすればよいはずです。

アジャイルな開発では、実際に数イテレーション回した結果としてのベロシティと、リリースまでに実現したいストーリーポイントの総計を元に、全体スケジュールを立てる形かと思われます。しかし、ベロシティは所詮「まだ作っていないフィーチャ」とは直接関係のない実績にすぎません。作っていないフィーチャについては、まだ大した設計すら行っていないのです。想定していなかった技術的な困難が存在しない保証は、どこにもありません。

必要充分なアーキテクチャを吟味できる

システム全体の段階的詳細化を繰り返せば、必要充分なアーキテクチャを構築することが可能となります。必要以上に緻密でもなければ、YAGNIと無責任に叫んで、明らかに必要な部分を後回しにするわけでもありません。

アジャイル型の開発では、アーキテクチャを充分に吟味する前にいくつかのフィーチャを構築しがちです。これらは後々技術的な「sunk cost」となり、最適なアーキテクチャの実現を妨げる可能性があります。

もし実際に実装を行ってみないとアーキテクチャの妥当性が分からないのであれば、事前にコアドメインだけを実装してみる、などの手段もとれるはずです。

ステークホルダ間の利害関係の調整をじっくり行うことができる

ステークホルダ間の利害関係の調整は、非常に重要かつコストも高く、失敗しやすいポイントです。じっくりと調整し、明文化し、何度も推敲と議論を重ね、全体のコンセンサスを得る必要があります。そして、そのコストの高さから、何度も行うのは得策とは言えません。

アジャイルな開発では、この困難な部分を、お金を支払う顧客（PO）に一任し、短いタイムボックス毎のアップデートを要求します。「ステークホルダ間の利害関係の調整」を「（例えば）2週間おきに」「顧客が」行う。これは現実的とは思えません。

開発チーム側に顧客プロキシを立てる、といった代替案もありますが、社外の人間が利害関係の調整を行うと、ますます調整のコストは高くなります（というより、大抵は不可能ではないでしょうか）。

責任の分担・階層化ができる

システムの全体が見通せて、必要な仕様が決まっていれば、適当な単位で各チームに責任を分担出来ます。問題が発生した場合も、どのチームが何をすべきか/すべきだったかは明確です。また、これによりオフショア・ニアショア開発が可能になります。これは大きなメリットと言えるでしょう。

特に大規模な開発では、このような分担なしには、プロジェクトのカオス化を防ぐ事は困難です。「自己組織化チーム」の集合では、プロジェクト全体として上手く回っているかどうかは、誰が担保するのでしょうか。プロジェクトリーダーでしょうか。各チームに自律的に行動してもらっているのに、どうやって担保するのでしょうか。カオスに陥りそうです。うまく回るイメージがわきません。

出来る人もいるのかもしれません。しかし少なくとも、自分がこのプロジェクトリーダーになると思うと、胃に穴が開きそうです。

並列度を高めることができ、完成された製品を素早く提供できる

前項と関連しますが、分担出来れば開発の並列度を上げることができます。これにより、完成した製品をいち早く顧客に提供することが出来ます。

※もちろんチームが増えるほど複雑度は増すので、CIや全体での定例mtgなどは必要で、線形オーダで効率が上がる事はないでしょう。

よく言うアジャイル型開発の「迅速なデリバリー」は、全体の一部分のデリバリーに過ぎません。エンタープライズなシステムは、一部分だけでは利用価値がない場合がほとんどです。また一部分だけを先行導入してしまうと、後々データ移行等が苦しくなります。そもそも、先行導入したシステムの運用は誰が行うのでしょうか。その後、インクリメントがリリースされるたび、運用方法が変わって行くのでしょうか。

リーンスタートアップのbuild-measure-learnのループを回す、という話もあります。しかし、エンタープライズなシステムで、短いループで「システムの価値」を継続的に検証していく必要があるのでしょうか。事前の検証で十分な場合の方が多いのではないでしょうか。

洗練された形式知が手に入る

ウォーターフォールのフェーズゲートは、ほとんどの場合「形式知（大抵は仕様書などのドキュメント）」を要求します。フェーズゲートをくぐりぬけるうち、これらの形式知は何度もレビューされ、洗練されていきます。

「洗練された形式知」の存在は、人やベンダーを交換可能にします。これは属人性・べンダーロックインの問題を解決します。また、プロジェクト毎にこのような「洗練された形式知」が生成されることは、標準化の実現や、ノウハウ・ベストプラクティスの蓄積など、組織としての成長を支援します。

アジャイル型の開発では、知見はチームメンバーの中に暗黙知として蓄積します。確かに暗黙知は形式知よりも「帯域幅」が広く、近視眼的には効率もよいです。しかし、上記の理由から、大抵のSIerでは「洗練された形式知」を選ぶのではないでしょうか。

というより、大抵のSIerには既にこのようなノウハウが蓄積されています。これらを放り投げてまで、新しい開発手法を適用するほどの価値があるのでしょうか。

専門分野の単位で作業分担ができる

アジャイル型の開発を行うのであれば、開発チームはユースケース単位（あるいはストーリーでもフィーチャーでも呼び方は何でもよいです）で開発することが必須といえます。よって、コンウェイの法則から、チームは職能横断型であることが望ましい、という結論が導かれます。

しかし、職能横断型のチームというのは、基本的に組織として管理しづらいです。メンバーが抜けたらどう補充するのでしょうか。それに、薄く広く知っている開発者よりスペシャリストの方が、ある特定分野では明らかに技量が上です。こういったスペシャリストの個性を活かすことこそが、組織の強みにつながるのではないでしょうか。

追伸

はてなブログに若干悪戯されましたが、本日は4月1日です。私の中に新しいペルソナを生み出して記事を記述してみました。とはいえ、（若干知ったかぶり感はあるものの）内容は真面目に書いています。

私の2013年 2月のツイートを適当にまとめてみる

まとめ

2013年 2月のツイートをまとめた備忘録。グルーピングは非常に適当。

主な参加イベント

実践メモ






energize








agile








devsumi 2013






devlove たのしい自分戦略


ユーザーの本質的要求からビジョンを描き提案する - OpenCU

junitbook


chef


DDD・GOOS

validation borad

ITS


ビジネス・SI







諸々








その他


私の2013年 1月のツイートを適当にまとめてみる

まとめ

2013年 1月のツイートをまとめた備忘録。グルーピングは非常に適当。

主な参加イベント

ツイート



Noから始める。毎回根拠を確認し、なくなったら自動でやめられる仕組みづくりが大切。


多様性重要

ボーイスカウトルール



ボーイスカウトルールは楽しいですし、initialコストゼロです。強くお勧め。

リーンスタートアップまわり




KPIを決めるのは、とてもとてもスキルが要る。

雑感


「怒り」がスーッと消える本―「対人関係療法」の精神科医が教える自分の小さな「箱」から脱出する方法

アカギ コミック 1-26巻 セット (近代麻雀コミックス)

アジャイルになる、系のおはなし


アジャイル導入！とか、その時点で少しもアジャイルじゃないし。


最初あった志は、ともすると簡単に忘れられて手段だけが残る。


赤いピル = いわゆる破壊的イノベーション（だと理解している）

Scrum Regional Gathering 2013



目から鱗が落ちる講演（これだけでも十分すぎるほど凄い）は何度かあるが、感動する講演はなかなかお目にかかれない。
アジャイル開発とスクラム 顧客・技術・経営をつなぐ協調的ソフトウェア開発マネジメント


直観的に、そしてこれまでの経験則からして、これは絶対正しいと思う。


改善って、そもそも目指すところはある程度理解できている前提。


パターン



今、パターンが（私の中で）とても熱い。
Organizational Patterns of Agile Software Development

SIerなど




手近な不満点に反応的になるだけでは籠の中の鳥。
システム思考、ビジネス全体の理解、それと大前提の自己マスタリー。
このあたりがカギか？

学習する組織――システム思考で未来を創造するビジネスモデル・ジェネレーション ビジネスモデル設計書

プラクティス


「幸福度」は間違いなく重要な指標。


「やりたいこと」って放っておくと無尽蔵に増えて、次に何をやるかについて「分析麻痺」状態になりがちですので。
（こうなると、経験上誰かに言われた「緊急に見える」タスクに隷属することになりがちで、これは悲惨・・・）


これも実践の積み重ねかなー。

その他


これは酷い。


やっぱ4だな。


ご存知の皆様はよろしくお願いします！

イテレーション毎に価値ある成果を届ける 〜アジャイルサムライ読書会　横浜道場　「現場で実践する」に参加しました #agilesamurai #横浜道場 〜

アジャイルサムライ読書会 横浜道場 「現場で実践する」 - アジャイルサムライ読書会 横浜道場に参加させて頂きました。

下記、勉強会にインスパイアされて、私が学んだ/感じたことのまとめです。
※例によって、勉強会のまとめではなく、内容のごく一部にしか触れていないことにご注意を。

アジャイルサムライ横浜道場にご興味を持たれた方はこちらをチェック！

イテレーションのゴール = 顧客に価値ある成果を届けること

「イテレーションのゴールは、お客さんに取って価値ある成果を届けることだ。」
本日は、これまで何気なく読み飛ばしてしまいがちな一文に引きつけられました。

  • 「設計書」のような、その時点では何者でもないもの
  • 納品出来ない品質のコード

ではよくない、というのはもちろんなのですが、

  • それだけでは何も生み出さない「機能」
  • もう1イテレーション実施すれば、価値を生み出すであろう「中間物」
  • とりあえず動くソフトウェア

でも充分でない。そして、もっとも重要な点として、下記を感じ取りました。

  • たとえ、「ストーリー」を実現するフィーチャーを作っても、「お客さん」に「価値」を届けなかったら意味がない。

お客さんは誰なのか、この1イテレーションの間に、「価値」を届けるにはどうすればよいか。その中でも最も優先度の高い価値は？一文から改めていろいろと考えさせられました。

※私は、何となくふわっとした「とても抽象的な」レベルの「顧客」が、「もしかしたら必要かもしれない」何かをする、そんなレベルのストーリーを記述しがちだったで、よい学びとなりました。具体的な顧客像、具体的な顧客の課題感（の仮説）が大切。

必要なとき、必要な分だけ

いち早く価値を届ける為には、早すぎる最適化を防止し、「選択と集中」を行う必要がある。
分析やバックエンドの準備は、必要なとき、必要な分だけ。

必要なとき

必要性を感じた時がそのとき

  • 「DB」も、必要が生じたタイミングでアーキテクチャジャンプをする、のがよい？
必要な分だけ

分析なら、プランニングポーカーで、見積もりのコンセンサスが得られる程度の分析。

  • つまり、チームのレベル、ドメインやアーキテクチャへの習熟度にも（もちろん）依存。 画一的な方法論（常にモデル書こうぜ、とか）はよろしくなさそう。

参考図書

アジャイルサムライ−達人開発者への道−アジャイル・ユーザビリティ ―ユーザエクスペリエンスのためのDIYテスティング―Running Lean ―実践リーンスタートアップ (THE LEAN SERIES)User Stories Applied: For Agile Software Development (Addison-Wesley Signature Series (Beck))

開催頂いた @tw_takubon さん、皆さん、素晴らしい場を設けて頂きありがとうございます。

モックの本当の価値とは？ 〜『JUnit実践入門』写経・実践会 in 横浜#3 #junitbook に参加しました〜

『JUnit実践入門』写経・実践会 in 横浜 #3 - connpassに参加させて頂きました。

下記、勉強会にインスパイアされて、私が学んだ/感じたことのまとめです。
※例によって、勉強会のまとめではなく、内容のごく一部にしか触れていないことにご注意を。
※そして、開催者によるこれ以上ないクオリティのまとめ記事はこちら。

次回の募集も始まっているので、ご興味をもたれた方は是非！

モックとスタブの違い

「モック」のためのライブラリを用いて、「スタブ」的なことも問題なく実現できる（特にMockitoのようなlenient mock）ので混同しやすいが、役割も注目点も違う。

モックの価値とトレードオフ



モックの本当の価値

モックを用いる事で、SUTと依存オブジェクト（これをモックにする）の、今注目すべきやりとりに集中し、テストとして定義することが出来る。これはどのような価値を生み出すのか。正直なところ、私にはまだ熱く語れるほどの実感がない*1。

ただ、実践テスト駆動開発 テストに導かれてオブジェクト指向ソフトウェアを育てる (Object Oriented SELECTION)にはこうある。

私たちは、実行時のシステムをコミュニケーションしあうオブジェクトの網の目と捉える。したがって設計時には、必要な機能を実現するために複数のオブジェクトがどう協力し合うかという点に注力する。確かに、クラス構造はうまく設計したい。しかし、オブジェクト間のコミュニケーションパターンの方が重要だと考えるのである。
Javaのような言語では、インターフェースを使ってオブジェクト間のやり取りに使えるメッセージを定義できる。しかし同時に、コミュニケーションのパターンも定義する必要がある。これは言わば、コミュニケーションプロトコルだ。命名と規約を使って出来ることはやるが、インターフェース同士の関係やインターフェース内のメソッドの関係を記述する手だてが、プログラミング言語には用意されていない。そのため、設計において非常に重要な箇所が暗黙的なままになってしまうのだ。
私たちがモックオブジェクトと共にTDDを用いるのは、こうしたコミュニケーションプロトコルを明示するためだ。

私たちが主張して来たのは、互いに命令を送り合うオブジェクトに集中すること、そして、その状態を問い合わせる方法を一切露呈させないということだ。しかしこれでは、ユニットテストでアサートする手段がなくなってしまったのではないだろうか。
…
テスト対象のオブジェクトの隣接オブジェクトを、テスト中に代用品と置き換えるやり方の一つとして、…モックオブジェクトを使うことで、起点となるイベントに対して、テスト対象のオブジェクトがどのように隣接モックとコミュニケーションするかについて、自らが期待する内容を定義できるのだ。こうした定義のことをエクスペクテーションと呼ぶ。テストをしている間は、期待された通り呼び出されたことをモックオブジェクトがアサートする。
…
こうしたテスト基盤を適切に用いれば、TDDでの作戦を変える事が出来る。
…私たちはただテスト対象のオブジェクトだけをテストしたいのだということ、それから、隣接オブジェクトがどのようなものであるかが、既に分かっているということだ。しかし実際には、ユニットテストを書いている時点では、こうした協調して動作するオブジェクトは存在していなくても構わない。テストを使う事で、自分たちのオブジェクトが必要とする補助的なロールを明らかにすることができるのだ。こうしたロールはJavaのインターフェースとして定義され、実際に実装されるのはシステムの残りの部分を開発するときだ。私たちはこれを、インターフェースの発見と呼んでいる。

コードを書く上で非常に重要な観点に触れた気がする。


実践と、合わせてGOOSの熟読をしたい。

参考書

JUnit実践入門 ~体系的に学ぶユニットテストの技法 (WEB+DB PRESS plus)実践テスト駆動開発 テストに導かれてオブジェクト指向ソフトウェアを育てる (Object Oriented SELECTION)xUnit Test Patterns: Refactoring Test Code (Addison-Wesley Signature Series (Fowler))SQLアンチパターンレガシーコード改善ガイド (Object Oriented SELECTION)プログラミングGROOVY

他の記事（把握できてるだけ）


*1:恥ずかしながら、私は普段スタブは使っても「モック」を使った事がない。