無料ブログはココログ

考えろ、理解しろ、整理しろ

渡辺幸三さんのブログ:設計者の発言を読んでいて感じたこと。

日々の仕事をする中で口うるさいと思われても、年長者の務めなのできっかけを見つけては指導している。色々と言っているが、だいたい以下の3つに集約できるだろう。

考えろ

指示されたままに仕事をしたり、いつも通りで良いと思っていないだろうか。

渡辺さんの「論理削除」ではなく「無効化」をスタンプ属性や更新履歴テーブルの無駄っぽさを読んでいると、習慣ではなく考えて仕事をすることの重要性を感じる。

より良い方向を考えても、全体との調和の問題で実施できないかもしれない。しかし、きちんと考えてシステムを作り上げることはとても重要だ。次の仕事に活かせるからだ。

なぜかを理解しろ

学部の恩師の言葉で忘れられないのが「職人になるな勉強を続けなさい」という言葉(社内勉強会より社外の勉強会)。知っているだけではなく、きちんと理解していなければ技術者とは言えない。

人に聞いてわかったつもりで仕事に使い、うまくいったらそれでおしまい。それは技術者でも職人でもない。ただの人工(にんく)に過ぎない。

ものごとの原理は何なのか、その人はどうやって情報を知ったのか、広い目で深く理解していれば、自己流ではないより良い方法が選択できるだろう。

整理しろ

世の中のできる人を見ていると、常に考えて仕事をし、より深く理解しているだけでなく、情報を整理してコンパクトに理解している(できる人を観察して勝負する

得た知識はそのままにしておけば忘れてしまうし、量が増えれば大変になる。知識を活かしてステップアップするには、これまでの知識との関連を整理しておく必要がある。

体系化できていればすべてを覚えておく必要はない。どの資料に書いてあるかを知っていれば、いつでも確認できるからだ。経験のインデックスを作るのだ。

おわりに

世の中には新しい情報があふれているが、実は似たような議論を繰り返していることも多い。

渡辺さんの議論も、コードクローン(リンク先は阪大井上研)は全て悪か、より良いバランスはあるのか、と言う議論に見えなくもない(普及しているオープンソースには一定のコードクローンが存在するらしい)。このようにマッピングできるのは、ものごとを考え、理解し、整理しているからである。

ここに挙げた内容は技術者にとって基本的なことであるが、実践は難しい。自分のことはともかく、若者の可能性を信じて意見するのが年長者の務めだと思っている。

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


在庫推移監視方式にみるDOAのアプローチ #benkyoenkai

生産管理再入門-MRPを超えて <第43回IT勉強宴会> に参加しました。

メインの話題は在庫推移監視方式(Stock Projection Monitoring)で、その基本と事例の紹介でした。在庫推移監視方式はMRP(所要量計算)方式がバッチで処理するところを、手作業を前提とする事でリアルタイム処理する方式です。

在庫推移監視方式について

在庫推移監視方式は(1)新たな発注などの入出庫予定の変動があった際に、MRPは、(2)所要量の計算、(3)受払予定の再編成、(4)在庫推移の再計算、(5)推移以上の対応までバッチ行います。

しかし、実際は在庫を見たいだけなのに、(1)の入出庫予定の変動があるたびにバッチを実行しているユーザが多いそうです。そこで在庫推移監視方式は(2)と(3)だけをリアルタイムで行うことで、在庫の状況を確認できる様にしています。

在庫推移監視方式の事例

事例では、受注と発注の担当者を同じ組織にすることで、MRPがルールで行うことを人間によって調整できる様にしています。これによって、ムダに生産や在庫することが無い様に稼働を調整しているそうです。

在庫管理のポイントは、DB設計、方式設計、組織設計、工程負荷だそうですが、 在庫推移監視方式にあわせて組織設計までされたようです。

お話で興味深かったのは、在庫推移監視方式を知って実践したのではなく、実践してからそれが在庫推移監視方式であることに気付いたそうです。GoF本が出た時に「前からやっていた」という人がおられましたが、良いパターンは誰もがたどり着くものなのでしょうね。

そしてそのパターンを見いだして命名された渡辺幸三さんは、生産管理というドメインを極めたスパーエンジニアなのでしょうね。

在庫推移監視方式は方式設計?

在庫推移監視方式は方式設計ではないかということです。ドメイン分析の様に見えながら、実はリアルタイム処理かバッチかという方式まで決めています。

同じような感じは、ライブモデリングの時にもしました。データモデリングのようなのですが、理由を問われると「こんな有力画面を考えているんですよ」と答えられていました。

データモデリングと言いながら、画面設計もある程度できていたのです。DOAは常に実装と繋がっているのだと思います。

DOAのアプローチ

渡辺幸三さんは、ドメイン知識はDDDがいうような汎用的な方法では獲得が難しく、ドメイン専門家にならないといけない、といった主旨のお話をされていました。今回の在庫推移監視方式は専門的な経験があるからこそ、できる事なのでしょう。

DOAのアプローチはどちらかというと業務分析に始まるトップダウンアプローチです。でも、実装がどうなるかを意識していないと動くシステムは作れません。

たぶん、DOAはその溝を業務固有のデザインパターンでつないでいるのだと思います。今回は在庫推移監視方式というパターンでしたが、それ以外にも多くのパターンがあり、その獲得がドメイン専門家になるという事であると思いました。

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


クリティカルチェーンの定義から小規模プロジェクトの難しさを考える

小規模開発の難しさは独特です。これまでも問題点の指摘と解決法が提案されてきました。

改善に書けられる工数が少ない

プロセス改善ブームの前、多くのヨレプロジェクトが予算の2倍を消費していた頃は、会社の存続を左右する大規模開発に比べて被害が少ないので、小規模プロジェクトはあまり関心を持たれませんでした。やがて、大規模プロジェクトが統計的な手法でうまくいくようになると、小規模プロジェクトの被害が無視できなくなりました。

しかし、小規模プロジェクトでは改善の工数を大きく割く事が困難で、標準プロセスを管理する独立したSEPG(Software Engineering Process Group)を作る事も困難です。そこで行われたのは、大規模システムで行われている管理手法の簡素化です。標準プロセスをシンプルにすることと、自律的な改善活動でした(VSEセンター:資料ダウンロード)。

外乱による変動が大きい

しかし、小規模プロジェクトの難しさは、改善の工数が少ないだけではありません。規模が小さいので外乱による影響を受け易いのです。

環境、実現方法、業務ドメインの未知の問題が発覚すると、プロジェクトはその対応に追われます。脆弱性対応など、外乱による問題は規模に関係なく同じように理解と対応が求められますので、知識と経験の蓄積が必要とされます。

増員が難しい

このような問題を認識しても、まだ小規模プロジェクトの難しさの本質を表現できずにいました。先日、CCPM(リンク先はWikipedia)におけるクリティカル・チェーンの定義を見ていて、増員できない事が問題を難しくする事に気付きました。

大規模プロジェクトでは、クリティカルパス法やPERT法のように「作業員を雇用することが容易」という前提を置く事が可能です。しかし、小規模プロジェクトでは

  • 増員によるコスト増加の比率が高い
  • 教育コストの比率が高い
  • 一人分の初心者向け作業を切り出すことが困難

といった理由から、増員が困難です。このことで、「作業工程上の従属関係」だけでなく、クリティカルチェーンの様に「必要リソースが限られているために発生する従属関係」の考慮が必要になります。

リソース制限による難しさ

例えば並行して実行可能な2、3、4人日の作業A、B、C、があった場合、3人で実行すれば最短の4日で完了できますが、メンバーが2人なら最短で5日かかります。これを4.5日でとりあえず動かして欲しいと言われたなら、どのような対応ができるか考えてみましょう。

増員:トレーニングに1日かかるなら、指導1日もかかるので、3、4、4日となって4日で終わらせる事ができる反面、2人日の追加工数が必要です。このようにうまく配員できるかどうかという問題もあります。

手伝い:半日分の作業をもう一人に手伝ってもらえるなら、何とかなりそうです。しかし作業に専門性があるなら、その理解に必要な時間分は、はみ出てしまいます。

共通化:まだまだ上流なら、作業や構造の共通化で何とかなるかもしれません。でも、すでにきちんと設計されていたなら、難しいでしょう。

作業をショートカット:テストを端折ってでもリリースして欲しい。というお話を聞く事もありますが、障害対応に必要な作業で他の作業ができなくなりますので、一番危険な方法です。

後回し:保守用ドキュメントはリリース後に回すなど、作業内容を精査してリリースに必要な作業だけを実施します。リリースの目的が他のモジュールとの結合テストなら、有効な方法かも知れません。

以上の方法を考えると後回しが有効だと思われますが、開発標準に抵触する可能性がありますし、全体の作業内容を良く理解していないと混乱を生じる可能性があります。

残業というバッファ

クリティカルチェーンの正攻法はCCPMのように、あらかじめバッファを確保する事、他の作業からリソースを回す事です。本当に使える開発プロセスで書かれているように、大規模プロジェクトでは理想見積もりの1.5〜2倍の予算を確保してスケジュールがきめられるので、バッファをとれるかもしれません。

しかし、小規模プロジェクトの場合は、発注側が詳細な作業内容を把握しています。このため、理想見積もりを基準に予算が確保され、スケジュールを決められる傾向があります。

そこで小規模プロジェクトでは、残業時間がバッファになりがちです。スケジュールが厳しいからと、あらかじめ残業が見込まれてしまうと、さらに打つ手が限られてしまいます。

小規模プロジェクトの難しさ

そこで、いざとなれば開発標準をよく理解して、顧客との合意が可能な範囲で作業の最適化を行い、優先度の低い作業や手戻りの可能性のある作業を後に回すといった柔軟さが求められる事になります(Win-Winプロセス(ウォータフォール編)追記)。

このような方策は作業のショートカットと紙一重です。作業間の関係を理解した上で、独自のプロセスを構築する。そのようなアクロバティックな難しさが小規模プロジェクトには存在します。

クリティカルチェーンの定義から小規模プロジェクトの難しさを考えてみました。小規模開発では、改善工数の制約や外乱の影響を受け易いほか増員が困難で、クリティカルチェーンの特性であるリソースの制約があります。そこに予算とスケジュールの制約が加わるので、独特の難しさが生じているのだと思います。

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

[#agileto2014] コーディネートは全体で - Agile Tour Osaka 2014「パタン特集」 -

Agile Tour Osaka 2014「パタン特集」に参加しました。

パタン探し

午前中は「@haradakiroと行くパタン探し」というオプション企画で、伊丹の町を歩きながらクリストファー・アレグザンダーのパタンを探しました。

クリストファー・アレグザンダーは建築家で、心地よいと感じるパタンを、町、建物、施行の3レベルにまとめました。たとえば、小さな広場、南向きの屋外、いっぱいに開く窓、というパタンの組み合わせを聞くと、素人の私でもなんとなく良いイメージがわきます。

このようにパタンを体系化したものをパタン・ランゲージと呼びます。クリストファー・アレグザンダーの書籍名についている冠詞は「a」で、本に書かれたものはアレグザンダーが見つけたものであり、他にもパタン・ランゲージは存在するという意味だそうです。

ワークショップ&ディスカッション

懸田さんのワークショップでは、謎のAさんが健康的な生活が取り戻せるように、

  • 力の衝突(フォース)を 明らかにする
  • 解決策とパタンの名前を考える
  • スケールで分類する
  • スケールの異なるパターンを組み合わせて素敵な未来を 描く

といった作業をしました。ここでスケールという概念が出てきて、アレグザンダーが3つのレベルにまとめていた事が思い出されました。

Posauneさんの講演は「テスト自動化のパタンランゲージ」でした。以前聞いた内容でしたが、ワークショップのあとで聞くと、パタンを間連付ける事の重要性を感じると共に、「スケール」のない事が気になりました。

ディスカッションでは小林サンからの午前中の報告のあと、原田サンが登場。

  • パタンとは対立のフォースをそらすもの
  • 良いパタンはあたり前のもの
  • パタンはソリューションカタログではない

というお話がありました。

おわりに

対立するフォースをそらせるパタンを関係付け体系化したものがパタンランゲージです。パタンにはレベルがあり、それらを組み合わせて、何を、なぜ、どのように、作るかを考えます(このように物事の対立を前提に解決する点は、TOCfEに似ていると思いました)。

ソフトウェアでパタンというと、最初に思い出すのはデザインパターンです。でもこれは、実現したいものの一部に過ぎません。実現する際に立ちはだかるフォースを避けてより良いものを実現するには、アーキテクチャや組織のパタンなども組み合わせる必要があります。

ソフトウェアを開発する技術者は「プログラマ」と呼ばれる事が多いですが、ソフトウェアを実現する行為は、プログラミングのレベルを超えたコーディネートだと思います。開発に関わる体制、プロセス、アーキテクチャ、もちろんプログラム、に存在するフォースを利害関係者と調整し、進行し、実践するからです。

それは、対立する課題からよりよい解決策を求める作業です。 パタン・ランゲージの視点で見ると、我々の仕事のゴールは色々なレベルのパタンを組み合わせて、より良いシステムを作り上げる事だと思います。

そこで技術者に求められるのは、より良いソフトウェアを実現できるように、会社間、組織、モチベーション、技術、など複数のレベルのパタンを常に洗練し、パタン・ランゲージとして用意することです。複数のレベルのパタンをコーディネートして、より良いシステムを実現することが必要だからです。

Agile Tour Osaka 2014に参加して、特定のレベルを最適化するだけでは不十分だと考えるようになりました。全体をうまく構成できるように、広い視点を持って、パタン・ランゲージを用意できるように心がけたいと思います。

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


ソフトウェアと制約と自由 - 「納品」をなくせばうまくいくを読んで -

倉貫さんの「納品」をなくせばうまくいく を読み終えました。

この本に示されている「納品のない受託開発」は単に技術をあわせただけでなく、
イノベーションの原型である シュムペーターの新結合遂行の例(イノベーションに背を向け続けた研究開発)だと思いました。読み進めるにつれて、アジャイルをはじめとする技術(ARC)との関係、ビジネスモデル、対象マーケット、営業力、ソフトウェアの特性、について、色々と考えさせられました。

ARCとの関係

本を読む前に少し書きましたが、倉貫さんの考えは、リーンスタートアップ、アジャイル開発、DevOpsといった考え方と繋がっています。かつて倉貫さんはARC(Agile, Ruby, Cloud)という技術的な視点で語られていましたが、これが、「納品のない受託開発」の技術、組織、ビジネスと繋がっていると思います。

技術
組織
ビジネス
Agile
段階的に開発することで無駄なく開発できる
顧客と協調した自己組織化を実現する
リーンスタートアップにより新しいマーケットを創造する
Ruby
少ない工数で多機能なソフトウェアが構築でき、フィードバックが得易い 技術指向の人を集めることができ、相互学習の場を作ることが容易
早い段階から顧客に価値を提供し、スモールスタートできる
Cloud
やり直し容易で、小さく失敗できる
ネットワークの利用が前提の組織を構築できる
スモールスタートが可能で、必要な分だけ払えば良い

ビジネスモデル

「納品のない受託開発」はARCがベースになっていますが、それだけなら納品と関係なく実現できます。特に五月雨ウォーターフォールなら結構良い感じで無駄をなくすことができますし、準委任契約なら顧客と対立することも少ないでしょう。

また、月額定額というモデルは書籍中に出てくるSaaSに限らず、昔からある保守契約や永和システムマネジメントさんの「価値創造契約」(終了時の利用条件と休止が異なる?)もあります。

「納品のない受託開発」の特徴は、月額定額という表面的なビジネスモデルではなく、ターゲットとするマーケットが新しい点だと思います。

対象のマーケット

「納品のない受託開発」ターゲットは新規ビジネスです。しかも、大規模投資が必要なビジネスではなく、リーンスタートアップが向いている小さく始められるビジネスです。

ソフトウェア開発は昔からの大規模化の流れのほか、1990年代から小規模化が始まっています。規模がドンドン小さくなり、最後に行き着くところの一つが「納品のない受託開発」で実現するオールラウンドなエンジニアによる小規模開発かもしれません。

単に小規模であるなら景気の影響を受けてしまいますが、新規ビジネスですので不景気なときほど重視されるソフトウェア開発です。規模の大きさを狙わず、社会を替えていく小規模に狙いを定めたスーパーニッチのマーケットです。

営業力

「納品のない受託開発」は、マーケティングはしても営業しないとされています。情報発信が人を集め(情報を得るには Give & Give)、効果的なマーケティングになる。まるで、コミュニティのような営業戦略です。

この方法は新しいマーケットには効果的だと思います。いずれにしろ情報を伝える必要があるので、情報発信をインターネットで行い、興味を持つ人を集め、営業することなく、問い合わせのみに対応する。飛び入りに比べて非常に効果的です。

これができるのは、倉貫さんが率いられているからでしょう。その情報発信力は大きな営業力になっていると思います。会社を大きくする必要はなくとも、次の倉貫さんが生まれるかどうかがマーケット継続の課題で、問題が顕在化する前に後継者を得るか、社会的な認知を受ける必要があると思いました。

ソフトウェアの特性

「ソフトウェア」はハードウェアの対比から生まれた言葉です。ハードウェアでもプログラミングは可能ですが、ソフトウェアで実現することでシステムが柔軟になります。

しかし、ソフトウェアはその柔軟性が故に、一定の制約がないと混乱してしまいます。スパゲティプログラムに対する構造化プログラミングのほか、ドキュメントやプロセスの標準化も混乱を避けるための制約の一つでしょう。

しかし、単純で教条的なウォーターフォールによる固定的な制約の与え方は、 ソフトウェアの特性を奪い、柔軟な開発を難しくする、あるいはより混乱させる、と言う事態を招きます。

そこで、アジャイル開発では、繰り返し単にであるイテレーション中は原則的に仕様を凍結する代わりに、イテレーション毎に仕様の見直しを許して、ソフトウェアの特性を生かすような制約を与えました。

このような開発法で、Ruby on Railsのような強力なフレームワークを用いると、イテレーション毎に価値をユーザに提供できるようになるので、適切なフィードバックを得易くなります。

ここで、Ruby on Railsはソフトウェアに対する制約で、まつもとさんの言われる
ある種の制約は自由を増やす」 状態になっていると思いました。

最後に

私もエンジニアですので、ぼんやりと独立を考えたこともあります。その際のネックが、営業力、技術力、資本力、でした。

倉貫さんの「納品のない受託開発」は、これらをコミュニティ的な方法、Ruby、クラウドとリーンスタートアップ、によって解決されました。さらに、新しいマーケットを開拓することで、新結合を遂行し、社会の変革を始められたと思います。

あえて限界を考えるなら、上に挙げた倉貫さん個人に依存する限界のほか、Railsの限界、規模の限界だと思います。

Rubyコミュニティも活発で、新しい技術が継続的に出てくると考えられることから、その限界は遠いのかもしれません。もし、「納品のない受託開発」に関わる中から、色々な支援が行われたなら、限界はさらに遠のき未来が広がるかもしれません。

規模の限界は、一定の体制が必要になる場合(「納品」をなくさなくてもうまくいく)です。しかし、初めから大きな体制が必要な場合は、それを支援するフレームワークが支援してくれないなら手を出さないのだと思います。

問題となるのは、初めは小さく始めたのに、ユーザの増加によって体制が大きくなる場合だと思います。たぶん、この場合は小さなコンポーネントの組合せで実現することで分割統治するか、不可能な場合は他の業者への引き継ぎをして顧客の卒業を支援されるのでしょう。

いずれにしろ、新しいマーケットを開発し、社会の構造変革の一端を担われることになると思います。そこには多くの可能性と、いくつかの課題があると思います。

それは「どのような制約を与えればソフトウェアの特性を生かすことができるか」という大きな社会実験でもあると思います。「納品のない受託開発」がどのように発展していくか、とても楽しみにしています。

おまけ

かつて倉貫さんが大阪に来られて、リーンスタートアップの勉強会が行われました(ちょっとだけ関係する記事:リーンを考える - 無駄と必要なアソビ - )。

その時に、「ビジネスになることは考えることができるが、それを事業にすべきかどうかわからない」と質問しました。それに対して「そのビジネスを通して何を実現しようとしているか、ビジョンが大切です」といった主旨の回答をいただきました。

ビジネスでも仕事でも、そのこと自身ではなく、それを通して何を実現するかが大切だと思います。この本に書かれたビジョンはとても良心的で技術者の理想の姿です。

「納品のない受託開発」があたり前のビジネスの一つになることを期待すると共に、「納品のない受託開発」でなくてもその理想の実現を目指したいと思いました。

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


レビューを考える - SEA関西プロセス分科会 - #seakansai

森崎先生のレビューの講演に参加しました。
個人的には@ITの記事のようなことを期待していたのですが、そのような記事ではわからない議論をすることができてとても有用な講演でした。

議論を通じて感じたことは以下の点です。

(a) 開発者は項目の抜けに敏感

 実践していなくても頭の中がWモデルになっているのかもしれません。テスト項目の源泉を仕様書に求めるので、どうしても項目の抜けが気になるのでしょう。

(b) レビューに優先順位をつける

 優先順位というとリスクベーステストを思い浮かべてしまい、全てをしないでどうするのかと思われるかもしえません。しかし、極限までレビューすることは困難で、時間の制約や体力の限界で終わってしまうので、優先順にレビューのフォーカスを変えていくことが有効だと思いました。

(c) レビュー道の極意は、レビューをせずにバグをとる

 私が勝手にN先生のフロントローディングの話をまねました。すべてをレビューできなければ、その対象を減らすために、ドキュメントのひな型を用意する、ワープロの文章チェック機能を使う、エディタの自動整形機能を使う、静的解析ツールを利用するなど、効率化や自動化は有効でしょう。

(d) レビュー技術の研鑽には経験を積むことも重要

 ドメイン知識がソースコードになっていることから、コードを良く知っているというのも、抽象化できる人なら高度な技術者なのだろうと思います。理由もなく、これまでそうしていたからというのは統一性には役立ちますが、将来役に立たなくなるでしょう。

(e) レビューの特性を生かせ

 テストで見つかると工数がかかるからということがレビューのモチベーションになっていますが、それだとどれだけ時間をかけても良いことになってしまいます。しかし、欠陥の種類によってはテストの方が早く見つかるものも少なくないでしょう。懇親会ではテストは積み上げという議論があり、それからするとレビューの特徴はトップダウンです。レビューに向いているトップダウンでしかわからない所を攻めるべきでしょう。ボトムの細かなところは、なるべくほかの手段で済ませたいですね(それには(c)が有効でしょう)。

つらつらと書きましたが、このようなことを考える良いきっかけになりました。

要求開発はアジャイルのフロントローディング #redajp

要求開発アライアンス 西日本10月勉強会に参加しました。

これまで、XPJUG関西のMLなどで名前は知っていたもののよく理解していませんでした。今回はチュートリアル編と言うことでお勉強のために参加しました。

まずは稲田さんの概要説明です。感想を交えながら主要なキーワードを説明されました。後半は「要求開発~価値ある要求を導き出すプロセスとモデリング」の共著者の萩本が、要求開発への思いを要求開発、そして匠メソッドに至った経緯を含めて説明されました。

1.全体の感想

最も印象的だったのは

「開発時にモデリングしていては遅すぎる」

と言う言葉でした。アジャイル開発では、顧客に価値を提供するために優先度の高い仕様から実現しますが、要求開発はバックログとして仕様を具体化する前にも、IT技術者が関わって価値の高い者を提供しようというものです。いわば、アジャイル開発のフロントローディングです。

このことが実現できるなら、仕様をあらかじめ決めざるを得ない、アジャイル開発の効果が少ない場面でも有効だと思いました。スコープが変更できない場面でアジャイルは、段階的に開発することで、技術的に未知な部分やUXのリスクを低減できるものの、価値を想像するという感覚は生まれません。そのような開発においても、IT技術者が要件定義の最初から関与することで、戦力的な価値を提供可能な要求を開発することができると思います。

2.要求開発が提供するもの

要求開発は、必要な事と、選択して整備する仕組みを提供します。

その基本は、こたつモデルと呼ばれるもので、戦略的(将来の価値)、業務問題解決(現在の価値)、技術活用の視点、この3つでこたつを囲むように進めていきます。価値、戦略、業務、IT活用、IT実現、に分けて、それらをつなげて、同時並行に回します。早くつなげて価値を創造するのです。戦略と実現の線上にしか価値は存在しないのです。

これらはWHATとHOWの関係です。実装(HOW)に対する要求(WHAT)のように、要求(HOW)に対する業務(WHAT)、業務(HOW)に対する戦略(WHAT)という関係です。これらを、トップダウンに決めるというよりは、HOWを手さぐりしながら開発していきます。そこでは、ものを作る力ではなく、描く力(価値・要求を手さぐりでデザインする)が重要です。要求開発で用いる「プロジェクトシート」は将来の価値と短期的視野で表します。

要求開発で実施することは、フェーズ(準備、立案、デザイン、シフト)とPDCAのマトリックスで表され、「プロセスキャビネット」と呼ばれます。これらは選択的に実施されるのですが、プロセスセルという枠組みがあり、必要と思われるものを組み合わせてプロセスフローを実現します。稲田さんは、この仕組みを「詳細に走らないように用いています」とのことでした。

3.要求開発への思い

要求開発は、萩本さんをはじめとする、今世紀の初めの頃の豆蔵の方達が提唱されました(豆蔵は、オブジェクト指向、RUP、アジャイル開発などで有名な会社です)。ビジネスの開発方法論の必要性から、BDA(ビジネス・ドリブン・アーキテクチャ)、そして要求開発の方法論に発展したそうです。要求開発はカスタマイズ可能で、目的と手段を連鎖させ、プロセスセルはPDCAの慣習化として実現され、無駄なものを作らない方法です。そこには、分析モデルを開発で作るのはおかしい、という思いがあったようです。

要求開発では価値のあるものをつくります。要求開発の4象限はRUPと同じで、HOWはWHATに、つまり価値の高いものを作るためにITエンジニアが手さぐりの協力をします。システム開発以降でIT技術者が協力してももう遅いのです。業務を変えないといけないので、開発はビジネスのところでします。ビジネスの中でアジャイルするのです。

ビジネス戦略を決める際に予想することはは難しいです。やっていないとわからないところがあるので、それをアジャイルでやってみます。そのために、「こたつモデル」は重要で、知識のカスケードをするためにこたつを実現します。ただ、立場の違う人が集まるだけでは空中戦になりがちで、声の大きいものが勝ってします。そこで、ファシリテーションとマネジメントが重要になってきます。

このような萩本さんのお話を聞いて、なぜXPJUG関西の人たちが注目しているかがわかったような気がしました。

4.まとめ

ソフトウェア開発は、単純なウォーターフォールモデルで実現できるような簡単なものではなく、自分たちの能力とその限界を知った上で最高のパフォーマンスを実現しなければうまくいきません。そのための一つの答えがアジャイル開発であったのです。しかし、システム開発を最初からアジャイル開発だけで実現できないので、従来のV字モデル(あるいはW字モデル)の実装部分だけを、アジャイル開発に置き換えている会社も多いでしょう。でも、それではだめだったのです。

価値の高いソフトウェアを開発するには、要求は定義するだけではだめで、開発しないといけないということなのです。要求開発は、いわば「アジャイル開発のフロントローディング」だったのです。

(聞きかじりを個人的な思いでまとめました。間違い等ありましたらご指摘ください)


アジャイルを考える - Agile Tour Osaka 2011 -

去年は自宅で見ていたAgile Tour Osaka 2011ですが、今年はLTに出番がいただけたので朝から参加しました。講演を聞く中で、多くの刺激をいただくことができました。

1.インパクトのあった言葉

アジャイルを標榜しながらもチケット駆動開発で現場を改善しようとしている私にとって、最もインパクトのあった言葉は、

アジャイル開発ができない理由として「制約」と言われるものは「解決すべき妨害事項」

「守破離」と言われるが、「守」をせずに「破」をしてしまう

という@ryuzeeさんのお話でした。@ryuzeeさんのほか@smorisaki先生のお話にあったように、何かをするには説明責任が伴いますし、何かをせずにおくことも

変化しなければ緩やかに滅びる、という背任!(@ryuzeeさん)

であるなら、安易にプロジェクトを進めるのではなく、解決すべき妨害事項が現時点においては制約であることを説明する必要があると思いました。

2.アジャイル開発導入への妨害リスト

私から見えている「妨害リスト」は以下のようなものだと思います。

契約
まずはこれでしょう。準委任でなく一括請負になる場合には、減価償却したいという場合があって、ちょっと厄介です。また、藤井さんの講演にあったように、信頼関係を築かないと始まりません。

多能工を増やせない
複雑で先進的なシステムの場合、すべてを把握・実現できる多能工ではなく、専門工になりがちです。いずれは多能工化したくとも、新しい技術を順次取り入れたり、新しい人が入るような状況だと、実現が困難になります。

システムの並行開発
連携する複数システムを並行して開発する場合など、あらかじめインタフェースを決めて開発します。インタフェース汎用的でない場合などは仕様が限定されてしまい、段階的にリリースする場合も、スコープの変更ではなくリスク低減が目的とされます。

危機感の共有
実は、組織やチーム内の合意形成が最も困難ではないかと思っています。様々なステークホルダーのいる中で、プロジェクトの目標は、価値、利益、信頼性、QOLなど様々ありますので、プロジェクトの問題点が共有でき、解決法としての合意が必要になります。

それぞれ程度の問題で、簡単な問題や長期的に効果が見込める問題であれば解決すべきでしょう。

しかし、現実を見ると目の前にはプロジェクトがありそこで求められていることは、アジャイルを実践することだけではありません。すぐに求められていることは、アジャイルを実践した先にあることなのだと思います。

2.アジャイル開発導入をあきらめてみる

アジャイルを一旦あきらめて、すぐに解決したい問題の観点で、各講演を見直すと、以下のような項目があがります。

任せること(設楽さん)
そのために細分化、見える化、自動化する。見える化は変化を検出可能にすること。チケットをうまく使えばできそうです。

説明すること(森崎先生)
事例とシミュレーションを組み合わせて説明する(Exsample scenario)。全てを実績で説明することが困難な場合、過去の実績と未来の予測を組み合わせて利用する方法です。メトリクスサーバをうまく利用できそうです。

見積もりと計画(藤井さん)
処理されるデータを中心に見積もるCOSMIC法は興味深いと思いました。ファンクションポイント法も表面的な機能だけでなく、内部のデータも見積もりに加える事例もあるようですので、分野によっては効果的だと思います。また、ベーム先生のアンカー留めスパイラルモデル(1994)は、マイルストーンをしっかり決めて守る事なのだと思います。この他にも、アジャイルUP、AMDD、southernSCOPEといったキーワードは参考になると思います。

自己組織化(吉羽さん)
トップダウンの外科医チームのような組織は、構造化プログラミングされた巨大なプログラムだと思いました。頑張れば何とかなるかもしれませんが、外乱に強い安定した組織にするには、オブジェクトの能力が発揮できる自律分散型の組織が必要だと思いました。

これらは、成功したアジャイルにより得られるものではありますが、危機感の共有と工夫によってある程度実現できるのではないかと思っています。そして効率化していけば、その先にアジャイル開発に近いものが見えてくるのではないかと思っています。

謝辞

このように多くの刺激をいただけたAgile Tour Osaka 2011のスタッフのみなさま、発表者の皆様に感謝いたします。

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


[#TiDD] チケット駆動開発によるアダプタブル・ウォータフォール開発 #agileto2011

Agile Tour Osaka 2011でライトニイングトークをさせていただきました。当日になって修正したり、説明を追加してしまい。3分の2ほどしかお話しできませんでした。せっかくスライドを作りましたので公開します。

「チケット駆動開発によるアダプタブル・ウォータフォール開発」というタイトルで、ウォータフォール開発には難しいことがあるけど、チケット駆動開発を導入するとアジャイルの良さを取り入れることができるというお話です。アダプタブルというのは、アジャイル開発の名称の候補であった(参考アジャイルマニフェスト10周年 - アジャイルマニフェストはどう生まれたのか<kawaguti の日記>)アダプティブを参考に、これまで従来型開発における補完型チケット駆動開発と呼んでいたものに命名しましたです。当初、アダプティブにしようかとも思ったのですが、あらかじめ変更のための仕組みを入れておくのではなく、必要に応じて変更の仕組みを入れることが可能であることから、アダプタブルとしました。

まだまだ整理しないといけないこともありますので、これから徐々にやっていこうと思います。


Jenkinsの特長 - メトリクス収集サーバの視点から -

第1回大阪Jenkins勉強会に参加してきました。これまでXP祭り関西でHudsnの運用のお話を聞いたことがありましたが、直接動作を見ながらの説明で良くわかりました。以下、自分なりのまとめと、メトリクス収集サーバの観点からの感想です。

Jenkinsまとめ

JenkinsはHudsonをルーツとするCI(継続的統合)ツールです。ソフトウェア開発を進める中で、以外とはまりやすいのがソフトウェアの結合です。インタフェースを決めて開発をしていたのに動かない、この前まで動いていたのに動かなくなった、担当者がいないとビルドできない、といったことは、笑い話になるほどありがちです。

CIツールを用いると、ソフトウェアのビルド、デプロイ、テストを常に実行する環境を構築できます。ここでいう「常に」というのは

・必要なときに画面あるいはコマンドラインから
・リポジトリにコミットしたとき
・定期的にリポジトリをポーリング(チェック)して更新があったとき

です。Subversionを用いたJavaの開発で使われることが多いようですが、勉強会の時点で427(どこかの薬局のCMを思い出しますね)ものプラグインによって、様々な言語や環境と連携することができます。もちろん、シェルスクリブト等を介して外部のコマンドと連携することもできます。

上述の起動タイミングのうち、ポーリングによる方式だと、頻繁に更新されるリポジトリでの実行負荷を下げることができますし、さらに複数のJenkinsで連携することもできるそうなので、大規模な開発にも対応できるようです。

そしてJenkinsで忘れてならないのはインストールが容易なことです。コマンドラインでたった1行実行するだけで、インストールができます。プラグインの設定やプロジェクトの設定もインストール時に構築されるWebの画面から簡単にできます。勉強会のLTではHudsonからJenkinsへのアップグレードも非常に容易であることが、開発者の川口さん自身による動画で紹介されました。

メトリクス収集サーバの視点から

ソフトウェア工学の世界では、当初からメトリクスの重要性が語られ、多くのメトリクスが提唱され、実証されてきました。それぞれのメトリクスには有用な場面があるものの、その収集のための負担の大きいことから、コード行数以外はあまり活用されてきませんでした。

そこで、開発者に負担を与えないように、リポジトリからこっそりとメトリクスを収集する方法がとられるようになりました。私もEPM(PDF)というメトリクス収集環境の開発にかかわりました。しかし、その開発は、とても大変でした。

メトリクス収集環境で最も大変なのは、サーバの構築とツールのインストールです。1日1回メトリクスを収集するには、ツールのインストールはもちろんのこと、関連ライブラリWebサーバやコンテナのインストール、アカウントやcronの設定が必要です。このあたりになるとインストールできる人が限られてきますので、簡易なインストーラの開発や、OSの仮想イメージでの提供までしていました。

しかし、Jenkinsを用いたならツールの開発だけで済みますし、基本的なメトリクスならプラグインもあるでしょう。開発者に負担を与えることなくメトリクスを収集できるので、めったに役に立たないメトリクスであっても、あらかじめ収集しておくといったことも可能になるでしょう。

勉強会でもメトリクス収集の話がありました。メトリクスの収集だけであれば品質保向上にはなりませんが、作業やプロダクトの状況確認や、異常の早期発見には大いに役立つでしょう。

このように、Jenkinsのソフトウェア工学への活用には、大いに期待しています。



より以前の記事一覧