RegionalRubyKaigi レポート (42) とちぎ Ruby 会議 05

初稿：2013-12-21

RegionalRubyKaigiレポート (42) とちぎ Ruby 会議 05

はじめに

toruby.jpg 「formal and casual」をテーマにした とちぎ Ruby 会議 05 が開催されました。

「厳密な仕様を書くということ」に始まり、言語仕様、本の執筆、品質活動、新しい Ruby、モックアップとプロトタイプ、テストの事など様々な事が発表そして話し合われました。

とちぎ Ruby 会議 05 について

  • 開催日
    • 2013/09/21 (土) 13:00 〜 17:00
  • 開催場所
    • 東那須野公民館
  • 主催
    • とちぎ Ruby 会議 05 実行委員会
  • 後援
    • 日本 Ruby の会、とちぎ Ruby の会( toRuby )
  • 定員
    • 45 名
  • 懇親会
    • 17:30 〜 ダイニングバーウニコ

基調講演

厳密な仕様を書くということ

酒匂寛さん

sako.jpg 「わたしは見かけから分かるようにオールドプログラマ。というかオールドエンジニアです。」と和やかな自己紹介で酒匂寛さんによる招待講演が始まりました。

テーマは”厳密な仕様を書くということ”。酒匂さんのここ 10 年のテーマである”形式手法”についての講演です。前半の講演、後半の大質問大会、合わせてご紹介します。

ソフトウェア開発のドキドキを取り戻せるすばらしい時間でした。

やっぱりちゃんと仕様作らなきゃだめ

最初に酒匂さん自身のソフトウェア開発との関わりを振り返ります。

80 年代、酒匂さんはワークステーションのツールを作成する仕事をされていました。「そこでは 35 万ステップ書いて死ぬ様な目にあったんですよ」と語る酒匂さん、この経験から”契約による設計”と出会い、90 年代初頭メイヤーの”オブジェクト指向入門” 1 の翻訳本を出版します。

その後。「ツールもいいんだけど、じゃあオブジェクト指向って何でしょうね?」と考えた酒匂さんは、医療、物流系のソフトウェアをオブジェクト指向の考えを利用して組み直していきます。

そして、90 年代の終わり、マイケル・ジャクソンの”ソフトウェア要求と仕様“を翻訳します。

「やっぱりちゃんと仕様書かなきゃだめっていう話がさらに強まって、今日の話はこの延長線上にあります。」

そして 00 年代、酒匂さんは形式手法に向かっていきます。

なお、ここまで、Ruby の話ができていませんが、00 年代初頭に既存システムのデータのコンバートに Ruby を使用していたそうです。

「ホントは Ruby 会議なので Ruby の話をしたほうが良いのですけど、今日はその話をしないで仕様の話をします。」

仕様は課題と設計を繋ぐものです

今回のテーマは”厳密な仕様をかくということ”、仕様とは何なのでしょうか?

「仕様は課題と設計を繋ぐものです」と酒匂さん。

「つまり、どのような問題があって、それをどう解いたら良いか?を結びつけるところを記述しているものです。」

酒匂さんは”道案内のソフトウェア”を例に説明します。この場合、”道を案内する”というのが課題になります。

「この課題を解決するのにいきなり経路探索を設計するか、というとそうではなくて、そもそも”経路とはなにか?”とか、”探索とはなにか?”とか、”どのような入力と出力がありえるのか?”とか、そこに仕様が当然あって、複数の仕様を組み合わせ、如何に目的に達するかみたいな話があります。」

仕様が課題と設計の間に存在する。仕様と設計の間のトレーサビリティ(仕様からテストケースを作成するなど)は最近になり、実際の開発現場でも使用できるようになってきているとも酒匂さんは語っていました。そして、仕様を形式化することの大事さを語ります。

「問題をいかにうまく”仕様”という形で形式化するにはまだやらなければならない課題がいっぱいあります。 (世の中には)事実があります。事実というのは私達には手出しができません。法律、理論、原則などです。その変えられない世界の中に要求が生まれます。 要求というのは、提案、改善、企画、欲望、想像、課題です。大事な事は、私たちは何か価値を生み出さなくてはいけない。 なにかを作ることでなにかうれしいことが起きなければならない。それらを実現するのに仕様をどう作れば良いか、それを切り出してから設計をしましょうね、ということです。」

いずれにせよ、解かなきゃいけない問題と解き方と、その間をつないでいる”仕様”が存在する構造は変わりません

そして話は現場での仕様に関するよく耳にする話に移っていきます。

「(開発の現場では)仕様はいったい何なんだとか議論がよくあります。仕様が曖昧だと色々困ったことが起きますね。課題、問題の世界では欲望が渦巻いています。そしてこれをアーキテクチャ、コンポーネントといった設計に落とす。ここに仕様が挟まっている。しかし、多くの仕様書は曖昧、矛盾があったり、そもそも書いていなかったり。個人メモであったり、それぞれの人が違う解釈をしている。本来、ある課題がトレースされて仕様に繋がって、実際には設計に落ちている。これが理想的な世界です。しかし、仕様がないと、対応付けが良く分からない、このモジュールはどっから来たのかなどのが議論しにくくなる、そもそも誰が決めたんだとか。(仕様)を書かないとその間の関係が分からない。」

確かに開発現場でこういった話はよく耳にします。それでは、仕様を完全に決めてから、設計すれば良いのでしょうか? それってうまくいくものなのでしょうか?

酒匂さんはこう続けます。

「こういう話をすると、仕様を全部書いて(決めて)から、次に設計するんですか、ウォーターフォールなんですかとか仰る方もいられます。実際にはある種の要素が課題の領域で起きて、それがパラレルに仕様と設計に反映される、これらは同時に起きても良いのです。どのような手順で(それらを)追いつめていくかによって色々な方法論があるのです。ここを全部やって(仕様を決めて)、ここを全部やって(設計して)とやると、ウォーターフォールになるし、ある種の特定の所だけプロトタイピングして、フレームワークを決めて行うといった方法もあります。(どのような方法論を用いるかは)問題の性質、時間などといった様々な制約により(我々が)決定すれば良いのです。いずれにせよ、解かなきゃいけない問題と解き方と、その間をつないでいる”仕様”が存在する構造は変わりません。」

仕様を検討している段階で様々な有用なテストケースが想定されている訳ですけれども、それを実装のテストで使わないのはもったいないですよね

それでは仕様をちゃんと書けるとなにがうれしいのでしょうか?

「仕様をちゃんと書くと、仕様そのものをテストすることができます。」と酒匂さん。

では、仕様をテストできると何がうれしいのでしょうか。

1 つは仕様を検証できるということです。

「ふつうの場合、仕様をテストするということはどういうことかというと、人間がレビューすることになる。実際には単体テストやったり、総合テストをやったりして、その段階で仕様に問題があることが分かったりする。その時、正しい仕様って何だったの?という話になる。ここ(仕様)をちゃんと書いて早い段階で検証しましょう、それによって随分先々楽になるんですよ。」

検証を行うタイミングも変わってくるようです。酒匂さんはこう続けます。

「要求を出す側が、そうそう、私が欲しいのはこういうことなんですよということを早く言えるようになる。もちろん、完全に言えるわけでは無いのですが、プログラムが実際できてからこれ違うんじゃないのという話よりも、もっと早い段階で言いやすくなる。」

もう 1 つは、仕様を検証したことにより生成された成果物を再利用できるということです。

「それから、仕様の段階で検証するため、仕様自身をテストすることができる。テストをしたということはせっかくだから、そのテストケースを実装のテストでも使うことができますよね。テストケースの生成、流用もできる。仕様を検討している段階で様々な有用なテストケースが想定されている訳ですけれども、それを実装のテストで使わないのはもったいないですよね。」

さらにこう続けます。「もちろん、仕様と設計の間のやりとりだけを観てみても、設計者が、この仕様どうなってるんですかね?という疑問により良く答えることができるようになります。」

形式手法は銀の弾丸でもない数学でもない、開発対象をより厳密に書き留め解析を行う工学的手法です

ここから講演は例題を交えた形式手法の話題に移ります。

「形式手法とは何かというと、仕様を厳密な構文と、意味を持つ手段で記述して、検証( Verification )、妥当性( Validation )、確認、文書化、設計といった開発活動の品質を向上させる手法です。」

今回の講演の例題では VDM というツールを使いました。VDM ( Vienna Development Method ) はその名の通りヨーロッパ生まれの手法でツールは無償で提供されています。我々が普段目にするプログラミング言語の様な実装言語ではなく、仕様を書くための言語、仕様記述言語です。

では仕様を具体的にどのように書くのでしょうか?機能仕様を以下の 3 要素に分けて考えます。

  • 構造(普遍条件、データの関連性など)
  • 機能(入出力、事前条件、事後条件など)
  • 振る舞い(状態遷移、並列性など)

この中でも VDM は構造と機能に関する記述が得意そうです。

「検証可能な記述をすることで、品質を評価することができる。」と酒匂さん。

例題として休日の定義とはなにかを考えるため、国民の休日に関する法律の文章を形式手法言語で置き換えてみます。そして、さらに具体例として、指定した日付から N 営業日後の日付を求める関数の仕様を考え、形式的に書くことで何がうれしいのかまとめてくれました。 「集合演算と関数を駆使することによって、見通しの良い、コンパクトな記述を実現できます。短い記述、論理的な記述だけに着目することによって、議論がしやすくなる。仕様を書く際に手続きではなく、性質を宣言的に綴ることで仕様の質が高まります。」

最後に酒匂さんは講演をこの様に締めくくりました。

「形式手法は銀の弾丸でもない数学でもない、ただ、開発対象をより厳密に書き留め解析を行う単なる工学的手法です。」

大質問大会

ここからは後半戦、酒匂さんへの大質問大会です。

先ほどの基調講演を踏まえ、繰り出された数々の質問の中から抜粋して紹介します。

Q: 形式手法自体があまり知られていないのはなぜ?

「多分、やっている人達が自分たちが適用するのには熱心であったが、普及に熱心ではなかったのではと、やや反省している。(今後は)分かりやすい例題、教材などを提供したい。本質的な議論を聞いてもらえれば興味は抱いてもらえるはず。」

Q: (オブジェクト指向の普及具合と比較して)もっと広まるべきだと思うのですが。

「オブジェクト指向は流行ったんですが、これは実装言語として流行った訳ですよね。じゃあ、皆さん、メイヤーの言うところの PreCondition、PostCondition をちゃんと書きましたかっていう話です。本当はそこが本質なんですけども、何となくモノが動いちゃうから、動かす方にみんな熱心にいってしまうわけです。オブジェクト指向自体は大変有効な技術だし、私も随分関わっていますから分かるんですけども、そもそも、”これはなぜこういう仕様になっているんですか”という話になったとき、実はここ(仕様)をちゃんと考えなきゃいけない。職場で一度ならず”ここの仕様はどうなってるんだ”という話はしているはず。(仕様)をきちんと作っておくのは非常に大事なのです。」

Q: 課題と仕様との対応が残っていないことが多々あります、そういうのは VDM などでサポートされていますか?

「そこは発展途上です。実は願望が一番もやもやしている。宣言的なフラグメントを作り出して、(課題と仕様の間の)トレーサビリティを確保するように書いていくのが大事かな。そうやって決意をしないとトレーサビリティは確保されない。」

Q: 漏れが検出しやすいと聞くけど、どうなんですか?

「漏れを検出しやすい訳ではなくてですね、漏れというのは何をやっても検出できません(笑)ただ、形式手法記述言語を使うことによって何が書かれていて、何が書かれていないかがはっきりするだけです。やっぱり書かれていないことは分かんないんですよ、残念ながら。書かれていないことを発見するのに今までの経験から一番分かりやすいのはテーブルです。表に書かれていると対称性が崩れてしまうので、ここが無いねっていう話になる。私は今日、形式手法の話をしている訳ですけど、もちろん(道具は)それだけでは無い訳です。」

Q: UML を使って厳格な仕様書を書いていたけど、仕様変更のコストに耐えれなくなってトレーサビリティがとれなくなった経験があります。厳格に書けば書くほど、仕様変更が入ったときに固くなってしまう感じがするのですが。

「それは私が思うに図で書いているからです(笑)。UML の図をメンテナンスしても何もうれしくない。図は説明に使えばよろしい。図は使い捨てで良いんです。」

一般講演

casual に Ruby をパースしてみた

早川 真也 さん
  • 思いやりプログラミング
    • 読みやすく、使いやすく書くべき
      • 読み手にも自分にも
    • プログラミング言語はコンピュータに命令を伝えるための道具
      • 伝えることに意識しすぎると自己主張に偏ったコードになりがち
      • 「命令を伝えるための道具」-> 「つながりを深めるための道具」
  • 自然言語の表現力をプログラミングに取り入れたい
    • 言葉の本質は、理想分を作り出す力はない
    • 本質的に意味確定度不十分なもの
    • 他人の心が(ある程度)読めるからこそ思いやりを示せる
      • 聞き手の推論能力に依存
  • 資料: http://es.slideshare.net/tsurumau/tochigi-rubykaigi05

hayakawa.jpg 自然言語、プログラミング言語を通しての実装、設計を発表していただきました。

プログラミング言語が「コンピュータに命令を伝える道具」でもあり「人が読んで仕様、設計を理解する言語」でもある事を再確認させてもらえる内容でした。

また、資料にもあるような「スピリチュアル!?」な件もあり、会場を笑いの渦へ巻き込んでくれるネタは今回も健在でした。

パーフェクト Ruby のつくり方

三村 益隆 さん
  • 書籍：パーフェクト Ruby) の紹介
    • Ruby 2.0 に対応
    • メタプログラミング の事も詳細に書いている
    • ライブラリの一部紹介が入ってる
  • 書籍を書くまでにどうやって Ruby を勉強してきたか
    • リファレンスマニュアル読む
    • ML に入ってみる
    • Ruby に詳しい人のブログを見る
    • 本などのサンプルコードを読む
    • 標準ライブラリのコードを読んでみる
    • gem のコードを読んでみる
    • 手を動かす
      • 使っているライブラリのコードを修正して動かしてみる
      • ブログなどに書くことで他の人に伝えながら知識を得ることができる
    • block について
      • yield を使いながら理解
        • Ruby だとより明示的に書けるようになる
    • method のレシーバについて
      • self が何なのか意識して書けるとメタプログラミングの幅が広がる
    • class について
      • class も object である事が意識できるようになると面白い

mimura.jpg 書籍を書くまでにどうノウハウや経験を貯めて、アウトプット:「パーフェクト Ruby」するかを発表していただきました。

これから、本を書こうとする人向けの話だけでなく、これから Ruby を始める人にとっても有益な「Ruby の学び方」を教えていただきました。

クックパッドの品質活動

高井 直人 さん
  • 料理を楽しみにすること
    • ユーザに使って貰わなければ解らない
    • 「誰が顧客か解らなければ、何が本質か解らない」
    • requirements が予め解っていない
      • リリースして初めて解る
      • V 字モデルを適用できない
  • リーンスタートアップ
    • ソフトウェアを作って使って貰って 計測して 学んでいく
    • validate running
  • 正しいプロダクトを作ってるか？
    • validation が重要な業界
  • 自工程完結

takai.jpg クックパッドの品質活動を通じて、感じたことを発表していただきました。

他の業界でも言われている「リーンスタートアップ」や「自工程完結」は今後、IT業界にどう関わってくるのか興味深いですね。

また最後に「自工程完結をどうやったら実現できるのか?」の参加型質問コーナーとなり、会場が盛り上がりました。

どうやったらテストと実装と品質改善などを効率よく(サイクルを)回していけるのか？考えていきたいですね。

Ruby 2.1 のすべて

笹田 耕一 さん
  • クリスマスに 2.1 が出る予定
    • 10 月にプレビュー版、11 月にプレビュー 2 版、12 月初めに RC 版出る予定
  • 変更点
    • syntax
      • method への引数渡し方
      • Rational の仕様
      • 文字列に f を付けた時の object の挙動
      • Complex の仕様
      • method return 値(式)の記述がない場合、symbol が返却
    • Runtime changes
      • いくつかの method 追加
        • String#scrub
        • Object tracing
      • Refinement
        • Ruby 2.1 から公式機能に
    • パフォーマンス改善
      • RGenGC: Generational GC の改善
      • inline cache が良くなった
  • 資料: http://www.atdot.net/~ko1/activities/toruby05-ko1.pdf

sasada.jpg 残念ながら発表時間が足らず全て聞けませんでしたが、2.1 の新たな展望を発表していただきました。

※資料から残りの発表されなかった部分を見る事が出来ます。

また、資料を読んでいて、ほぼ全て英語で書かれているのですが英語が苦手なレポート係でも「読める」事に気が付きました。

簡潔にまとまっている資料は言葉の壁を超えるのだと感動しました。

モックアップとプロトタイプ

後藤 謙太郎 さん
  • モックアップとプロトタイプを 仕事で使い分ける機会がない
    • 元々の意味: モックアップが見本、プロトタイプが試作
  • 必要性
    • イベントでデモをする時（商品化しなくても)
    • 開発者に何を作ればよいか伝えたいとき
    • 機能が曖昧な時
  • 開発するものの定義が決まってないために、ヒアリングが失敗する場合
    • モックアップじゃ動くけど、本番用に作ってない
      • 依頼者はモックアップで動くから本番でも動くと勘違い
  • 目的によって使い方が違う
    • 企画段階だとワイヤーフレームで OK だが…予算を出す時は綺麗なデザインが欲しい
  • 仕様が厳密に決まってないと迷ったり…
    • 人によって精度が違ったり..
      • 1 px ずれてる?..とか
  • 指示する人が文章化してくれなかったり…
  • 誤解をなくす必要がある
  • なるべく開発、企画に混ぜてもらわないと難しい..

gotoken.jpg ご自身の経験上「モックアップとプロトタイプ」を通して様々な場面での定義を 発表していただきました。

「1 px のズレが…」では会場内で「苦笑い」が聞こえてきた事から(自分もですが)味わった人達が多かったのではと感じました。

「仲間を増やしたい：一緒に考えてくれる人、仕事をしてくれる人を募集します。」は決して他人事ではなく何かアイデアがあれば提供していきたいものですね。

仕様が厳密に決まってないと、「どのように苦戦」し「どういう対処」が必要なのか?貴重な体験談でした。

カジュアルにテストして、フォーマルに検証する

福井 修 さん

ir3.jpg 今回のテーマであるカジュアルとフォーマルに沿ってのテストへのアプローチを発表していただきました。

発表の中に Turnip の紹介があり、ご自身が書かれた記事(るびま) や ソースコード(github) のURL を教えていただきました。

興味のある方は読んでいただければと思います。

「?性」について考える

和田 卓人 さん
  • simple と easy の違い
    • simple
      • 一つのもの
        • 反対：編み物が絡まっている:複雑
      • 客観的である
      • 信頼できる(かな)
    • easy
      • すぐ近くにある(語源)
      • 使うのが容易い
      • 自分の文化に近い
      • 相対的で主観的
  • simple と easy を比較すると…… simple の方が大事
    • 自分にとってよりも色んな人にとって大事だから
  • 自分の作ったツール
    • simple と easy が作っているうちにごちゃ混ぜになる
    • 思わぬ使われ方をした
      • 自分の想像を超えていた
      • 簡単さは使って貰って他人にゆだねるしかないな……
    • 簡単なものから作り始めてしまう..
      • 分けないと！
      • 他の人の簡単と自分の簡単は違うから
      • 教訓:小さくて simple なものから作っていこう!
    • 簡潔性
      • 設計が人間の頭に入るもの
    • 直交性
      • 分離性、独立性
      • ある変更が他の変更に対して直交しているかどうか?

t_wada.jpg 発表はまだまだ途中でしたが、設計や実装に関する「?性」の話をしていただきました。

simple と easy は日常生活では同じように見えるのですがプログラミングとなると違うという事に気付かされました。

「客観的」と「主観的」は確かに違うのでコードの設計をする時は是非意識してやりたいものです。

残りは別の機会に話した頂けるそうなので、楽しみですね。

いつもの勉強会

arton.jpg とちぎ Ruby 会議の開催母体となっている toRuby でいつも行っている勉強会を行いました。

toRuby では現在「さまざまなデータとアルゴリズム」の朗読、写経を行っています。

今回は著者の 1 人である arton さん本人による朗読を交えた勉強会となりました。

朗読の合間の、どうしてこういうことを書いたのか?など、書籍の行間を埋めるような発言の数々は、著者ご本人による朗読ならでは。また、会場の様子を見てもらうと分かるのですが、写経をペアプロで行う方も多かったようです。 　 　 　

　

　

　

　

　

　

trio.jpg 余談ですが、このような勉強会で写経に使う本を忘れると参加できないんじゃないかと思われる方がいらっしゃいますが、それは違います。隣の席の方とのペアプロのチャンスとポジティブに受け止めましょう。

実は筆者も忘れてしまった一人です。しかし、忘れ物をしてもネガティブにならない。

これは arton さんも本を持ってくるのを忘れてしまっていたことがしっかり証明してくれています。

　

　

　

　

　

　

　

ikezawa_sako.jpg gouka_retsu.jpg

　

kakoi.jpg shitsumon.jpg

さいごに

形式手法に始まり、思いやり、品質、モックアップ、テスト、simple とeasy、そして Ruby! と非常に話題は多岐に渡りました。

そこには、今回のテーマである”formal and casual”が散りばめられており、とちぎで今しか味わえない極上の Ruby 会議であったと思います。

次回 06 も楽しみです。

そうそう、06 が待ちきれない方には朗報です。

とちぎ Ruby 会議 05 の主催である toRuby は毎月第 1 水曜日 18:30 から西那須野公民館にて開催しています。 とちぎな方もそうでない方もご参加お待ちしています!

  1. 2 冊あります。 ↩