無料ブログはココログ

« 2013年11月 | トップページ | 2014年1月 »

いびつにとんがれ! - スーパーニッチの人生戦略 -

景気が良くなりそうな気配ですが、ランチェスター戦略でいうチョキの後はグーです。誰もが失われた20年は勝ち目のないビジネスをやめて利益の出るビジネスに限定するチョキの戦略を取りがちでしたが、これからは、一点集中で攻めていくグーの時期になるでしょう。

もしかするといきなりバブルになって、パーの戦略で頭数を揃えれば儲かるようになるかもしれません。でも、簡単に儲かる分野は競争が激しく、儲かる間に撤退できなければ大きな損害を被ります。

スーパーニッチ

スーパーニッチという言葉を初めて聞いたのはTI(Texas Instruments)社がTTL(Transistor-transistor logic)から撤退した時です。パソコン黎明期の計算機の論理回路はトランジスタでできていて、TI社の74LSシリーズが業界のデファクトスタンダードでした。

そのTI社が撤退すると聞いて、とても驚いたのを覚えています。汎用部品が儲からなくなったので、当時としてはニッチな市場だったカスタムチップを中心に、スパーニッチを目指すと報道されていました。

TTLは競合他社からもライセンス料が入るので、利益を取り合うよりも強みのある新しいビジネスを始めて、ビジネス戦略を広げようと言う判断もあったのかも知れません。

人生のリーンキャンバス

このスーパーニッチという考え方は人生戦略にも活かせます。江川達也さんの「まじかる☆タルるートくん」やアラジンの「完全無欠のロックンローラー」はマーケティングから生まれたヒットです。また、東進ハイスクール林修さんは、数学が得意だったのにライバルの少ない国語の先生になられたそうです。

こだわりを捨てて、冷静に自分の力を見極めて勝負する。このような考え方は人生のリーンキャンバスと言えるかもしれません。

いびつな人になる

2008年に松江市で開いたソフトウェアシンポジウムの基調講演でRubyのまつもとさんは「棚卸をしていびつな人になる」と言われていました。その後に話題になったリーンキャンバスを先取りしたようなお話でした。

まつもとさんはリーンキャンバス的な棚卸しをした上でいびつになる事、つまり「差別化重要」「機嫌重要」「継続重要」「行動重要」と言われていました。

まつもとさんの講演記事を見直して驚いたのですが、同じような事を最近つぶやいていました。

きっと、心の奥底に残っていたのでしょうね。ここで言いたいのは、本を読み、基礎力を高めること、そして、社内内弁慶を社外勉強会に参加させる方法に書いたように外に出て、その理解を確認すると共にあたらし刺激を受けないといけません。

でも「好きこそものの上手なれ」というように、義務感からでは続きません。仕事をポジティブにとらえて、好きなところを見つけたら理解できるまでとことん学ぶ事です。

そのような事を繰り返していれば、自然と自分の考えや得意な事がわかってくるはずです。そして、[#agileto2012] 『チェンジ!』の考え方 ~マネしやんと!~ に書いたように戦略的に攻めれば、きっと世界は変わるはずです。

2014年もまだまだ挑戦していきます!

このエントリーをはてなブックマークに追加

実装優先時の考慮点 その4 - パッケージとしてのアジャイル開発 -

実装優先時の考慮点を説明してきました。ここまで実装を優先してリスクを回避する際に、実装したソフトウェアに引きずられない事自動化により実装・確認・フィードバックのループを早く回すと共にリファクタリングを容易にする事バランスを考えながら効率の良い言語と環境を選ぶ事を説明してきました。

これらをふりかえると、アジャイル開発のいくつかのプラクティスは、実装優先で開発してリスクを低減する際には実施しないとうまくいかないか、効果が減ってしまうという事に気付きます。

さらにアジャイル開発を見直すと、他のプラクティスも同じように必然であることに気付きます。実装優先をプロジェクト全体に広げるには、チームとしての活動が前提になるからです。

ゴールの共有

インセプションデッキなどによるゴールの共有は、チームが同じ方向に向かう為に必要です。

上流のドキュメントに仕様が定められたプログラムを実現する場合には、ゴールが明確でなくてもそれなりのものが実現できます。しかし、何をどのように作れば良いかを実装して確認する場合には、向かうべき方向と現状の共有が必要になります。

ゴールを共有して、現在の状況を共有するからこそ、今後の進め方がわかります。実装を優先して開発するにはゴールの共有が必要です。

情報共有

実装優先で開発してリスクを低減する場合、開発中に気付いた事やできたものを見て気付いた事を、今後の仕様や開発法をフィードバックしないといけません。しかし、気付きをチーム全体で共有できないと、実装を優先しでも意味がありません。

そこで、気付きを共有して知恵を出し合う仕組みが必要になります。ふりかえりを実施すれば、過去の問題を共有し、今後に活かす事ができます。改善する事はWikiやカンバンボードの注意書きなどにまとめておき、具体的な作業はタスクカードやチケットにすると良いでしょう。

見える化

情報共有はふりかえりだけでは不十分です。実装による確認があまり必要でない場合はスケジュールの制約を利用して期限内にやるべき事を明確にできます。しかし、実装を優先してわからない事を発見する場合は、直近のゴールとしてマイルストーンを定めて迷走しないようにします。

バーンダウンチャートなど短期的なプロジェクトの計画と進捗を可視化する事で、その問題点を見える化できます。タスクボードはイテレーション内の進捗が見える化できますし、チケット駆動開発ならロードマップ全体の進捗を見える化できます。

イテレーションとリズム

マイルストーンはソフトウェアを動作させて知見を得るタイミングです。マイルストーン間の期間が短いと得られる知見が少ないほか、デプロイや説明資料など動作させるために時間が取られるので、自動化してる場合てもある程度の期間をあける方が良いでしょう。

その期間を一定にするとチームはリズムを感じだし、習熟します。一定の周期の中で、計画やリリースなど定型的な作業の期間が安定するほか、メンバーの役割も安定してくるでしょう。それがイテレーション(あるいはスプリント)や組織パターンのロールだと考えられます。

サーバントリーダーシップ

実装優先で開発する際にはメンバーが指示で動くだけではなく、メンバーが能力を最大限に発揮して多くの気付きを得て、その気付きをチームで共有します。

あらかじめ理論的に確認する事が難しい場合、実装して少しずつ確認します。それはリーダーも同じで、全てを理解している訳ではありません。チームのみんなで協力して確認します。

外部とのインタフェースとなる(プロダクトオーナなどの)担当者は、チームのボトルネックになり易く、作業効率化の要として行動しないといけません。関係者の意見を集約し、チームを方向付けます。

サーバントリーダーシップはアジャイル開発への壁となる価値観の壁だと思っていましたが、これも実装を優先してリスクを低減する場合は必然だと言えます。

顧客との協調とドキュメント

対象の業務を最も知っているのは顧客です。成果物や実装の終わったソフトウェアを評価してフィードバックします。効率的なフィードバックを得るには、適切ナタイミングで顧客が関わらないといけません。できれば同席が望ましいでしょう。

組み込み開発の場合には共通ライブラリも開発対象となる事が多く、ドキュメントによる確認を行う事も多いでしょう。また、他チームと連携する場合にも適切なドキュメントが必要になります。

逆に業務が小規模な場合や対象業務を小規模な範囲に追い込めた場合には、ドキュメントがあまりなくてもソースコードで十分な場合もあるでしょう。

パッケージとしてのアジャイル開発

このように実装優先の開発を考えると、アジャイル開発のプラクティスは必然であると思えます。

エクストリームプログラミングでは、各プラクティスの依存関係が説明され、全ての実施が好ましいと考えられてきました。しかし、プラクティス間の依存関係を意識して注意深く代替プラクティスを用いれば、期待するアジャイル開発の効果を得る事ができます。

ソフトウェア工学の個別の技術がCMMに体系化された事で発展し、大きナ効果を得る事ができました。しかし、それと同時に当時のプロセスモデルに固定化してしまい、実装優先で開発する際の応用を難しくしてしまいました。

スクラム開発などのアジャイル開発は、実装優先の枠組みの中で必要とされる現代の技術を体系化し、パッケージ化したものと考える事ができます。パッケージとして受け入れる事で、効果を発揮するでしょう。

しかし、それぞれのプラクティスがなぜ必要であるかをきちんと理解していれば、本来必要なプラクティスを闇雲に省いてしまう事なく、最適で効率的なソフトウェア開発が実現できると思います。

まとめ

アジャイル開発は新しい技術なので、これまでの開発法をあてはめて理解するのではなく、別物として理解するように言われる事や、守破離のように先ずは守れと言われる事もあるようです。

しかし、上に述べたようにアジャイル開発は、必須と思われるプラクティスを組み合わせたパッケージであると考えられます。今回はリスクを低減すべく「実装優先で開発する」という視点で見直す事で、プラクティスの依存関係を必然性として考える事ができました。

アジャイル開発には、リスク低減以外にもオブジェクト指向の視点やファシリテーションの視点など、様々な視点があります。それぞれの視点で見直す事で、アジャイル開発がより実践的で応用の効く技術になるでしょう。


実装優先時の考慮点 その3 - 言語と環境の選択 -

ここまで実装を優先する事でリスクを回避する際に、実装したソフトウェアに引きずられない事自動化により実装・確認・フィードバックのループを早く回すと共にリファクタリングを容易にする事を説明してきました。

今回は実装・確認・フィードバックのループを早く回すもう一つの視点として言語と環境の選択を取り上げます。進化的プロトタイピングの研究開発事例である「WEBユーザビリティ評価用ツールWebTracer」の経験を通じて説明します。

WebTracerはWeb画面とキー入力、マウス操作、ユーザの視線を記録し、議事アニメーションで再生すると共に、基本的なメトリクスの分析をするツールです。エンピリカルソフトウェア工学(実証的ソフトウェア工学)の研究テーマの一つとして開発し、ユーザビリティテスティングに利用しました。

言語の選択

開発言語はVisual Basic 6(VB6)を選択しました。当時はVisual C++(VC++)に慣れていました。また、所属組織としてはSmalltalkを使った方が良以上今日でした。しかし、MSDNなどのドキュメント類に慣れていたこと、学習工数を考慮しても生産性に期待でき、IEとの相性の良さが期待できるなどメリットがあり、そして何よりもWYSIWYGな開発環境が進化的プロトタイピングに有効だと思われたからです。

元々パソコンをBASICで学んだ時代の人ですし、すでにRubyによるリエンジニアリング支援ツールの研究開発はしていましたので、コードを書けばすぐに確認できるインタプリタの効果は理解していました。

作らないとフィードバックが得られないのは、ユーザだけでなく開発者も同じです。コードは実行してその結果が表示されるまではプログラムに問題があるかわかりません。インタプリタならコーディング後にすぐ確認できるので、徐々にプログラムを作り上げる際に効果を発揮しました。

環境の選択

WebTracerの開発は、想像以上にうまくいきました。もし、VC++で開発していたなら、2倍ぐらいの工数がかかっていたと思います。もしかすると、完成していなかったかもしれません。

VB6は見た通りに画面が作成でき、それがそのまま動きます。ビルドにまつわる余分な事を考えなくて済み、その時間も必要ありませんでした。

またIDEによる開発支援もあって、こうすればできるとわかった時にはすぐにプログラムができました。ツールを今後どのように発展させるべきか、どのように活用できるか、を検討するなど、より高度な仕事ができました。

このように、フィードバックがすぐに得られるメリットを大いに感じました。

限界を知る

結果がすぐに得られる環境は、実装によるフィードバックループを高速化します。その効果は絶大です。しかし、複雑なプログラミングが簡単にできるという事は、できない事も増えました。

VB6は基本がシングルスレッドなので、画像の圧縮と保存を並列処理できませんでした。一旦、全ての画像をメモリー上に残しておいて、実験が終了する際に保存するという仕組みで、やり直せない実験には少し使いにくいツールでした。

WebTracerではVC++と併用する事でVB6の限界を超えましたが、環境の選択はその限界を見極めないと、アプリケーションの寿命を縮めてしまいます。

かつて4th DimensionというMacintosh上の開発環境を利用したプロジェクトを担当した事があります。これはこれで高速な開発が可能な環境で、お客様との仕様調整がうまくできれば良いツールでした。

しかし、これも標準規格でない事が足かせになるのか、WEBベースのWAKANDAが開発されている様です。同様の効率的な開発では、超高速開発(リンク先はPublickey)が話題になっていますが、これらはどういう開発に向いていて、どのような状況になれば限界にぶつかってしまうのか、大変興味のあるところです。

まとめ

言語や環境の選択によって、高速なフィードバックを得る事が可能になります。しかし、言語や環境の選択によっては効率的に開発できる内容には限界があり、プロジェクトの特性をきちんと把握して、ふさわしいものを選ぶ必要があります。

進化的プロトタイプのように実装優先で開発する場合、実装結果を早く確認できないとあまり効果が得られません。今回取り上げた言語と環境の選択と同じように、前回の継続的統合やテスト自動化もバランスを考えて実施すべきでしょう。

プロジェクトにはバランス以外にも考えないといけない事がたくさんあります。次回は実装優先のプロセスの一つである、アジャイル開発で考慮されている他の要素を考えてみる予定です。

実装優先時の考慮点 その2 - 継続的統合とテスト自動化 -

プロトタイピングは前の記事で書いたように、ある程度実装してみないとわからないリスクを低減します。

特に進化的プロトタイピングは、アジャイル開発のように最終的なコードを漸増的(インクリメンタル/スパイラル)に開発していく方法で、リスクを低減しながら着実に開発を進めていきます。

特徴

その特徴はドキュメントの調査によってではなく、「実際に動かして確認する」ことです。

  実装 =>  確認 =>  フィードバック

を繰り返す事で、確実に動作する部分を増やしていきます。

その場しのぎのコードを実装するのではなく、きちんと考えられた使えるコードを実装して増やしていきます。また、機能の一部を作るのではなく、動作が確認できる単位で作り、ソフトウェアを進化させます。

継続的統合

使えるコードを増やすには、実装・確認・フィードバックの時間を確保しないといけません。実装した後のビルド、テスト、デプロイなど、動作させて確認できるまでに時間がかかるなら、使い捨てのプロトタイプで確認するか、繰り返しの回数を減らす方が効率的です。

しかし、それではソフトウェアを効率よく進化させられないので、実装以外の作業を自動化する必要が出てきます。実装・確認・フィードバックに関係ない作業にかかる時間やミスによる手戻りを減らして、本来必要な作業の時間を確保します。

継続的統合は作業を効率化するという側面で見られる事もあります。しかし、漸増的な実装で開発のリスクを減らするなら、確認までにかかる作業を継続的統合で自動化して、常に動作可能にすることは必然といえるでしょう。

テスト自動化

プロトタイピングの注意点の一つは、すでに実装した部分に引きずられる事です。アーキテクチャの見直しを避けていてもいつかは限界がきてしまいます。早めにあるべき姿を実現しておくべきです。

しかし、リファクタリングしてより良い構造を実現する際に、既存部分が動かなくなっては意味がありません。既存の機能を常に確認できるようにテストを自動化しておく方が良いでしょう。

また、漸増的な開発は、動作確認されたモジュールを積み上げていく作業です。信頼性の低いモジュールが混在していたなら、砂上の楼閣のようにいつか破綻します。

継続的に漸増的開発するなら、テストの自動化は必須であると言えるでしょう。

まとめ

アジャイル開発では継続的統合や自動テストが、あたり前のように行われています。これは先進的な技術者がアジャイル開発をしているという側面もあるかもしれません。

しかし、リスクを低減する目的で実装を優先しているなら、常に動作が確認できる継続的統合や、信頼性を常に確保してはリファクタリングを容易にするテストの自動化は必然です。

もちろん、継続的統合による生産性の向上や、テスト自動化による信頼性の向上は、アジャイル開発のような漸増的開発でなくても効果があります。

しかし、それらがなぜ必要になったかを考えれば、ラピッドプロトタイピングを取り入れる事や、漸増的に開発すべきところを切り出す事、さらには、全面的にアジャイル開発をする事、をきちんと検討しないといけない事がおわかりいただけるでしょう。

ソフトウェア開発のトラブルを減らす効果的な方法の一つは、リスクを低減する事です。開発中に生じる可能性のある問題を明確にし、適切なプロセスを構築する事が大切なのです。

実装優先時の考慮点 その3 - 言語と環境の選択 -に続く

実装優先時の考慮点 その1 - プロトタイピングとスパイクソリューション -

ソフトウェア開発を成功させるには、リスクを常に考慮しないといけません。その中でも、新しい環境やアーキテクチャ、ユーザビリティなどのリスクは、ある程度実装してみないとわかりません。

そこで、そのような場合は古くからプロトタイピング(リンク先はWikipedia)が行われてきました。プロトタイピングには捨ててしまう前提で作る「ラピッドプロトタイピング」と実物を徐々に作り上げるプロセスとしての「進化的プロトタイピング」があります。

XPJUG関西の代表やアジャイルラジオで有名な西さんが「WFできないとアジャイルできない」という言葉をつぶやかれていました。

エクストリームプログラミング(XP)の調査作業である スパイクソリューション でのソフトウェア開発は調査用の「ラピッドプロトタイピング」ですし、アジャイル開発の繰り返し開発はマイルストーンまでの期間を固定した「進化的プロトタイピング」と似ています。プロトタイピングの注意点もアジャイル開発でもきっと役に立つと思います。

ラピッドプロトタイピング

使い捨てを前提にプロトタイプを作る場合は以下のような目的があるでしょう。

  • 技術的な確認
  • 性能評価
  • 生産性(見積もり)の基準作り
  • ユーザビリティの確認、など

ここで注意しないといけないのは、プログラムが動くようになると、捨てるはずで作ったのに、できたつもりになりがちな事です。いわば「やっつけ」で作ったのですから、そのまま流用すると、コードの品質が悪く、アーキテクチャや仕様の検討が不十分で、仕様漏れが生じ易くなります。

後からテストコードを書けば、品質の問題はある程度回避できるかも知れません。しかし、その後の開発では、できている部分に知らず知らず引きずられてしまいがちです。

使い捨ての前提で作り出したのですから、最初から作り直す方が良いでしょう。もし、どうしても正式なコードとして用いるなら、テストコードを用意するだけでなく、「 ほんまか(それで良いか)?」「なんでや(どうしてか)?」とコードを見直した方が良いでしょう。

XPのスパイクソリューション

XPは進化型プロトタイピングのようなものです。繰り返し開発する実開発と調査用のプロトタイプを区別できるように「スパイクソリューション」という言葉を使って、明確に分けるようになったのでしょう。XPエクストリームプログラミング導入編の訳注にこうあります。

スパイクソリューション(spike solution):大まかな解決。スパイク(大きな釘)を問題の中心に打ち込み、解決を試みるイメージ。精巧ではないが、本当にうまくいくかを大まかに解決する。従来、プロトタイプと言われていたものに近い。

また、アート・オブ・アジャイル デベロップメントではスパイクソリューションの見出しに「私達はもっと情報が必要なとき、小さな独立した実験をする」とされ、「スパイクで書いたコードを捨ててしまうべきでしょうか」との質問に以下のように書かれています。

誰も後で参照する事がないのであれば、捨ててしまおう。スパイクソリューションの目的は、問題の解決方法を知るために、情報を得て実際にやってみることであって、問題を解決するためのコードを作り出す事ではないということを思い出そう。

ラピッドプロトタイピングやスパイクソリューションは、使い捨て前提と割り切ったプロトタイプです。きちんと割り切ることが成功の秘訣なのでしょう。

進化的プロトタイピング

捨ててしまう前提ではなく、段階的に作るプロセスは進化的プロトタイピングと呼ばれます。この場合も、初期のプロトタイプは以下のような目的を持たせると良いでしょう。

  • やり方(コーディング基準やプロセス)を決める
  • 共通部分のうち必須部分から
  • 横展開するベース開発
  • 横展開の元ネタ、など

このようにたたき台として作り、それを全体に広げるやり方が向いています。その際には以下のような点に注意すると良いでしょう。

  • 作業が効率化する順番に組み立てる
  • リスクが低減する順番に組み立てる
  • テストコードを必ず用意する

進化的プロトタイピングでは、アーキテクチャを考慮して基本的な作りから始める事を検討すると良いでしょう。見通しが悪いままにとりあえず作っていると、アーキテクチャや仕様の検討が不十分になり、仕様漏れが生じ易くなるからです。 しかし、必要以上に決定しすぎても、プロトタイピングの良さがなくなり、手戻りが増える場合があるので、注意してください。

まとめ

ウォーターフォール型プロセスをベースに標準プロセスが決められている場合でも、プロトタイピングが許されている場合も多くあります。ウォーターフォール型プロセスの欠点は広く知られているからです。

その一方で、闇雲に実装してしまう事や、評価用のプロトタイプをそのまま正式コードにしてしまう事は、常に警戒して注意深く利用されています。

アジャイル開発の長所はたくさんあります。「温故知新」と言われるように、過去の技術のノウハウをふりかえる事で、バランスの取れたより良い未来が見えてくるかもしれません。

実装優先時の考慮点 その2 - 継続的統合とテスト自動化 -」に続く

このエントリーをはてなブックマークに追加


ドメイン駆動設計と業務分析の違い - 第28回 関西IT勉強宴会 -

ドメイン駆動設計(DDD)とはなにか?

それを知るには「ドメイン」という言葉の定義を知る必要があります。一般にドメインエキスパートが出てくる文脈でドメインというと業務ドメインを指しています。そして業務ドメインというと業務分析の対象になっています。

しかし、今回の関西IT勉強宴会 ドメイン駆動設計を知ろうの議論を通じて、 ドメイン駆動設計でいうドメインと業務分析でいうドメインが異なっている事がわかりました(参考: 2013-12-13(金)第28回関西IT勉強宴会 ドメイン駆動設計を知ろう(関西IT勉強宴会のブログです)、ドメイン駆動設計に出てくる「モデル」とは何ですか?(プログラマの思索))。

業務分析の対象となるドメイン

議論中の言葉をお借りすると、DOAで行う業務分析では、管理レベルからドメインを見ます。ユースケースによってシステムの内側と外側の境界を定めて、その内部を開発します。

IBM-DOAで用いられるDFDでは、トップレベルのコンテキスト・ダイヤグラムでシステムの境界を定めて、トップダウンにプロセスを分割します。部分的に深められることや洗練される事はありますが、システムの境界は基本的に変わりません(最近はユースケース図になっているかもしれませんがが、境界を定める点は同じでしょう)。

ドメイン駆動設計の対象となるドメイン

これに対してドメイン駆動設計ではユーザとの界面は、システム側のUIでさえも対象としていません。ドメイン知識を持つドメインエキスパートと開発者との間でユビキタス言語を定め、モデル駆動で開発します。

この点がディスカッションでは話題になりました。システムの境界を定めるのではなく、SEA関西「ぐるぐるDDD/Scrum」 - モデルは実装のうずまきで洗練される - で経験したように、コアな業務からインクリメンタイル(漸増的)に開発していくイメージの様です。

ユビキタス言語とデータディクショナリとの違い

懇親会で講演者の後藤さんを交えてお話しさせていただけたので、 ユビキタス言語とデータディクショナリとの違いをおうかがいしました。データディクショナリは名詞しかありませんが、ユビキタス言語は名詞と動詞があることや、著者のエリック・エヴァンスは言葉を大切にしているとのお話をうかがいました。

このあたり、青木淳さんのSMALLTALKの黒本にあるように細胞をメタファとしてデータとメソッドでオブジェクトをカプセル化したオブジェクト指向の流れを感じます。

ドメイン駆動設計と業務分析の違い

業務分析を行う基幹業務では、一定のまとまりの機能が必要とされます。会社によって管理方法の違いがありますが、制約となる法律やルールは変わりません。そこで、一定の機能を含む境界が生まれます。

これに対してリーンスタートアップのように、最低限の機能によって大きな効果を得ようとする場合は、よりコンパクトな機能が求められます。ドメイン駆動設計のようにインクリメンタルに機能追加して、ビジネスに適したソフトウェアを実現することが求められていると思います。

(おまけ)プロセス再考

この関係はフレームワークとしてプロセスがパッケージングされているスクラムと、ムダの少ないプロセスを構築していくリーン開発の関係と似ています。

開発チームを一定の水準まで実現する場合や、流動化した労働力による混合チームを実現する際にはスクラムが向いています。完全型チケット駆動開発の目指すところも同じです。

一方、すでに開発チームが存在し、原則やカンバンを導入するなど、徐々に改善したい場合はリーン開発が向いています。補完型チケット駆動開発も同じような使い方になります。

まとめ

開発にしろプロセスにしろ、必要な特性に応じた方法を用いる事が大切です。それにはブームだからという理由ではなく、説明責任が果たせるだけの理解が必要でしょう。

今回の勉強会に参加して、議論の中でDOAとオブジェクト指向は目指す方向性が違う事がわかりました。単に講演を聴くだけでなく、議論する事が大切だと思いました。

みなさま、ありがとうございました。


アジャイル開発の「考え方」と「やり方」を学べ

最近、「ウォーターフォール開発が危ない」と思うようになりました。アジャイル開発は従来の開発の延長線上にある(アジャイル開発におけるプロジェクト成功の定義 - アート・オブ・アジャイル デベロップメント -)とは思うものの、様々なほころびがある([#TiDD] 従来法の限界とアジャイルの利点、そしてチケット駆動開発)ので、若い元気な人がアジャイル開発を目指す反面、社会動向と相まって既存企業は管理強化に向かい、従来法の大切な「考え方」が失われつつあるように思います。

従来法の問題点はトップダウンの管理(コマンドコントロール)によって、すべてのプロジェクトがうまくいくと思う人が少なからずいた事でしょう。しかし、ソフトウェア開発は人間が行うものです。人間がどのような「考え方」を持ち、どのように「やり方」を実践するか、によってプロジェクトの結果は大きく変わります。

アジャイル開発が革命的だったのは、それまで基本的な管理を学んださらにその先にあると思われていた「考え方」や「やり方」にアジャイル宣言で光を当てた事だと思います。

この「考え方」や「やり方」を理解して実践すれば、どのような状況でも一定の効果が得られるでしょう。また、トップダウンにアジャイル開発が導入された場合でも教条主義に陥らず、形骸化を防ぐ事ができるかもしれません。

「考え方」と「やり方」のふりかえり

ソフトウェア開発は構造化やプロダクトの設計法という「考え方」や「やり方」が中心でした。やがて生じている事象の説明に統計学が用いられるようになり、プロダクトを可視化する目的でメトリクスが使われるようになりました。

その後、プロダクトだけでなく、より「やり方」を示すプロセスメトリクスが注目されました。しかし、それは工程ごとのレビュー指摘件数など管理に必要なやり方で、リスクの低減に必要なプロトタイピングの検討有無など、より良い開発の「考え方」や「やり方」を示すものではありませんでした。

そのような中で、大切な「考え方」はトップダウンの管理の下、チームで育まれました。リーダーに求められる大切な事 - 100人のプロが選んだソフトウェア開発の名著 - に書いた他にも色々あり、それらはアジャイル開発と共通するものです。

しかし、プロセス管理は徐々に重くなる一方で、チームには利益の確保が求められ、そのゴールの実現で力を使い果たし、大切な考え方を見失いがちになってしまったようです。

大切な考え方

従来法とアジャイル開発のやり方から大切な「考え方」を説明します。

従来法
アジャイル
考え方
マイルストーン
イテレーション
リズム
ゴールを近くに設定する事で、進捗が明確になり、チームが一丸になれま す。リリースのマイルストーンを定期的に設定すると、習熟度が向上します。
プロトタイピング

実装優先
スパイク
ユーザインタフェースなど確認に実物が必要な場合はプロトタイプを開発 します。実使用が可能な開発と、スパイクと呼ばれる性能などの技術要件の確認は誤解され易いので明確に区別します。
記録を残す
トラッカー
記録を残す事でエビデンス(証拠)になるだけでなく、プロジェクトの生 産性(ベロシティやスループット)を知る事ができるので、継続的に改善する事ができるようになります。
フロントローディング
手戻りを無くす
テスト駆動開発、ペアプロ
ムダの排除
障害は後から取り除くのではなく、作り込まないようにします。決定でき ない事は、無理に決めて手戻りしないようにします。
状況の認識と共有
作業一覧(WBS)・線表
タスクボード、カンバン
バックログ、バーンダウンチャート
プロジェクトの状況を常に認識し、共有します。状況を共有することで、 今後の見込みを知るだけでなく、お互いに助け合う事ができます。
Win-Winの関係
価値の提供
同じ方向を向く
顧客と開発者が目先の利益で対立するのではなく、長期的な視点を持ちます。リファクタリングを実践しつつ変化を受け入れるなど、価値の あるプロダクトを提供する事が顧客の利益になり、長期的には開発者の利益になります。
最大の能力を発揮させる
サーバントリーダーシップ
プロジェクトファシリテーション
やらされ感をなくし、チームのやる気を引き出します。開発の障壁を取り 除き、(命令ではなく)チームを導く事で、効率的な開発を実施します。

まとめ

このように並べると、アジャイル開発が従来法の「考え方」や「やり方」を形式化し、シンプルなプロセスをパッケージングしている事がわかります。

あなたのポジションはどこでしょう。もし、従来法の開発をしているならアジャイル開発の価値観を学べば、管理以外の大切なことが理解でき、より良い開発ができるでしょう。もし、すでにアジャイル開発をしているなら、アジャイル開発の価値観を見直す事で形骸化を防ぐ事ができるかもしれません。

これは、チケット駆動開発に置いても同じです。[#TiDD] チケット駆動開発をプロジェクト管理の視点だけで考えてはいけないに書いたように自律的なチームを構築し、ソフトウェア開発の現場力を向上させることが大切です。

プロジェクトは言われた通りにすればうまくいくものではありません。常に状況を把握して、どうすべきかをよく考えないとうまくいきません。そこで、何をやったかを管理するのではなく、どのように考えて何をすべきかをきちんと理解する必要があると思います。

おまけ:違いについて

なお、アジャイル開発は一定のサービスが実現可能なら、スコープを調整する事ができますので、残業を前提としない事も可能な場合があります。

これに対して、 従来法はスコープを固定して、コストと納期で調整する方法です。仕様が膨らむとみんなで頑張るか納期をのばすしかありません。もし、リリース日が決まっているなら、頑張るか泣きつくしかありません。

(もちろん、上流を準委任にすると共に必要なプロトタイピングを実践して、あらかじめ予想できるようにできれば、仕様削減や段階的なリリースも可能です)

これは、従来法とアジャイル開発の本質的な違いです。最も学ぶべきところは、IT技術はビジネスの要(かなめ)であり、ユーザがリスクを取る事でより大きな利益が得られること、開発者はそれに開発を通じて協力する。という考え方なのかもしれません。

このエントリーをはてなブックマークに追加


[#TiDD] Scrum × PBL × チケット駆動開発 - 第9回 RxTstudy(Redmineやタスク管理を考える勉強会@大阪) -

『大学で学んだ事は役に立たない』というのは都市伝説。そんな思いを抱いた第9回RxTstudy
の招待講演:大阪大学 井垣宏先生「Scrum × PBL × チケット駆動開発」でした(資料あきぴーさんのまとめtogetter)。

大学では専門知識が学べるメリットがあります。たとえば、Key Value StoreのひとつであるRedisのマニュアルを読むにも「計算量」を知らなければRedisのありがたみは半減します。大学で専門知識を学ぶメリットはあるでしょう。

とはいえ情報系の学部でないだけでなく、文系の学部を出た方でも、ソフトウェア業界で活躍されている方はたくさんおられます。後から専門知識を学んだなら、その方の資質や経験を生かす能力などの方が、長期的には実社会での能力差になるのかもしれません。

Project Based Learning

企業にいれば現場経験によって、そうそう大学には負けないと考えていました。専門知識で負けても、現場の経験がなければわからない事もたくさんあるからです。

しかし、アジャイル開発のワークショップやコースを見ると、必ずしも現場的ではありません。学ばなければいけないポイントを絞ってトレーニングが行われています。

それは実験計画法のように感じます。実験計画法では、評価対象以外の要素の影響を排除する事で、評価対象の効果を明確にします。例えば、被験者を2群に分けて一方はA・Bの順に実施して、もう一方はB・Aの順に実施するなどです。

講演された授業での、以下の内容を 教授目標とされています。

  • Scrumフレームワークの理解
各イベントにおけるプロセスと成果物
    • 各ロールの振る舞い
    • プロセスの透明化(記録),検査,適応
  • ・チームソフトウェア開発プロセス
    • 構成管理, CI(Continuous Integration)等
    • 実装,レビュー,テスト
  • プロダクトスキル
    • MongoDB, JavaScript, JavaによるWebアプリケー ション

これだけを数日で教える事はなかなか困難です。そこで、教えたい事をしぼって制約を与えられています。

先日の原田さんのScrum&DDDのワークショップでは、受講者にわからない形で教えたい内容が理解できるように導かれていました。そうする事で、自然と理解できるように考えられているようでした。

井垣先生の場合は、できる学生だけが実装してしまうなど影響を排除したい内容が多いので、自然と導く事は難しいのでしょう。逆に制約を明示する事で、教えていない事を明らかにされているように思いました。

現場で実践すべし

大学が現場に追いついてきたのなら、我々現場の人間はどうすれば良いのでしょう。たぶん、ワークショップだけで、わかったつもりになっていてはいけないのでしょう。それでは学生さんと変わりません。

また、大学の授業が文献を元にした偏りの少ない知識が得られるのに対し、企業人の講師は実践的である反面、講師の思い入れが入っていますので良くも悪くもサブセットになっています。

そこで、企業人がプロであるためには、学ぶ際も「現地・現物」を徹底すべきだと思います。学んだ事をチャンスを見つけて仕事に生かすのです。人から聞いたり、限定的なトレーニングでなく、現場で実践して自分のモノにする事が大事だと思います。

プロジェクトの経験を活かせ!

講演された授業ではチケット駆動開発で実践されていました。ホワイトボードでの打ち合わせとtracを併用されていた様です。

このチケットは作業の履歴として、プロセスの確認に用いられていました。きっとソフトウェア工学のリポジトリマイニングのように研究ネタにも利用されるのでしょう。

さて、現場をふりかえってみると古くから多くのメトリクスが収集されていますが、活用されているでしょうか?必ずしもチケット駆動開発である必要はありませんが、プロジェクトの経験をムダにせず、活用していくべきだと思いました。

講演後の議論の中で、ルール(制約)を守ってきちんとチケットとコミットを関連づけていたチームの話題がありました。厳密な評価ではありませんが、ルールを守っていないのは優秀なチームとあまり成果の良くないチームで、ルールを守っていたチームは特に優秀ではないが比較的成績の良いチームである傾向があったそうです。

作業者や作業方法によっては、経験を生かせるチケット駆動開発は悪くない選択肢なのかも知れません。

まとめ

インターネットブームの元になったアメリカのUNIXの普及は、大学でUNIXを学んだ学生がUNIXを就職先を選ぶ際の条件にした事がきっかけだそうです。Scrumやチケット駆動開発も、同じような普及の仕方をするのかもしれません。

現場の私達も、負けないように腕を磨いておかないといけませんね。


« 2013年11月 | トップページ | 2014年1月 »