Location via proxy:   [ UP ]  
[Report a bug]   [Manage cookies]                
SlideShare a Scribd company logo
第2回TPS/ゕジャ゗ル研究会
  有限会社来栖川電算 山口陽平
      2011年7月8日(金)
   自己紹介
   せっかくTPS/ゕジャ゗ル研究会なので
    ◦ 巨大滑り台で考えるアジャイル
   DSLによる要求獲得でスーパーゕジャ゗ル
    ◦ ドメイン固有言語(DSL)
    ◦ ユーザ言語で仕様を記述・整理する
    ◦ スーパーアジャイルじゃない?
山口陽平
   プログラミング言語・型理論の研究者
    ◦ 世界を美しく記述することを夢見る32歳
    ◦ 人を驚かせてなんぼ
      Nativeコードより速いPure Javaコード
      1日でHaskellを作る
      ハードリアルタイムJava VM
      1000台以上のサーバで構成されるペタバイト
       級分散データベース
      PC上で1000万クエリ/秒を達成するKVS
   来栖川電算
    ◦ 名古屋工業大学発(2003年設立)
    ◦ ソフトウェアの品質・生産性の向上
    ◦ IPA未踏ソフト経験者(を多数輩出)
                                   ※あくまでも゗メージです。
                                   実物に髪の毛はありません。
   開発者「巨大滑り台できました!」
   お客様「あれ?左の端、…モゕ゗?」
   開発者「ハ゗!特にご希望がなかったので、
    今流行りのモゕ゗にしておきました!」
作った後で気になることは
多いが、作る前は何を気に
してよいか分からない。
     ⇒捉えどころがない困難
   開発者「巨大滑り台できました!」
   お客様「あれ?左の端、…モゕ゗?」
   開発者「ハ゗!特にご希望がなかったので、
    流行りのモゕ゗にしておきました!」
そもそもお客様は表面的な
要求しか把握していない、
些細な要求・偽りの要求に
囚われていることが多い。
しかも世の中が変わって行
開発者「巨大滑り台できました!」
くからややこしくなる。

お客様「あれ?左の端、…モゕ゗?」

   開発者「ハ゗!特にご希望がなかったので、
    流行りのモゕ゗にしておきました!」
お客様は都合のよい効果だ
けに夢中で、副次的効果の
絡まりに関心や理解が乏し
く、想像も苦手。システム
の姿を劇的に変えてしまう
開発者「巨大滑り台できました!」
かもしれないのに。

お客様「あれ?左の端、…モゕ゗?」

   開発者「ハ゗!特にご希望がなかったので、
    流行りのモゕ゗にしておきました!」
要求を持っているのはお客
様。気付いていない・もや
もやした表現し難い要求を
開発者に伝えなくてはなら
ない。どうやって?
   開発者「巨大滑り台できました!」
   お客様「あれ?左の端、…モゕ゗?」
   開発者「ハ゗!特にご希望がなかったので、
    流行りのモゕ゗にしておきました!」
根源は沢山あるけれど…


   開発者「巨大滑り台できました!」
   お客様「あれ?左の端、…モゕ゗?」
   開発者「ハ゗!特にご希望がなかったので、
    流行りのモゕ゗にしておきました!」
ゕジャ゗ル
お客様と開発者からなる
チームの認知力・想像力・
伝達力を強化する補助魔法
   開発者「巨大滑り台できました!」
   お客様「あれ?左の端、…モゕ゗?」
   開発者「ハ゗!特にご希望がなかったので、
    流行りのモゕ゗にしておきました!」
1. 認知・想像・伝達の機会を作る
 ストーリーの作成・バックログの作成・受け入れテスト・
 スプリントレビュー

2. 認知・想像・伝達の機会を増やす
 開けた作業空間・反復・スプリント・頻繁な振り返り

3. 認知力・想像力・伝達力を増幅する
 共通の用語・ストーリーカード・バックログ・動くソフト
  開発者「巨大滑り台できました!」
 ウェア・現物
    お客様「あれ?左の端、…モゕ゗?」
    開発者「ハ゗!特にご希望がなかったので、
     流行りのモゕ゗にしておきました!」
ドメイン固有言語(Domain Specific Language)
お客様の頭の中を整理し、彼らの想像力と表現力を高めれば、最良の要求や仕様を引き
出せる。正確で厳密に記述された要求や仕様は機械的に処理できる。ドメ゗ン固有言語
はコミュニケーションやプログラミングを効率化する強力なツールとなる。
   特定の知識を表現・解釈
    するための形式的手法         直観的

    ◦ 自然言語より伝えやすい。
     曖昧で混乱を誘う表現・解釈
      が少ない。                  自然言語
                                    ドメ゗ン
                                    固有言語
     整合性・効率性・過不足を検
      証しやすく、場合によっては
      実行できる。
    ◦ 汎用言語より分かりやすい。                 汎用言語

     ドメインの知識を直接的かつ
      簡潔に表現できる。                            厳
                                           密
     ドメインの専門家が理解でき、
      場合によっては記述もできる。
   文法定義
    ◦ LEX, YACC, ANTLR, Javacc, TMF, MPS
   文書作成
    ◦ sed, TeX, HTML, Wiki記法
   グラフ作成
    ◦ gnuplot, GraphViz
   フゔ゗ル処理
    ◦ UNIX shell, find, grep, make, ANT
   データ処理
    ◦ SQL, XML, XSLT, XPath, XQuery
 背景          効果
  ◦ 根本的な困難     ◦ コミュニケーション
  ◦ 技術の変化         想像をガイドする
  ◦ 社会の変化         意思疎通をスムーズにする
                  判断を合理的にする
               ◦ プログラミング
                  確認が楽になる
                  修正が楽になる
                  専門による分業ができる
                  記述が資産になる
   2種類の専門家が知識を交換する
    ◦ お客様はシステムが何を為すべきかを決定できる。
    ◦ 開発者はシステムをどのように実現すべきかを提案できる。
   想像や表現が難しい知識を扱う
    ◦ 暗黙的・非直観的・抽象的でたくさんの知識を厳密に整理・
      検証・伝達し合わなければならない。




               要求
        決定
               仕様              提案
   プラットフォームが安定しない
    ◦ 数年経つと新しいプラットフォームでの競争が始まる。
     最近の舞台:クラウド・モバイル
   プラットフォームから切り離すことが難しい
    ◦ 同じ言語でも移行は難しい
     三層モデルアプリケーションをクラウドへ
     iアプリをAndroidアプリへ
    ◦ 言語が異なるともっと難しい
     SwingアプリをAJAXアプリへ
    ◦ 性能を追求するとAPIが全く変わってしまう
     KVSとSQLでは全く作り方が違う
   お客様がソフトウェゕを内製する傾向にある
    ◦ 数は少ないが企業内アマチュアプログラマが増えている。
     Excel・Access・VBA・VB・SQL・PHP・Apache・Unix
    ◦ 変化へ素早く対応することが重視される。
     入出力項目・ワークフローの絶え間ない改善
    ◦ セキュリティが重視される。
     企業ノウハウ・個人情報の流出阻止
   プロがやるべき仕事が変わってきている
    ◦ アマチュアプログラマでは不可能な規模・複雑さの開発
    ◦ アマチュアプログラマでも使えるツールの提供
   特徴を捉えた的確な表現方法が知識の姿形となる。
    ◦ 直観で認識できる世界が広がり、勘が良くなる。
   形式的な解釈方法が様々な気付きをもたらす。
    ◦ 非直観的・暗黙的な知識をあぶり出す。
             違和感       妄想

            表現




                    読み書き
                    整理する
   特徴を捉えた的確な表現方法が会話を助ける。
    ◦ 注目すべき点が明確になる。
    ◦ 混同や飛躍がなくなる。
   共有された解釈方法が曖昧さを減らす。
    ◦ 誰がいつ解釈しても同じになる。

     プロペラ
   形式的な解釈方法が判断材料を増やす。
    ◦ 思いもよらない・予想に反する事柄の発見が常識や偏見
      にとらわれない判断を可能にする。
   記述が地図となり見通しを良くする。
    ◦ 頭の中に入りきらないほど大規模で複雑な知識を扱える。




     火力は低いが浮く        火力は高いが浮かない
   機械的な解釈をツールで自動化できる。
    ◦ 複雑な解釈方法を伴うドメインも扱える。
    ◦ 矛盾や誤りや非効率を自動的に発見できる。
    ◦ 確認時間が短縮されるため思考錯誤しやすくなる。


矛盾

          誤り



               非効率   ツール   レポート
   言語処理系は保守性を高める
    ◦ プログラムやドキュメントを生成するコンパ゗ラや゗ン
      タプリタは関連する記述の一貫性を自動的に維持する。
    ◦ 拡散する記述を閉じ込めるため、設計が美しくなる。
    ◦ 最適化により性能が高まる。

一貫性維持
             拡散防止
             性能向上




             言語処理系
ユーザ言語で仕様を記述・整理する
 生産記録システムの事例から言語指向プログラミングを理解する。
   要求
    ◦ 記録用紙を電子化したい。
    ◦ 記録用紙
     頻繁に様式が変化する。
      定期的な改善活動がある。
     種類が多い。
      商品ごとの工程数に比例する。
     記入欄が複雑かつ多い。
      記入内容やその正しさが他の(記録用紙の)記入内容や外部情
       報に依存して決まることがある。
      一度に全ての記入欄が埋まらないことがある。
      条件によって記入方法が変化することがある。
   生産現場(数百数人)
    ◦ 記録用紙を使って業務を行っている。
     記入欄が何のためにどのように使われているか知っている。
    ◦ ITリテラシーがある人がちらほらいる。
     ExcelやWordを使える人がいるだけでなく、稀にアクセス
      でプログラムできる人もいる。
   情報室(十数人)
    ◦ 社内システムのデータベースを管理している。
     生産現場から収集した情報をデータベースへ登録したり、
      データベースから抽出した情報を生産現場へ提供している。
    ◦ ITリテラシーが高い。
     全ての人がSQL・VB・Access・Excelを使える。
   ExcelとSQLでカスタマ゗ズできるシステム
    ◦ 様式(生産記録スキーマ)をExcelで編集できる。
    ◦ 記録用紙(生産記録エデゖタ)をすぐに確認できる。
    ◦ 記入内容を格納する生産記録(トランザクションテーブル)と初期
      値や選択肢などを格納する生産記録(マスタテーブル)を生成
      できる。後者をトリガで更新するかビューにすることで
      他システムのマスタテーブルと連動できる。
   対応が分かりやすく編集しやすい表現
    ◦ 1個の記入欄を1行で表す。
     階層的識別子を使う。特徴を各列で表す。
    ◦ 識別子を使った関係式で特徴を宣言的に表す。
   ユーザ言語は主に次のフェーズを経て獲得できる
    ◦ 抽出フェーズ
     お客様も気づかない隠された要求や仕様を洗い出す。
    ◦ 整理フェーズ
     全ての要求や仕様を正確に表現し、お客様と合意する。
    ◦ 自動化フェーズ
     要求や仕様を実行する。
   続くスラ゗ドでは生産記録スキーマ言語をどのよ
    うに獲得したかを上記のフェーズごとに紹介する
項目
   お客様も気付かない隠された要求や          識別子

    仕様を洗い出すことが目的              型

    ◦ 記録用紙から言語とスキーマを抽出する。     制約

      記録用紙とスキーマをお客様に見せなが      空白不可

      ら対応を説明する。               値

     解釈が間違っていると教えてくれる。       コンポーネント

    ◦ 各項目はヒアリングの項目になる。        フォーマット

     具体的に1つ1つ確認すると分かってくれる。   単位

     複数人でするため書き方の合意はとる。      表示

    ◦ 合意した書き方で書けなくても書く。       有効

     マークしておき、後で言語に反映する。      マスタ記録

     書けないことは隠された要求の発見に繋が     トランザクション記録
      りやすい。                   備考
DSLによる要求獲得でスーパーアジャイル
   全ての要求や仕様を正確に表現し、
    お客様と合意することが目的
                            表現が変わった項目
    ◦ 洗い出したスキーマを正確に表現できる
      より単純な言語を探し、それでスキーマ    識別子

      を再表現する。               増えた項目
     言語処理系が作りやすくなる。        表示識別子
     開発コスト・検証力・性能・表現力のバラ
      ンスが難しい。
    ◦ この時期から編集や検証を自動化する
      ツールを作れるようになる。
     言語が成長している間は、使い捨てツール
      と手作業を組み合わせて編集するとよい。
類似語統一

英語名生成


        共通部分抽出
   要求や仕様を実行することが目的         減った項目

                            範囲
    ◦ 開発者やアプリケーションや実行環境の
      都合で必要な情報を表現できるように言    空白不可

      語を拡張し、スキーマにその情報を付加    フォーマット

      する。                   単位

     多くの情報(のデフォルト値)は既存の情
                            増えた項目
      報から補えるので、自動編集ツールを作る
      とよい。                  型パラメータ

    ◦ お客様が自分でスキーマを修正し、他シ    制約

      ステムと連携できるようにサポートする。   コンポーネントパラ
                            メータ
     繰り返し作業やよくある間違いを言語や    マスタ実態名
      ツールの改善で抑制する。          トランザクション実態
                            名
新   新
表   表
現   現   生
        成
   フォーム&テーブルスキーマ       共通仕様   6行
    ◦   選択肢はマスタから読み込み   個別仕様   18行
    ◦   入力項目:3n + 9
    ◦   検査項目:3n + 13
    ◦   計算項目:n + 3
   うまくいったポ゗ント
    ◦   お客様の能力に合った言語仕様
    ◦   記録用紙と対応がとりやすい言語仕様
    ◦   強力な検証機能を持つ言語仕様
    ◦   言語仕様からプラットフォームの知識を排除
    ◦   言語仕様の変化を考慮
   効果
    ◦   お客様による試行錯誤
    ◦   短期間に大量の画面を作成
    ◦   他のプラットフォームへの乗換
    ◦   ベンダーロック
   PDCAサ゗クル高速化
    ◦ 発注に伴うオーバヘッド
                     記録用紙1枚の電子化にかかる時間
      を気にしない。
                    タスク       従来手法    LOP手法
     小間切れ・突発
                    仕様書作成      4 時間    1 時間
    ◦ 何が良いか判断できる人
                    内部設計書作成    4 時間    0 時間
      が納得いくまでする。
                    プログラム作成   16 時間    0 時間
     品質が向上
                    内部試験      12 時間    0 時間
     誇りと一体感が発生
                    データ作成      2 時間    2 時間
    ◦ 共通理解の深まり
                    試験         2 時間    2 時間
     お客様が賢くなり、コ
      ミュニケーションコスト   合計        40 時間    5 時間
      が減少
   開発したもの
    ◦   Collectionライブラリ
    ◦   SwingもどきGUIライブラリ
    ◦   言語処理系×10個
    ◦   記録用紙の生産記録スキーマ
    ◦   各種ドキュメント
   工数
    ◦ 15人月                 タスク   入力項目数 画面数

    ◦ 1.5画面/人日             合計     4000 個 200 画面
                           人月毎   267 画面   13 画面
    ◦ 驚異的な生産性
   言語処理系を作りなすだけ
    ◦ 業務知識は全て再利用できる。
   現在検討しているプラットフォーム
    ◦ .NET
    ◦ AJAX
    ◦ Android
   様々な理由
    ◦   お客様は自分で作った物に誇りと愛着を持つ。
    ◦   お客様は試行錯誤になれるとやめられない。
    ◦   DSLで効率化された両社関係は捨てるには惜しい。
    ◦   DSLの言語処理系を作れる会社は多くない。
    ◦   別のシステムを作るとき非常に効率的で見通しが良い。
         生産記録スキーマ(を加工したもの)に情報を足して、新
          たな言語処理系を作ればよい。
         非常に有益な構造化がなされた多くの業務知識が再利用で
          きる。
         具体的な情報をこねくり回してから判断できる。
         汎用言語プログラムか自然言語の仕様書の中に拡散する非
          定形な情報ではこうはいかない。
   抽出フェーズからPDCAサ゗クルが速い
    ◦ 私たちの動くものはプログラムだけじゃない。しっかり
      した意味を持つ言語を作るから、お客様の記述を私たち
      がインタプリートして身振り手振りで動かせる。いきな
      り現物確認できる。
   最後はPDCAサ゗クルがめちゃめちゃ速い
    ◦ お客様だけですぐに画面(現物)が確認できる。

More Related Content

DSLによる要求獲得でスーパーアジャイル

  • 2. 自己紹介  せっかくTPS/ゕジャ゗ル研究会なので ◦ 巨大滑り台で考えるアジャイル  DSLによる要求獲得でスーパーゕジャ゗ル ◦ ドメイン固有言語(DSL) ◦ ユーザ言語で仕様を記述・整理する ◦ スーパーアジャイルじゃない?
  • 3. 山口陽平  プログラミング言語・型理論の研究者 ◦ 世界を美しく記述することを夢見る32歳 ◦ 人を驚かせてなんぼ  Nativeコードより速いPure Javaコード  1日でHaskellを作る  ハードリアルタイムJava VM  1000台以上のサーバで構成されるペタバイト 級分散データベース  PC上で1000万クエリ/秒を達成するKVS  来栖川電算 ◦ 名古屋工業大学発(2003年設立) ◦ ソフトウェアの品質・生産性の向上 ◦ IPA未踏ソフト経験者(を多数輩出) ※あくまでも゗メージです。 実物に髪の毛はありません。
  • 4. 開発者「巨大滑り台できました!」  お客様「あれ?左の端、…モゕ゗?」  開発者「ハ゗!特にご希望がなかったので、 今流行りのモゕ゗にしておきました!」
  • 5. 作った後で気になることは 多いが、作る前は何を気に してよいか分からない。 ⇒捉えどころがない困難  開発者「巨大滑り台できました!」  お客様「あれ?左の端、…モゕ゗?」  開発者「ハ゗!特にご希望がなかったので、 流行りのモゕ゗にしておきました!」
  • 8. 要求を持っているのはお客 様。気付いていない・もや もやした表現し難い要求を 開発者に伝えなくてはなら ない。どうやって?  開発者「巨大滑り台できました!」  お客様「あれ?左の端、…モゕ゗?」  開発者「ハ゗!特にご希望がなかったので、 流行りのモゕ゗にしておきました!」
  • 9. 根源は沢山あるけれど…  開発者「巨大滑り台できました!」  お客様「あれ?左の端、…モゕ゗?」  開発者「ハ゗!特にご希望がなかったので、 流行りのモゕ゗にしておきました!」
  • 10. ゕジャ゗ル お客様と開発者からなる チームの認知力・想像力・ 伝達力を強化する補助魔法  開発者「巨大滑り台できました!」  お客様「あれ?左の端、…モゕ゗?」  開発者「ハ゗!特にご希望がなかったので、 流行りのモゕ゗にしておきました!」
  • 11. 1. 認知・想像・伝達の機会を作る ストーリーの作成・バックログの作成・受け入れテスト・ スプリントレビュー 2. 認知・想像・伝達の機会を増やす 開けた作業空間・反復・スプリント・頻繁な振り返り 3. 認知力・想像力・伝達力を増幅する 共通の用語・ストーリーカード・バックログ・動くソフト  開発者「巨大滑り台できました!」 ウェア・現物  お客様「あれ?左の端、…モゕ゗?」  開発者「ハ゗!特にご希望がなかったので、 流行りのモゕ゗にしておきました!」
  • 13. 特定の知識を表現・解釈 するための形式的手法 直観的 ◦ 自然言語より伝えやすい。  曖昧で混乱を誘う表現・解釈 が少ない。 自然言語 ドメ゗ン 固有言語  整合性・効率性・過不足を検 証しやすく、場合によっては 実行できる。 ◦ 汎用言語より分かりやすい。 汎用言語  ドメインの知識を直接的かつ 簡潔に表現できる。 厳 密  ドメインの専門家が理解でき、 場合によっては記述もできる。
  • 14. 文法定義 ◦ LEX, YACC, ANTLR, Javacc, TMF, MPS  文書作成 ◦ sed, TeX, HTML, Wiki記法  グラフ作成 ◦ gnuplot, GraphViz  フゔ゗ル処理 ◦ UNIX shell, find, grep, make, ANT  データ処理 ◦ SQL, XML, XSLT, XPath, XQuery
  • 15.  背景  効果 ◦ 根本的な困難 ◦ コミュニケーション ◦ 技術の変化  想像をガイドする ◦ 社会の変化  意思疎通をスムーズにする  判断を合理的にする ◦ プログラミング  確認が楽になる  修正が楽になる  専門による分業ができる  記述が資産になる
  • 16. 2種類の専門家が知識を交換する ◦ お客様はシステムが何を為すべきかを決定できる。 ◦ 開発者はシステムをどのように実現すべきかを提案できる。  想像や表現が難しい知識を扱う ◦ 暗黙的・非直観的・抽象的でたくさんの知識を厳密に整理・ 検証・伝達し合わなければならない。 要求 決定 仕様 提案
  • 17. プラットフォームが安定しない ◦ 数年経つと新しいプラットフォームでの競争が始まる。  最近の舞台:クラウド・モバイル  プラットフォームから切り離すことが難しい ◦ 同じ言語でも移行は難しい  三層モデルアプリケーションをクラウドへ  iアプリをAndroidアプリへ ◦ 言語が異なるともっと難しい  SwingアプリをAJAXアプリへ ◦ 性能を追求するとAPIが全く変わってしまう  KVSとSQLでは全く作り方が違う
  • 18. お客様がソフトウェゕを内製する傾向にある ◦ 数は少ないが企業内アマチュアプログラマが増えている。  Excel・Access・VBA・VB・SQL・PHP・Apache・Unix ◦ 変化へ素早く対応することが重視される。  入出力項目・ワークフローの絶え間ない改善 ◦ セキュリティが重視される。  企業ノウハウ・個人情報の流出阻止  プロがやるべき仕事が変わってきている ◦ アマチュアプログラマでは不可能な規模・複雑さの開発 ◦ アマチュアプログラマでも使えるツールの提供
  • 19. 特徴を捉えた的確な表現方法が知識の姿形となる。 ◦ 直観で認識できる世界が広がり、勘が良くなる。  形式的な解釈方法が様々な気付きをもたらす。 ◦ 非直観的・暗黙的な知識をあぶり出す。 違和感 妄想 表現 読み書き 整理する
  • 20. 特徴を捉えた的確な表現方法が会話を助ける。 ◦ 注目すべき点が明確になる。 ◦ 混同や飛躍がなくなる。  共有された解釈方法が曖昧さを減らす。 ◦ 誰がいつ解釈しても同じになる。 プロペラ
  • 21. 形式的な解釈方法が判断材料を増やす。 ◦ 思いもよらない・予想に反する事柄の発見が常識や偏見 にとらわれない判断を可能にする。  記述が地図となり見通しを良くする。 ◦ 頭の中に入りきらないほど大規模で複雑な知識を扱える。 火力は低いが浮く 火力は高いが浮かない
  • 22. 機械的な解釈をツールで自動化できる。 ◦ 複雑な解釈方法を伴うドメインも扱える。 ◦ 矛盾や誤りや非効率を自動的に発見できる。 ◦ 確認時間が短縮されるため思考錯誤しやすくなる。 矛盾 誤り 非効率 ツール レポート
  • 23. 言語処理系は保守性を高める ◦ プログラムやドキュメントを生成するコンパ゗ラや゗ン タプリタは関連する記述の一貫性を自動的に維持する。 ◦ 拡散する記述を閉じ込めるため、設計が美しくなる。 ◦ 最適化により性能が高まる。 一貫性維持 拡散防止 性能向上 言語処理系
  • 25. 要求 ◦ 記録用紙を電子化したい。 ◦ 記録用紙  頻繁に様式が変化する。  定期的な改善活動がある。  種類が多い。  商品ごとの工程数に比例する。  記入欄が複雑かつ多い。  記入内容やその正しさが他の(記録用紙の)記入内容や外部情 報に依存して決まることがある。  一度に全ての記入欄が埋まらないことがある。  条件によって記入方法が変化することがある。
  • 26. 生産現場(数百数人) ◦ 記録用紙を使って業務を行っている。  記入欄が何のためにどのように使われているか知っている。 ◦ ITリテラシーがある人がちらほらいる。  ExcelやWordを使える人がいるだけでなく、稀にアクセス でプログラムできる人もいる。  情報室(十数人) ◦ 社内システムのデータベースを管理している。  生産現場から収集した情報をデータベースへ登録したり、 データベースから抽出した情報を生産現場へ提供している。 ◦ ITリテラシーが高い。  全ての人がSQL・VB・Access・Excelを使える。
  • 27. ExcelとSQLでカスタマ゗ズできるシステム ◦ 様式(生産記録スキーマ)をExcelで編集できる。 ◦ 記録用紙(生産記録エデゖタ)をすぐに確認できる。 ◦ 記入内容を格納する生産記録(トランザクションテーブル)と初期 値や選択肢などを格納する生産記録(マスタテーブル)を生成 できる。後者をトリガで更新するかビューにすることで 他システムのマスタテーブルと連動できる。
  • 28. 対応が分かりやすく編集しやすい表現 ◦ 1個の記入欄を1行で表す。  階層的識別子を使う。特徴を各列で表す。 ◦ 識別子を使った関係式で特徴を宣言的に表す。
  • 29. ユーザ言語は主に次のフェーズを経て獲得できる ◦ 抽出フェーズ  お客様も気づかない隠された要求や仕様を洗い出す。 ◦ 整理フェーズ  全ての要求や仕様を正確に表現し、お客様と合意する。 ◦ 自動化フェーズ  要求や仕様を実行する。  続くスラ゗ドでは生産記録スキーマ言語をどのよ うに獲得したかを上記のフェーズごとに紹介する
  • 30. 項目  お客様も気付かない隠された要求や 識別子 仕様を洗い出すことが目的 型 ◦ 記録用紙から言語とスキーマを抽出する。 制約 記録用紙とスキーマをお客様に見せなが 空白不可 ら対応を説明する。 値  解釈が間違っていると教えてくれる。 コンポーネント ◦ 各項目はヒアリングの項目になる。 フォーマット  具体的に1つ1つ確認すると分かってくれる。 単位  複数人でするため書き方の合意はとる。 表示 ◦ 合意した書き方で書けなくても書く。 有効  マークしておき、後で言語に反映する。 マスタ記録  書けないことは隠された要求の発見に繋が トランザクション記録 りやすい。 備考
  • 32. 全ての要求や仕様を正確に表現し、 お客様と合意することが目的 表現が変わった項目 ◦ 洗い出したスキーマを正確に表現できる より単純な言語を探し、それでスキーマ 識別子 を再表現する。 増えた項目  言語処理系が作りやすくなる。 表示識別子  開発コスト・検証力・性能・表現力のバラ ンスが難しい。 ◦ この時期から編集や検証を自動化する ツールを作れるようになる。  言語が成長している間は、使い捨てツール と手作業を組み合わせて編集するとよい。
  • 33. 類似語統一 英語名生成 共通部分抽出
  • 34. 要求や仕様を実行することが目的 減った項目 範囲 ◦ 開発者やアプリケーションや実行環境の 都合で必要な情報を表現できるように言 空白不可 語を拡張し、スキーマにその情報を付加 フォーマット する。 単位  多くの情報(のデフォルト値)は既存の情 増えた項目 報から補えるので、自動編集ツールを作る とよい。 型パラメータ ◦ お客様が自分でスキーマを修正し、他シ 制約 ステムと連携できるようにサポートする。 コンポーネントパラ メータ  繰り返し作業やよくある間違いを言語や マスタ実態名 ツールの改善で抑制する。 トランザクション実態 名
  • 35. 新 表 表 現 現 生 成
  • 36. フォーム&テーブルスキーマ 共通仕様 6行 ◦ 選択肢はマスタから読み込み 個別仕様 18行 ◦ 入力項目:3n + 9 ◦ 検査項目:3n + 13 ◦ 計算項目:n + 3
  • 37. うまくいったポ゗ント ◦ お客様の能力に合った言語仕様 ◦ 記録用紙と対応がとりやすい言語仕様 ◦ 強力な検証機能を持つ言語仕様 ◦ 言語仕様からプラットフォームの知識を排除 ◦ 言語仕様の変化を考慮  効果 ◦ お客様による試行錯誤 ◦ 短期間に大量の画面を作成 ◦ 他のプラットフォームへの乗換 ◦ ベンダーロック
  • 38. PDCAサ゗クル高速化 ◦ 発注に伴うオーバヘッド 記録用紙1枚の電子化にかかる時間 を気にしない。 タスク 従来手法 LOP手法  小間切れ・突発 仕様書作成 4 時間 1 時間 ◦ 何が良いか判断できる人 内部設計書作成 4 時間 0 時間 が納得いくまでする。 プログラム作成 16 時間 0 時間  品質が向上 内部試験 12 時間 0 時間  誇りと一体感が発生 データ作成 2 時間 2 時間 ◦ 共通理解の深まり 試験 2 時間 2 時間  お客様が賢くなり、コ ミュニケーションコスト 合計 40 時間 5 時間 が減少
  • 39. 開発したもの ◦ Collectionライブラリ ◦ SwingもどきGUIライブラリ ◦ 言語処理系×10個 ◦ 記録用紙の生産記録スキーマ ◦ 各種ドキュメント  工数 ◦ 15人月 タスク 入力項目数 画面数 ◦ 1.5画面/人日 合計 4000 個 200 画面 人月毎 267 画面 13 画面 ◦ 驚異的な生産性
  • 40. 言語処理系を作りなすだけ ◦ 業務知識は全て再利用できる。  現在検討しているプラットフォーム ◦ .NET ◦ AJAX ◦ Android
  • 41. 様々な理由 ◦ お客様は自分で作った物に誇りと愛着を持つ。 ◦ お客様は試行錯誤になれるとやめられない。 ◦ DSLで効率化された両社関係は捨てるには惜しい。 ◦ DSLの言語処理系を作れる会社は多くない。 ◦ 別のシステムを作るとき非常に効率的で見通しが良い。  生産記録スキーマ(を加工したもの)に情報を足して、新 たな言語処理系を作ればよい。  非常に有益な構造化がなされた多くの業務知識が再利用で きる。  具体的な情報をこねくり回してから判断できる。  汎用言語プログラムか自然言語の仕様書の中に拡散する非 定形な情報ではこうはいかない。
  • 42. 抽出フェーズからPDCAサ゗クルが速い ◦ 私たちの動くものはプログラムだけじゃない。しっかり した意味を持つ言語を作るから、お客様の記述を私たち がインタプリートして身振り手振りで動かせる。いきな り現物確認できる。  最後はPDCAサ゗クルがめちゃめちゃ速い ◦ お客様だけですぐに画面(現物)が確認できる。