僕は目標を立てるのが下手だ。ついでに言うと、自己評価も下手だ。 評価面談を行う上司やシニアデザイナーにはいつも迷惑をかけていた。今回も、例によって「あとはやるだけだ！」という目標設定はできていない。 それに対し、プライベート活動に関する目標を立てるのは上手だ。なぜならば、自分のやりたいことがたくさんあるから。とにかくやりたいことに対し、モチベーション全開で向き合うだけでよかった。ただ、なんとなくあっちこっち行き当たりばったりで軸がないような気もしていた。

去年は公私ともに悩んだ結果、自分が本当にやりたいことをやっとの思いで言語化することができた。《「わからない」をなくす 》というのがそれだ。 これに至ったのは、「自分が作ったものが、誰かにとっては使い物にならない」ということがあり得ることが嫌だったからだ。「なにこれ、よくわかんないんだけど」という言葉を聞いたら、かなりショックである。しかし、必ずそれがあるのも事実だ。 僕は誰でもストレスなく使えることを追求することが好きで、だから人間そのものの特性ついてもっと知りたいし、視覚障害など晴眼者とは違う条件下での利用にも対応できるようにしたい。

仕事の目標を立てることに現在進行形で悩んでいる。締め切りはとっくに過ぎているが、プロジェクトの関係で、もっと戦略が具体的になってから定義する手筈になっていた。 が、しかし。具体的になったとしても、評価者が悩まず高評価をつけてくれるような自己評価をすることができる目標設定はできないだろう。

何に困っているのか？それは「言い回し」だ。ハッキリ数字が出る目標設定は簡単だ。それに達成しているか・いないかの２択だけでいい。今回の目標が改善タイプであればそのように数字の変化を軸にした目標を設定すればよいのだが、今回は改善タイプではない。新しくモノを作ることで期間ギリギリ（計測期間を確保できない）のケースだ。 よって、「作り上げる」タイプの目標設定をする必要がある。

「○○を作った」「○○で成果を出す」では、定量的ではないので評価者が評価をしにくい。解釈次第では、あとから結果がいくらでも変化することになる。 どうにか、上手い言い回しはないだろうか？評価判定がしやすい目標設定とは？ 他の人の評価シートを眺めていても、真に上手なのか、評価者によってはその人も「評価しにくい目標」という判定になるのではないか、それ自体の判断すら曖昧だった。なので「説得力」に関しても重要だった。

そこで、「作り上げる」タイプの目標設定が上手な人を探した。そのためにまず「上手であると判定できる人」を探す必要があった。 僕はデザイナーだが、以前からエンジニアの評価シートを眺めることが好きだった。職種柄、言語化に長けているからだろう、読んでいて気持ちが良かったのだ。 僕が勤めるGMOペパボには、シニア・プリンシパルエンジニアという上位職のエンジニア @matsumotory さんがいる。 技術者と研究者の狭間で得たたったひとつの教訓 2016 というスライドを読んでからファンになってしまって、スライドやissue、ブログ記事などをよく眺めてさせていただいていた。 @matsumotory さんに「作り上げる」タイプの目標設定について尋ねてみたら、想像以上に多くのことをアドバイスしていただけた。今回いただいたアドバイスを自分の中に取り込み、自分なりの解釈をし以下に記録する。

「作り上げる」の目標設定・達成のためのヒント

1. アウトプット・フィードバックを繰り返し「説得力」を獲得すること

作って公開・作ったものを社外で発表・自社サービスへ導入。エンジニアの王道スタイルという印象のあるこのパターン。 しかし、ただ作ればいいというわけではない。自分だけしか価値を感じない結果に終われば、それは自身の評価には繋がらない。その疑念を払拭する意味も含め、大事なことはアウトプットでそれを測ること。アウトプットし、それに対する社外のフィードバックを受け…というその繰り返しによって社外でも一定の評価を得られれば、それが社内評価での「説得力」となる。

2. 考えをまとめるだけでコンテンツになる

「これ（ FastContainerアーキテクチャ概論 ）とか何も作ってないですけど、考えだけをまとめたものですが、ちゃんと一つの作り上げたものに見えますね。それをベースに提案する、などがその先でしょうか」

ライブラリ・ソフトウェア作成以外には、上記のような設計や思考、アーキテクチャをちゃんと整理してアウトプットするなどがある。なので「プログラミング言語が扱えないから、エンジニアみたいに全部自分で作り上げるなんてできない！」などと嘆く必要はない（とはいえデザイナーもフロントエンドに特化している人ならばひとりでやってしまいそうであるが）。 設計こそデザイナーの本来の役目。ターゲットユーザーに対してインターフェイスがどのように機能するか。使いやすさはこれが一番か。誰でもアクセスできるか。セオリーに則っているが、もっとこうしたらこれまで以上に利便性が向上するのではないか。 考え始めたらアウトプットに繋がる題材はゴロゴロ存在する。

3. 社外へのアウトプットは「一般化」で解決する

やっていることを一般化して整理する、ということをやれば社内業務の出来事も社外へ向けてアウトプットすることができる。 Webオペレーションエンジニアのアウトプットと開発力 にも書かれている。 一般化とは、業務で生み出したもの・やったことを、組織に依存しない手法、コード、テクニックへと変換し誰でも問題なく参照できるようにすることだと僕は認識した。 一般化をすることで、会社的に出していいものか…まずいかなあ…などというアウトプットに対する足枷を外すことができる。

4. 提案したものをちゃんと作り上げる

細かくアウトプットしていく、というのがどのケースにおいても重要。 細かくアウトプットし、フィードバックを得て磨き上げる。その先で説得力を獲得する。 そしてそれを経て提案し、ちゃんと作り上げるまで実行する。

まとめ

目標設定のための「言い回し」に関する具体的な答えを見出せるまでには至らなかった。 しかし、

• 将来、説得力を獲得している
• 将来、設計や思考がまとまっており、伝わる状態になっている
• 将来、提案が実行され（取り入れられ）作り上げられるものがある

これらを意識していけば自ずと言い表せるようになるはずだ。 一般化して考える癖をつけることと、自分の業務と社外の内容を重ね合わせるように努力して生産性を高くしていくことに注力するとよくなる。

僕はこの出来事を経た後も、変わらず目標を立てることも自己評価も下手くそだろう。何かに気づいたからその後一気に好転するくらいデキるやつなら、こんなに悩まずともきっとそのうちできていた。 大事なのは、すぐにできるかできないかではない。 これからも何度も失敗を積み重ねていく中で、今回得たことを忘れず継続していくことだ。 すると、失敗の先にきっと成功があるだろう。

最後の最後にこのアドバイスをする @matsumotory さん、さすがだった。