開発チームのライターが開発の上流に入るには

私がkintoneヘルプの担当になったのは2017年6月ごろからで、産休に入る同僚から引き継ぎました。
いろんなことを引き継いでくれた同僚が話していた中で
「開発の上流から入りたかった」
という言葉が忘れられません。

同僚は、開発メンバー内と交流を増やし、ヘルプ担当としてできる限り上流から加わろうとしていました。でも、志半ばでお休みに入ることになってしまった。
開発が全部終わった後に待ち受けてヘルプを書かないで、もっと上流から加わりたい、というのは、常日頃私も感じていたことで、その言葉に深く頷きました。

エンジニアではないライターという立場で、開発の上流から入るってどういうことなんだろう？

PMが要件定義、設計する上流工程があり、そこからエンジニアの実装、試験と流れて、リリースが下流。それが一般的な製品開発の流れです。川が上流から海に広がっていく、というイメージ。
ヘルプを書くライターは、一般的に開発後にその機能を反映する作業をするので、下流で待ち受けていることが通常です。

担当する業務の幅を広げる

ライターが上流から入るには、まず「担当する業務の幅を広げる」ことが大事かな、と私は考えています。ヘルプだけを書いていても、なかなか上流から顔を出すって、難しいものです。開発の途中経過あたりからJoinすることはできても、どうしても限度があります。

2017年当時、ヘルプ担当と、製品文言を決める担当は、きっちり分かれていました。私はずーっと、製品の中に入る文言を考えてみたい、と切望していました。UXライティングに非常に興味があったことと、文言とヘルプを連動して担当したほうが、相互作用でよいものが書ける。ずっとそう思っていて、当時の上司にも言い続けていました。

kintoneヘルプ担当になって数か月たったころ、いろんなタイミングが重なって、製品文言も担当することになりました。それはもう、ものすごく嬉しかったです。文言担当になったのと合わせて、ちょうどヘルプの改善も進み始めたころで、さあ今だ！と思って開発チーム内に座席を移動しました。よし、上流に食い込んでいくぞー！！
･･････って意気込んでいたのもつかの間、文言を担当し始めて2，3か月で、そんな都合よくはいかないと打ちのめされることになりますw

当時の開発フローでは、エンジニアが開発中に仮文言で実装をして、開発のお披露目をするスプリントレビューでは、その仮文言状態でデモが行われていました。その後、文言管理アプリにばばーっと数十個の文言がある日突然登録されてきます。通知を見て「何の機能の文言かな」と、ようやく機能の詳細を確認します。そこから手直しをして、プロダクトマネージャー（PM）にレビュー依頼して、せかせかと文言をFIXさせていました。
ヘルプよりほんのちょっと早いタイミングではあるけど、結局「待ち受けて手直しする」という受け身のタスク状態なのかーと残念な気持ち。
それでも、文言を担当できることはそりゃあもう嬉しくて、かつまだ全く慣れていなかったこともあり、「わ、また文言アプリにたくさん登録された！急いで確認してPMレビュー依頼しなくちゃ」みたいな日々を送っていました。

一方、PMはPMで、スプリントレビューに仮文言の状態でデモすることを変えたいな、と思っていたようでした。文言を決めるタイミングを早くしたい、というPMの意向を聞いて、私も共感しつつ、何をどうしたらいいのかは全くわかりませんでした。

変わるきっかけ

ある日の業後、PMが席に来てくれて、また「文言を決めるタイミングを変えたい」という話になりました。最初は文言の話をしていたのに、途中で私は
「もっと最初の段階から開発に入りたい・・・」
と、自分の業務全体のことについて、ぽつりと気持ちを吐露していました。
当時、私は1人でヘルプと文言とリリースノートを担当していて、かつ他製品のそれらも担当していて、とにかくリリースタスクに追われて極限まで忙しい状態でした。現状を変えたいと思っても、その改善策を落ち着いて考える時間も余裕も全くありません。PMも、そのことをよくわかってくれていました。

私の発言を聞いたPMは、「タスクの強弱をつけること。それができないなら分担すること」とアドバイスしてくれたうえで、開発チーム全体の流れを説明してくれました。誰がどの段階でどういうことをやっていて、どんな情報をキャッチしているか。
そのうえで、どこだったら私が入っていけそうか。「最初」というのもいろんなタイミングがあるので、どこの「最初」なのか。
1.UXリサーチャーがリサーチをする段階から加わってみる
2.デザイナーがデザインを考える段階で近くまで行って文言を提案してみる
3.エンジニアが実装するときに合わせて文言を検討する
この3パターンが考えられるかな、という提案をしてくれました。
「1」は非常に興味深いけど難易度が高くて、当時その時間もさけそうになく。
「2」は他社でも聞くパターンで試してみたいけど、私がデザイナーの元へ行くことで、デザインの仕上がりが遅くなるのではないかという懸念。そしてタイミングを見計らうのが難しい。
そこへいくと「3」は現実的で、関わりのないエンジニアとも仲良くなりたいし、ぜひやってみたい！と思えたのでした。

上流から関わるなら、スクラムのイベントにももっと参加したほうがいいね、という話になってきました。ただし文言のためだけにスクラムイベントにフルで参加するのはアウトプットに対してコストが見合わない。そこで大事になってくるのが「ヘルプ」です。
文言とヘルプはタスクを行うタイミングが違うけど、開発の最初の段階から仕様を理解していけば、どちらもスムーズにライティングできる。この2つのタスクをスムーズに行うために、開発の上流にJoinする！というストーリー。これは非常に納得感があって、わくわくしました。
その日、約1時間半という貴重な時間を割いて話を聞いてくれたこと、具体的な提案をしてくれたこと、PMにはとっても感謝しています。

その後、要件の工数を見積もるリファインメントというスクライムイベントにまずは参加するようにしました。
当時kintoneチームには専任スクラムマスターがいたのですが、リファインメントにでるようになって少し経った頃、「文言検討のタイミングを変えたい」と改めてPMと一緒に相談しました。現状のフローを紙に書いて洗い出し、どこを削ると改善できそうかを複数人で一緒に考えました。そこでようやく「スプリント中、エンジニアと一緒に文言を検討する」という開発フローが正式に決定となったのです。
正直、最初はエンジニアの方々の戸惑いが感じられましたが。。

実際に変更となった文言フローを試してみると、一緒に検討するのではなく「大石さん、この画面の文言を検討してください」という依頼がエンジニアから来て、スプリント中に文言を決めて提出し、実装してもらう。そんなやり方が定番になりました。
それでも、ある日突然まとまって文言が登録されて追われるように検討していた時に比べたら、1つ1つの機能を理解しながら細かく文言検討できるようになったし、仕様でわからないことはエンジニアに質問するようになったし、文言フローはずーっとスムーズになりました。細かく決めて細かく実装。文言もアジャイルに！
スプリントレビューでも、きれいな日本語文言でお披露目できるように！

また、上流から入るなら、なんとか自分の時間をもっと作ろう、本気出して自分のタスクを分散させようと決意。それまで以上に上司などに掛け合い、他製品のタスクを手放し、kintoneに集中できるようにしました。

2年たって

このやり方で2年がたち、最近は要件によってはまさに「エンジニアと一緒にモブで文言検討をする」「仕様の理解のために、エンジニアのモブに参加する」ということができるようになってきました。
まさに2年前「開発の上流から入りたい」と願っていたことが、少しずつ少しずつではありますが、できてきている。それが実感できて、とても嬉しいです。

とはいえ、まだまだ道の途中です。
私がkintone開発チームのライターとなってからの日々は、常に業務改善の繰り返しでした。よい文言を考えるためには、よいドキュメントを書くためには、そして自分がライターとして伸びていくためには、どの段階でタスクを行うのが良いのだろう？どうしたらもっと良くなるのだろう？
そんな自問自答の繰り返し。
そして業務改善について考えることそのものが、kintoneという製品を考えることにもつながるのかな、とも思っています。