こんにちは、Dev Contentチームのmochikoです。LINEヤフー株式会社でテクニカルライターとして働いています。
今日は、テクニカルライティングの専門チームで、私たちテクニカルライターが「チームの目標」をどう決めたかについてお話しします。
※本文中に記載されている会社名、製品名、キャラクター名などは各社の商標、または登録商標です。
テクニカルライターってなに？
目標の話に入る前に、そもそも「テクニカルライターってなに？」という方もいらっしゃると思いますので、テクニカルライターについて簡単に説明します。
LINEヤフー株式会社の技術組織には、技術ドキュメントやAPIリファレンスなどを書く専門職として「テクニカルライター」というポジションがあります。日々、テクニカルライターがどんなふうに働いているかについては、合併前のLINE Engineering Blogに書いた『LINEの社内には「テクニカルライティング」の専門チームがあります』という記事や、LINE DEVELOPER DAY 2021の動画『LINEの開発者向けドキュメントを支える「テクニカルライティング」の専門チーム』をご覧ください。
私がLINEに入社した2019年ごろは、まだテクニカルライターという職業があること自体が業界の中でもほとんど知られていませんでしたが、そこから約5年が経ってテクニカルライターを募集しているIT企業を見かけることが多くなったな、と感じています。LINEヤフー株式会社の他にも、たとえばサイボウズ株式会社や株式会社SmartHR、株式会社Helpfeelなど、テクニカルライターやUXライターが存在感を見せる企業が増えています。
テクニカルライターのチームで「目標」を決めることの難しさ
テクニカルライターは、基本的に自分たちがプロダクトそのものを開発している訳ではないので、「今度、こんな機能が追加されるのでドキュメントをお願いしたい」や「新しくリリースするこのプロダクトのAPIリファレンスを書いてほしい」のように、持ち込まれる相談に応じて仕事をしていくことになります。
そのため仕事の方向性は必ずしも自分たちだけで決められるものではなく、会社やプロダクトの方向性に左右される部分が少なからずあります。能動的に「この辺りのドキュメントをもっと手厚くしていこう」のような業務を進めつつも、やはり会社として優先度の高いプロダクトのドキュメントが最優先となるため、ある意味「言われたことをやる」という受動的なところからは逃れられない、とも言えます。
テクニカルライターのチームとして今後どこを目指していくのか、という中長期的な目標を決めようとしても、どうしても各プロダクトから持ち込まれた案件に左右されるため、Technical Writing Meetupなどのイベントで各社のテクニカルライターが集まると「目標設定って難しいですよね」「他社のみなさんはどうしていますか」という話題はよく挙がっていました。
チームのMVVを考えてみよう
ですが、言語化することが仕事のテクニカルライターなのに、いつまでもチームの目標がふわっとしたまま言語化されていない状態はよくありません。「医者の不養生」とか「紺屋の白袴」みたいに、「テクニカルライターの文書化遅れ」と後ろ指をさされてしまうかもしれません。
という訳で2024年春、重い腰を上げて、チームの「MVV」というものを考えてみることにしました。
MVVってなんだ？
会社の経営理念や企業紹介には、よく「ミッション」や「ビジョン」や「バリュー」という言葉と一緒に、スローガンみたいなものが載っています。あれがMVVです。
みなさん、MVVってなんだか分かりますか？ MVVで検索して「MVVとは、ミッション（Mission）、ビジョン（Vision）、バリュー（Values）の略でうんぬん」と言われても、「なるほど、それぞれの頭文字を取ってMVVなんだね。目標みたいなものかな」ということは分かるものの、それぞれがどういうものなのかとか、ミッションとビジョンの違いとかはよく分からなくないですか？ 私は大人なのに正直よく分かりませんでした……。
Mission、Vision、Values……ミッションとビジョンとバリュー……この3つの違いは何なんだろう？ 困ったときのChatGPT頼みです！ 聞いてみましょう。
MVVを日本語にしてくれと頼んだところ、GPT-4oからは「使命と理想像と価値観です」と返ってきました。使命と理想像と価値観……なるほど分かるような分からないような。小学生でも分かるような言葉でお願いと再び頼んでみたら、今度は「目標と夢と大切なことです」と返ってきました。なるほどやっぱり分からん。
ぱっと理解するのは諦めてMVVについてじっくり調べていったところ、MVVは企業理念のテンプレートのようにあちこちで使われている割に、そもそも何が出典元なのかや、MVVそれぞれの正しい解釈なども曖昧らしいということが分かりました。そこで今回は「弊チームにおけるMVVとはこういうもの！」という独自解釈のMVVを定義しました。大事なのはチームの中で認識がそろっていることです。私たちは世界中で通じる「大統一MVV」を定めたい訳ではありません。
独自解釈でMVVを定義する
以下、私たちのチームにおけるMVVの独自解釈です。例えも含めてすべ て勝手に定義したものなので、これが公式！ これが正解！ という情報ではない点に注意してください。
ミッションとは
ミッションは「使命」です。子供たちが大好きなアンパンマンでいうところの「何のために生まれて〜」というアレです。たとえばウルトラマンなら「この星の人たちを守る！」みたいなものがミッションですね。
ビジョンとは
ビジョンは使命を果たすために自分たちはこういう存在、組織になりたいという「理想像」です。ここで大事なのは、チーム内の個々人ではなく「組織」の理想像であるということです。ウルトラマンなら「みんなのヒーロー」みたいなものですね。ちなみにいろいろなMVVを調べたところ、企業によってこのビジョンは省略されることもあるようです。
バリューとは
最後にバリューは、理想とする存在になり、使命を果たすための「行動指針」です。たとえば大胆さと慎重さ、素早さと確実さのように相反するものの間で、自分たちが何を優先して行動すべきか迷ったときの指針になるものがバリューです。ウルトラマンなら、仮に「誰も死なせない」というバリューがあれば、「目の前の敵にとどめを刺せば、もう二度と地球は襲われず平穏が訪れる。でも敵を倒すことを優先したら、隣にいる瀕死（ひんし）の地球人は治療が間に合わずに死んでしまう」みたいなときに、バリューに従って「敵を倒すより、地球人を病院に連れていこう」という判断ができます。
LINEヤフー株式会社としてのミッションとバリュー
さて、MVVの独自解釈ができたところで、LINEヤフー株式会社のミッションとバリューを確認してみましょう。
- ミッション
- 「WOW」なライフプラットフォームを創り、日常に「！」を届ける。（Create an amazing life platform that brings WOW! to our users.）
- バリュー
- ユーザーファースト（Users Rule）
- やりぬく（Get It Done）
- 少数精鋭（Lean & Mean Teams）
ミッションは「使命」なので、私たちは『「WOW」なライフプラットフォームを創り、日常に「！」を届ける。』ために存在しているんだ！ そのために生まれてきた会社組織なんだ！ ということですね。分かりやすい。
そしてバリューは「ユーザーファースト」「やりぬく」「少数精鋭」です。たとえば「この機能があればユーザーの体験は確実によくなるが、工数をかけてそこまでやるべきか……？」のようにユーザーとコストをてんびんにかける判断を迫られたら、バリューに従って「ユーザーファーストだ！ 工数をかけてでもやろう！」と判断できます。
すごい、会社のMVV、ちゃんとしていた。決しておしゃれなスローガンなどではなかった。
テクニカルライターのチームのMVV
いよいよテクニカルライターのチームのMVVを考えていきます。
もともとみんなで決めたチームの「ミッション」だけは存在していました。あとはチームの中で「言語化されていないけれどこういう気持ちで働いているよね」というふん わりした共通認識もあったので、それを元にチームのマネージャーである私がなんとか「ビジョン」と「バリュー」をひねり出しました。
できあがったMVVはチームに共有してフィードバックをもらいながら直していこうと思っていたのですが、共有したところチームの全員が「わかる」となったので、結果としてそのままで決定となりました。
ミッション
役に立つドキュメントで開発をもっと楽しく（Make development fun with helpful docs）
開発者がLINEヤフーの提供するプロダクトを使って開発をするとき、その体験が楽しいものになるか、それともイライラしたつらいものになるかには、プロダクトそのものの使いやすさだけでなく、ドキュメントの分かりやすさも大きく関わってきます。
私たちDev Contentチームの「使命」は、分かりやすく役に立つドキュメントで、みんなの開発をもっと楽しくしていくことです。
ビジョン
ドキュメントのスタンダードを確立するパイオニア（Be the pioneer. Set the standard for IT technical documentation.）
LINEヤフーの社内でも、あるいは周りのIT企業を見渡しても、ドキュメントで悩んでいるところは多くあります。たとえば 「ちゃんとドキュメントを残すべきだ」という気持ちがあっても、どうしても開発だけが先行してドキュメントは置いてけぼりになってしまう。あるいはみんな頑張って社内に情報を書き残しているけれど、あまりにコンテンツが多すぎて「もう古くなってしまった過去の仕様」と「最新の仕様」がごちゃごちゃになって見つけられない、といった事象にはみ なさんも心当たりがあると思います。
テクニカルライターのチームを抱える会社は少しずつ増えてきたものの、まだ当たり前の存在にはなっていません。私たちは、「ドキュメントってああいうふうに書いたり、管理したりすればいいんだ。うちもLINEヤフーのやり方をまねしてみよう！」と言われるような、ドキュメント管理のスタンダードを確立するパイオニアになることを「理想像」として掲げました。
バリュー
バリューは以下の4つです。何を優先すべきか迷ったときに、このバリューが私たちの「行動指針」になります。
走りながら考える（Think on the run）
何かをやるかやらないか、どんなふうにやるか、という計画を立てることは大切ですが、検討に時間をかけすぎていつまでもその場にとどまっていると何も始まりません。何かやった方がいいと思うことがあったら、取りあえずやってみよう！ まずは走り出して、それ以上のことは走りながら考えよう！ やってみて失敗しても、少なくとも「こうやったらうまくいかない」という学びが得られるという点でなにもやらないよりはいいことだ、と私たちは思っています。
早く公開すれば早く直せる（Release early, fix faster）
情報の正確さは大切ですが、一方で「完璧で何一つ誤りのないドキュメントになるまでは世に出さない」と思っているといつまでもドキュメントが公開できません。ドキュメントが何もない状態よりは、多少の不足や分かりにくさがあってもドキュメントが「ある」方がまだいいはずです。万全を期すあまりにいつまでもリリー スできないよりは、ある程度の失敗を許容することで早く公開することを優先しています。
惜しみなく出すともっと得られる（The more we share openly, the more we gain）
テクニカルライターが持つライティングの知見は、社内の研修や社外のイベントなどで惜しまず共有しています。自分たちが書くものだけでなく自社全体のドキュメントが、さらに自社だけでなく業界全体のドキュメントの品質が底上げされていく過程に貢献できたら、それは素晴らしいことです。ノウハウは隠して独占するよりも、みんなで広く共有し、集合知によってさらに改善されていった方がいいはずです。
愛着が湧くほど詳しくなろう（Know the product best, love the product most）
そのプロダクトに興味のない人間がおざなりな理解で書いたドキュメントは、読めばそれと分かるものです。私たちは「言われたとおりにドキュメントを書くだけ」ではなく、実際の開発者と同じようにそのプロダクトを使ってみて、仕様や背景を理解した上で、分かりやすいドキュメントを作り上げたいと思っています。そのためにはプロダクトに愛情を持つことで詳しくなり、詳しくなることでもっと好きになっていく、という姿勢が不可欠です。
MVVができてどう変わったか
忙しい日々の中で、普段は目の前にあるひとつひとつのドキュメントを書いたり直したりすることに集中して向き合っていますが、私たちテクニカルライターも「あれ、どっちに向かって走っていたんだっけ？ なんのためにこんなに頑張ってたんだっけ？」と立ち止まる瞬間があります。
そんなと き、MVVがそこにあって「そうだ、みんなでこっちに向かって走っていたんだ。進む方向は間違えていない」と確認できると、「闇雲に頑張っているけどこれでいいんだっけ？」という焦燥感にとらわれることがなくなったように思います。
以上、テクニカルライティングの専門チームで、テクニカルライターが「チームのMVV」を決めた経緯とその内容でした。ぜひみなさんの組織のMVVも教えてください！