PPL2015 ポスター発表の内容です。かなり適当なスライドなのでここで補足します。 【概要】 残念なぐらい使いにくい画面のソフトウェア（あるいはサービス）というのがたくさんあります。で、その原因のひとつには「ただHTMLをゴリゴリ書くだけでは、人間がどう考えてどう操作するかはどこにも書かれていない」ということにあると考えました。だから、依存型付き関数型言語であるAgdaを使ってその部分を形式的に記述すれば、残念な画面が減ってもっとみんな幸せになるだろう、と考えています。Agdaを使うとうまくいけそうだ、という予想の根拠はいくつかあるのですが、まだ実装はできていません。Position Paperというのが世の中にはありますが、さらにそれの前段階のPosition Presentationです。 やっぱりここは狭いので続きはブログにて。 http://d.hatena.ne.jp/kiiiino3+lab/

1. ソフトウェアUI妥当性確認の
形式化に向けて
木下修司
神奈川大学大学院理学研究科
概要
1. なんだか使いにくいソフトウェア（サービス）が多い
2. 原因のひとつは、UIの妥当性確認（≒インタラクション
デザイン）が欠けていること
3. GUI記述言語として、Agdaのような表現力の高い依存型
付き関数型言語を利用することで、GUI定義と「その妥
当性確認」をあわせて記述できるのではないか？
4. 一緒にやる人を大募集中！

2. 使いにくいソフトウェアが多い
• 原因は、「使いやすさ」の検討不足。
• 期限のある開発プロジェクトでは、「とにかくシス
テムが動作すること」に重点が置かれる結果、サー
バ側処理やDB設計が優先
• ユーザビリティの考慮は後回しにされ、使いにくい
まま本番リリース
• 本番リリース後は
「そんな変更してデ
グレしたらどうす
る？！」と、操作性
改善は却下される
最初の検討が重要。

3. UIの検証と妥当性確認
• 検証 Do the things right.
• 仕様どおり実装されているか
• UIの例：定義されたとおり画面遷移が行われるかど
うか
• 妥当性確認 Do the right things.
• そもそも仕様が正しいか
• UIの例：そもそも、その画面遷移はユーザの目的達
成に適切かどうか
UIの妥当性確認≒ユーザ操作の流れの検討・作
成（インタラクションデザイン）

4. • UCD（ユーザ中心設計）やUI/UX分野の研究
• ISO9241-210:2010（人間中心設計）
• ペルソナ・シナリオ法
• 師匠と弟子モデル（Contextual Inquiry）
：
• SE/PGに比べてUI/UXデザイナは不足。
• BtoCのサービスはまだしも、BtoBのサービス開発
では、専門の人員を用意することは困難。
• デザイナがいれば問題がすべて解決する、とい
うわけでもない。
• 成果物の形式→ソフトウェア固有の問題がある
使いやすさの研究は多数あるが、
気軽に使えるわけではない

5. プログラム、ソフトウェアから
システム、サービスへ
• 単純なInput / Outputのみのプログラムから、プ
ログラム実行中に画面出力 / 人間の入力が行わ
れるインタラクティブなプログラムへと変化
• 人間の動きまで含めたデザインが求められるが、
従来の「プログラミング言語」には、それを記
述する部分はない。
従来のプログラミング言語に記述される部分
ここも書きたい

6. インタラクションの例
打合せの資料をアップロードしたい。
1. 「この画面にファイルを添付したいな」
2. 「どこを押せばいいだろう、あ、このボタンか」
3. ★【「ファイルを追加」ボタン押下】
4. ファイル選択ダイアログが表示される
5. 「資料はどこにあったかな・・・」
6. ★【ドキュメントの一覧を数回クリック】
7. 「あ、これだな」
8. ★【ファイル選択】
9. ★【開く】ボタン押下
10. ★【画面上にアップロード中の表示】
11. ★【画面が自動更新されてアップロード完了】
12. 「ああ、添付できた！」
★のついている部分は
コードとして記述されて
いるが、それ以外はプロ
グラム上には存在しない。
しかし、画面設計の妥当
性を考える上では、この
流れは重要。

7. 従来のUI設計の問題点まとめ
1. UI/UXデザイナーの不在
• 専門の人員が用意できる開発PJは少ない。（予算
の問題etc）
2. デザインの成果物とソフトウェアの不整合
• 仮に専門の人員がいたとしても、デザイナの成果物
は主にドキュメント
• 頻繁に修正されるソフトウェアの場合、ドキュメン
トだけが更新されずに残る危険性
3. デザインから実装への移行がスムーズでない
• 「モックアップ」と呼ばれる画面サンプルを一度捨
てて、改めて実装しなおすことが多い。

8. 従来のUI設計の問題点の解決
1. UI/UXデザイナーの不在
• 専門の人員でなくても（プログラマであっても）、
気軽にインタラクションの検討ができる開発環境が
あればよい
2. デザインの成果物とソフトウェアの不整合
• 最終的な画面のプログラムと、デザインの検討結果
が常に対応づけられる開発環境があればよい
3. デザインから実装への移行がスムーズでない
• モックアップのコードがそのまま実装で利用できる
ような開発環境があればよい。

9. 解決方法（Webサービスの例）
• HTML/Javascriptを直接記述するのではなく、
Agdaから自動生成する。
• Agdaで記述した画面定義の検証・妥当性確認
をAgda内に記述する。
HTML &
Javascript
Webブラウザ
サーバ側の
ロジック
APサーバ
Database
更新処理
DBサーバ
HTML &
Javascript
Webブラウザ
サーバ側の
ロジック
APサーバ
Database
更新処理
DBサーバ
画面定義
Agda
生成
UI設計書
As Is
To Be 簡単なサービスなら自動生成可能？
検証・妥当性確認
Agda code

10. 利点
• 画面定義の記述と、その画面の検証・妥当性確
認の記述をAgdaコードとして共存させること
ができる。→シームレスな開発環境
• 画面のコンポーネントが変更されたときに、妥
当性確認の記述を修正する必要があることを、
型検査によって通知できる

11. Agdaコードとグラフィカルな
表現の変換
Agda
コード
GUI表現