ソフトウェア開発に必要なイメージ力

スペンサー・ジョンソン著「チーズはどこへ消えた」(扶桑社) を読みました。この本は6年前にブームになった本ですが、古本屋でたまたま見つけました(105円！)。出版社の案内にはこう書かれています。

迷路のなかに住む、２匹のネズミと２人の小人。彼らは迷路をさまよった末、チーズを発見する。チーズは、ただの食べ物ではなく、人生において私たちが追い求めるもののシンボルである。

ところがある日、そのチーズが消えた！ネズミたちは、本能のままにすぐさま新しいチーズを探しに飛び出していく。ところが小人たちは、チーズが戻って来るかも知れないと無駄な期待をかけ、現状分析にうつつを抜かすばかり。しかし、やがて一人が新しいチーズを探しに旅立つ決心を・・・。

一度の成功体験にしがみついて状況の変化に対応できない小人と、成功をイメージすることで過去を捨て新しいことに挑戦する恐怖に打ち勝つ小人の寓話とそれを聞いた人たちの議論が書かれています。

この本の発売当時は、企業に活力をもたらすためか、企業内教育にもてはやされたようです。しかし、このお話は何となく、ソフトウェア開発にも当てはまると思います。

以前書いた「能力の向上を意識する」こととも関係するのですが、仕事をどのように進めるかということです。ある意味、戦略とか、理解した上で、魂の入った、というような言葉で表わされることだと思います。

ある開発をする際には、何らかの方法論を用いて作業が進められます。しかし、うまくいかないパターンの一つに、方法論を理解せずに形だけ実施するというのがあります。しっかりと文献を読めば、なぜそのようにするのか「思い」のようなものが書かれているのでしょうけど、ルールのようにとらえて、現実を見なければうまくいきませんよね。

プロセス改善もそうですよね。「レベルXXを取得するんだ(あえて間違った表現をしています)」なんて言う言葉で、プロセスを変更したなら、営業向けには改善しても、開発作業のモチベーションがさがって、開発者や管理者はなんとかすり抜けることばかり考えてしまうでしょうね。

何かをする上で、その意味や戦略をしっかり考えてイメージすること、それが重要だと思うんですよね。でも、これは能力を向上させることにパワーを割く必要があるので、「誰でもある程度のものができるようにする」という工場化的な発想だけではうまくいかないと思います。だから、コンサルティングというビジネスが成立するのかもしれませんね。難しいところです。

もし、イメージを持っていないことが問題と認識されているなら、すぐにできることがひとつあります。「ワークショップ」です。個人が作ってからレビューするのではなく、みんなで考える場を持つことです。みんなで共通認識を持てたなら、きっと良いイメージなのでしょう。アーキテクチャの設計も、プロセス改善も、ワークショップが注目されています。

テストのパラダイム

SEA関西プロセス分科会の勉強会で紹介したリー・コープランド著「はじめて学ぶソフトウェアのテスト技法」のセクションⅢに「テストのパラダイム」の概要を説明します。

パラダイムは概念をモデル化したようなもので、「ルールと規範であり、境界を明確にし、成功するために、境界内でどう行動すればよいかを教えてくれるもの」です。情報の伝達や、教育、議論する際に役立ちますが、「いわば心理的フィルターなので、適合しないデータはふるい落とされる」というマイナス面もあります。

この本では、テストのパラダイムとしてスクリプトテストと探索的テストが取り上げられています。スクリプトテストは「要件を順番どおりに検証する」もので、いわゆるウォーターフォール型の開発で、通常行われている方法です。計画に従って、試験項目書などをあらかじめ作成し、それに基づいて試験を実施する方法で、IEEE829では8つのドキュメントが定義されているようです。

探索的テストは、テスト担当者が製品について学習(探索)しながら、テストの設計と実行を同時並行で行うものです。いい加減に行うものではなく、熟練したテスト担当者が「システムの適切な振る舞いについての仮説(メンタルモデル)」を作りながらテストするものです。「自由形式の探索的テスト」のほか、テスト担当者の方向付けのために「チャーター(指示書)」を用意することもあるようです。

それぞれ良いところがあって、スクリプトテストは、「再現性、客観性、監査性が重要なときに利用できる」ものなので、仕事をフェーズに分割できるほか、網羅的な試験が可能で、文書化により、理解や評価、管理などが可能になります。また、「最終段階では、テストケースが要件定義書を補える」と言う特徴もあります。その反面、システム要件の品質に依存し、柔軟性にかけ、試験の実施は「こなし仕事」になりがちなのでテストスキルを低下させるというマイナス面が指摘されています。

一方、探索的テストは、テストケースが事前に予測できず、直前のテスト結果にしたがって選択する必要があるときに有利です。たとえば、開発初期の段階でのパフォーマンスのベンチマークテストや、プロトタイプのテストなど開発の初期段階や、テストの終盤になり、試験項目がなくなったときなどに有効です。また、見つかった問題をさらに追求し、欠陥の規模、範囲、バリエーションなど十分に探索してフィードバックできることも利点です。しかし、「チャーター(指示書)」を用意すれば、テスト担当者にテスト対象や欠陥の種類などを方向付けられるものの、欠陥を予防する力は持っていませんし、わかりきった試験には向きません。また、ルールが定められているなら、それに従わねばならないので補完的な技法としてしか使えません。

この本では、テスト計画を古典的計画から適応型計画へ変更すべきだとしています。そして、計画の発見的な策定法として、以下のようにすべしと述べています。

• (利用可能な時間とリソースに基づいて)計画できるときに
• (利用可能な知識に基づいて)計画できるところまで計画するが
• 計画が可能になる前にはそれを行わない

そして、「目の前の問題に対し、意味のあることなら何でもしよう」と両者をうまく組み合わせて使うことをすすめています。

この構成と内容が何かに似ていると思ったのですが、そう、あのベーム先生の「アジャイルと規律」にそっくりです。あの本もパラダイムと読んでも良いような二つの開発方法の特徴を述べ、実際の現場にどのように適応させるかを書いています。「アジャイルと規律」はプロジェクトの分析方法まで踏み込んでいる点が優れていますが、「はじめて学ぶソフトウェアのテスト技法」は、テスト計画の説明であるべき姿を述べている点が優れています。

このテスト計画の説明ではアメリカ海兵隊の"Planning"という文書の「計画する際に注意すべき落とし穴」について触れています。

• あまり遠い将来まで事態を予想しようとすること
• あまりに詳細まで計画すること
• 計画の手法を制度化してしまい、計画のプロセスも計画書も固定して変えられないという硬直化した思考に陥ること
• 計画を、問題に対する変更不可能な唯一の解決策だと思い込んでしまうこと
• 計画の欠陥を識別して必要な調整を行うための、フィードバック機構の必要性を無視すること

この記述、メアリー・ポッペンディーク＆トム・ポッペンディーク「リーンソフトウェア開発」にそっくりです。あの本でも、海兵隊の説明から変化に強い開発方法を述べていますので、その本質は同じと言っても良いでしょう。

この本を読んで感じたことは二つあります。一つは、「アジャイルと規律」にしろ、この本にしろ言っていることは、当たり前のことです。ウォーターフォールに向かないところは切り出してプロトタイピングするなど、すでに似たようなことは皆さんも工夫して実施されているでしょう。しかし、それを極端な二つのタイプにモデル化することで、その特徴を示し、より効率的な開発の仕方を示していることです。このような本は、好き嫌いが分かれますが、プロジェクト戦略を考える際に役に立つので、わたしは結構好きです。

もう一つは、アジャイルやプロセス改善がすでにブームでなくなり、実践の時代になったと言うことです。世の中のものは、流行りはじめに似て非なるものがでてその違いを理解するのも大変です。そして、徐々に淘汰されて残ったものにも限界が現れる。そして、ようやく実務でどう使うかのバランスの議論が始まり実践の時代になると思います。この本や「アジャイルと規律」はそのような実践の時代の到来を知らせる本だと思いました。

来年はバランスの年に

今年一年を振り返ると色々ありましたが、無理やり分けると二つの考えの対立(あるいはせめぎあい)に思えます。

• トップダウン、ウォーターフォール、計画駆動、機能指向、性悪説
• ボトムアップ、ボトムアップ、アジャイル、オブジェクト指向、性善説

上の方には、SOAやアスペクトなども含めます。

この二つに分類すると、バランスが悪くて「ホツレ」が出てきているように思えます。試験があるものの裏技を駆使してごまかすような事件があったり、まとめのWebページが話題になったり、、、

今年のお気に入りの本を上げるなら、「アジャイルと規律」「リーン・ソフトウェア開発」でしょう。これらの本を読むまでは、そろそろウォーターフォールも限界でアジャイルかとも思っていましたが、「アジャイルと規律」はそれぞれの長所・短所を明らかにし、対象や組織の状況によって、段階的に開発したり、部分的に適用するなど、バランスをとるべきであることを述べている、とっても良い本です。でも、よく考えると、すでに同じようなことをしてませんか？

「リーン・ソフトウェア開発」は「アジャイルと規律」では最もアジャイルに分類されている、トヨタ式改善のソフトウェア版です。この本は、ソフトウェア開発の最適化とリスク回避の技術が詰まっている良い本です。でも、具体的にはリスク回避のためのオブション思考以外は、けっこう普通のオブジェクト指向でもあります。

結局、書籍はあるところに注目して書き上げたものなので、すでに色々工夫している人にとっては、けっこう普通のことが載っています。これは、オブジェクト指向を長くやってきた人が、デザインパターンやXPをそういう風に言われるのと同じだと思います。

で、なにが言いたいかというと、上にあげた2冊はバランスに注目している点がすばらしいと言うことです。具体的にああしろ、こうしろとはあまり書かれていませんが、現実の具体的な問題に対して、どのように判断するかが書かれているところが秀逸だと思います。

このようにバランスを考えた本は、20年前にもありました。テストの本で有名なマイヤースの「複合設計」です。機能指向とデータ指向で議論されていた当時、同じようにバランスをとった設計法でした。この本はわかりやすく、その内容を現場でよく使わせてもらいました。まあ、そのあとのオブジェクト指向ブームで、あまり読まれなくなっちょいましたが、、、

来年は、それぞれの要素技術をどう組み合わせてバランスをとるかが重要になるのではないでしょうか？もちろんある技術に特化した議論も進むでしょうけど、現場で実際に使われるようになれば、既存技術とどのようにバランスするかがポイントになると思います。

また、複合設計に対するオブジェクト指向のように、RonR(Ruby on Rails)あたりに吹き飛ばされるかもしれませんが、、、

最後になりましたが、本年もお世話になりました。来年もよろしくお願いいたします。

10分でわかるメトリクス

今日はSEA関西SPINで「初めて学ぶソフトウェアメトリクス」(Lawrence H. Putnam & Ware Myers著)から翻訳者の山浦恒央さんが書かれた「日本語版に寄せて－10分でわかるメトリクス－」を紹介しました。

「ソフトウェアエンジニアリング」という言葉が始めて使われた1968年にNATOの会議から現在に至るまでを、混乱期、胎動期、活動期、反抗期、成熟期に分け、メトリクスの歴史(光と影)を説明されています。この間に多くのメトリクスが提案、期待、疑問視され、行数とバグ数を軸にメトリクスが定着し、効果を上げたと述べられています。

この本の原題はFive Core Metricsで、時間、工数、機能量、信頼性、プロセス生産性について述べられています。上記の歴史はその導入として書かれているのですが、McCabeのサイクロマティック数とHalstedのソフトウェアサイエンス尺度について、非常に多く書かれています。この二つの尺度が当時、新鮮、斬新、カリスマ的だったかがうかがわれます。

リーンソフトウェア開発～CMM/CMMIの利用～

第8章：使用説明書と保証書では、大企業においては改善プログラムと闘う代わりにそれらを利用するようにすべきと書かれています。CMMとCMMIのところを要約すると

【CMMにあわせて仕事をすること】

• KPAで問題を発生させていた要因をアジャイル手法は解決する(レベル3以上で認識できる)
• CMMは現在の手法が既知の失敗パターンを解決するかを評価するだけ

【CMMIには用心すること】

• 不運にも、CMMIはソフトウェア開発の領域を超えた多くの領域を網羅するように設計されている
• 10年間の試みの結果世界一の兵站になったが、リーン思考を30の原則や方針として再挑戦している
• リーン原則を軍事調達システムのプラクティスに取り込むことは、気が遠くなるような作業になった
• しかし、その努力をたどることで、リーン原則を採用する確固たる理由が見つけられるだろう

と書かれています(このほかにもシックスシグマを利用すること、PMIには注意することが書かれています)。CMMには好意的ですが、CMMIにはかなり否定的な書き方です。リーン開発の1番目のツールは「ムダを認識する」で、CMMIはムダに大きくなったと言いたげです。CMMIはうまく参照するものだと思うのですが、必要なところを抜き出す努力がまず無駄ということでしょうか。

ちなみに、この少し前には、

【ムダの最小化をうまくやること】

• 不要な文書が廃止できないなら、なるべく上位レベルで作成すること
• 計画をリリースレベルで保持すること(この程度はどの道やらなければならない)
• 要約文書を作成すること(普通の人が短時間で理解できるなら、じゃまされないですむかもしれない)
• コーディング完了後に設計要約文書を保守用に作成する(2度手間になるから)

と書かれていて、リーンソフトウェア開発を組織のルールにあわせる工夫が必要なようです。

先日、日本の技術が米国で発達してCMM/CMMIになったような説明を聞きました。リーンも元はトヨタですから、日本発の技術を組み合わせるために、日本人が苦労すると言うのもおかしな話ですね。

＃思いつきで書いてますので、説明の順番がむちゃくちゃですみません。

リーンソフトウェア開発～できるだけ速く提供する

「決定をできるだけ遅らせる」とともに、この「できるだけ速く提供する」は重要です。

変化に対応させて手戻りを生じさせないために、コンカレントに広さ優先で、効果的なオプションを残し、最終責任時点まで決定を遅らせて開発することを説明しました。並列処理の効率を上げ、オプションのコストを下げ、最終責任時点をより遅い時期にするのがこのできるだけ遅く提供するです。

できるだけ速くというのはアジャイルすなわち機敏ということで、早い時期という意味ではありません。これを実現するには、前に説明したプルシステムで効率よく開発するとともに、各作業をスムーズに流れさせ、パイプの詰まりを生じさせないようにします。「リーンソフトウェア開発」ではこれを待ち行列理論で説明しています。

待ち行列を効率よくするにはサイクルタイムを短縮する必要があります。それには到着の平準化とサービス時間の平準化が有効です。到着の平準化が有効な例としてテストがあげられています。ウォータフォールプロセスではテストが後工程に集中し、十分なテスターがいないとボトルネックになってしまいます。作業を平準化してより速く提供するには、リリースを分ける、つまりイテレーション(繰り返し)開発が必要になります。到着の平準化はテストのみでなくもっと詳細なプロセスにおいても有効だと思います。

サービス時間の平準化には作業を細かな単位に分割することが有効です。作業時間のばらつきをなくすことで待ち行列は効率よく動かすことができます。これは、対象ソフトウェアで制御できるはずです。オブジェクト指向で推奨されているように、より細かなクラス・メソッドに分割することで、実現できると思います。なお、上流でばらつくときは下流に影響が出るので、ばらつきそうな作業は、なるべく下流にもって行くほうが良いようです。

なお、この待ち行列は人間が処理しますので、ゆとりを持たせなければなりません。作業負荷が高くなると人間が疲弊・故障し、待ち行列は止まってしまいします。XPの様に適切な作業量を守らなければなりません。

(全体にカテゴリーを変えてみました。いずれカテゴリーを独自のものに変えるようにします。)

アジャイルとプルシステム

リーソフトウェア開発におけるプルシステムとは、トヨタ式カイゼンの看板方式のことです。後工程で必要なものを前工程で用意する際に用いられるのが看板で、この看板によって生産を管理します。従来のあらかじめ用意する方法は、無駄が多く、機敏に開発することができません。YAGNI(You Aren't Going to Need It：今必要のあることだけをやれ)を実践するために、タスクカードを用いて管理します。

これは、計画の線表を後ろから引くことに似ています。前から順に線を引くと完成できないことでも、後ろから線を引くと各作業間の制約が見えてきて、並列化するなど効率的な計画を立てることができます。最小限のことに限定して、後ろから計画する。それがYAGNIとプルシステムです。

ソフトウェアメトリクス

ソフトウェア工学という言葉を知っていても、メトリクス(尺度)という言葉を知らない人は多いのではないでしょうか？最近、初めて学ぶソフトウエアメトリクス～プロジェクト見積もりのためのデータの導き方という本が出たようです。ソフトウェア開発を見える化するためには何らかの尺度に基づく定量的なデータが必要です。ひとまず買ってみます。

シンプルルール

シンプルルールは自律的な組織運営を可能にします。「リーンソフトウェア開発」ではシロアリのシンプルルールの例と、それを応用したネットワークルーティングなどの例を示して、以下の特徴を挙げています。

• 柔軟性：集団が変化する環境にすばやく順応
• ロバスト性：個体が失敗しても集団はタスクを実行できる
• 自己組織性：集団に対する指揮やトップダウン管理が少なくてすむ

シンプルなルールを決めておくことで、狭い範囲で物事を決めてしまう深さ優先でなく、システム全体を考慮しながら広さ優先の意思決定が可能になり、コンカレント開発を支援します。また、一般により良い決定である直感的な意思決定ができるようになります。

リーンソフトウェア開発 - 決定をできるだけ遅らせる

アジャイルソフトウェア開発はどこが優れているか？なかなか理解できませんでした。これまでの理解では、無駄なドキュメントを書かない、リファクタリングで変更容易性を維持する。コードの共有とペアプログラミングでコミュニケーションを向上させる、などで、概念的にはわかるものの、経験の不足している私には、なにか欠けているような気がしていました。

リーンソフトウェア開発のなかで、まずショッキングだったのは「決定をできるだけ遅らせる」という説明でした。この基本的はコンカレント開発です。従来のようにシーケンシャルに開発すると、まだ決定すべきでない変更の可能性のあることも暫定的な決定が必要とされ、生じるべくして生じた変更の対応のために、ドキュメントの変更、関係者への周知、プログラムの変更、レビュー、テスト＆デバッグといった余計な作業が生じていました。

リーンソフトウェア開発は、変更の生じそうことはそれ以上に決定をの最終責任時点まで決定まで決定しません。また、開発上、何らかの決定が必要なときには必要なオプションを保持します。このような方法で全体をコンカレント(平行)に開発します。コンカレント開発は容易でなく、また、オプションを保持することはコストがかかります。しかし、よく考えて計画することで、変更によって生じるリスクを低減するのです。

また、コンカレントに開発する場合は、開発者に自律的な行動が必要とされます。この方法は、次回に説明します。

５つの重要要因

アジャイルと規律によると、プロジェクトがアジャイルと計画駆動のどちらのホームグランドに近いかは5つの重要要因で判断できるます。アジャイルのホームグラウンドは
以下のように要に定義されています。

人：手続き的な作業が可能な人は０％、手法を改定カスタマイズ可能な人は35%
　　=>希少な熟練者が十分な割合でプロジェクト期間を通じて必要である．
　　　　手法に慣れていない人を使うリスクは高い
変化の度合い：1ヶ月あたりの要求変更の割合が50%程度
　　=>変化の度合いが非常に高い環境では設計をシンプルにして
　　　　継続的にリファクタリングするとうまくいくが，きわめて安定した
　　　　環境では再設計のコストが高くつく可能性がある
文化：カオスで反映する割合が90%
　　=>高い自由度を持つことによって，快適で権限が与えられている
　　　　と感じる文化で反映する(カオスにおける反映)
規模：小規模（典型的な場合3人月）
　　=>小規模な製品やチーム向け．暗黙知に依存しているため
　　　　規模を拡大することは困難である
重要度：
　　=>安全性が非常に重視される製品への適用事例はない．
　　　設計がシンプルで文書が少ないことによる困難が予想される

リーンソフトウエア開発

SEA関西SPINの勉強会に行ってきました。
皆さんとお話していて思ったのは、視点と対象読者が面白いと言うことです。

これまで、いろいろなアジャイル本がありましたが、この本は

• 既存の技術からアジャイルの説明を試みている
• オブジェクト指向未経験者をターゲットとしている

と言う点です。上は、前に書いた良い点ですが、下は要注意です。計画駆動の経験がないと、問題点がピンと来ないようです。まあ、アジャイルをやっているなら、余計な説明本かもしれませんが、、、