Konifar's ZATSU

私はのび太の味方じゃないわ、悪の敵よ

自社のことを紹介する文章のレビューについて

今日も今日とてインターネッツは騒がしい。今日はたくさんの人がラグビーになっていた。

style.nikkei.com

『GAFA』『ラグビー』『乱入』という本来混じり合うはずのない言葉のハーモニーに、インターネッツの住人の心がコチョコチョとくすぐられたのだ。しかし、こんな真偽も実際の状況もわからないような話自体をいくら話題にしても不毛である。こういう話題は明日は我が身と考えて、学ぶべきことを探した方が生産的だ。ここで学ぶべきことはひとつで、「自社やチームのことを紹介する文章を公開する前にどういう観点でレビューすればいいのか」ということである。

まあ今回の話について言えば外部のメディアなのでレビューできなかったみたいな事情もあるのかもしれないが、自分が普段社のブログレビューで指摘しているポイントを雑に書き出しておく。

読者との間に温度差がありすぎないか

  • 温度感をもった記事はそれはそれでよいが、ありすぎると危険
  • 内輪感を不快に思う人もいるので、自分たちを持ち上げすぎないバランス感が大事だったりもする

言葉だけで誤解されない表現になっていないか

  • 言葉だけだとどうしても正確に状況を伝えられない可能性もある
  • 例えば楽しさや盛り上がりは効果的に写真を使ったりしないと伝わらないことが多い

インターネッツで拒否されやすい表現をつかっていないか

  • 「いかがでしたでしょうか?」とか
  • (笑) みたいな語尾の表現も危険な場合もある

背景の説明が十分か

  • 育ってきた環境が違うので、背景をちゃんと説明しないと伝わらないこともある
  • 背景を共有しないと変なところで噛み付かれたりするので注意が必要

複数の読み手の視点で読んでみても問題ないか

  • 社員、ユーザー、知り合い、投資家、パートナーなど色々な人が読む可能性がある
  • 事実と違うことが書いてあったり、前置きが足りなかったりしないかチェックした方がよい

機能など専門用語に揺らぎがないか

  • 社内用語になっていたりとか
  • この辺はTextLintでチェックしたい

肯定表現できる部分がネガティブな否定表現になっていないか

  • 基本的に肯定表現の方が読んでいて気持ちがいい
  • ここもLintでいい感じにできるかもしれない

日付に曜日が入っているなどフォーマットが同じか

  • Lintだね

あのラグビーもさ、本当はみんなニコニコ楽しくやってるかもしれないし、あの施策によって普段の雑談が増えて仕事しやすい雰囲気になってるかもしれないよね!施策自体は良し悪しわからんよね。悪かったのは、良し悪しわからんような記事を公開しちゃったところだけだよ。そもそもGAFAの話と絡めてあの話が必要だったのかという観点もあるけど、ラグビーボール持ってニコニコしている写真とかが2〜3枚あるだけでだいぶ印象変わってたと思う。

インターネッツは馬鹿っぽい人に厳しい。馬鹿ではなく馬鹿っぽい人に厳しいのだ。自社のことを紹介するときは、馬鹿っぽく見なされないように最低限のレビューが必要。私からは以上だ。

あわせてよみたい。

konifar.hatenablog.com

何で成果を出したいかを共有して期待感の齟齬をなくす

zatsuというブログ名に恥じぬよう雑に考えを書いておく。

チームで働くときは自分がどこで成果を出そうと思っているかをちゃんと言語化して共有しておくとみんな幸せになりやすい。EMやPMなど、個々人が思い浮かべる役割のイメージが違う場合は特にやっておいたほうがよい(念のため書いておくと、いま一緒に働いている同僚氏にめっちゃ不満があって書きなぐっているとかではない)

仕事に限らず、ほとんどの人は気づかぬうちに他人に何かを期待していることが多い。一方的な期待に対して成果が足りないと感じるとストレスがたまり、それが積み重なると信頼関係が崩れていく。

あの人にはもっとこういうことしてほしいとか、私ならこうするのにとか、頭の中で勝手に期待して勝手に裏切られるのは不毛だ。イライラしている様子は相手に伝わるが、相手からするとなぜイライラしているかわからないことが多く、めんどくさい大人の関係が始まってしまう。

そういった期待感の齟齬にイライラしてるなと感じたら、すぐに相手に直接伝えるべきだ。ただ、イライラした状態だと理性的に言語化してコミュニケーションを取れない人もいる。つまり、そういった状態になってからでは遅いのだ。

防止策として、何で成果を出したいと思っているかを先に周囲に共有しておくとよい。期待感の齟齬にイライラする前に最初に潰しておくのだ。組織内で個人の目標設定をするフローがあるのであれば、その目標を公開しておくだけでも効果はあるかもしれない。

マネジメント層であれば、マネージャーという役割をどう捉えているかとか、何に責任を持って何に取り組むかといった話を文章にして共有するとか、すでにやっている人はたくさんいると思う。たとえば「組織のマネジメントはノータッチで、ひたすら技術的なリードをやる予定です」みたいにやることとやらないことを話しておくと、周りもそういうスタンスで接する心構えができるのでお互い楽になる。周囲からの期待の齟齬がなくなることで本来やるべきでない仕事を抱えることも減り、成果を出すべき仕事に集中できる。

ちなみに今の自分はどうかというと、ちゃんと伝えられていない気がする。あまり範囲を限定したくはないけれど、少なくともこの領域では120%の成果を出しますという話を来週にでもチーム内で共有しておこうと思う。

余談だが、自分が朝起きたときに猫のトイレ掃除をしなかったことが続いて、最近嫁氏の機嫌が悪い。これは自分が100%悪いのだけれど、こういうのも期待感の齟齬によるものなのかもしれない。

行動の優先順位

当人としてはよく考えて選択して行動や言動なんだろうなと納得しつつも、なんだか自分とは相入れないなと思うことがある。

どういう話でそう感じることが多いかとふと考えてみると、大きなスケールのことを考えた行動に対してかもしれない。

例えば、とある業界全体の意識を変えたくて書いた記事だったり、人類全体のことを考えて起こしたデモだったり。当人は外野の10倍は物事を考えているものなので、様々な懸念は考慮した上で選択した行動なのだろう。しかし、その熟考の果てに取った行動がそれなのかと考えてしまうことがあるのだ。身近にいる人に対する影響よりも全体のことを優先するのだなというか。うまく説明できないけれど、行動の優先順位のつけ方が矛盾していると感じてしまうことがある。Fate/Zeroの切嗣くらいいけば逆に清々しいのだけれどね

Slackでよく使うフレーズ

自分がSlackやオンラインでよく使うフレーズをメモしておく。他の人のも知りたい。

「質問です! :raising_hand:」

  • 質問をしたい時に最初に書く
  • 例) 質問です!これって○○ということですか?

「進捗です」

  • ひとまず進捗報告する時に最初に書く
  • 例) 進捗です!結論から言うと1日分くらい遅れてます :bow:

「just ideaですが」

  • ポッと思いついたアイデアを伝えたい時に最初に書く
  • 例) just ideaですが、○○というのはどうでしょう?

「間違ってたら指摘してください :pray:」

  • 誰かの考えられた意見に対して意見を言う時に書く
  • 例) これって○○の方がいいかもと思ったんですがどうでしょう?間違ってたらすみません指摘してください :pray:

「:cool:」

  • よいと思ったときに最初に書く
  • 例) Cool :cool:

「念のため確認です!」

  • 相手もすでに考えてるであろうことに対して何か言うときに書く
  • 例) もうすでに考慮済みかもしれませんが念のため確認です!

「天才なので」

  • いいことをした時に最初に書く
  • 例) 天才なので今のところクラッシュフリーレート100%です(不安)

「オッ」

  • オッと思った時に最初に書く
  • 例) オッすみません、すぐ見ますね

「流石です!」

  • 流石だと思った時に最初に書く
  • 例) 流石です! :sasuga:

「:eyes:」

  • まず見たということを示したほうがいい時にすぐに書く
  • 例) :eyes:

「ありがとうございます!」

  • 何かしてくれた時に最初に書く
  • 例) ありがとうございます!!

「すぐわかったら教えてください」

  • 誰かにとりあえず聞いてみる時に最初に書く
  • 例) もしすぐわかったら教えてください!〇〇ってどこで見れますか?

「ヤッタネ!」

  • やったと思った時に書く
  • 例) ヤッタネ!!

大人の不満の処理方法

大人になるにつれて、感情的に不快な気持ちをぶつける人が少なくなる。直接的な本音のかわりに、建前が増える。余裕がない人は、それが嫌味や苛立ちといった形で表面に漏れ出てしまったりもする。皆が見えるSNSへのボヤキとかも同じ。正直にいってめんどくさい。何よりも消耗する話だ。

例えば、仕事でなんとなく疎外感を感じてしまったり、方針に納得できなかったりした時、不満はあるけど何も言わないあるいは「まあいいですけど」といった言葉で不満な気持ちだけをそれとなく表明するみたいな。公私関係なくよくある話だと思う。

モヤモヤとした気持ちを消化する方法が見つからない時はとても辛いものだ。大人になると「てめえムカつくんだよ」みたいな感じで適当にふわっと感情をぶつけて消化できないケースが増えるのかもしれない。

自分の感情を理性的かつ正確に言葉で伝えられる能力があればいいというケースもある。自分の気持ちを深堀りして、何が気に食わないかを相手にもわかるように説明するのだ。ただ、この方法はうまく実践するのが難しい。深堀りした結果、自分の信条だったりプライドだったり他者に言葉で簡潔に説明するのが困難な領域に達することが多いからだ。相手も理性的であることが前提であるという点も難しさの一つになっている。

自分の感情をうまく飲み込みきれず、まわりに負の感情を伝播させたり潰れたりしてしまうよりかは、子どものようにぶつけてくれればいいのにと思うこともある。別にみっともないとも思わない。大人であっても、自分の感情を理性的に伝えるのはかなり難しいことなのだ。理性的であろうとして刺々しい言葉を吐いてしまうよりは、「うまく言葉で説明できないけどすごくイライラするし嫌な気持ちです」みたいな感じでストレートにぶつけてくれる人の方が好きだ。それもそれで、なかなか勇気がいるし難しいことなのだけれど。

今年最後のアプリリリースとSHIROBAKO

これはSHIROBAKO Advent Calendar 2018最終日の記事である。

今年最後の少し大きめのアプリリリースを終え、『えくそだすっ!』最終話を完パケした後の杉江さんのような心持ちで家路についている。

いやー12話ほどではないにせよ正直なかなかひりつくスケジュールで 「綱渡りか…」 と呟く瀬川さんの姿が頭によぎったよね。

12月7日(金)にやるかどうかの会議があって、19日(水)にiOSアプリを申請するというスケジュールだったから、都合8日でデザイン、サーバーサイドの実装、アプリの実装、テストをやりきらなければならなかった。

「これ現実的に年末までに出せますかね?」
「現実的ではないですけど、まあ出せたら年末気分いいですよね」

などと話しながらも「正直厳しいなー」と思ったが、 変な話間に合わなかったらリリースしなければいいだけだし、ムサニよりはよっぽど楽だよなとも感じていた。杉江3日伝説には遠く及ばないが、こういうギリギリのテンションで仕事をするのは嫌いではない。実際、19話の回想シーンのような現場感があり、チームの雰囲気もよかったと思う。

雰囲気はよかったが、いま思い返してみると結構ピリピリしていた時もあった気がする。

デザイナー氏がすごい勢いで仕様とデザインをほぼ固めてくれた時、シャチョーとデザイナー氏の間で実装機能の目的の食い違いで議論になった。

平岡と円さんのような感情的な言い合いではなかったものの、「どんなユーザーのために作るのかという部分から考え直した方がいいのでは?」という話が出た時は、変な話 「ウォッ3話のあるぴんじゃん」 と思ったよね。最終的に、ユーザーからの声という定性データと実際の数字という定量データをもとに議論して、大きな変更をせずにそのまま行くことになった。

宮森のように場の空気を変えていい感じに軌道修正できたわけではない。正直に物を言いまわりを程よく巻き込める能力は、宮森の素晴らしい才能なのだ。

また、リリースできるか見極める最初のチェックポイントまでにサーバーサイドの開発が間に合わず翌日にリスケになってしまったこともあった。

その時、佐倉さんのように 「いいよー別に。待つのも仕事だからねー」と言える余裕が自分にはなく、思わず 「万策尽きた」 と言いそうになってしまった。あらゆる状況を想定して準備をし、常に心穏やかにまわりに接することができる能力は、佐倉さんの普段の努力によるものなのだ。

第二チェックポイントまでに何をどうするか決め、 「現場は生き物って言うからね。何時も何かが起きる。だから、今できることをやっておかないとね!」と言った宮森を見習って先にテストケースを作ったりデザインを完璧に仕上げたりすることに集中した。

「全部を一度には無理でもね、小さなことからコツコツやればいつか終わるよ」 というロロの台詞はいつでも正しく、最初は終わるか不安だった開発でもタスクを書き出して進めているといつの間にか終わりが見えてくるものだ。

開発終盤に差し掛かると、いくつかの仕様や修正を年内のリリースからは落とす判断をしたりもした。アニメ制作と違い、出したものをまた手直しして改善できるところがサービス開発のよさだなと思うと同時に リスケが許されないというプレッシャーの中で、合意を取りにくい芸術分野をあれだけうまくまとめた新卒2年目の宮森には尊敬の念を禁じ得ない。

そんなこんなでリリースしたアプリは、今のところ大きなバグもなくユーザーの皆さんからはポジティブな意見をいただいている。あとは、明日予約したリリース打ち上げのバルバッコアどんどんドーナツどーんと行く のみである。

ちなみにここまで色々書いてきたが、SHIROBAKOのコンテキストは社内の誰とも共有できていない。全て自分1人の頭の中で思い浮かべていただけである。

実は来年には本物のアニメ制作進行経験者が入社してくるので、一緒に最高の完パケ体験をするのを心待ちにしている。


今年もSHIROBAKO Advent Calendarお疲れ様でした。参加してくださった皆さま、ありがとうございました。

いつのまにか4年目を終え、トータルでは100記事を超えたと考えるとすごいことですね。年明けの松亭新年会でお会いしましょう。

開発タスクを決める思考整理のためのIssueテンプレート

開発タスクの決まり方は組織によって色々だろうけれど、いきなりポンとタスクを渡されて 「そもそもこれなんでやるんだっけ?」「他のタスクと比べて今やる意味あるんだっけ?」という気持ちになったことはないだろうか。工数かかるなーと思いながらよくよく課題を聞いてみたら、実はもっと簡単なやり方でスマートに解決できそうだったとか。

開発する時には、課題と解決策の納得感を持って進めたい。結果的にその解決策の筋がよかったとしてもだ。こういった意識を持っている開発者は意外と多い印象だが、チームで働く上でそのマインドを統一するのは意外と難しい。

そこで、開発タスクを決定する際の思考整理としてIssueテンプレートというものを用意してみたことがある。やろうとしているタスクに関して、一度このテンプレートに沿って埋めてみるのだ。書いている途中であれ?となるかもしれないし、書いたものを叩き台にして開発者からもっといい解決策を提案してもらえるかもしれない。アイデアを出す時にこれを強いるのはつらいかもしれないので、タスクを決める時の思考整理として使うとよい。

このIssueテンプレートがうまくいったか定量的には測っていないが、少なくとも自分の肌感では解決策だけ渡されて戸惑うといった経験は減ったように思うのでメモしておく。


解決したい課題

  • やることではなく、どういう問題を解決したいかを書いてください。

経緯

  • どういう経緯で話が出てきたかを書いてください。
  • 経緯を聞いてみたらそもそも課題が違った、ということを防ぎます。

やりたいこと

  • 解決策として何をやりたいかを書いてください。
  • 上で解決すべき課題が明確になっていれば、開発者からより良い解決策を提案できるかもしれません。

予測KPI

  • 結果を何の数字で判断するのかを書いてください。
  • どのくらいの効果が予想されるのかによって優先度も変わるので、定量的に書いてください。
  • 現状の数字がないものも、予測でいいので書いておいてください。

リリース希望日

  • 開発やデザインの都合は一旦無視して書いてしまって大丈夫です。
  • 希望日の理由があれば書いてください。
  • ASAPは優先度を判断できないのでダメです。

リスク

  • 数字が下がるなど、考えられるリスクがあれば書いておいてください。

イメージ

  • 手書きや他のアプリのキャプチャがあれば貼ってください。

参考リスト

  • データのURLや関連するIssueなどがあれば書いておいてください。

ステークホルダー

  • このIssueを知っておいてほしい人にメンションしてください。
  • 法務など、GitHubにいない人も書いておいてください。