アルファのチェックリストをExcelで作成
鷲崎弘宜氏（以下、鷲崎）：島田さん、ありがとうございました。では3人目はシステム情報の小林さんよりポジション表明を頂戴します。
小林浩氏（以下、小林）：簡単に自己紹介から始めます。私は、小林浩と申します。株式会社システム情報のCMMIコンサルティング室というところにいます。CMMI（能力成熟度モデル統合）はもちろんですが、APHというアジャイルのリーダーのための行動モデルも使って、最近はお客様のプロセス改善や組織能力向上を支援しています。
鷲崎さんがけっこう私の事例も話してくれたんですけど、きっかけから簡単にお話しします。私は2014年くらいにCMMIのリードアプレイザーになりました。当時CMMIってアジャイルとか小規模プロジェクトにはそんなに使えないんじゃないかと思っている人もけっこう多かったと思います。
私は、そんなことないのになと思っていました。今回の角さんが訳してくれた『モダン・ソフトウェアエンジニアリング』の著者の1人にPaulさんという方がいるんですけど、彼はCMMIとアジャイルをどういうふうに融合させるかという本を書いていました。そこからいろいろなことを学んでいたんですね。この本の中に、実はいいことが書いてありました。
どの組織にも繰り返し発生する固有の弱みがあって、その弱みの発生に気づいて適切に対応するためには、シンプルなチェックリスト……大きな組織になると、重厚長大なとんでもない数のチェック項目になるやつがあります。それを品管（品質管理）みたいな人が来て、アセスメントして表面上でチェックする、そんな印象が私もありました。
確かにシンプルなチェックリストいいなぁと思っていたらですね、PaulさんがEssenceというのがあるんだと。この本は2013年に出ているんですけど、2014年くらいに知りました。それから平鍋さんが記事を書いてくれていたり、鷲崎さんと知り合ったりして、実は6年くらい前からEssenceに注目しています。
Essenceはすごくよさそうなんだけど、ちょっと概念的に難しそうだなと思いました。私としては、お客様とか現場とかで使ってもらわなきゃ意味がないので、どうしたら使えるのかといろいろ考えていました。まずはアルファを使って、広い視野を保つことでなにかいろいろできないか？ということで最初に私は、チェックリストをエクセルで作りました。それをベースに鷲崎さんが（鷲崎研究室の）先崎さんとツール化してくれてました。
あとはいろいろなお客様の重厚長大なチェックリストと、SEMATのアルファのチェックリストを比較してどんな感じになるのかな？と思い実際に比較してみたら、実は重厚長大なチェックリストのわりには、アルファの機会に関するチェック項目がすごく少なかったりすることがわかったんですね。
みんなの知恵を集めるためのフレームワーク
私のお客様はSIerさんが多いんですけど、今までSIerは「要求」どおりに作ることを求められるというポジションだったと思います。なんのためにこのソフトがいるのかとか、「機会」のところはあまり関係なかったのかなと思うんですね。だからしょうがないのかな、でもそれでいいのかな？とも思っていたんですね。
これは鷲崎さんがさっき言ったITAの分析で、「チーム」とか「仕事のやり方」にもこういう根本の原因があったなぁとかですね。その他にもXP祭りで2年連続で鷲崎さんと先崎さんとワークショップをやっていて、参加してくれた方から「アルファを使うと視野が広がるな」とか「アジャイル開発のトラブル防止に役立つかもしれない」とか、いろいろポジティブな反応や、「やっぱり慣れるまで難しい」とか「各チェック項目の意味が難しいね」という意見をいただきました。
今まで私はプロジェクトマネージャーとか品管とか専門家がチェックリストをチェックするようなイメージでやっていたんですけど、そうじゃないなと。
本に書いてあるように、まずみんなでカードを使ってディスカッションをしながら気づいていく。一部の人が使って気づきを得ることはできるかもしれませんが、次のアクションを起こすという意味ではみんなで考えるほうが絶対効果があるだろうと。
私は今までアルファにしか注目していなかったんですね。今回の『モダン・ソフトウェアエンジニアリング』をもう1回読んで、その中にスミス君という、大学を卒業した人が実際に仕事をやっていく中でだんだん視野を広げていくというおもしろいストーリーが入っているのですが、
スミス君と一緒になってやっていくうちに（読み進めていくうちに）、アルファだけじゃなくて、さっき言っていたアクティビティの話とか、アクティビティスペースとか、プラクティスをちゃんと実装するところまで踏み込まないと、次のアクションってなかなか起こせないのかなと思って。
今後は両方向ですね。チーム全員でカードを使うとか、実際にどのプラクティスが必要なのか気づくとか。上に書きましたけど、みんなの知恵を結集するためのフレームワークとして使えないかなと。
どこを形式知化すべきか？なにがなんでも全部の手順書作る必要はないと思っています。（カードを使ってみんなでディスカッションをすると）ここの作業は可視化して、ガイダンスがいるよねっていうところが見えてくるんですね。そこをちゃんと気づくようになるので、意味があるかなと思います。
ビジネスと社会のためのソフトウェア工学をEssenceで比較
最後なんですが、ここ1週間以内の事例です。みなさんの中で第1回のSE4BS「社会やビジネスに価値を生み出すソフトウェア工学に参加した人もいるかもしれません。
鷲崎さんや平鍋さんや羽生田さん、萩本さんが始めた社会やビジネスに新たな価値を生み出すソフトウェア工学をEssenceのアルファで比較するとどうなるんだろうっていうのを、特に（Essenceで推奨されている）代表的なプラクティスの1つである、匠Methodでマッピングしてみました。
「ステークホルダー」、「機会」、「要求」、「作業」、このへんを確実に押さえて、ほかにもいろいろなプラクティスがSE4BSに入っていますけど、ソフトウェアシステムを押さえているんだなっていうのがなんとなく見えてきたんですね。
私は先ほど角さんが紹介してくれた、エッセンシャル化をどうしても使いたくて、こんな感じで匠Methodに注目してサブアルファを作ったり、いろいろやりました。
先週SE4BSの会合の中で、大胆にもこれを説明したらいろいろな議論が巻き起こりました。7つのアルファに対して、SE4BSの取り組みの何が新しいかと言うと、例えば「顧客」は実は顧客だけじゃなくて、市場や社会まで視野を広げているところがおもしろかったです。
その他にも、「機会」の中にはもちろん「価値」が入っているのですが、ステータスの1個に埋もれている感じがあるんですが、SE4BSでは「価値」を独立して取り上げている。これは継承して分離したほうがきっといいんだろうなとか。
他に「チーム」についても、カーネルアルファではあまり「要求」や「機会」の関連がつながっていないんですが、SE4BSで言っている「チーム」は、「価値」や「機会」や「要求」にも積極的に関与する「チーム」だよなとか、いろいろ出てきました。それを踏まえてこんなふうに絵に描いてみました。
今やっている取り組みをこうやってマッピングすることによって、何が新しいのかとか、角さんがさっき言っていましたけど何が足りないのかとか、いろいろなものが見えてきて、それが非常におもしろいなと思いました。
今後もこんな使い方をどんどんして、SE4BSにもこういう観点でよりよいプラクティスをどんどん入れて、よりよいフレームワークにしていけたらなと思っています。以上になります。
（次回へつづく）
