開発における "あと一歩" の追求

例えば、UIの配置やプログラミングのパターンを、あと１つだけ多く試してみるとか。手間としては、それほど多くなるわけではないでしょうが、これをやるかやらないかの違いは大きいと思います。

時間との兼ね合いもありますけれども、特にソフトウェアにおいてはちょっとした違いが積み重って全体の印象を決めています。むしろ地味な違いほど効たりします。

だから、ソフトウェア開発において、"あと一歩" の追求は時間に切羽詰まっていない限りは重視したいと思うのです。

※この記事について指摘・意見・提案・感想などありましたら下のコメント欄にどうぞ。

UI設計では素朴な感覚を大切にする

ソフトウェア開発におけるUI設計は、経験や理論も影響してくるものではありますが、それより大切だと思っていることは「素朴な感覚」です。

まっさらな気持ちで、初めてそのソフトウェアを触った人のような気持ちになって操作し、何を感じるか。そこで「使いやすい」と感じられるか。何か足りないと思うことはあるか。多すぎると思うことはあるか。変えたほうが良いと思うことがあるか。などなど・・・。そこでかすかに感じるわずかな違和感に気づくことが何よりも重要です。

確かにプログラミングには経験や理論もファクターとして大いに絡んできます。しかし、そのプログラミングを通して作り上げ、最終的にユーザとの接点になるUIにおいては、何も知らない人間の感覚になる必要があります。

こういった感覚の切り替えもソフトウェア開発の面白いところですね。

※この記事について指摘・意見・提案・感想などありましたら下のコメント欄にどうぞ。

UI設計とは想像力である

良いUIを設計するのには何が必要なのか、と問われたら、僕は「想像力」と答えます。実際にそのシステムを利用するユーザは誰で、どんな目的で、いつ、どういうタイミングで使うのか。場合によってはそのユーザの置かれている立場や、年齢、性別、性格、あるいはその時の気分まで想定することによって、いかにリアルに使っている時の状況を思いうがべることができるか。そこの勝負だと思うんですよね。

さらに、ボタンや入力欄などの要素はどう配置たら使いやすいのか、実際に自分がそのシステム使っていると想像する時のリアルさが研ぎ澄まされているほど、使いやすさに考慮したデザインが出来るでしょう。

確かに経験があれば、ある程度かこに制作したUIとの類似点から、とりあえず失敗しない程度のUIを作ることは出来るかもしれません。しかし、あらゆるプロジェクトは同じように思えても1つ1つ違うものです。そして、そのUIに触れるユーザもまた、その類のシステムに触れるのは初めてかもしれないのです。であれば、例えば自分が初めてそのUIを触れているようなつもりになって、まっさらな気持ちで見なおしてみることで、どうすればもっと改善できるかが見えてくるじゃないか、と思っています。だからこそ想像力が必要だと思うんですよ。

※この記事について指摘・意見・提案・感想などありましたら下のコメント欄にどうぞ。

SCSSが便利すぎる

WebアプリのUIを組んでいて、今回初めてSCSSを使ってみているわけですが、便利さにびっくりしてます。以前からその便利さはネット上で色々語られているので知識としては知っていましたが、やっぱり自分で実際に使うと実感できますね。

今回SCSSを書くこと自体初めてでしたが、ものの30分くらいで全く問題なく作業を進められるようになりました。記法としてはSASS記法ではなくSCSS記法です。ネットを見ているとHAMLを採用したSASS記法の方が記述量が少なくすっきりしていて、そちらが好みの人もいるらしいですが、僕はCSSの書き方が流用できるSCSS記法を支持します。

なお、LESSという選択肢もありますが、Rubyを採用したプロジェクトなのでSCSSと相性が良さそうという理由でSCSSを選択しました。Padrinoフレームワークは、.scssファイルを自動的に.cssファイルに変換してくれます。

うーん、一度実際に体験してしまうと、もはや生のCSSなんて書きたくない（笑）

ちなみにSCSSの書き方詳細についてはネット上に良質な解説サイトが沢山あるのでそちらをご参照ください。

※この記事について指摘・意見・提案・感想などありましたら下のコメント欄にどうぞ。

エンジニアの差は「最後のツメ」に出る

設計書とかプログラミングとか、エンジニアの成果物にはクオリティが求められますけれども、結局のところどこに差が出てくるかというと、いわゆる「最後のツメ」ってやつですよね。

頻度は少ないものの重要なユーザの操作に対するちょっとした仕様の工夫だったり、万が一のための例外処理で最悪の事態を避けるものだったり、ハッキリ目に見えて分かりやすいものでは無いかもしれないですけれど、「何かあった時に違いが分かる」ってやつです。

しかしまあ、そういう「最後のツメ」のクオリティを上げるっていうのは、義務感とかじゃ無理だと思うんですよね。僕は、「こだわり」だと思うんですよ。気になって仕方ないっていう感覚のほうが、正しいと思うんです。

ちなみに、この最後のツメをしつこく追い求めていると、結局１時間で終わるはずだった作業が２時間もかかってしまったりします。しかし、最後のツメを甘いままに作業を終わりにしてしまったら、例えば後になってミスが発覚し、しかもその前提で進めてしまった別の作業の部分も併せて修正を入れるはめになり、結局トータルで４時間かかったりするのですよ。

決して分かり易くないけれど、やっぱりそういう差ってあると思うんですよ。

※この記事について指摘・意見・提案・感想などありましたら下のコメント欄にどうぞ。

画面仕様書にはどこまで詳細を書くか

仕事でソフトウェア開発をしていて仕様書を書いてますけれども、今週から画面設計の部分にとりかかりました。そこで考えるのは、仕様書に画面設計の詳細をどこまで書くか、ということです。

以前仕事をしたある職場では、画面仕様書に関係する関数名や変数名の一覧まで書いてありましたけれども、ちょっとそこまでやるのはやり過ぎだと思います。実際コードを書く際にいくらでも変更される部分ですし、いちいちドキュメントを修正していたら手間がかかりすぎてそのうち仕様書を見向きもしなくなるでしょう。

逆に、以前アジャイル開発をした時は画面設計というはむしろ仕様書自体、開発中は全く手を付けていなかった状態でした。それはそれで最後に時間がなくなり、結局まともな仕様書を残すことはできませんでした。まあ、それは仕様書を残す必要のない性質のプロジェクトだったからよかったものの、そうでなければ少々まずい事態でしたね。

その辺の落とし所は一概にこうすればいいというものではなく、プロジェクトごとの個々の状況に応じて変わってくるんだろうなと思います。今回の僕の方針としては、機能を文章で説明しつつ、ごくごく簡単なワイヤフレーム（白黒で装飾の全くないもの）でボタンやテキスト等の要素の配置を示すことにしたいと思ってます。詳細に立ち入りすぎず、かつ機能の説明を最低限のラインで果たしているという感じを目指します。

あえて、「全ての機能を完全に」書くのではなく、文章の文脈や図などを見れば必然的に想像できることについては記述を省略する・・・って構成にできれば理想的です。この加減や方法については今後も研究していきたいと思います。

※この記事について指摘・意見・提案・感想などありましたら下のコメント欄にどうそ。