Fictions
著
知ったきっかけは、ひろみつさんの書いたポエムに呼応するポエム、またはわたしのFictions - hiromitsuuuuu.log();なんですけど、編集を担当された泉水さんと先日、第34回 W3C CSS Module 仕様書もくもく会@東京でお会いしたのを機に、『Fictions』のKindle版を買って読みました。500円=ワンコインで買って読むにはちょうど良い分量で、共感できる内容も多く、楽しませていただきました。自分もこんなポエムで本を書けたらいいな、とも思ってしまいました。
スペシャリストを目指していたらその周辺スキルも身についてジェネラリストに、ジェネラリストを目指していたら領域をまたぐことで発見された新たなスペシャリストになることもある。
上記は「スペシャリストとジェネラリスト」からの引用なんですけど、この辺の予測し難さって面白いですよね。対象とする分野に何をどこまで含めるか次第でいくらでも立ち位置が変わり得ることもあって、自分がスペシャリストとジェネラリストのどちらに類別されるかは、正直よくわからないのですけど。
ユーザーの視点で考えてみると、少しイメージが湧いてきた。何かのサービスを使っていて、一度も「リニューアルして欲しい」と思ったことはないのだ。
上記は「分割統治リニューアル」からの引用。継続的な利用に対するモチベーションを妨げない程度には使いやすい、という前提があってのことかと思いますけど、その前提では新たな学習コストを好んで払おうなんて思わないのが人の常、でしょうからね。誰の・何のためのリニューアルかというのは、どんな案件なりプロジェクトであっても意識し続けたいポイントだと思いました。
開発中、デザインカンプを見ているときに「なぜこのデザインなのだろう」とよく考える。エンジニアはあまりそう考えずに、「デザインカンプ通りに実装する」ことこそが大切だと考える人が多いと思う。
これは確かになぁ、と思ったところ。デザインカンプの再現性が評価の基準になってしまいがちではあるけど、そこを突き詰めればいわゆる「ピクセルパーフェクト」の再来にもなりかねないわけで......むしろデザインカンプという形態において表現されていない部分にこそWebらしさは存在し、それを具現化するのがエンジニアの役割みたいな風に自分は捉えているから、「なぜ」を問うのはごく自然なことと自分には感じられます。また、実に達観されているなぁ、看破されてるなと感じ入ったフレーズベスト4:
人は情緒的な生き物なので、常に合理的ではいられない。
デザインの変更のし易さは、高度なシステム化によって生み出されるものなので、一概に簡単とは言えない。
チーム開発において、行き過ぎた部分最適化や不要な全体最適化は良くないことが多い。
GUIデザインというのは、システムの複雑さと美的因子をコントロールすることだと思う。
それと一箇所だけ、誤字っぽいところが「分割統治リニューアル」にありました(そのいった
ではなく「そういった」?)。