無料ブログはココログ

« [#TiDD] カードかチケットか、タスクボードかBTSか | トップページ | [#TiDD] 書籍「チケット駆動開発」では広い議論を狙っています »

自動化による信頼性向上 - オブジェクト指向とアジャイル開発 -

XPやスクラムはオブジェクト指向の著名人がまとめたそうです。そのことから、アジャイル開発の繰り返し開発、テストファースト、常時結合、リファクタリング、などを考えると、オブジェクト指向開発の信頼性向上にはアジャイル開発が必然である事が見えてきました。もちろん、これらのプラクティスは変化を受け入れたり、信頼性を向上させる、作業を効率化する、などの目的がありますが、オブジェクト指向開発を適用するとそれらの効果があったという事なのかもしれないと思っています。

オブジェクト指向

Smalltalkの大家である青木淳先生らの「Smalltalkで学ぶオブジェクト指向プログラミングの本質」によると、オブジェクトのアナロジー(類推)は細胞だそうです。大きなシステムを構築できるように細胞の構造を参考にしたのでしょう。外界との間に細胞膜があり外界の信号(メっセージ)を受け取り、内部には私的データ領域(インスタンス変数)があります。このような細胞の複製とメッセージによる差異によって、大きな生命体が構成されるのです。

このアナロジーが示す事をざっくり言うと

・小さな単位のオブジェクトの組み合わせによって大きなシステムを構築する

のですね。今や当たり前に受け入れられる考え方ですね。

しかし、かつてSmalltalk-80がパソコンで動くようになったころ、オブジェクト指向には以下のような課題があると言われていました。

・動的な部分を持つ言語なので実行しないと正しく動作するかわからない
・処理系が複雑で豊富なリソース(メモリー、CPU)が必要

そこで、Smalltalkには逐次実行する環境があったのですね。インタプリタを用いて逐次実行して確認すれば、実行時に解決される動的な処理も確認する事ができます。そういう信頼性の高い小さな開発の繰り返しによって、大きなシステムが開発されていました。

そのように順次拡張されていったSmalltalkのライブラリは一つの世界を表現していて、既にあるライブラリをうまく拡張することで新しいシステムが開発されていました。その様な環境を維持するには、プログラムが単体でも組み合わせでも正しく動く事はもちろんの事、再利用が容易なようにきちんとリファクタリングされているる事が必須でした。

リソースの問題は、いまや計算機の性能向上が解決してくれましたので、オブジェクト指向開発に求められるのは、ソフトウェアの再利用性の維持と信頼性の向上になりました。

アジャイル開発

アジャイル開発ではソフトウェアを常に実行・テスト可能にしておき、段階的に開発していきます。これはオブジェクト指向を実現するための動的な要素を含む言語であっても、安心な構造であると言えるでしょう。また、リファクタリングによって再利用が容易な構造になりますので、再利用性が維持できます。

アジャイル開発は自律的な組織を前提にするなど、オブジェクト指向的な要素を含んでいます。コンウェイ(リンク先はWikipedia)は、組織構造に似たアーキテクチャが作られると言いましたが、開発方法論によって似たプロセスが生まれることもあるのですね。

自動化による信頼性向上

テスト自動化や継続的統合・デリバリーは、常に実行可能なソフトウェアを実現するだけでなく、オブジェクト指向で必要とされる信頼性向上と維持を容易にします。

・常にきれいにして問題の発生を見える化する
・問題を局所化して発見を容易にする

トヨタ式改善の基本は工場の掃除だそうです。ネジや部品が落ちていたらすぐにわかるからです。ソフトウェアをいきなり結合すると、ちらかった工場でネジを探すようなもので、見つけるのに時間がかかってしまいます。

テスト以降の工程を自動化すると、常にテストされた状態にソフトウェアを保つ事ができます。問題が生じれば前回との差分、新たに追加されたか変更された部分であると予想できます。規模が増大しても、自動化テストの範囲の不具合は比較的短時間で不具合を摘出できるでしょう(この効果によってケントベックさんが言われているように規模が大きくなっても工数があまり増加しなくなりますが、想定外のバグはうまくいかないと思っています)。

このように、アジャイル開発はオブジェクト指向開発での信頼性を向上させる仕組みを実現していると思います。

アジャイル開発のプロセス

アジャイル開発のプロセスをオブジェクト指向になぞらえると、実行しないとわからないという問題は、人間の仕様に対する理解や外界の変化、リソースの問題はアジャイル開発に必要な作業に相当するでしょう。

動的な言語と同じように、人間の要求も実際に動くモノがないと仕様は明確になりません。また、外界の変化に対応するにはなるべく早くソフトウェアをリリースする事でしょう。段階的な開発によって、その問題は軽減されるでしょう。

リソースの問題は多くのツールが支援してくれます。統合開発環境、バージョン管理ツール、障害管理ツール、xUnit、CIツールなどが作業負荷を減らしてくれるでしょう。

プロセスの自動化

プロセスは人間が実行するものです。このため、完全な自動化のほか、警告や指示、支援などは、すべてプロセスの自動化に含まれます。

開発作業の自動化と同じように、プロセスもバージョン管理や障害管理などプロセスの一部はツールによって自動化されています。しかし、ビルドツールだけでは不十分なように、プロセスもまだまだ自動化の余地が残っています。

その一つはチケット駆動開発で用いるBTSのワークフロー、ツールの関連付け、通知方法など様々な特徴だと思っています。アジャイル開発はオブジェクト指向の問題を解決する中で生まれましたが、チケット駆動開発は現場の問題を解決する中で生まれました。

様々な問題が発生する開発現場において、アジャイル開発だけでは負担の大きい問題もあるでしょう。その解決にはプロセスの自動化が効果を発揮する場面があると思っています。

まとめ

XPが話題になった頃、前述の青木先生に「XPをどう思いますか?」と質問したとき、「同じような事は、前からしてるよ」とあまり気にしていないそぶりで言われました。当時は、研究開発をされているからだと思っていましたが、オブジェクト指向開発にとってXPのような開発スタイルは必然だったのかもしれません。

それにも拘わらず、日本ではなかなかアジャイル開発が普及しません。それは現場において単体テストまでの工程で問題点を吸収するなど工夫しているのか、それともまともなオブジェクト指向開発が行われていないのか、あるいはそろそろ限界で破綻に向かって進んでいるのか、私にはわかりません。

しかし、信頼性を向上させる観点では、実装と同時にテスト以降の作業の自動化は必須だと思います。アジャイル開発が考慮しているオブジェクト指向での信頼性をどのように担保するか、どのように効率化するか、よく検討しなければいけないと思います。


« [#TiDD] カードかチケットか、タスクボードかBTSか | トップページ | [#TiDD] 書籍「チケット駆動開発」では広い議論を狙っています »

私のアジャイル」カテゴリの記事

コメント

コメントを書く

コメントは記事投稿者が公開するまで表示されません。

(ウェブ上には掲載しません)

« [#TiDD] カードかチケットか、タスクボードかBTSか | トップページ | [#TiDD] 書籍「チケット駆動開発」では広い議論を狙っています »