Xtextでクロスリファレンス利用時の要素の絞り込み
Xtextでクロスリファレンスを使用する際に親要素によって絞り込まれた要素名をリファレンスする方法を試してみたので紹介します。
まずは普通のリファレンスを使用する文法をサンプルとして作成します。
スポーツのリーグの構成を定義する簡単な文法を作ってみました。
リーグがあってその下にチームがあって、チームにプレイヤーが所属しているという具合です。
この文法を使ってリーグやチームを定義してみます。
今回の本題は、両リーグ通じてのMVPを定義するときに以下のようにリーグ.チーム.プレイヤーの階層構造を利用してコンテンツアシストに表示される候補を絞り込む方法です。
具体的には下記のような定義をする際にALeagueの後のチームを選択する候補がXTeamとZTeam、XTeamの後のプレイヤーを選択する候補がPlayer1、Player3となるのが期待結果です。
MVP mvp
ALeague.XTeam.Player1まず、上記のようなMVPを定義するために文法を修正します。
この状態でMVPの定義をしたらどのような候補が表示されるか試してみましょう。
ALeagueを選択しているのでXTeamとZTeamのみが候補として表示されてほしいところですが、YTeamも表示されてしまいます。
期待通りに候補を絞り込むにはScopeProviderに絞り込みの処理を記載する必要があります。
具体的には、以下の部分になります。
この部分に記載する絞り込みの処理の形式はXtextのマニュアルのScopingに書かれています。
以下のURLで”Declarative Scoping”の項です。
https://www.eclipse.org/Xtext/documentation.html#scoping
マニュアルには以下のように記載されています。
IScope scope_<TypeToReturn>(<ContextType> ctx, EReference ref)
TypeToReturnというのは、絞り込んだ結果の候補の型です。ContextTypeというのは絞り込みを行う要素を含む型です。今回のケースだとTeamとPlayerがTypeToReturn、ContextTypeがMVPということになります。
以下のように記載してみましょう。
再び、MVPの定義を試してみましょう。
ちゃんと、親要素に応じた選択候補が出るようになりました。
ソフトウェア品質シンポジウム投稿応援フォーラム in 関西
3/19（水）に大阪で"ソフトウェア品質シンポジウム投稿応援フォーラム in 関西"を開催します。
ソフトウェア品質シンポジウム（通称：SQiPシンポジウム）日科技連さん主催のソフトウェア品質をテーマにしたシンポジウムです。
SQiPシンポジウムがテーマにしている「品質」は単にバグのあるなしではなく、広い範囲を扱っています。例えば、ユーザにとって使いやすいデザイン、魅力的で所有欲を刺激するようなものも「品質」の一種になります。
皆さんの価値ある知見を是非、SQiPシンポジウムで発表していただきたいと思い大阪でのセッションを企画しました。SQiPシンポジウムでの発表はアブストラクトで投稿し、査読の上、採録かどうかを判定するという流れになっています。アブストラクトってどんなこと書けばいいの？という疑問や、発表経験者からの体験談を紹介します。
また、私からは、「新人中心のアジャイル開発事例」と題して、現場で計測したデータを紹介します。皆さんの参加をお待ちしています。
プログラムの詳細と、申込み方法は以下を参照ください。
XDDPについての議論
先日、リーンカンファレンスでXDDPについてのセッションがあったためか、アジャイル開発実践者の方がXDDPについて言及されているのをよく見かけます。Facebook上でも議論をしたので、その時に書いた私のXDDPについての個人的な感想を書きます。
XDDPを適用する判断基準
まず、私はアジャイル開発とXDDPの両方の経験があり、プロジェクトによって使い分けています。XDDPを適用する判断基準は次の通りです。
- 自分達でない誰かが作ったプログラムの変更である。
- 役に立つドキュメントがない。
- 長い関数が大量になるなど複雑なコードになっている。
- 変更にかけることができる期間やコストが少ない
特に組み込み系の開発では、上記のような条件に当てはまるものが多いので、その分野でXDDPが支持されている理由の一つなのではないかと思います。XDDPでは、リファクタリングしたりユニットテストを書いたりしないのか？というと必ずしもそうではありません。変更設計書をレビューする際に、リファクタリングした方が良いという提案があって、チームで検討してリファクタリングすることもよくあります。また、製品の性質上、よく変更が加わるところは、ユニットテストを書くのは効果的です。
XDDPはウォーターフォール？
XDDPは変更設計書を書いてからコードを変更するというやり方なので「XDDPはウォーターフォールだ」という感想も見かけました。私のところでは、XDDPを適用する際は、原則として変更要求仕様毎に反復的に開発を行っています。派生開発自体が、「前からの変更」であり、それを何回も繰り返しているわけですので、反復していると言えます。特にUSDMの形式は変更要求毎に識別可能な番号が付いていて、（書き方によりますが）単独で扱えるので、スクラムのプロダクトバックログと同じような扱いも可能です。XDDPそのものと、変更要求仕様を一度に実装するか、反復的に実装するかはあまり関係ないというのが私の考えです。
XDDPとアジャイル開発の共通点
私はXDDPとアジャイル開発の共通点は、“チームでコードレベルまで共有することに対するこだわり”だと感じています。それがXDDPでは、トレーサビリティマトリクスや変更設計書というドキュメントの作成とレビュー、アジャイル開発では、コードの共同所有、ペアプログラミングやテスト駆動開発というプラクティスを手段としています。どちらの方法が効果的かはコンテキストによって異なりますが、どちらの方法もコードがどのように実装されるかということに対する関心が非常に高いことが特徴です。Facebookでの議論でも話題になりましたがXDDPが効果的な状況のフォースに着目してパタンで表現すると面白いと思っています。
XDDPをやれば変更の影響範囲を見落とさない？
よく、「XDDPをやれば変更影響を見落とさないようになりますか？」ということを聞かれます。私は、XDDPは“良くわからないコードをチームでハッキングするためのプロセスの一つ”と捉えています。もちろん、他にも良い方法はたくさんあると思います。あたりまえのことですが、他人が作った複雑なコードの変更影響を見落とさないためにもっとも必要なスキルは、“コードを読む力”です。XDDPはコードを読んだ結果の残し方を定めたものであり、適用したからと言って、“コードを読む力”が大幅に増すことはありません。なので、メーカーのような派生開発が多い組織では、オープンソース等を使ってコードをハックするスキルを高める訓練をすることが重要だと感じています。
自分たちがやっているやり方と違う方法について、ネガティブな感想を持ってしまいがちだと思いますが、私は、基本的に「うまくいっているということは何らかの必然がある」と思っています。そのうまくいく理由となっている要因（これがたぶんパタンにおけるフォースのようなもの？）を突き詰めていくと、自分たちが現在実践している方法がうまくいく本質的な理由をより深く理解することができると思います。
「Fearless Change アジャイルに効く アイデアを組織に広めるための48のパターン」予約開始
書籍「Fearless Change アジャイルに効く アイデアを組織に広めるための48のパターン」 が予約開始されています。
http://www.amazon.co.jp/dp/462108786X/
この本は2011年にAgile Japanの基調講演で日本に来てくださったLinda Risingさんが書かれた「Fearless Change: Patterns for Introducing New Ideas」の翻訳本になります。翻訳者の方々は川口さんをはじめ、この本のテーマである「アイデアを組織に広める」ことを実践してきた素晴らしい方々です。
表題には「アジャイルに効く」とありますが、開発プロセスには依存しない（ITにも依存しない）広い範囲で活用できる内容です。
組織によって状況は様々なので、どの組織にもバッチリ合うような良い方法を書籍のような形で提示することは困難です。本書は、パタンランゲージを用いて、色々なアプローチを、そのアプローチが有効である状況、その裏にある目的を達成するにあたってかかってくる制約（ポジティブなものとネガティブなものの両方）、具体的なストーリーによって説明してくれます。
私たちが、自分の状況に合わせて、有効なパタンを組み合わせた自分の方法を考える大きな助けになります。
自分達の組織やプロジェクトを良くしたいけど、意見が取り入れられないと思っている方は、是非、読んでいただければと思います。アイデアそのものと同じくらい、アイデアを実行するための活動が重要で、もっとできることがあるということに気づく一冊です。
「IMPACT MAPPING」読みました
平鍋さんと上馬さんが訳されたIMPACT MAPPING インパクトのあるソフトウェアを作るを読みました。プロダクトバックログを作る指針となる部分の作り方、共有の仕方は悩ましいところです。最初のプロダクトバックログをうまく作れて、かつそのメンテナンスの方針を関係者と共有できれば、プロジェクトが成功する確率はかなり高いのではないかと思います。この書籍はまさにそんな悩みの解決に直結する内容です。
この書籍で紹介されているIMPACT MAPPIMGは、作ろうとしているシステムを目的、アクタ、アクタに与えるインパクトという段階でマインドマップに表現します。これを関係者と共有することによって、目的に沿わないユーザストーリーが実装されるようなムダを減らすことができます。スクラムのプロダクトバックログで厳格に優先順位付けを行うことでムダな機能が実装されるムダはかなり抑えることができますが、それ以前の利害関係者との調整に苦心することがあります。そのような場合に、IMPACT MAPPIMGのようなシンプルな形で目的とその実現手段を共有できれば調整もスムーズにできると思いました。しかし、IMPACT MAPPIMGを使う目的は、もっと先にある、システムが届けたい相手に対して文字通りインパクトを与え、相手が変化することなのだと思います。自分の携わるシステムが社会にインパクトを与え社会を良い方向に変えて行く、という思いをこの本を読んで改めて強くしました。
「リーン開発の本質」を再読
皆さん、あけましておめでとうございます。今年もマイペースで更新しますが、どうかよろしくお願いします。
昨年、市谷さん、藤原さんが監訳されたリーン開発の現場 カンバンによる大規模プロジェクトの運営 | オーム社eStoreは、今迄のリーンソフトウェア開発の書籍では紹介されていなかった現場での具体的なやり方が詳細に説明されています。また、この本が素晴らしいと思ったところは、色々な具体的な方法を紹介するだけではなく、「私たちが何故、システムを作るのか？」ということとしっかりと繋がっていることです。
この本を読んだことがキッカケで、数年前に読んだ日経BP書店｜商品詳細 - リーン開発の本質を再読したくなり、読み返していました。以前、読んだときとは、自分の立場などが異なっていることもあり、沢山の気付きがありました。
リーン開発では、ムダが無いかの指標としてスピードを重視しています。ムダが無いかどうかを調べるのに、よく単位時間あたりのコード行数や、ドキュメントページ数のような、一つの作業をこなすスピードを計測することがありますが、リーン開発でのスピードは、一つの作業ではなく、顧客のニーズを顧客価値として提供するスピードです。バリューストリームマップは、このスピードに着目してムダを見えるようにする強力なツールです。以前、読んだときもこの辺は同じように理解していましたが、現在は、「誰と誰と一緒にこれをやろう」と自分の行動に反映できそうに思いました。
あと、デミング博士について、7ページくらいを使って紹介されていました。今回読んで、デミング博士は「従業員に対する毎年の査定をやめる。個人の成績を評価して、チーム内の協力関係を崩してはならない」とおっしゃっていたと書かれていたことです。6章では、このようなチームや個人に対する評価について書かれており、数年前に読んだときには、あまり入ってこなかったのですが、現在自分が評価をしなければならない立場になって読むと「こんなこと書いてあったのか」と思います。
昔は、リーン開発は、考え方は理解できるけど「自分が実践する」という気持ちにはならなかったのですが、今、「リーン開発の現場」と「リーン開発の本質」を読んで、自分が実践することを念頭において勉強しなおしてみたいと思いました。
2013年のふりかえり
今年も残り日なので1年をふりかえってみました。
1月
Scrum Alliance Regional Gathering Tokyo 2013の技術トークスに登壇。
玉川さん、和智さん、和田さんという素晴らしい方々と一緒にお話することができました。
2月
TFSUG大阪を開催。セッションも1枠担当しました。
3月
夫婦でレッスンを受けている声楽の発表会に出演。イタリア古典歌曲とドイツ歌曲を1曲づつ歌いました。
あと、「わかりやすいアジャイル開発の教科書」が発売されました。
4月
SB Creativeさんにて「わかりやすいアジャイル開発の教科書」の発売記念イベント。
自分の本に関するイベントには初めて出たので新鮮でした。
5月
Agile Japan2013を開催。実行委員として関わりました。私は大阪サテライトのセッション1枠を担当しました。枡野さんの話が印象的でした。あと、意外にも中村洋さんと同じイベントで話すのは初めてでした。
7月
Agile Conference Tokyo2013にて長沢さんからマイクロソフトスポンサーセッションへの登壇を依頼していただきました。「スクラムと品質」の話をしました。今年はこの話を大阪、東京、北海道、仙台でさせていただきました。
8月
アジャイル同人誌「Ultimate Agile Stories vol.3」の刊行。James O Coplienさんをはじめ、沢山の方々に寄稿いただきました。
夏コミももう3回目。次も計画しているのでよろしくお願いします。
あと、JaSST '13 Kansaiで岩橋さんとダブル基調講演を担当しました。
9月
日科技連のソフトウェア品質シンポジウムに一般発表、企画セッションで登壇。
企画セッションは、永田さん、にしさん、大沢さん、天野さん、小井土さん、かわぐちさんと物凄いメンバー。とても刺激的なセッションでした。
きょんさん、井芹さん、太田さんの3人でアジャイルテスティングの議論を始めました。オンラインとオフラインの併用で何回か議論していますが、毎回とても気付きが多くて楽しいです。
10月
Agile Tour Osaka2013を開催。今年は、ベトナムからChris Kruppaさんを招きました。
原田さんには多大な協力をいただきました。4年に渡って支援してくださっている長瀬さんにも感謝です。
JaSST '13 Hokkaidoの基調講演を担当。リクエストが今まで話したことのない内容で、長い時間をかけて準備しました
が、自分のやってきたことの整理になり、自分自身気づきが多かったです。
前日の前夜祭でもお話しさせていただきました。アジャイル札幌の皆さんと交流できました。
あと、Microsoft MVP for Visual Studio ALMを受賞しました。
12月
すくすくスクラム仙台と仙台ソフトウェアテスト勉強会の共催イベントで「スクラムと品質」の話とアジャイルテストのワークショップを担当。
実はすくすくスクラムに初めて参加しました。
ふりかえってみると今年は沢山の機会を色々な方からいただけた1年だったと思います。
また、それぞれの機会を通じて多くの方を知り合い交流することができたことも嬉しいです。
多くの方に大変お世話なりました。
来年も、皆さんよろしくお願いします。
