nishimotzの日記

月: 2014年2月

  • モバイル見積もり勉強会　IN　広島に行ってきた

    モバイル見積もり勉強会　IN　広島に行ってきました。
    下記のような見積もり勉強会が最近関西や東京で開催されるようになり、ぜひ広島でもやろうと企画されました。
    WordPressサイトを構築するといくらかかる？ 見積り勉強会で価格を出してみた
    カレー屋チェーン店公式アプリの仮想案件をみんなで見積もってみた #モバイル見積
    最少催行人数が最初は10人だったはずですが、けっきょく9人で開催。
    あの人が東京から駆けつけて、お土産の東京ばな奈が美味しかったです。ありがとうございました。
    発注側役から、架空案件とは思えないほど具体的に準備された資料が提示され、チームに分かれて見積もりです。
    3チームを作れるほどの人数が集まらず、3人ずつの2チームとなりました。
    私のチームは「最初にリスクを洗い出す」ということで、ハイブリッドよりもネイティブアプリのほうがリスクが少なく安全な見積もりができるという話に。なるべく早くベータ版をストア登録申請する、といった提案が盛り込まれました。また、管理工数として週1回の打ち合わせに相当する費用が計上されました。
    項目ごとの人月を決めるときには、まず相対的な作業量の見積もりをして、最後にそれぞれの項目に係数をかける、というやりかたをしました。
    もう一つのチームはHTML5を使う提案だったり、「これがあったら喜ばれる」という工夫が盛り込まれていたり、こちらのチームといろいろ違っていて興味深かったです。
    相見積もりの金額のばらつきは技術者の見解の相違であり、発注側の要注意ポイントになる、だそうです。
    ディスカッションでは、受注者としての日頃の苦労や工夫、この案件のどこがどう「地雷」なのか、興味深い「ここだけの話」がたくさんありました。
    「見積もりをどうすると発注者・受注者ともに良いかを考えましょう」というのがこの勉強会の目的だったはずなので、帰宅して改めて考えてみたのですが。。
    私のチームの人は「本当は正確な見積もりなんかできない」「要求通りに作っただけでお客さんのニーズが満たせるとは思えない」という本音がありつつ、今日は時間がないのでとにかくルールに従って数字を埋めた感じでした。もっと「アジャイルな開発」「リーンなスタートアップ」をやりたい受注者は、今回のような見積もり要求に対してどのように応えるべきなんでしょうね。。
    「発注者は機能に対してお金を払いたい」
    「受注者は人と時間の拘束に対してお金を受け取りたい」
    この現実のギャップを垣間見た一日でした。
    残念ながら参加者が少なかったので、広島でまたこういう見積もり勉強会が開催されますように、という期待を込めて、見積もりの苦手な私がこうしてブログを書きました。

  • #OSH2014 感想と懇親会LT #nvdajp

    オープンセミナー2014＠広島に参加しました。
    懇親会LT（ライトニングトーク）の私のスライド「テスト駆動開発とアクセシビリティ（仮）」は下記の通りですが、スライドだけではわからないでしょうし、トークも言葉足らずだったので、昼間のセッションの感想をふくめて補足します。

    NVDA 日本語版 の紹介。NVDA の開発には Python が使われています。
    実は「NVDA日本語チーム」を立ち上げる前に、私はまず「NVDAユーザ会広島」を立ち上げて、地域コミュニティ活動を始めました。
    オープンソースカンファレンス2013広島への参加の後、活動が滞っていますが、暖かくなったら再開したいです。
    アクセシビリティ、Python、Windows API、テキスト音声合成、自然言語処理、バージョン管理など、NVDA の開発を語る切り口はいろいろあるので、いろいろな団体と交流が必要だと思い続けています。
    NVDA は Web 開発者の方々にも、アクセシビリティチェックツールとして注目されています。
    NVDA は誰にでも無料で使えて、視覚障害をもつユーザーに実際に利用されている（され始めている）ツールです。
    一方で、ソフトウェアの自動テストという文脈からは、例えば Selenium でスクリプトを書いて Web アプリのテストをされる方も多いでしょう。
    NVDA が動いている状況で Selenium で Firefox を制御するスクリプトを書いて実行するとどうなるか、最近少し試してみました。
    Tab によるフォーカス移動、フォーム要素（コントロール）の操作、文字入力などはうまく制御できるので、Firefox でウェブを操作する様子を読み上げながら自動テストすることができます。
    しかし、NVDA が提供しているのは単なるフォーカス移動だけではありません。ブラウズモードという特別な操作が追加され、例えば数字キーの１から６で見出しジャンプができたり、文字単位で任意のテキストの内容を確認できたりします。
    こうした機能は Firefox ではなく NVDA がキーイベントを受け取って、NVDA と Firefox のプロセス間通信（IAccessible2という専用プロトコルが使われます）を通じて Firefox を制御しているため、Selenium で Firefox に ‘1’ や ‘2’ などのキーイベントを送っても見出しジャンプは実行されません。
    残念ですが、もうちょっと何かできないかなと検討中です、というのが最初に言いたかったネタでした。
    2個目のネタですが、NVDA を Windows 7 以降で使うと UI Automation という技術がデフォルトで有効になります。
    この技術は Windows システム・スクリーンリーダー・アプリケーション、というレイヤーをつなぐ一種のプロセス間通信で、特に GUI をリモートプロセスから制御するモダンなオブジェクトモデルを備えています。
    そして UI Automation は「ソフトウェアの自動テストの技術」でもあり、Microsoft のエバンジェリスト（当時）だった長沢さんが、そういう文脈でいろいろ記事を書いておられたわけです。
    しかし、和田さんの朝一番のセッションで FAQ として触れられた「GUIはテスト駆動開発に向いていない」という話は、私もうすうす気づいていた事実でした。
    Python 界隈では「Selenium は負債」という認識 がちらほら聞こえていましたが、どう「負債」なのかは、和田さんの講演で腑に落ちました。
    GUI テストは一般にターンアラウンドが長すぎて、「黄金の回転」が回せない、「ただのテストがある開発」になってしまうのです。
    「早くて小さい回転をうまく回す」という「TDDのこころ」を、テスタブルでアクセシブルなUIの開発という目標にどうつなげていくか、新しいチャレンジが必要と痛感しました。
    3番目のネタですが、NVDA 日本語版は点訳エンジンを「テスト駆動開発」しています。
    こう書くと大げさですが、実は liblouis という（日本語に対応していない）多言語対応オープンソース点訳エンジンはちゃんとテストを Jenkins でチェックしながら開発が行われています。
    それに倣って、日本語点訳エンジンを、まずテストを書いて、テストが落ちることを確認して、それから実装を直す、というサイクルで作ってみました。
    実際の作業は2012年春から2013年春にかけて行ったのですが、実は最初はタッチカーソルのカーソル位置を処理する「ポジションマッピング」というアルゴリズムを入れていませんでした。
    点訳エンジンをあちこち書き換えつつ、既存の処理を壊さずに最小限の修正でタッチカーソル対応できたのは、テストケースという命綱のおかげでした。
    最後に2枚追加したスライドは、昨日のオープンセミナーを通じて感じたことでした。
    私はチクセントミハイの「フロー体験理論」を1990年代後半に知り、最初はヒューマンインタラクションの評価手法などに応用したいと思っていました。
    スライドに張り付けた「技能と挑戦のモデル」はちょっと古いモデルの図ですが、要するに「いきなり難しいことをする、身の丈に合わないことをすると、不安になり、挫折する。自分の技能にあったちょうどよいレベルのチャレンジを繰り返していくと、人はその作業に集中でき、没入でき、自己目的的な楽しさを得られる」ということです。
    このフロー体験理論のことを最近ふっと思い出したのは「アジャイルサムライ」の読書会でした。
    フロー体験理論という社会心理学のモデルは、日本ではゲームデザインの研究者に着目され、近年ではモチベーションの研究で参照され、もはや古典なのかも知れません。
    しかし、テスト駆動やアジャイルというプラクティスの根幹に、フロー体験というシンプルな社会心理学のモデルが、やはり無視できないかかわりを持っているように、あらためて感じた、和田さんや長沢さん、そのほかの貴重な事例報告のセッションでした。