＠IT：28歳から挑戦するITアーキテクト（2）
それがそうでなければならない必然性の説明。
設計者の説明責任。
Category Archives: オブジェクト指向・システム開発
マジカ、アジャイル
平鍋さんにコメントをいただいたので、それに答える形で。長くなったのでこちらにまとめました。
＞マジカ、なんかはどう思いますか？その二重構造に一番焦点を当てていますね。
マジカはすごく良いと思います。
ただマジカ自身は実際の現場にいる方に書いてもらう必要があると思うのですが、それが今自分のいる場所では難しいと考えています。
またマジカは基本的にワークフローを発見する物で、それだけでは完結できないという問題があると思います
問題はユーザーや、スポンサーとの距離で、その距離がアジャイルな方法をとることが難しくしています。たぶん自分が関わっているような競争入札による契約形態や、プラント建設の一部としてのソフトウェア開発では大変難しいですね。仕事の始まり時点でビジネスワークフロー自身が明確ではない場合がほとんどです。
そういった、現在自分の置かれている立場で、その距離を縮めていくことは難しいと考えていて。実際のユーザーやスポンサーとの距離がある以上ペルソナ法のような形でユーザーの持つ問題点や、必要なことを見つけていくしかないのかとも思っています。
あーでも泣き言だなぁ。
UMLの使い道
UMLと、分析・設計。JUDE製品の方向性。 – An Agile Way [ITmedia オルタナティブ・ブログ]
“UMLモデリングトゥールは、「コンパイラ」ではなく「人」との対話に重点をおくべきだ”
これは本当にそうだと思います。UMLを含む図は多数間で誤解を出来るだけお互いに持たずに何か表現を共有するには良い方法で、それはUMLのように表記法が一般化されていればなおその誤解を小さくしていくことが出来ると思います。ただ難点はお客さんがみてもわからないと言うところでしょう。プロジェクトに関わるステークスホルダでUMLを理解するのはごく一部だし、他のステークスホルダにUMLを覚え、理解しろというのも技術者の傲慢です。UMLの難点と言えばそこが最大の難点ですね。このため、UMLで書いたとしても翻訳が必要になってしまいます。マインドマップも結局は同じ問題を抱えていると思います。
結局のところ非技術サイド用の資料と技術サイド側のモデル図という二重構造が残ってしまうのですが、それについて折り合いを付ける良い方法が思いつきません。結局人間がどちらからどちらかへ翻訳するしかないのでしょう。清水建設さんのフロー図が折衷案のような気もしますが、あれも翻訳の一つの方法かなぁという気がしています。
ユーザーインターフェイスの設計
実はユーザーインターフェイスについての記事を書こうかと、あれこれ準備をしていたのですが、以下の記事を見つけ、読んで、自分でかくのはやめることにしました。
私が書こうとしてしていたことがまとめられている上に私が書くよりきっと上手く書かれているから。
Joel on Software プログラマのためのユーザインタフェースデザイン
ユーザーインターフェイスが持つべきアフォーダンスについて。
奇抜な物では無く、みんなが慣れたインターフェイスを再利用する。
ペルソナ。（文中にはペルソナという言葉は出てきませんが。）
機能ではなく、ユーザーアクティビティによるデザイン。
以上がすばらしい文章とともにまとめられています。
どっちが馬鹿なんだか。
バカが征く
読んでいて、懇々と説教したい気分に駆られるわけですが、まぁどっちがバカなんだかと言うことにまとめたいと思います。
ユーザーインターフェイスの設計が悪いと人が死んだり、停電したり、事故が起きるかもしれない現場で鍛えられれば良いんだよ。それにそのユーザーインターフェイスもあんたらが相手にしてるその小さなWebブラウザだけじゃないんだ。と怒りが止まらなそうなのでここまで。
ITアーキテクトとソフトウェアアーキテクトは違う
ということだ。
と言うよりも、Javaコミュニティやマイクロソフトの見ている世界とIBMが見ている世界が少し違うと言うことかもしれない。IBMは結局のところキャビネットを売ってなんぼの会社のままだし、マイクロソフトはCDと紙っぺらを売ってなんぼの会社だからだ。
これはどっちが良い悪いではなくて、企業やコミュニティのスタンスの違いでしかないので、それぞれから発せられるメッセージを受け取る我々がそれを気にかけて、理解・判断すればいいことなのだろう。
＠IT：ITアーキテクトを探して（2）
ユーザー中心設計なんて本当は当たり前の話。
使いにくい業務システムが生まれる理由：IT Pro
お客様から代金をいただいて、物を、それもほとんどがオーダーメイドで作っている以上、お客様に満足いただくのは当然です。したがって、ユーザー中心設計なんて言葉が持ち出されるまでもなく、ユーザビリティやお客様の満足が得られるように設計するのは当たり前なのですが、その当たり前をやってこなかったのがこの情報通信産業というやつです。
おそらくこの当たり前が出来るようにならなければこの業界の未来はないと思っていますし、社会の発展もないでしょう。券売機の前で立ち止まって固まってしまったおばあさんは、このおばあさんになにか悪いところがあったのでしょうか、このおばあさんの能力が低いからですか？それとも券売機のインターフェイスのデザインが適切でないのでしょうか。答えは明白なはずです。能力にかかわらず大多数の人は列車の切符ぐらい買えるべきです。
技術は人を手助けする物であって、人に制約加える物では無いはずです。ましてや自分の不勉強や不誠実を技術のせいにしてはいけません。
言語学習方法
GDNJにも書きましたが、社内用に作成し日の目を見なかった言語学習に関してまとめたスライドをさらします。
このスライドを作りにあたっては今は廃刊してしまった、ネクストエンジニアという雑誌に豆蔵の萩本さんが書かれた記事を参考にしています。
言語学習法
http://www.isisaka.com/言語学習方法.pps
感想・ご批判なりいただけるとうれしいです。
ソフトウェアのプル生産
ソフトウェアのプル生産 - An Agile Way
後工程が必要とするまで仕事に取りかからない。仕掛品を作らない。無駄な在庫をなくす。
前工程が後行程を駆動していく（プッシュ）ではなく、後工程が前工程を駆動していくからプル生産。
最終的にプルするのはお客さんであって、お客さんに届かなければ結局それは仕掛品で、むだな在庫か。
その点ではXP等での段階的リリースは正解なのだけど、僕らの業界（プラント計装）では難しいか。でもやり方はあるはずなんだから考えてみよう。
ソフトウエア・セル生産WGが始動
日本のソフト開発力向上狙い、「ソフトウエア・セル生産」の研究会が始動 – 日経コンピュータ
今のこの状況を根本的に見直す最後のチャンスかもしれない。
どうか大きな成果が上がらんことを。