第1回SEMATカーネル勉強会で考えた状態指向とプロセス指向のギャップ
第1回SEMATカーネル勉強会に参加しました。
- SEMATカーネルとは、SEMATというプロジェクトの核(kernel)
- SEMATとは、ソフトウェア工学(software engineering)を「再建」しようとする試み
詳細は省略しますので、平鍋氏の『SEMAT.org にて「ソフトウェア工学再建」運動が開始：An Agile Way』という記事や、SEMATの詳細をご覧下さい。
※ちなみに"SEMAT"の発音は「シーマット」(sea-mat)でいいようです。SEMAT創始者Ivar Jacobsonのスピーチによると。
品質・テストの重視は日本の独自性
さて、第1回SEMATカーネル勉強会の内容については、最後の課題共有ワークショップが面白かった。参加者から提出された課題のなかで、一番多かったのが「個人のスキル」で、二番目が「品質・テスト」でした。
たしか『ソフトウェア企業の競争戦略』で論じられていたはずですが、ソフトウェア産業には「お国柄」があるようですね。西欧は科学的合理性や学術的美しさ（Smalltalk流行ってるし）、米国はとにかくビジネス（金儲けが正義）、日本はとにかく品質（テスト大好き）というお国柄がよく出てたという。
これは単なる「業界文化」の違いではなくて、もっと深い根を持つ文化的差異だと思うんですよね。西欧文化、米国文化、日本文化の違い。普遍主義、資本主義、手法主義とでも言えそうな。
まあ良し悪しはどんな特徴にもあるわけですし、自分の特徴とは一生つきあっていくしかないわけです。日本のソフトウェア産業は「品質重視」を強みにしていくのが前向きだと思います。とくにバグがあると人命に関わるような組み込みソフトウェアの品質保証などでは「日本」のブランド価値が上がるといいですね。
Appleは"Designed by Apple in California"ですけど、"The software of this product is tested by X in Japan"ってブランド入れるようになったらいいな、なんて。
SEMATはプロセス指向ではなく状態指向
さて、第1回SEMATカーネル勉強会のプログラムを遡って、名古屋大学山本修一郎先生の『SEMATの基本概念と活用上の留意点』という講義です。「SEMAT Kernelは状態指向であって、プロセス指向ではない」、「言い換えるとゴール指向だ」という指摘は興味深い。
SEMATによる記述方法は、まず「あるべき状態」(to-be)と「現状」(as-is)を記述し、そのギャップを埋める活動を実行し、「あるべき状態」が達成されたことを確認する、というPDCAサイクル的な考え方になっているようです。ここではプロセスよりも状態が重視されています。
さらに山本先生は「日本人はプロセス思考に寄っているので、SEMATの考え方は理解しづらいのでは」と指摘しました。そうかもしれません。
状態指向のPERTと、プロセス思考のWBS
日本ではスケジュール管理でPERTを書く際にも、状態指向ではなくプロセス指向で描く人が多いのではないでしょうか。PERT図では、作業を矢印、作業の開始状態・完了状態を○印で表します。これは状態指向の記法です。一方で、これを逆にしたプロセス指向の記法も見かけます。
PERTよりもWBS (Work Breakdown Structure；作業分解構造) とガントチャートを使う現場が多そうなのも、プロセス思考性向と関係しているような気がしないでもないです。
日本の「型」はプロセス指向で、SEMATの記述パラダイムに馴染まない？
さて、日本では「型」という言葉があります。クリストファー・アレグザンダー的なパターン(pattern)に似てます。ソフトウェア開発の「型」は、当然ながらSEMATで記述しうるはずです。
ただし、日本では「型」がプロセスとして捉えられる傾向があるでしょうから、注意が必要ですね。ここでSEMATとのギャップがあるかもしれません。
「型」の差異について考えてみましょう。プロセスで捉えると差異があるような「型」同士でも、状態で捉えると大差ないようなものがある。要するに、インプットとアウトプットだけ見て、プロセスをブラックボックスとみなしたときに「同じブラックボックス」なら、それを「同じプラクティス」だと呼びましょう、というのがSEMATの考え方です。
一方、日本人はそのブラックボックスの中身にこだわる人が多そう。ブラックボックスの中身とは、プロセスや、やり方や、「手つき」ですね。ある意味での精神論。極端に言うと、同じアウトプットが出てきても「手間ひまかけてない」とか「心がこもってない」とか難癖つける文化が無いわけではない。
よくある都市伝説っぽい話を引用すると、
Excelで大量の単純作業を指示されたので、VBA書いて一瞬で終わらせた。1日かかるはずの仕事が1時間で終わったので、褒められるかと思って報告したら、「きちんと手でやりなおせ！」と言われた。この会社辞めたい。
といった話は聞いたことがあるのではないでしょうか。ここにはプロセス指向と状態指向、あるいはホワイトボックス思考とブラックボックス思考の対比が、戯画的に描写されているわけですね。
常駐・人月見積はホワイトボックス思考
ちなみに、ホワイトボックスとブラックボックスで言えば、『「ユーザー企業は出席をとるな」，日本IBMの大歳社長が提言：ITpro』（2001年）に代表されるような、「常駐と人月見積」の関係にも通じるかもしれません。
発注者が「請負契約上の成果物がきちんと納入されればよい」とは考えずに、「目の届く場所で委託先のエンジニアに働かせる」ような考え方はホワイトボックス思考だと言えます。
共通フレームとSEMATのギャップ
一つ思い起こしておきたいのですが、日本にもSEMAT的な試みがあります。共通フレームというやつです。共通フレームとSEMATとの間のギャップは、いずれ問題になってくるかもしれないですね。共通フレームは明確なプロセス思考ですから。
共通フレームは，情報システムの企画から，開発，運用，保守，およびそれらに関するさまざまな作業内容を，標準的な作業項目とその中身に分類する。それぞれの作業項目は，プロセス，アクティビティ，タスクの3階層で表現される。
最初の話とつながるんですが、日本人の「品質重視」と「プロセス思考」（手法主義）って、すごく密接な関係にあると思うんですよね。さきほどのブラックボックスの話でいうと、「ブラックボックスなんだから中身どうでもいい」（"It's YOUR business!"という感じ？）と考えるのが米国的だとすると、精神論で中身にこだわるのが日本的。それはつまり内部品質の重視ということでしょうから。
というわけで、SEMATでもなんでも使えるものは使って、プロセス指向・ホワイトボックス思考の良いところを殺さずに、できるだけ悪いところをなくしていくのが有意義じゃないでしょうか。
日本の奇妙なブラックボックス思考
そう考えると奇妙なのが日本の分業体制です。日本の強みとされている「擦り合わせ」をやろうと思ったら、いまのSIerのやり方ではダメでしょう。SEが設計書を書いて、PGがプログラミングする、みたいな分業体制。
ここだけ妙にブラックボックス思考なんですよ。SEに要求をインプットすると要件定義や仕様書がアウトプットされて、PGに仕様書をインプットするとソースコードがアウトプットされる、みたいな。それは「組み合わせ」であって、「擦り合わせ」ではないのです。
日本的「擦り合わせ」とドメイン駆動設計
「日本的」な「擦り合わせ」のソフトウェア開発とは何でしょうか。「ドメイン駆動設計」だと思います。ITアーキテクトがお客さんと話して、プログラミングもする、ドメイン駆動設計のようなやり方に変えていったほうが、日本のソフトウェア開発の文化がレベルアップするんじゃないかと思います。というのも、より「日本的」なやり方になって、「擦り合わせ」の強みを活かせるだろうからです。
個人的には、実際に会社間のシステム連携などで「擦り合わせ」がうまくできるのは、やはりアジャイルなプロジェクトだという感覚があります。
SEMATを通じてアジャイルの価値が浸透していくか
ドメイン駆動設計も基礎にアジャイルの価値を置いています。SEMATも同様です。そう考えると、日本のプロセス指向のパラダイムをSEMATで再解釈・再記述する意義がありそうです。
共通フレームのような公式なソフトウェア開発方法論に、アジャイルの価値を明に暗に埋め込んでいくことができるとしたら、それはとても有意義なことだと思います。
- プロセスやツールよりも個人と対話を、
- 包括的なドキュメントよりも動くソフトウェアを、
- 契約交渉よりも顧客との協調を、
- 計画に従うことよりも変化への対応を、
価値とする。
※ここで重要なのはアジャイルの価値(value)であって、具体的な方法(method)やプラクティス(practice)ではありません。
常駐と擦り合わせ
余談ですが、個人的に難題だと思ってるのは、「擦り合わせ」と「常駐」が結びついてしまうことですね。XPでもオンサイト顧客(on-site customer)っていいますが。このへん難しいところ。実際に常駐するとコミュニケーションとりやすいでしょうし。個人的な解決策としては、定例会議とオンライン・コラボレーションの工夫でなんとかしてます。ていうのも、常駐したら複数案件を掛け持ちしにくいです。今後は、常駐せずに「擦り合わせ」のレベルをどんどん上げていきたいです。
