【システム開発】画面検討とユーザインタフェース検討は違う？
SI業界に入り、１０年以上経つのだが、今までホストでの開発や、クラサバ系または現行アプリの改修を中心に実施して来ており、あまり画面について深く考えることはありませんでした。
私の頭のなかにはビジネスアプリ（Webなどとか関係なく、一企業の中で使うアプリ）は
「無駄をそぎ落として」
「必要最低限の機能で・・・」
「使う側が仕組みを理解して・・・」
というのが染みこんでいたのだろうか、「ユーザビリティ」という視点を持っていたようで抜けていることに気づいた。
私なりの認識で画面検討というと
「入力」「表示・参照」を「どのような項目で行うか」というのを考え、
モックアップを作成し、ユーザに確認、合意を行う。
というプロセス。
しかし、これって、画面のイメージや業務ストーリーはすべてユーザ任せ何だよなと
最近気づきました。
受託案件でも常駐型でも、「使いやすさ」「見やすさ」というのは大いに求められていると思われる。
スマホアプリや私用のPCでWEBサイトなどを利用し、登録・参照を行うときの画面の使いやすさ（使いやすさに気づかず、使いやすくなっているのだが・・）に慣れていると新たに企業システムを作ると不都合さのギャップにハマり、使ってもらえないならまだしも、画面イメージでNGを受けるのではないかと。
いくらシステム開発がメインで、WEBデザイナーでないとしても、多少の嗜みを持って、UIを考える時代になっていると実感しています。
そこで、今参考にしているサイトは・・・
デザイニング・インターフェース: パターンによる実践的インタラクションデザイン - Jenifer Tidwell - Google ブックス
・google booksで一部参照できるので
【インタビュー】クックパッドのUIデザイナー：「エンジニアの仕事が0を1にする仕事なら、デザインは1を100にする仕事 」 - THE BRIDGE（ザ・ブリッジ）
・UIってcookpadかなと思ったので、ググった。
この記事に付いているui-patternでデザインパターンを知る
UI/UX JAPAN - UIデザイン・UXデザインのいろいろを発信するブログメディア
・シンプルに、何を伝えたいのかという原則を考えるのに使ってます。
51のチェックリストに記載の内容を元に画面を複雑にしないように意識しています。
他にも優良な情報というのはあると思いますが、今は限られた中で消化中です。
画面を考えるときには、言われたとおりに考えるのではなく、
「利用ユーザになりきって、想定される使い方をイメージし、システムの利用動線を
考えながら画面のラフ案を作る」
ということがユーザ・インタフェース検討になっていくのかと今は思っております。
現在進行形で、動いていますので、また経験値を積んだら、
おさらいをしようと思います。
運用って・・・ただこなすだけじゃないだろう！
ITILのサイトにも書かれているように、
 |
ITサービスに対するユーザと顧客の満足度の向上 |
|
サービス可用性の向上、事業の利益と収益の増加 |
|
やり直しと損失時間の削減、リソースの管理と利用の改善によるコスト削減 |
|
新しい製品やサービスの市場投入までの時間の短縮 |
|
意思決定の改善とリスクの最適化 |
ってのが運用担当には求められている。
作業手順書に従って、日々、ユーザからの依頼にしたがって、淡々とこなすのは
何か違う気がしています。
エンタープライズ・・アプリケーションの保守運用であれば、日々運用に携わりながら、
・システムの特徴
・データの特徴
・発生しやすいこと
などを掴み、システム改善の提案やシステム品質を保つための提案を
先んじてできると感じています。
せっかく仕組みを作っても、システムとともに人が劣化させて行ったら元も子もないので、運用は運用でしっかり考えていただきたいものである。
【R】ggplot2のインストール
Rを勉強しようと
RとRubyによるデータ解析入門
posted with amazlet at 14.12.22
でRの学習開始をし始めてます。
昔にRをインストールしており、バージョン3.1.0で開始。
一個一個やっていたのですが、ggplot2のパッケージインストールをしたところ、
digestが見つからないと。
よく見ると
http://cran.ism.ac.jp/bin/macosx/mavericks/contrib/3.1/digest_0.6.6.tgz
を指している。
実際にサイトを見ると、0.6.7が置いてある。
下位バージョンのRだと、パッケージは取れない仕組みなのか？？はたまた自分がやり方をまだ知っていないからなのか？
今はよくわらかないので、ひとまずRを最新の3.1.2にあげたら、0.6.7を指すことができたのでよしとしよう。
まだ課金されていた in AWS
もう、大丈夫だろうと思っていた、AWSが課金されていた。。。
何じゃと思ったら、SnapShotが削除されていなかったようである。
http://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/deregister-ami.html
Amiの管理下であったため、SnapShot情報が削除できず残っており、
まあ、1$にも見ていないが、月額で細かく取られていた。
スタートアップは便利だが、クロージングが結構面倒なのかもしれない。
先日も、食事していた時に聞いた話だが、試しにResionサイトを日本とアメリカでインスタンスを立ち上げ、データ通信のテストを検証していた人がいた。
その後、自身ではインスタンスを落としたつもりだったそうだが、
請求で４０００＄が来たようである。
話を伺うと、バックアップ処理が残っており、結構大容量データを検証していたため、データ使用量を取られたそうな。
一応、悪意はないことをAmazon Japanにダメ元で確認を取り、本国で対応してもらい、請求されたお金は、返金されるみたいですが・・。
便利な分、使う方も気をつけて使わないと、余計な出費になりそうである。
【メモ】ETL系のデータ生成での調査の段取り
本日ハマったので、段取りを残す。
１．登場するファイル、データベースの一覧を取得する
２．登場するファイル、データベースのER図（関係図）をまとめる
３．ETLツールを調査し、生成元ファイルと生成先ファイルの関連性を整理する
４．トリガーイベントが隠れていないか・・・確認する
５．ETLツール以外にデータにアタッチしていないか確認する
トリガーイベントは基本使わないだろう・・・とう認識があったので、
完全見落としており、ずっと「なんでこのDBのデータが生成されているんだろう？」と
悩んでいた。
ホスト系の開発ですと、トリガーを利用する意識がなく、調査のフレームに入っていなかたのですが、GUI系のシステムならばどうも使っている傾向があるようである。
SQLServerでは、このサイトで確認方法を見たので、記述。
select tr.name as trigger_name, ta.name as table_name, tr.is_disabled as disabled
from sys.triggers as tr
inner join sys.tables as ta on tr.parent_id = ta.object_id
リンク先のSQLにはdisabledの記述は記載がなかったが、トリガーが無効になっているか否かも調べておいたほうが後々説明する場合、及び自身の仮説を作成するのに利用できます。
【メモ】リバースエンジニアリング(ETL編)
ここ、1、２年くらい、いろいろなお客さん、社内の誰かが作った現行システムの調査、分析を行ってます。
開発を行うよりも、ソース見て、設計書見て、「不具合？」「なにこれ？」「へ〜〜そういうこと」ということが多く、びっくりと発見を繰り返しながら
・今の状態を極力可視化する
・設計書とソースの差異を洗い出す
・問題点を出す
・解決の方向性を示す
というのも意識して、実施しています。
今回は、タイトルのとおりETL。。。の分析。
今までETLツールを実際に扱ったこと無い（HULFTはあるが、設計はしたこと無い)という状態でしたが、基本、データを加工するだけなので、見方さえ覚えれば、なんとかなるもんなんだと。
さて、実際に解析して気づいたのですが、こういうことがあると調査がとまどるな〜〜ということがあります。
・意味のないカラムや項目が紛れている（なんであるのかな・・・調べたのに使ってない）
・意図通りに動いているのか判断できない条件文（バグかな？？）
では、どうやって乗り越えるのか。
世の中にはたいそう便利なリバースエンジニアリングツールが多くあるのは知っております。しかし、実際にそのツールを使って分析しているお客さんにいまだあったことはございません。
個人的には、実際のソースはツールを利用すれば、見えるのだが、本当に知りたいのは、
「なんでこんなことしているんだろね」
「今をベースもしくは新しく作りなおすには何を気にしないといけない？」
といったことを知りたいものかと。
それを起点に考えると、いくら現在のシステム状態を見せても「で？？」と聞かれるのが落ちなんでしょうね。
では、私は何をしているか・・・。
と、言っても画期的なことをしているわけじゃないです。
やっていることは３点
・ER図の作成（ETLの元、先のシステムのDBの）
・ETLの処理のマッピングを人がわかるレベルで記載
（ツールでうまく出しているのもあるが、I,P,Oで記載）
・ETLのJOBの関連性を記載して、時系列で表現する
と、いうことです。
要は、点ではなく、線や面で表現して、ユーザが利用している業務の言葉や、表現、流れに以下に近づけて、今の業務の問題点を炙りだしてもらうか。次の新システムの考えをイメージしてもらうか・・・が勝負かと。
地道な作業ですが、データの移行などの肝となる作業なので、早く、正確にやらんとなと。。
【メモ】ホストとWebとどっちが安心・・・という話になったので
昨日は飲み会。
他愛もない話から、趣味の話になり、その一部に、
「ホストのほうがWEBよりトラブル時の対応がやりやすい」という話がでた。
私もホストでの開発、運用が長いので、個人的な意見を。
ただ、WEBは運用経験がほぼ無いので、妄想です。
正直、ホストのほうが何かあった場合、リカバリが聞くのではないかと思う。
ホストの世界ですと、24/365では無いので、オンラインとバッチの世界に分かれる。
基本的に、オンライン中にシステムダウンはよっぽのことがない限り無い。バグがあり、トランザクションエラーはあるが、本番リリースを行ったあとは無いだろう。
と、いうことでバッチの世界で考える元とする。。。
ホストでのバッチは「実行したか」「実行していないか」というのが明確に判断できる。もともと最初に「人の意思で設定した順序のトランザクション」しか流れないので、不確定要素がない。スケジューラーの実行結果を見れば、「どの時点でトラブった」というのがわかる。
WEBでもログとDBを使っていれば、COMMIT、REDOログなどで判断は可能だ。
「時点がわかるのはWEBでもできる」というのは同じという意見は理解できる。
個人的には、ここからが大変なのかなと。
ホストであれば、
「このトラブった時点で、どのファイルが更新されており、このファイルはまだ更新されていない」というのがわりと容易（ちょ〜簡単という意味ではない）にできる。
一方、WEBの場合、データを突き合わせていって、「どこまで更新されており、どのような状況なのか」を判定するのに時間がかかる。トラブル時の複雑度がホストに比べると高いのではないかなと思う。
ただ、それだけでホストがいいというつもりは無いです。
要は使う会社や人の業務レベル、システムレベル、サービスレベル、何を実現したいのかによって、選べばいいかと。
なんでも最新技術を使ってやればいい。。と思うのではなく、「何を実現したいか」を軸に、「何を使うか」。あたりまえのことをしっかり考えて、情報システムは構築しなければと改めて考える飲み会であった。
