読者です 読者をやめる 読者になる 読者になる

情報アーキテクチャってなんだ?

今日は書店で情報アーキテクチャについて書かれた本を見つけ、なんだろう?と興味を持ちましたので、その概念について調べてみる。

 

まずはwikipediaから転載

情報アーキテクチャInformation Architecture)は、いわゆるWeb屋用語としては、知識やデータの組織化を意味し、「情報をわかりやすく伝え」「受け手が情報を探しやすくする」ための表現技術といった意味である。ウェブデザインの発展に伴い、従来のグラフィックデザイン(平面デザイン)に加え、編集・ビジュアルコミュニケーション・テクノロジーを融合したデザインが要求されるようになった。情報アーキテクチャはこれらの要素技術を組み合わせた、わかりやすさのためのデザインである。ウェブ技術の発達に伴いその重要性が認識されているが、情報アーキテクチャの考え方自体は、紙面デザインの頃から変わらない。

なるほど!ほとんどこれでわかりました。

わかりやすさを考慮した情報の伝え方と、とらえるとグラフィカルなものだけでなく話し方など情報を伝えるということ全般に応用が利きそうですね。

しかし視覚的な情報って処理が複雑な気がするのでこういう概念がでてきたんでしょうね。

いずれは実際のプラクティスについて調べてみようと思います。

英語勉強まとめ(編集中)

VOA ゆっくり短いニュース動画あり

VOA - Voice of America English News

使用した感想:ゆっくりなので聞き取りやすい。続けると効果あり?

 

英語と日本語訳が載っている。短いニュースあり。音声もある。

英語のニュース | The Japan Times ST オンライン

使用した感想:日本語訳載っているのがうれしい。

 

アプリ編

 

管理とはなんなのか?

怒りと反省と今日おもったことを書きます。

 

怒り

 管理って何なの?

 というか、管理職って何のためにいるの?

私がおもうのは、部下が自分の能力を発揮して仕事させる環境を整えるのが管理です。

 

自分(管理職の人、もしくはもっと上層部が)思い通りに進めるために監視する

という意味合いで管理といっている人がいて、残念な気分になる。

 

そういう意味での管理をしろってことなら、無理だな・・・

 

 

反省

 自分はそういう被害妄想が強すぎるのかな。と。

 ちょっとでも監視するようなことを言われたらナーバスに考えてしまう。

 

結局、信頼関係が大事だなと。

それには、ゴールを統一することが一番かなと、私はおもいます。

監視して、それを守らせる。やらせる。

そこに同意できることがある。もしくは議論した結果そうしたならいいと思います。

しかし、理由も根拠も告げず、指示だけして命令する。

そんなんでやらされるのは、自分が一番やりたくない。

だからそんなことはしたくない。

 

 

 

 

言い訳が多い人、いうとおりにするだけの人

って、誠意を感じない。

 

何か指摘をうけたときの、説明や、自分が報告するときに

How的なことをいうことが多い。

時系列的にやったことをならべるのが報告だとおもっているのだろうか?

 

「だから何?」

といわれておしまいという。

 

「自分はこう考えたから、こう行動しました!

その点で指摘を受けた部分について、自分はこう考えます。

何かアドバイスはありますか?」

 

みたいなね。

 

指摘されたことを

「ハイッ!その通りです!

やり直します!ハイッ!」

っていう通りにする人も

 

「あれ、こことここも直さないといけないな。自分で見直しした?」

と、なりがち。

 

そこも、指摘に関して

指摘された趣旨を説明できるくらいまで理解し、納得した上であれば

そういうミスは少なくなると思う。

 

PDCAのサイクルとWFとかTDDとかコミニュケーションとか

今頃?だが、よくPDCAという言葉が使われる。身近で。

PDCAってサイクル短いほうがフィードバック早くてよいはず。

でもWFとはそうならない。

だって、基本設計ビシッ!と固めて、変更あるならお金くださいってんだから。

1タスクでみたら、予定工数のなかでPDCA的なことは行われるだろう。

ただし、それはフェーズが変わると、サイクルのスピードがストップするに等しい。

 

タスクをこなすスピードとしても、PDCAのサイクルが早いほうが正解にたどりつくのが早いという実体験としての例がある。

 

FizzBuzzをTDDでやった。

テストケースがざっくりとしていて、ケースを洗い出すことに時間を掛け、それを完全に満たす実装を行った人と(完璧な設計で、動くものに時間がかかる)

テストケースを細かくし、設計はそこそこに動かしながら、バグをつぶしていく人(きたなくても動くものを作っていく)の場合では

後者が圧倒的に早く実装が完了した。

(前者が30分掛けても実装・テストが終わらなかったところ、後者は10分ほどで実装・テストが完了した。)

 

つまり、フィードバックがないなか、頭の中で検討するより、

実際に動かした結果から改善するほうが早い場合もあるということ。

 

正解はその中間なんだろうけども。

で、こういうのは、個人差があるけども、経験で埋められる。

で、経験が無いから無駄に悩むってこともある。

経験が無くても、ゴールさえわかっていれば、そこに突き進むこともできる。

 

ただし、ゴールがわかってないと、どこに進んでるかわからん。

早くできても正解じゃないかもしれないしね。