works4Life Season VI

具体的なユースケースを作ってから、作成されることを激しくお願いしたいです。

世の中デザインファーストとか言われていますが、ぶっちゃけその通りです。使われてナンボのこの世界。格好良さや速さなんてのは使い勝手の前では儚いものです。それに格好良さや速さが何のために存在するのか？ そんなもん一言で言えば、人が使うのを速くするためです。

しかし、一つ一つのアクション自体が速くなっても、サービスがよってかかって攻めてもどうにも難しいことがあるのも事実。それは何か？ 人の動きとゆーものです。画面の前にいるその操作をしてくれる人は、結構簡単にあっちへうろうろ、こっちへうろうろしてしまいます。そこに特効薬はあるのか？ あると思います！

ユーザビリティとかそーゆーもんです。

私がサービスを使って手がわなわなとなるのはどんな時か？ こうしたいと思った時にその機能がない時です。「飲みたくなったらお酒、眠たくなったらベッド」とは昔の流行曲のフレーズで私の好きなフレーズベスト10にも入るわけですが、まぁサービスにもそんな次から次へと差し出すサービスを求めるもんです。少なくとも私は求める。

でもさー、ユーザは好き勝手にするから、ユーザビリティっていっても一概に決められないじゃないかー

何を言ってますですか、動作を決めるのはユーザではありませんよ、サービスです。サービスがちょちょちょと誘導させてユーザがどう使うか決めるんです。誘導です。牧場と一緒です。迷える子羊ばっかりなんです。牧羊犬よろしくがんばるのです。それができてこそのサービスです。しかし、ユーザビリティといっても、これが決まってなくてはユーザビリティも発揮できないんです。一番初めに決めてないこと、あるじゃないですか。

それはユースケース。

ここで言うユースケースとは、そのサービスを使ってユーザがどんな風に振舞うかを決めること。ここでボタンを押して遷移したりとかそういう奴です。一番上で言ってるデザインファーストは、私はここと同じことを指し示してます。いやいや作ってるよと言われるかもしれません。

しかしですよ、その時にボンビラスなみのいやーなユーザーにねちねち文句を言われても大丈夫なようなユースケース、作られたとですか。自分が頭の中でイメージしたその画像になるようにユースケース書けたですか。んな無茶な！ と思われるかもしれませんが、こんぐらい気合入れないとユースケースの意味はありません。

こんな売り文句よく見かけます。 「可能性は無限大です！」 そんなもん嘘です。作ったところで使い方がわかってないだけです。作った方がわからないのにユーザがすぐには理解できるわけがないじゃないですか。

こんなこともよく聞きます。「いいサービスだったら使われるに違いない！」 いつまで白馬のユーザ様を待ってるんですか。世界は変わりました。ユーザ市場の世の中、サービスからアプローチをしなきゃいけないんです。

使いにくいのにがんばって、使い方を見出すようにがんばりたくなるツールなど、ないわけないですが、超稀です。そしてそんなサービスは効果が出にくいので、ぶっちゃけメジャーになりません。

作るサービスを愛してください。

そのサービスが好きなら、どういう風に使われることを望んでいるのか、教えてください。他のサービスと違ってどんなことができるのか教えてください。どんな風に使ったら快感なのか教えてください。少なくとも私は、バカでドジでのろまなユーザです。使って30分以内にそれがわからなかったら、次のサービスに行ってしまいます。

さよならだけが人生です。

それでも、私はそのサービスに良さがあるなら、共有したいと思います。できないなら言いません。できるからこそ言うんです。開発者さまさま、良いサービスを提供してください！

以上、口うるさいユーザからでした。

 

自分コメント

• 勢いに任せすぎてどうしようもない。。

Categories: Drafts

http://blog.shibu.jp/article/28983162.html

上で渋川さんがプログラミングについてまとめてたので、何かしらプログラミングで言いたいなーと思ってしまったので、今やってるプログラミングの作業順番をまとめておきます。

私はもともとjavaのプログラマでした。ブログのタイトルはその名残です（小文字始まり・4使用）。プログラムめんどいよ～仕様決める仕事がいいよ～、と思ってPMにジョブチェンジしました。粒度が合わなかったんですね。それはさておき、今回の自動化作業のだいたいの作業の順番について。

今回のお仕事

お題：ウェブサービスの運営で、定常作業を自動化するのに、perlでプログラミングを組むこと。

ゴール：他の人がそれを使って作業を実施できること。問題があっても他の人がメンテナンスできること。何かあったら他の人が改変しやすいこと。

とゆーよーな感じのお仕事です。

作業手順

1. 定常作業から作業項目を洗い出す
2. できるところからプロトタイプ
3. ２を繰り返す
4. 標準化
   1. conf設定対応
   2. IF統一
   3. ログ追加
   4. 定数化作業
5. 資料作成

以下詳細。

１．定常作業から作業項目を洗い出す

もともと手作業でやってたのを自動化するので、もとあった手順書からプログラミングすべき作業を洗い出します。この時点で作ろうと思う関数は洗い出しされてます。設計がないと、ここで抜けもれが発生しました（例：conf設定対応とログ）。

２．できるところからプロトタイプ

プログラミングも久しぶりだし、perlも手馴れてないんで、できるところから書いては実行です。動いているので安心感があります。この時は面倒なのでファイル1枚で実行し、関数を増やすといった感じ。

３．２を繰り返す

必要な関数を増やします。で、一通りできたら、それを使って手順書通りに実行する関数を作ります。正直ここで終われるものなら楽です。

４．標準化

私のやる気ナッシングな領域に。

４．１．conf設定対応、テンプレート対応

設定ファイルは外部化します。xxx.confとかそんなファイルから読み込めるようにしておきます。使いまわしする予定があるのでー、ファイルと同化してるとダメなんです。

テンプレート対応とは、conf設定やtmplファイルに、テンプレート変数を使っていたので、それの対応もしました。これは、confファイルで、出力ファイル名を”xxxx-$today_yyyymmdd.xls”とか設定しておくと、自動的に”xxxx-20090511.xls”とかに変更してくれるような仕組みです。

ここらへんで、ファイルを分割してライブラリ専用ファイルを作りました。

４．２．IF統一

上記との兼ね合いもあり、再度関数のインタフェース（引数とか返り値とか）を見直しです。

４．３．ログ追加

ここでようやくログ追加。

４．４．定数化作業

文字列排除。今作業はここらへん。今思ったけどやっぱり徹底的に文字列は排除しよう。。

５．資料作成

で、上記の設計をまとめた資料を作る予定。

• 概要設計 – ツールの目的、ゴール、ユースケースがあると便利（使い方のイメージつくから）
• 外部設計 – 枠決め。関数のインタフェースと機能を決める。シーケンス図があると便利。
• 内部設計 – 中身決め。関数の中身を説明する。アクティビティ図。
• 実装設計 – 実装決め。どのファイルにどの関数を入れるか。設定ファイルはここら辺で書くと思う。
• 使い方説明 – 使い方。修正方法等。

後残ってるのが、ログの説明ぐらいか。。どこに組み込もう。

総論

perlもプログラミングも昔とった杵柄レベルであまりに慣れてないので、今回はプロトタイプの作成から始まりました。しかし、時間がかかりすぎるのが難です。

なぜなら、あとから追加項目が多いから。毎回変更したら、ちゃんと動くかどうかテストするのが面倒だから。なんにせよ、手戻り作業が多すぎるです。

今回は、プログラム自体は2ファイル程度（設定ファイルは10ファイル前後）の成果物でしたのでなんとかなってますが、時間のことは関係しなくても、他人が使うことを想定すると、やはり設計は必要です。とはいっても、自分が使うにしても、やっぱり設計は必要だと思います。なぜなら、3ヶ月前の自分も赤の他人だから。

でもね、プロトタイプは最初は楽しいんだよねー。

まぁあれですね、他の人に共有すること前提なら、プロトタイプからのプログラミングは、あんまり合わない、ということでした。

ソースがきれいとか構造がきれいとか

ソースがきれいとか構造がきれいとかありますが、私の昔の感想は以下のような感じでした。

作った直後の私は、自分のソースはきれいと思ってました。他人のはきれいかそうでないかというか、読みにくいな、と私は思うのでした。理解の粒度は違うのでそれはしょうがないんですな。そして、数ヶ月後の私は、自分のですら汚い読みにくい何コレサイテー！と本気で思うのでした。

 

自分コメント

• 勢いでやった。後悔はしてないけど、文章に責任はもてずにすぐお蔵入り。
• ていうのと、どのライン用なのよ、というのがあって、やっぱりお蔵入り。

Categories: Drafts