ハードなプロセス、ソフトなプロセス

さかばさんの記事を読んで思ったことをラフなメモ書き。

【元ネタ】
[#TiDD] チケット駆動開発の開始タイミング - 良いプロダクトはふさわしいプロセスが生む -: ソフトウェアさかば

システム開発から属人性を排除しようとして失敗する: プログラマの思索

さかばさんが書かれているように、製造業の会社から派生したSIはハードウェアの開発に憧れて、ソフトウェア工場によるソフトウェア開発の工業化を目指していたように思える。
属人化を廃し、信頼性重視の開発スタイル。

(前略)
ソフトウェア開発の歴史を振り返ると、ソフトウェアはハードウェアの開発にあこがれていたと思います。各社が「ソフトウェア工場」を作り、ソフトウェア開発の工業化を目指していました。
工業化における品質とは主に信頼性です。計画された仕様が満たされたかどうか、設計どおりに実現されているか、それが求められます。当初定められた計画通りにできることを重視する、それをここではハードなプロセスと呼びます。
しかし、近年のソフトウェアに求められるものは、そのようなハードなプロセスでは実現が難しい柔軟な対応です。作ってみないとわからない仕様や、日々変化する実行環境とビジネスに対応できるソフトウェアです。
(後略)

ソフトウェア工場による開発を目指していたのは、製造業の会社から派生したSIだけではない。
マイクロソフトも一時期興味を持っていたようで「ソフトウェアファクトリー」のような本を出していた。

「ソフトウェアファクトリー」を僕も読んだけれど、ピンとくるものが無かった。
オブジェクト指向による限界を示した部分はなるほどと思ったけれど、内容はモデル駆動開発(MDA)のように思えた。
MDAは、抽象的な論理モデルをお絵描きしたら、動くソースを自動生成できるはずという思想。
OOAを突き詰めると、MDAにぶち当たる。

しかし、プログラムが書けない業務SEやPMはモデル駆動開発にいつも憧れているけれど、実現が難しいのが実情。
むしろ、RailsやSeasarのように、DOAによるデータモデル設計さえしっかりしていれば、優れたフレームワークによって、従来よりも大規模な実装が少人数で可能になった現実がある。

平鍋さんが主張するように、ソフトウェア開発は「プロジェクトを生産的に、協調的にするには、人の力とモチベーション、コミュニケーションを引き出すことが一番重要である」のが本質なのだろう。

チケット管理システムをつかってみよう！：An Agile Way：ITmedia オルタナティブ・ブログ

ソフトウェア開発は生物(なまもの)だ。
僕もチケット駆動開発を運用して、プロジェクトファシリテーションの各種のプラクティスを実践してみて、なるほどと思う所が沢山あった。
「ザ・ファシリテーター2―理屈じゃ、誰も動かない!」に書いてある「解けない問題を解ける問題へ変換すると、人は自然に解決する方向へ動き出す」ことを身近に感じられたからだ。
実際、ロードマップを見れば、チームのゴールが共有され、そのゴールへ到着するために何をしなくてはならないのか、メンバー自身が考え始める。

【Facilitation】解けない問題を解ける問題へ変換する: プログラマの思索

チケット駆動開発とプロジェクトファシリテーションの関係についても、もっと考えてみる。