こんにちは。
システムチーム/プログラマーのNです。
ここ1ヶ月ほど、１週間のタスクを決定するにあたり、
自身のタスクだけではなく、部下のタスクの仕様を考えて承認をとる仕組みの中で動いています。
仕様から考えるタスクが増えたことで差し戻しの数も増えています。
今回のブログは差し戻しについて言語化しようと思います。
なぜ差し戻しになるのか
なぜ差し戻しになるのかというと、それは
ユーザーの行動を制御できていないもの
だからです。
シナジーデザインでは、システムの定義を
未来の別の場所にいる誰かの行動を制御する
としています。
これは別の場所の不特定多数ユーザーの行動を洗い出し、
その行動の全てを処理する必要があるということです。
例えば
ボタンを追加して、そのボタンを押したらアニメーションしながら入力フォームが表示される。
それが動くかどうかだけを考えるなら、明確にしやすいですが、
不特定多数ユーザーの行動を制御するとなると難易度が上がります。
「最初から表示させておくべきだろう」
「ユーザーの操作が１つ増えてストレスに繋がってしまう」
「そもそも、入力フォームの表示にアニメーションが必要なのか」
など、考えなければいけないことが何倍にもなります。
自分が動かす前提で判断して作っている仕様は必ずと言っていいほど差し戻しになります。
書いたコードが動くというのは当たり前のこと
プログラマーなので、考えて書いたコードが考えた通りに動いたときはやはり嬉しいです。
しかし、
動いたからといって、それがユーザーの行動を制御していることには繋がらない。
ユーザーがストレスに感じていれば、それは自己満足でしかない。
仕事がストレスの代行である以上、
考えて考えて考え抜かなければいけないと思います。
上司が考える仕様との違いを考える
自分の作る仕様は、上司が作る仕様とは違い、至らない部分が多いです。
何が違うのかと考えたときに、
前述した
ユーザーの行動を制御できていない
部分以外に
将来・未来を見ている
足し算ではなく、引き算で考えている
と感じています。
自分の考えた仕様は今しか見ていない仕様
安易に文言を追加する
や
ボタン、またはリンクを追加する
などの考えが先にきています。
足し算ばかりで考えていたら、機能を追加するたびに要素が増えていき、どんどんわかりにくいシステムになってしまいます。
なんとなくで考えていたら、何が必要で必要じゃないかに気づくことはできません。
必要か必要じゃないかを論理的に考え、根拠を持たなければいけない
と思いました。
そのために、
上司の担当しているタスクの仕様を自分ならどうするだろうと考え、
実際の上司の仕様と何が違うのだろうと比較し言語化することを続けていきたいと思います。
最後までお読みいただき、ありがとうございました。
