久しぶりに、疲れた。
いや、いつも疲れるには疲れるんだけど、今日は自分に直接ではない。
今進めているプロジェクト。キーパーソンになっているメンバーに任せている周りの進捗がおもわしくない。あまり口を出しても変に自尊心を傷つけてもあれなので、もう少し見守っていくつもりだったが、ここにきて別プロジェクトが火を吹き始め、その原因が何を隠そうこの本人であった。
今日のところはとりあえずは任せたが、明日からは本格的に立て直しにかからなければいけないだろう。それ自体はいいのだが…。
うーむ。
明日からはちょうど来る台風並みに荒れることにならなければいいのだが。いや、荒れさせてはいけない。
のだが。。。。
うーむ。
Eric Sink著。青木 靖訳の「革新的ソフトウェア企業の作り方」を読んだ。内容は、Eric Sinkという人がMSDNのコラムにしるしたものを集めたのだと思う。
本書はソフトウェア開発者に向けられて作られた本であるけど、実際の内容は完全なビジネス書だと思う。著者はもっと多くのソフトウェア企業が世の中にはあるべきだと考え、マイクロISVという形態を提唱している。
本書で言うところの「マイクロISV」というのは、個人がISV（Independent Software Vendor:独立系ソフトウェア会社）を立ち上げる事になる。ただ、本書で薦められているものは脱サラ起業ではなく、いわゆる”週末起業”的な話。技術者であるソフトウェア開発者がそれを行おうとした場合に何に留意するべきか。どういう方向性で考えて行くべきかが本書では指南されている。
先般、ソフトウェア開発未来会議においてクラウド・コンピューティングが話題になった。ここで個人からみた視点として、iPhoneで言うところのAppStoreを例に挙げ、個人が作成したソフトウェアを世界に向けて配信する方向性の話が聞けた。オフライン会議に参加して、ここに強く共感を覚えたのはおそらく本書を読んでいる最中だったからだろう。
かなり刺激的な内容で、私自身も小さいながらISVに努めている事から色々と学ぶ事が多い一冊だった。また、昨今のクラウドに対する考え方やMarketPlaceがこの時期に出てきたのはもはや自分のためにあるのではないかと甚だ恥ずかしい勘違いをしたくなった。
また、ソフトウェア開発者であるならばぜひ読んでいただきたい私にとってお勧めの本となった。
どんなアプリケーションを作るのか。技術者の多くにとって不足しがちな商品開発におけるマーケティングの重要性があげられている。私もどちらかというとそうなのだが、”この技術を何かに使えないか？”という出発点ではなく、”この内容を実現するのにはどの技術が使えるのだろうか？”という、本来当たり前の出発点が必要になる。
「重要なのはユーザーにとってどうかということ」というのを覚えておこう。ユーザーが普通の人たちなら、彼らが.NET CLRをダウンロードしインストールする準備ができているだろうか注意して考える必要がある。普通の人々はすべてが「当たり前のように動く」ことを期待している（P.174）
そう、結局のところ技術は技術者にとっては主役なんだけどユーザにとってはどうでもいいことなんだ。Silverlightがどんなに操作性が良くても.Netの生産性が高くて製品の値段が抑えられても、インストールの手間がかかっていたのでは障壁になってしまう。これは意外と馬鹿に出来ないコストだ。言ってしまうと、我々開発者はその技術が一般化するまでは待たなければいけないことになる。ユーザーがアプリケーションを仕事として使っているのでない限り。
また、製品のマーケットの中での位置づけはどうするのか。
最近よく読む”週末起業”だとかの中では主に”その分野の先がけ・パイオニアになれ”という事がしきりに言われている。本書でのアプローチはこうだ
競合を避けることの大きな問題は、それが顧客をも避けることになるという事だ。競合の存在はお金を払っている顧客の存在を意味する。あなたのアイディアで商売をしている人が誰もいなかったとしたら、それが本当にお金になる事なのか怪しいと思うべきだ
（中略）
彼は、一番良いアプローチは「大きくて無能な」競合を見つけることだと言っている。（P.144-145）
完全に新しいマーケット。ブルーオーシャンは認知されるまでに大変大きい労力を要する。個人が週末レベルでそれを広めているのでは何年先になるのかがわからない。また、それがマーケットとして成り立つのかが不明だ。
マーケットの中で出来るだけ無能な競合を選び、そことの差別化を図る。製品の値段を決定する場合にも競合製品と見比べ、さらに価値を高めて値段を上につけて売り出す。もちろん、差別化した内容が、その価格差に適合しているのかは見極めないといけない。
だが、これらを考える基準を作る事が出来るのも競合がいて、そこのビジネスが成り立っているからであろう。やみくもにブルーオーシャンを探してニーズを無理に自分で想像していないか、確認する必要がある。
もちろん、そこにマーケットを見つけ出せるのであればブルーオーシャンを否定するものではない
この本で面白いのは、この主題を書きあげるためにEricが自らソフトを作って試してみたということだ。彼が作った”必ず勝つ方法があるソリティア”。その名も「Winnable Solitaire」だ。だが、彼の試みた今回の挑戦は結果として失敗した。
2004年9月29日の時点で、Winnable Solitaireは6本売れ、あんまりすごくない合計42ドルの収入を上げた。
支出が0だったなら、新たに得られたこの富で豪勢に買い物をするところだが、開発の際、アートワークのために379ドル使った。また、リリースして以来271ドルを広告で使っている。<中略>結論として、私の損益計算書には現在純損失626ドルと記されている。（P.50）
この失敗に対してEricは10の考えを記事にしている。「勝てる」というのは差別化要因としては弱かったのか？別な種類の製品であったなら？等々
これはよく言われる話ではあるけど、成功するためには多くの失敗をし、その多くの失敗から学ぶ必要があるという事だ。今回もEricは「これは素晴らしい失敗の仕方だと思う」、「小さな失敗で私が傷つくことは全くないと思う」等々の記事を記している。
結局のところ、多くの失敗をして学んだとしても次につなげることができなければ最終的な成功を収めることはできない。そのために致命的な失敗をしないための保険なりをかけておくべきなのだろう。
作ったばかりで売れてもいないソフトウェアに一人で惚れこんで、勢いあまって会社を辞めてしまうようなことはするべきじゃない。そこまでしなくてもマイクロISVという形態であれば十分可能性を試すことができるんだよってことだろう。
実際のところこのマイクロISVという事を実践するための環境は着実に整ってきているのではないだろうか。
クラウドコンピューティングは多くの開発者にサービスを提供する場を与え、AppStoreやWindowsMarketPlaceはモバイル端末に対してアプリケーションを配布する一つの入り口としての機能を持っている。
これらの場を生かして、早く、小さくともアウトプットを出していくことが大切なのだろう。エピローグに載せられた言葉をもって今日のエントリーを締めくくりたい
（君の考えは）クールなアイディアに聞こえる。実装はそう難しくないだろう。君にはそれをやる時間がある。基本的に心配すべきリスクはあまりない。このアイディアが良いものか見極めようと多くの時間を使ったところで。結局確かなことはわからないだろう。そうする代わりに、同じ時間をこのアイディアの実装に使う事も出来る。そうすればこのアイディアが良いものかどうかが本当にわかるだろう。
今日、ちょっと縁があって某大手データベース会社の研修プログラムを営業している人と話をした。ありていに言うと営業を受けたわけだが。
現状で、組織でまとまった研修プログラムを受ける予定は無いということを前提に、そもそもどうやって”勉強することが大事であるか”や、”技術力を高めよう”という方向に社員を向かわせることが出来るだろうか？ということを切り出してみた。
技術者というものはどちらかというと、専門分野に関して突き詰めて調べたり、あれこれと興味を持って動く人物であることが多いと思っていた。
ただ、最近入社してくる人を見ると必ずしもそうではないことが分かる。語弊はあるかもしれないが、数ある職業の中からたまたま選んできたのだ。
会社として、業務命令として勉強させたり資格に向かわせたりすることはできなくはないけど、それはそれでさみしいことである。出来れば、本人の興味を向かわせたほうが結果としては全体のプラスになるのではないかと思う。
さて、あれこれと話したのだが最終的にはやっぱり”ストーリー”を提示することだろうということになった。
会社の今後のストーリー。製品のこの先。それらのストーリーを実行するためには今何が足りないのか。それらを共有したうえでそのストーリーを実現するためのキャストとして登場してもらう。
言うのは簡単だけど、すっげー受け入れられるか、すっげー白い目で見られるかのどっちかだなぁ。
ふむぅ
仕事にストーリーはあるか？ 物語のチカラ
手でつかめない「商品」を売った人の気づきは参考になる
ストーリーの重要性には納得 ビジネスを、そして人生のすべてをエンターテインメントに
ふと思うところがあって手に取ってみた
WEBアプリケーションそのものの開発には関わっているものの、自分自身がそのすべてを作っているわけでもないし、そもそも対象としているシステムが「基本的に社内で運用」という前提が付いているので、少し弱い分野。
これまでもセキュリティ系の書籍は読んだことはあって、脆弱性のいくつかは確かに知っている。
ただ、項目を知っているのとそれの対応が正しく取れる。また、”ぜい弱性を指摘できる”と言うのはイコールにならない。
たぶん、どれだけ経験したのか？と言うことが、やはり一番なのではないか。
単純に目次だけを見るのであれば、先日第5版が発表されたIPAの「安全なWEBサイトの作り方」で十分に範囲を抑えていると言える
安全なWEBサイトの作り方 （IPA）
http://www.ipa.go.jp/security/vuln/documents/website_security.pdf安全なSQLの呼び出し方 （IPA）
http://www.ipa.go.jp/security/vuln/documents/website_security_sql.pdf
・・・・
なんか、目次にてるな・・・。
と言うか、よくよく見てみるとSQLインジェクションの例題なんて全く同じだし
って、こっちの作成にも徳丸さん絡んでるじゃん(笑)
そりゃ似たようになるよね。
当初、本書を手に取ったのは純粋に”セキュリティ対策”的な意図だった。
そういう意味で、本書ではVM環境を用意して実際にぜい弱性を体験できると言う素晴らしい教材だと思う。
ただ、一通り読んでみて思ったのは、タイトル通り「WEBアプリケーションの作り方」何だな、ってこと。
純粋なコーディングに限らずWEBアプリケーションに関わる周辺技術を含んで説明されている。
もちろん、これを読んだからと言ってWEBアプリケーションが作れるか？と言うとまず作ることはできない。
ただ、網羅的に周辺技術に対して”セキュリティを意識して”学ぶことができると言うのはいいなと思った。
先に書いたとおりぜい弱性との戦いは経験もある程度あると思う。
今ある技術の裏をどうすればつくことができるのか？と言うのは繰り返し行われてきたことだし、昨今の新技術目白押しの状況下においてはそれぞれの対策が必要になるだろう。
どこまで柔軟に考えることができ、幾重にも予防線を張っておくことができるか。
セキュリティを意識するうえで、まず最初に読む本としてちょうどよさそうだ。
ZDNetに日本でSaaSが普及しない理由として、各企業内での独自システムに関して記事が載っていた
日本でSaaSが普及しない理由
http://japan.zdnet.com/sp/feature/enterprise-trend/story/0,3800089971,20389127,00.htm?ref=rss
記事を読んでいると、SaaSが普及しない理由というよりは基幹システムをパッケージソフトウェアに一新する事の難しさに対する理由が書かれているように感じた。
記事にもあるとおり、日本の企業。特に中小～中企業では自社システムを手組で作っている場合が多い。
欧米で主流となるトップダウンな効率化と違って、日本では効率化の手段を現場主導で行う場合が多い。そうなると、どうしてもこの記事の中にあるとおり”その企業内での最適化”という形になってしまう。ましてや終身雇用が約束された時代に作られたシステム。業界内のシステムがどうであれ、あまり関係のない話だ。そして現場手動で作り上げた”その企業にとってかゆい所に手が届く”システムだけに現場が現行システムに対して思い入れを持っている場合も少なくない。
パッケージソフトウェアのビジネスは、基本的には業界で一般的であろうモデルで作られたパッケージソフトに対し、社内の業務を改革して適応させていく形が望ましいと私は考えている。パッケージに含まれる機能が不十分であるのであれば別ではあるが。
ただ、実際の導入事例を見ているとそのほとんどがアドオン等のカスタマイズ開発を要している。企業独自の付加価値を見出すような機能を追加しているのも多いが、そもそもパッケージの原形をとどめていないくらいのカスタマイズが入る案件も中にはある。この場合、パッケージ費用よりもカスタマイズ費用のほうが多くなり、なぜこのパッケージを選定したのか疑問が出てくるくらいだ。
この一つの要因が、現行システムの存在だ。カスタマイズを、”現行システムでこう動いているから”という理由だけで行っている場合もあれば、現行システムの全容を把握していないがために、あとから追加の機能に気付き、追加カスタマイズを要する場合もある。なかなか難しいものだ。なにせ導入企業自身が、自分の欲しい機能（現行システムが保持している機能）を知らないのだから。
決して個別企業における最適化が間違いだとは思わない。事実、それによって力をつけてきた企業は日本には多いと思う。経営のスタイルとして現場手動での最適化を目指すのであれば、結局のところ現状のようにカスタマイズ前提の基幹システムは続くのだろう。逆にトップダウンで動くのが主流になるのであればパッケージに適応させるような現場の改革が行われることになる。
それ抜きにSaaSへの移行は難しいのではないだろうか
仮にパッケージを受け入れたとしてもSaaSに踏み切りづらい理由の一つに、システムを外部に置くことに対しての危機感があると思う。企業にとっての生命線ともなるべき財務や顧客の情報を社外に持つことそのものに対する恐怖感があるのだろう。
ただでさえ個人情報保護法等が施行されたり情報流出、内部統制だの言われている中でこの問題にどう対応をするのか。そういう懸念を抱く層が多いのだと思う。たぶん、手元に持っておきたいのだろう。気持ちはわかる。
これに対してはSaaSプロバイダー側がある程度の保障や、障害児の対策を明確に提示する必要があるだろう。セキュリティ等は確かに懸念される点ではあるかもしれないが、普通に考えると自社に持つよりも”場所”としてのセキュリティはしっかりしている可能性が高いのではないだろうか。また、自社でデータセンター並みのセキュリティを整備しようとすると初期コストだけでなく維持にもかなりのコストがかかるはずだ。
以前、企業内におけるITに対するコストのそのほとんどが、現状システムの保守に対して割り当てられているという調査結果を見たことがある（確かMicrosoftのカンファレンスか何かだったと思うがうろ覚え）。自社で運用するという事はそれ相応の保守のためのコストもかかる事を忘れてはいけない。コストのほとんどが現状維持のために使われている状態は決していい状態とは思えない。
経営資源の有効活用という意味でも一考の価値があると思われる
全ての企業において基幹システムがSaaS形態になるかというとそんなことはないと思う。
現在、日本で出始めているのはCRMや営業支援関連のパッケージがSaaS形態で提供されているように見える。これから少しずつ他のシステムにも波及していくのだろう。アプリケーションを提供しているベンダーもSaaS対応を考慮しているが、オンプレミス環境でのシステム提供がなくなるわけではない。そうなると、比較的乗り換えが容易なSaaS形態で複数のシステムを試し、決定した段階で自社保有するような形をとる場合なども出てくるのかもしれない。
いずれにしても各パッケージベンダーがどういう対応を取ってくるのか。今後が楽しみではある
JINS PCを利用し始めてから2ヶ月が経ちました。
JINS PCを試してみています
http://d.hatena.ne.jp/krote/20120305/1330896902
だいぶ慣れては来ましたが、まだ気にならないという訳ではない状態です。
ちょっと疲れが溜まってくると、メガネをかけている事が疲れを倍増させているような感じがして
メガネをかけるのをやめてしまったりもします。
元々、ドライアイ等に悩んでいた訳ではない私。
つけないならつけないで問題は無いのでそのまま過ごしてしまったりもします。
いいのか悪いのか。
どうも、これが目にいいという事を実感出来ないのはメガネをかけるモチベーション（？）に欠けます。
本来は疲れている時にこそ目をいたわる意味でかけるべきなのでは？とも思うんですけどね。
何とも、何とも。
なぜいつもこうデスマーチへと向かうのだろうかと小一時間問い詰めた今日。
もう少ししっかりとプロジェクトマネジメントに関しての知識を体系だてて学ぶ必要があるな。
ふぅぅぅ
今日はおしまい
いつも拝見させていただいているオルタナティブブログで坂本さんが、あるプロジェクトでの逸話を紹介していた
トラブルが発生するときというのは、なぜだか同一の会社に重なります（坂本史郎の【朝メール】より）
http://blogs.itmedia.co.jp/shiro/2011/04/post-5da5.html?ref=rssall
お客様の要望は結構果てしなく、それでいて「本当のところどうしたいのか」がはっきりしていなかったがゆえに、当初想定していた以上の工数がかかってしまうことは結構ある。
マネジメントがうまくできていないだけということも言えなくはない。
実際問題、最初の納入以上にその後の改修のほうが大きくなってしまうなんて言う話もある。
結構大変
ここで紹介しているエピソードは、最終的に乗り越えるわけですが、企業としては心中するわけにはいかないので難しい判断を迫られることも多いと思う。
ただ、その中でお客様の話として出ている
お客様からの要望は全て入れる必要はないです。
ただ、入れたものに関しては充分にテストしてほしいです。異常形テストケースの割合は、テストケース全体の半分くらいが適当ではないか。
そういう考え方を徹底してほしい。
今は受け入れ側の素人テストで問題をあぶりだしているが、これはプロである
メーカーとして実施してほしいです。
と言う言葉にはちょっとハッとさせられた。
もちろん、それだけのテストを行う必要があると言う認識のもとでのプロジェクトを組まないといけないのはあるけど、そもそも”実装する”と決めたのであれば、その出所がなんであれお金をもらっているプロとしてのスタンスで臨まなければいけない。
まだまだ、自分自身でちゃんと出来ているところまで行っていない。
積み重ね、積み重ねて出来るところまで持っていかないといけないと、改めて思った。
今月の日経SYSTEMSに富士フィルムで行われた基幹システムの仮想化に対する取り組みが紹介されていた。
仮想化そのものは大変有用で、私も検証環境や社内での客先環境を模すのに良く使用している。実機を使用しなくてよいというこの利点にはかなり恩恵を受けている。なかったらと思うとちょっと怖いくらいだ。
ただ、富士フィルムの例でみられるように実際の基幹システムに仮想化を取り入れるには実のところ、未だに多くの問題を抱えている。
私が感じる一番の問題は、アプリケーションのサポートだと考えている。これは私自身がアプリケーションを作成するベンダーの立場であり利用する立場でもあるからだとは思う。
私が仕事で主に使用しているデータベースはOracleなのだが、Oracleは仮想化上での動作をOracleVM以外ではサポートしていない。実際のところ、VMWareやVirtualPC。Hyper-Vでも動いてはいるのだけど、障害時を考えると少し怖いものだ。Oracleも決してバグの少ない製品とはいえない事はこれまでも身をもって知っているし。
いくつかのアプリケーションベンダーの仮想化に対する対応はマチマチ。いくつか細かい違いはあるようだけど
という2種類が多いように思える。字面の問題のように見えるが、前者はユーザー側で確認をするのに対して後者はベンダー側で確認をするというスタイルだ。
比較的容易にインストールさせる事が可能なソフトウェアであれば前者で問題ないだろうが、大規模なシステムであった場合にはそもそもインストールが困難なので後者が選ばれると思う。ただ、ここで問題になるのがベンダー側の対応。サポートの仕方はベンダーで異なるだろうが、おおむね
のような流れになると思う。ここで問題になるのが、ベンダー側の環境で再現しなかった場合にそれが”本当に仮想化が原因”かどうかの判断をどうつけるのかではないだろうか。実際のところ、物理環境であっても現象によっては必ず再現するとは限らなく、いくつか複数の要因が重なって初めて発現する問題もある。また、仮想化が原因であるというのであれば、ベンダー側で仮想化環境を構築して検証を行う必要が出てくる。
となると、ベンダー側はユーザー側が使用している仮想化ソフトに対しての知識や、環境を用意しておく必要が出てくる事になってしまう。サポート部隊の涙目が見えてきそうな話だ。おそらく、そもそもの仮想化ソフトを限定しているのかもしれないが…。実際のところ、どうなのだろうか。気になるところだ。
ちなみにWindowsは以下の仮想化環境でサポートをしているようだ
http://www.windowsservercatalog.com/svvp.aspx?svvppage=svvpsupport.htm
上記一覧にOracleVMがまだ入ってない事を考えるとWindows+Oracleの環境で公式のサポートを得る事は難しいという事か。いずれにしても、綱渡りである事に変わりはない。
＜2009.03．07追記＞
コメントに情報をいただいていますが、OracleはWindows,Linux以外の環境ではサポートを表明しているようです。
http://www.oracle.com/technology/products/database/clustering/certify/db_virtualization_support.pdf
HP-UXやAIXは正直私は触ったことがないです。Solarisくらいかな・・・。Oracleの利用目的から考えるとこれらを選択肢に入れるのはいいかもしれませんね。私はその前にこれらOSの知識を手に入れないと不安でしょうがないですが…。
でも、たとえばHPのnParそのものはWindowsやLinuxもサポートしているのになぜHP-UXのみに限定しているのか。そしてOracleVMではそのWindowsやLinuxをサポートしているのか。
このあたりは企業戦略が見え隠れしているような気がしなくもないですねぇ。純粋に信用していないだけなのかもしれませんが。
さて、困った。どうしたものか。
仮想化環境を提供しているベンダー。VMWareやMicrosoft。Oracleもまたそうなのだが、これらの中でどこかが明確な方針を出してくれれば少しは動きやすいとは思うのだけれど、現在のところ主だった動きはないように思う。サポートの手厚さでは24時間サポートを打ち出しているOracleVMが手厚そうと言えば手厚そうだ。
シェアで言うと先行していたVMWareが大きいのではないかと思う。
いずれにしてもベンダーがいくつかのアプリケーションベンダーを巻き込んでサポート体制の新しい枠組みを作っていかなければいけないのではないかと考えている。望むならば申し出のあったアプリケーションベンダーに対して仮想化環境を提供。検証するための枠組みを作っていって欲しいと考えている。
もちろん、星の数ほどあるアプリケーションベンダーそれぞれに対してそのような事が可能かどうかというと、無理があるのかもしれない。かといって仮想化に対するユーザーのニーズというものはこれからも増え続けて行くわけで何かしらの対応をとっていかなければいけないだろう。
ウジトモコさん著、視覚マーケティングのススメを読んだ
「デザイン」というものを考える上で、ただ単にデザイナーに”いいものお願い”って頼むのではなく、マーケティングをすることで、効果的なデザインが出来上がる。マーケティングをせずに作ったデザインはマーケット上での効果は期待できないという考え方だ。
言ってしまうと、当たり前の話なんだけど、その当たり前のことを細部にまでできているかというとなかなか難しいことだ。一般に、製品を企画する段階では間違いなくターゲットとなるユーザーを設定するだろう。そのターゲットは年代に寄るものかもしれないし業界・業態によるものなのかもしれない。必然的に製品のパッケージや広告・キャッチコピーに関してもそれを意識したものが考えられる。
また、企業のロゴになると自分たちが顧客・ユーザーに”どう思われたいか”を意識して考えられるだろう。
ただ、それが本当にできているのだろうか？製品やサービスの細部。個々のパーツにまで落とし込めているだろうか？
おそらく、パッケージや広告が表に出てきやすいもの。お菓子や化粧品に代表されるようなものに関してはこのいわゆる”視覚マーケティング”はできているのだろう。化粧品みたいなものは明らかに年代を意識して製品を作っている部分もあるので特に意識されているのではないかと思う。
ただ、ソフトウェアの分野はどうだろう。もちろん意識しているソフトウェアもあるだろうけど、明らかに”機能重視”でデザインに関してはおざなりに済ましてしまっている部分はある。特に基幹系のシステムに関してはその色は強いのではないだろうか。
もちろん、これらのソフトウェアに関しては機能は第1に重要視されるものだと思う。ただ、複数ある基幹システムの候補からどれが選ばれるか。ユーザーの立場で”どれを使いたいか”を考えてみるとその要素の一つにデザインがあってもおかしくないと思う。また、そういう意味で”ファン”を作った製品はエンドユーザーからは根強く支持されたりもする。つまり、デザインによるブランディングができているのだろう。
また、個人のブランド。パーソナルブランディングに関しても意識の差は大きいように感じられる。本書でもその具体例として名刺が取り上げられているところからもそれは感じられる。
最近、セミナーや勉強会に顔を出すようになって様々な方と名刺を交換する機会をいただいている。私は個人名刺を所有していないので会社のを使っているのだが、多くの人は個人名刺を持参している。自分自身をどう見られたいか。どういう人間だと印象付けたいのか。この名刺の目的は何か。考えられた名刺もあるしまずは作ってみたというものもある。私自身、個人名刺に関してはほしいと思っているので、どう思われたいのか？どう表現するのかは大きな課題の一つだ。まずはそこを見つけ出さないことにはデザインも始まらない。
私はソフト屋なのでどうしてもソフトウェアにあてはめて考えてしまうのだが…
ソフトウェアの分野。先にあげた基幹系システムに関して言うと確かにデザインはいい加減なものが多い気がする。いや、実は結構頑張っていたりもするソフトもあるのだろうけど、VBフォームの延長線をいまだにたどっているソフトも割りと残っていたりする。
シンプルな作りなのがいいという業界もあるだろうし、スタイリッシュな物が好まれる業界もあるだろう。ただ、私自身が最近必要と思っているのは、要するに”スタイル”的なデザインではなく”ナビゲーション”を意識したデザインというものだ。これのいい方法が思いつかない。そういう事が得意なデザイナーもいるんだろうけど…、業界やユーザー層に踏み込んでまで考えられる人は少ないように思う。あ、それは発注側の担当ですか。
以前ペルソナを用いる手法に関する本を読んだ
まだペルソナに関しては試行錯誤段階で効果は不明だけど、実際に作ってみたペルソナが本当にあっているのかというのはわからない話。結局ウジさんの本にあるようにユーザーへの聞き取りのようなことをしなければいけないのだろう。
試行錯誤。試行錯誤の日々は続く