polog

どうも、ぺーぺープログラマねぎぽです。
僕は会社ヒエラルキにおける最も下っ端に位置する会社人なので、マネジメントをするしないとかもう全然関係なく完璧に指示を受ける側であります。仕様っぽいものもたまに書くっちゃ書くけど、そんなことはtinyな案件でない限りめったになく、上から横からやってくる画面仕様やらhtmlの形をした仕様やらをフルに想像力を働かせて実装しております。
でもやっぱり、編集部の人は編集語、デザイナさんはデザ語で仕様を回して来るので、マ語をしゃべる僕としては全然分からないんですよね、何が言いたいんだこりゃと。多分最もかっちりしている解決方法は仕様書のフォーマットを全社員の共通言語として策定することなんですが、そこは企業0.2.1ぐらいなうちのこと、ほら、阿吽だよアウン、てな具合です。
僕に今まで回って来た仕様書はどれもこれも「ここには何とかが表示」「これを押すとどうなる」的な事は何とかぎりぎり想像できるようにちゃんと書いてあります。良い。だけど、結構共通して仕様書から読み取れないことが「このリストはどう言う順番で表示するか」。これ、本当に伝わってきません。また、7割方は仕様書を書いた人もどのカラムとどのカラムでソートすることが一番適当かを把握していません。つまり、「このリスト、どう言う順番で並べたいんですか?」って画面を印刷して持って行った時に、正確な答えを得るためには普通にやっちゃうと結構な時間が必要なんですね。
そんな時に良いのが、テストデータを10個分ぐらいぱぱっと書いて、「じゃあこれ、並べ替えてみて下さい」とやること。設計者はちょっと迷いながらぽこぽこナンバリングしてくれるので、僕はそれを見ながら、うわ、ハッシュ必要じゃん、などと呟くのです。
まとめると、
1) みんながみんなホワイトボードを使った表現方法や言語化が得意な訳では無いので、もしそれが必要とされる場面であれば、より低レイヤーなコミュニケーションを行うこと
2) 自分にとって必要な情報がどこにも(自分にそれをやれと言った人の頭の中にも)存在していないことはままあるので、ブレストを相手に強いる手法を考えること
が下っ端的には重要だなあと。

# ちなみに、ある問題を解決しようとCTOに相談したら、上のリストソートの流れと似たようなことをやらされたのが今日最もショックな事です。反省。