Upgrade to Pro — share decks privately, control downloads, hide ads and more …

テクニカルライターのチームで「目標」をどう決めたか / MVV for a Team of T...

テクニカルライターのチームで「目標」をどう決めたか / MVV for a Team of Technical Writers

Technical Writing Meetup vol.37
2024/10/10(木) 19:00 〜 20:40
https://tw-meetup.connpass.com/event/332316/

LY Corporation Tech

October 10, 2024
Tweet

More Decks by LY Corporation Tech

Other Decks in Technology

Transcript

  1. © LY Corporation Yoshiko Horikoshi 6 プログラマ(3年) 広報(4年) インフラエンジニア(7年) 2020年1月からLINEでテクニカルライター

    2023年10月からLINEヤフー Programmer (3 years) Public Relations (4 years) Infrastructure Engineer (7 years) Technical Writer at LINE since January 2020 From October 2023 at LY Corporation @mochikoAsTech
  2. © LY Corporation 独自解釈で定義したMVV ミッションとは ミッションは「使命」です。 子供たちが大好きなアンパンマンでいうところの「何のために生まれて〜」というアレです。 たとえばウルトラマンなら「この星の人たちを守る!」みたいなものがミッションですね。 ビジョンとは ビジョンは使命を果たすために自分たちはこういう存在、組織になりたいという「理想像」です。

    ここで大事なのは、チーム内の個々人ではなく「組織」の理想像であるということです。 ウルトラマンなら「みんなのヒーロー」みたいなものですね。ちなみにいろいろなMVVを 調べたところ、企業によってこのビジョンは省略されることもあるようです。 バリューとは 最後にバリューは、理想とする存在になり、使命を果たすための「行動指針」です。 たとえば大胆さと慎重さ、素早さと確実さのように相反するものの間で、 自分たちが何を優先して行動すべきか迷ったときの指針になるものがバリューです。 ウルトラマンなら、仮に「誰も死なせない」というバリューがあれば、「目の前の敵にとどめを 刺せば、もう二度と地球は襲われず平穏が訪れる。でも敵を倒すことを優先したら、隣にいる瀕 死(ひんし)の地球人は治療が間に合わずに死んでしまう」みたいなときに、バリューに従って 「敵を倒すより、地球人を病院に連れていこう」という判断ができます。 59
  3. © LY Corporation 自社のMとVを独自解釈で確認 ミッションとは ミッションは「使命」です。 子供たちが大好きなアンパンマンでいうところの「何のために生まれて〜」というアレです。 たとえばウルトラマンなら「この星の人たちを守る!」みたいなものがミッションですね。 ビジョンとは ビジョンは使命を果たすために自分たちはこういう存在、組織になりたいという「理想像」です。

    ここで大事なのは、チーム内の個々人ではなく「組織」の理想像であるということです。 ウルトラマンなら「みんなのヒーロー」みたいなものですね。ちなみにいろいろなMVVを 調べたところ、企業によってこのビジョンは省略されることもあるようです。 バリューとは 最後にバリューは、理想とする存在になり、使命を果たすための「行動指針」です。 たとえば大胆さと慎重さ、素早さと確実さのように相反するものの間で、 自分たちが何を優先して行動すべきか迷ったときの指針になるものがバリューです。 ウルトラマンなら、仮に「誰も死なせない」というバリューがあれば、「目の前の敵にとどめを 刺せば、もう二度と地球は襲われず平穏が訪れる。でも敵を倒すことを優先したら、隣にいる瀕 死(ひんし)の地球人は治療が間に合わずに死んでしまう」みたいなときに、バリューに従って 「敵を倒すより、地球人を病院に連れていこう」という判断ができます。 60
  4. © LY Corporation ミッション 役に立つドキュメントで開発をもっと楽しく (Make development fun with helpful

    docs) 開発者がLINEヤフーの提供するプロダクトを使って開発をするとき、 その体験が楽しいものになるか、それともイライラしたつらいものになるかには、 プロダクトそのものの使いやすさだけでなく、ドキュメントの分かりやすさも大きく関わってきます。 私たちDev Contentチームの「使命」は、分かりやすく役に立つドキュメントで、 みんなの開発をもっと楽しくしていくことです。 69
  5. © LY Corporation ビジョン ドキュメントのスタンダードを確立するパイオニア (Be the pioneer. Set the

    standard for IT technical documentation.) LINEヤフーの社内でも、あるいは周りのIT企業を見渡しても、ドキュメントで悩んでいるところは多くあります。 たとえば 「ちゃんとドキュメントを残すべきだ」という気持ちがあっても、 どうしても開発だけが先行してドキュメントは置いてけぼりになってしまう。 あるいはみんな頑張って社内に情報を書き残しているけれど、あまりにコンテンツが多すぎて 「もう古くなってしまった過去の仕様」と「最新の仕様」がごちゃごちゃになって見つけられない、 といった事象にはみなさんも心当たりがあると思います。 テクニカルライターのチームを抱える会社は少しずつ増えてきたものの、 まだ当たり前の存在にはなっていません。 私たちは、「ドキュメントってああいうふうに書いたり、管理したりすればいいんだ。 うちもLINEヤフーのやり方をまねしてみよう!」と言われるような、 ドキュメント管理のスタンダードを確立するパイオニアになることを「理想像」として掲げました。 70
  6. © LY Corporation バリュー 走りながら考える (Think on the run) 何かをやるかやらないか、どんなふうにやるか、という計画を立てることは大切ですが、

    検討に時間をかけすぎていつまでもその場にとどまっていると何も始まりません。 何かやった方がいいと思うことがあったら、取りあえずやってみよう! まずは走り出して、それ以上のことは走りながら考えよう! やってみて失敗しても、少なくとも「こうやったらうまくいかない」という学びが得られるという点で なにもやらないよりはいいことだ、と私たちは思っています。 72
  7. © LY Corporation バリュー 早く公開すれば早く直せる (Release early, fix faster) 情報の正確さは大切ですが、一方で「完璧で何一つ誤りのないドキュメントになるまでは世に出さない」

    と思っているといつまでもドキュメントが公開できません。 ドキュメントが何もない状態よりは、 多少の不足や分かりにくさがあってもドキュメントが「ある」方がまだいいはずです。 万全を期すあまりにいつまでもリリースできないよりは、 ある程度の失敗を許容することで早く公開することを優先しています。 73
  8. © LY Corporation バリュー 惜しみなく出すともっと得られる (The more we share openly,

    the more we gain) テクニカルライターが持つライティングの知見は、 社内の研修や社外のイベントなどで惜しまず共有しています。 自分たちが書くものだけでなく自社全体のドキュメントが、 さらに自社だけでなく業界全体のドキュメントの品質が底上げされていく過程に貢献できたら、 それは素晴らしいことです。 ノウハウは隠して独占するよりも、みんなで広く共有し、 集合知によってさらに改善されていった方がいいはずです。 74
  9. © LY Corporation バリュー 愛着が湧くほど詳しくなろう (Know the product best, love

    the product most) そのプロダクトに興味のない人間がおざなりな理解で書いたドキュメントは、読めばそれと分かるものです。 私たちは「言われたとおりにドキュメントを書くだけ」ではなく、 実際の開発者と同じようにそのプロダクトを使ってみて、仕様や背景を理解した上で、 分かりやすいドキュメントを作り上げたいと思っています。 そのためにはプロダクトに愛情を持つことで詳しくなり、 詳しくなることでもっと好きになっていく、という姿勢が不可欠です。 75
  10. © LY Corporation 83 バリュー 惜しみなく出すともっと得られる (The more we share

    openly, the more we gain) テクニカルライターが持つライティングの知見は、 社内の研修や社外のイベントなどで惜しまず共有しています。 自分たちが書くものだけでなく自社全体のドキュメントが、 さらに自社だけでなく業界全体のドキュメントの品質が底上げされていく過程に貢献できたら、 それは素晴らしいことです。 ノウハウは隠して独占するよりも、みんなで広く共有し、 集合知によってさらに改善されていった方がいいはずです。