Cybozu Inside Out | サイボウズエンジニアのブログ

 

プロダクトのヘルプサイトをマークダウンに移行した話

こんにちは!開発部テクニカルコミュニケーショングループの仲田です。

皆さんマークダウン使ってますか?(唐突)
文書記法の一つで、プログラマーにとっては馴染みがあるものだと思います。サイボウズのプロダクト仕様書もマークダウンで書かれることが多くなっています。

ですが、公式ドキュメントを作る用途として採用される例はまだ少ないように思います。数ヶ月前になりますが、プロダクトのヘルプサイトをマークダウンに移行しましたので、今回はその話をします。

なぜ移行したのか

マークダウンに移行した動機は、一言で言うとヘルプサイトの制作や更新を効率化するためです。

サイボウズでは、プロダクトのアジャイル開発化を進めています。アジャイル開発では、ウォーターフォール開発と比べてリリース間隔が短縮されます。パッケージ製品がメインだった頃には、リリースは年単位で、短くても数ヶ月ごとというスパンでした。ところが、クラウド製品がメインになり、アジャイル開発の導入も進むと、リリースが毎月、毎週と短期間に繰り返されるようになってきました。このことは、ヘルプサイトの制作、更新にかけられる時間が短くなることを意味します。プロダクトだけでなく、そのヘルプも短期間で制作、更新し、リリースすることが求められます。

また、アジャイル開発では、実際に動く画面や機能を作成し、フィードバックを得ながら計画を修正していきます。要件やリリース計画を随時見直していくため、プロダクトのヘルプ制作の計画にも変化が付いて回ります。仕様が確定するまで待っていては間に合いません。

このような背景から、ヘルプサイトの制作や更新を大幅に効率化する必要がありました。

移行前の問題

マークダウンに移行する前には、CMSに記事を入力してHTMLやCSSを生成する、Movable Typeのような仕組みのCMSを使っていました。

f:id:cybozuinsideout:20180919142608p:plain
移行前のCMS

このCMSを使っていて、次の問題がありました。

  • リリース計画の変更に弱い
  • 記事の差分管理に手間がかかる
  • 翻訳結果の取り込みに手間がかかる

それぞれ、どういうことかお話します。

リリース計画の変更に弱い

アジャイル開発では、リリースの頻度が多くなるため、ヘルプの更新は計画立てて進めていかなければなりません。リリースタイミングが異なる要件Aと要件Bを記事Aに反映する必要があれば、まず要件Aを反映し、要件Aがリリースされてから要件Bを反映する、というように、順序立てて進めていきます。ただでさえ短い制作期間がさらに短くなってしまうだけでなく、記事の管理も複雑です。

リリース計画の変更によって、要件Aのリリースが要件Bよりあとになったりすると、さらに状況は複雑化します。要件Aを反映した記事Aをいったん反映前の状態に戻して、要件Bを反映した上で、要件Bのリリースに合わせて公開します。その後また要件Aを反映し直して、要件Aのリリースに合わせて公開する、という作業が必要になります。

わかりづらい例かもしれませんが💧要するに、変化が多いアジャイル開発に対応するためにはヘルプの記事管理が複雑化する、ということがおわかりいただければ大丈夫です。このような記事管理を手動でやっていくのは辛いですよね。

サイトの差分管理

もう一つの問題は、記事の差分管理の手間です。ヘルプの記事を追加したり更新したりする際には、公開前にわかりやすさや正しさなどをチェックします。チェックを依頼するときには、どういう目的でどこを変えたのかをチェック担当者に伝える必要がありますが、それに地味に時間がかかっていました。ヘルプの制作を効率化するためには、このような作業は自動化すべきでしょう。

また、ヘルプの運用では記事の変更履歴を残していくことも必要になりますが、手動で記録していると大変です。これも自動化したいところです。

翻訳の効率化

サイボウズではプロダクトを海外展開しているため、ヘルプサイトの翻訳が必要になります。翻訳の際には、CMSから出力されたHTMLファイルを翻訳し、翻訳結果をCMSに再度取り込んでいました。

f:id:cybozuinsideout:20180919142703p:plain
翻訳したHTMLをCMSに取り込む作業が必要

この取り込みには多くの時間がかかっていました。翻訳されたHTMLをそのまま公開すればいいんじゃない?と思うかもしれませんが、販売地域ごとにヘルプの記述を書き分けるための処理をCMSで行う必要があるので、HTMLそのままの公開はできない事情がありました。

また、機械翻訳がHTMLに弱い問題がありました。ニューラル機械翻訳が登場し、近年は機械翻訳の精度が目覚ましく向上していますが、HTML文書をニューラル機械翻訳にかけると、一部のHTMLタグが消えて構造が壊れることがよくあります。ニューラル機械翻訳は文章の構文解析は行わないため、仕組み上このようなトラブルが多くなります。マークダウンのようにシンプルな形式のほうが、ニューラル機械翻訳との相性が良いようです。

マークダウンとは

上記のような問題の解決のため、ヘルプサイトをマークダウンに移行しました。マークダウンについて改めて解説すると、文書を記述するための軽量マークアップ言語の1つです。見出し、本文、箇条書き、表などの文章構造を簡単な記法で表現することができます。たとえば、次のような書き方ができます。

見出し:

# レベル1の見出し
## レベル2の見出し
### レベル3の見出し

箇条書き:

* 番号無し箇条書きの1つめの項目
* 番号無し箇条書きの2つめの項目

番号付き箇条書き:

1.  番号付き箇条書きの1つめの項目
1.  番号付き箇条書きの2つめの項目

上記のような記法を覚える必要がありますが、慣れるとリッチエディターより素早く文書を作れます。ツールを選ばず、テキストエディターさえあれば文書を作れることもメリットです。「Microsoft Visual Studio Code」など、HTMLに変換した表示をプレビューしながら文書を書ける高機能なエディターもあります。

静的サイトジェネレーター

マークダウンをHTMLに変換する「静的サイトジェネレーター」と呼ばれるツールがあります。多数のツールがあり、Jekyll、HUGO、Next、Gatsbyなどが人気のようです。

サイボウズでは、HUGOを使っています。HUGOはGo言語で作られていて、コンテンツが大量になっても高速にHTMLに変換できることが特長です。マークダウンでヘルプ記事を作る際には、リアルタイムにHTMLに変換して表示を確認しながら記事を書いていくので、HTMLへの変換速度は重要です。ヘルプサイトは大規模になるため、速度を重視しました。

ヘルプサイトでは、注意書き、補足やヒントなど標準のマークダウンにはない表現を多用します。HUGOにはマークダウンを拡張する機能があり、これらのスタイルを定義できます。また、サイボウズのヘルプサイトでは、販売地域ごとの記述の書き分けがありますが、このような拡張も実現できます。

マークダウンにするメリット

マークダウンで記事を作る最大のメリットは、GitやSubversionなどのバージョン管理システムで扱いやすいことにあります。マークダウンファイルはシンプルなテキストファイルなので、バージョン管理システムで記事を管理すれば、いつ、誰が、どのような目的で、どのように記事を変更したのかを記録できます。

マークダウンに移行することで、ヘルプ記事をGitHubで管理できるようにしました。GitHubで管理すれば、記事の差分をブランチ単位で管理できます。プロダクトの開発要件と紐づけてブランチを作っていくことで、どの要件のためにヘルプのどこを変更するのかを管理しやすくなりました。要件の実装が完了しリリースされたら、それとタイミングを合わせて、その要件に対応するブランチを公開サイトにマージします(下図)。要件のリリース計画に変更があった場合には、ブランチをマージするタイミングをずらすだけで済みます。リリース自体がキャンセルされた場合は、ブランチを破棄するだけです。

f:id:cybozuinsideout:20180919142742p:plain
GitHubの運用:プロダクトの開発要件と紐付けてブランチを作る

記事のクロスチェックには、GitHubのプルリクエスト機能を活用できます。プルリクエストは、変更したファイルの反映をリクエストする機能です。「こういう変更をしたので、問題なければ反映してください」という依頼を出すことができます。変更を反映する権限を持つ担当者が承認すると、変更が反映されます。

このプルリクエスト機能を使ったチェックでは、チェックの際に記事の変更点を見やすく表示してくれます。先述のとおり、プロダクトの開発要件と紐づけてブランチを作るので、チェックの際には、どの要件に対応するためにどの記事をどう変えたのかを把握でき、効率よくチェックできます。

さらに、マークダウンファイルはシンプルなテキストファイルなので、翻訳も簡単です。マークダウンファイルを翻訳し、翻訳されたファイルをGitHubに保存するだけで、翻訳結果の取り込みが完了します。

記事の中にコメントを書けるメリットもあります。ヘルプサイトを運用していると、プロダクト開発チームやカスタマーサポートチームなどから依頼を受けてヘルプサイトに説明を追記することもよくありますが、そのような経緯をコメントで書いておくことで、他の担当者や後任の担当者に共有できます。

システム構成

移行後のヘルプサイト管理システムの全体像が下図です。

f:id:cybozuinsideout:20180919143433p:plain
移行後のヘルプサイト管理システム

ライターはマークダウンで記事を書き、GitHubに投稿します。先述のプルリクエスト機能を使って、書いた記事の公開をリクエストします。チェック担当者によって承認されたマークダウンファイルは、自動的にWebサーバーに展開され、HTMLに変換した上で公開されます。

同時に、マークダウンファイルは翻訳システムに取り込まれます。翻訳システムには、Memsourceを使っています。Memsourceで翻訳が完了すると、翻訳されたマークダウンファイルが出力され、GitHubに取り込まれます。日本語のマークダウンファイルと同様に、他国語のマークダウンファイルもWebサーバーに自動的に展開され、HTMLに変換した上で公開されます。

現在は、記事のチェックのところをさらに効率化すべく、自動化を進めています。文章のてにおはだけでなく、翻訳しやすい文章になっているかについても自動校正することで、翻訳の工程も合わせて高速化することを狙っています。

おわりに

今回は、ヘルプサイトをマークダウンに移行した経緯と、そのメリットについてお話しました。GitHubを使ったヘルプサイト管理では、ブランチの運用が肝になりますので、次回はそのあたりを書いてみようと思います。

もちろん、まだ課題もあります。大きな課題としては、拡張を加えたマークダウンファイルが翻訳システム(Memsource)にうまく取り込まれないことがあり、対処中です。Memsourceはマークダウン形式のファイルに対応しているのですが、先述のとおりサイボウズではマークダウンに独自の拡張を加えているため、それが影響してうまく取り込まれないことがあるようです。多国語展開するドキュメントをマークダウンで制作する場合、他社でも起こるトラブルだと思いますので、解決できたら共有していければと思ってます。

 

モブ英作文と、異文化間コミュニケーション改善活動の話

こんにちは。東京品質保証部の臼井です。

日本国外にも上海(中国)とホーチミン市(ベトナム)に開発拠点を持つサイボウズ。エンジニアの日々の業務にも英語が必須…とまではいきませんが、英語が使えたほうが便利な場面に遭遇することは多々あります。今回は、そんなサイボウズ エンジニアの英語学習を支援する「モブ英作文」の取り組みと、異文化間コミュニケーションの改善を目指すコミュニケーションエンジニアリングチームの活動をご紹介します。

モブ英作文とは

名前から想像がつくかと思いますが、モブプログラミングに倣ってみんなでわいわいしながら英語の文章を書いていくという取り組みです。モブ英作文では最初に書き手がお題(書きたい内容)を口頭で他の参加者に説明してから、画面をモニター上に投影して書いていきます。他の人たちは書かれた文を見て、修正したい点を提案します。

作文するためのツールはふつうのテキストエディタでも何でもかまわないのですが、サイボウズでは自社製品であるkintoneのアプリをよく使っています。

f:id:cybozuinsideout:20180914114005p:plain

適当なところで一度保存してはまた加筆修正して、参加者全員が「もう直すところないよね」と合意できるまで繰り返します(上の例では、画面上から下へ①~④の順で修正が進んだ状態になっています)。このようにするのは、作成途中の状態を残すことで思考の過程を追えるようにするためです。

サイボウズではモブ英作文が学習目的で行われることが多いためにこのようになっていますが、業務で使う文章を書くなど、最終的に作文ができあがればそれでいい(お勉強はいらない)という場合はわざわざこのようにする必要はないでしょう。

効果

通常は参加者の間で英語力に多少なりともばらつきがあり、知っている(思い出せる)語彙や文法事項にも違いがあるので、各自が得意分野や知識を生かして他の人の苦手を補うことができます。疑問や質問があれば周りの人にすぐに相談しやすい雰囲気になっているのも利点の一つです。

一方で、人を集めて話し合いながら進めるという特性上、一人で書くよりも時間がかかる傾向があります。一人だと辞書を引いたり考え込んだりする時間が長い、という人なら、それほどデメリットにはならないでしょう。

進め方や注意点など

モブ英作文を進めるにあたって気をつけている点の一部を以下に説明します。このあたりは、作文の目的(業務で使うのか、練習としてやるのか)や参加者のスキルなどに応じて変わってくることもあります。

1. 日本語で下書きしない

これは翻訳になってしまうことを防ぐためです。一般に、翻訳には作文よりも高度な英語力が要求されます。慣れていない人がやろうとすると、翻訳元の日本語に振り回されて不自然な英語を書いてしまうことが多いです。

他にも、日本語で文章を書いてから英訳しようとすると

  • 概念的に英語にしにくい表現や、日本文化に深く結びついた語が入り込んでくる
    • 例: 「せっかくなので」「お盆休み」
  • 遠回しになる
    • 例: 「できないこともない」「ちょっとどうかと」「誤りという理解で正しいでしょうか」
  • 行間を読ませる書き方になる

といった現象が生じやすく、補足を追加したり、意訳したりする羽目になることもしばしば。

日本語を書くにしても、あとで英語に訳すなら訳しやすさを考慮しないといけないというわけですね。また、エンジニアの業務では日本語版と英語版の両方が必要になるのではなく、英語だけあればよいというケースのほうが多いので、日本語で文章を書いてもたいていはすぐに捨てる(だったら最初から英語で書けばいい!)という結果になります。

業務で日常的に翻訳をしているような英語力の高い人たちばかりが集まるなら「モブ翻訳」もよいかもしれません。

2. すぐにわからないところは置いておく

上掲のスクリーンショットにもあるように、すぐに単語が思い浮かばない箇所には日本語の単語を仮置きして後回しにします。内容が複雑な場合、下のように単語よりももっと大きい句や節といった単位にABCなどの記号を当てはめておくこともあります。

f:id:cybozuinsideout:20180913145433p:plain

英語が苦手な人ほど細かい部分を気にしすぎて「木を見て森を見ず」になってしまいがちなので、まずは文章全体の構成を設計することに意識を向けられるように、こういった方法をとっています。

文章構成としては "PREP" を推奨しています。PREPとは

  • Point (要点)
  • Reason (理由)
  • Example (例示)
  • Point (要点)

の順番で書く技法のことで、その構成要素の頭文字をとってこう呼ばれます。日本語話者が作文すると、どうしても背景情報を先、要点を最後にしてしまいがちですが、そういった癖を直す意味でもこの技法は役に立ちます。

3. 完璧を目指さない

サイボウズのモブ英作文で扱うのはお客様にお出しする文書ではありませんし、書き手も読み手も非ネイティブなので、多少おかしなところが残っていても仕方がないと割り切ります。一人で書く場合よりも読みやすくなっているな、と思えれば十分でしょう。

この点はプログラムの試験とも似ていまして、問題の検出と修正を繰り返せば繰り返すほど、新しい問題が見つかる確率は小さくなっていきます。費やすコストに対して得られるメリットが次第に減っていくので、やりすぎにならないよう合理的な範囲で実施する必要があるというわけです。

コミュニケーションエンジニアリングチームとは?

今回紹介したモブ英作文をはじめとして、サイボウズの各国拠点間の言葉の壁・文化の壁を乗り越えるためのサポートをするチームです。

コミュニケーションエンジニアリングチームが実施する異文化間コミュニケーション改善活動には "Project Cenote" というコードネームがつけられています。"Cenote" はメキシコのユカタン半島に見られる地下水脈の上が陥没してできた泉のことですが、これに壁を壊すイメージと "Communication Engineering (Not Only Translation and English)" の頭文字を結び付けました。その由来の通り、英語や翻訳だけにとらわれずにコミュニケーションの改善に向けて幅広いアプローチを目指しています(と言っても、やはり英語関連は多いですが)。

今までの活動は

  • 「QAで使える英語」「誤解されにくい日本語の書き方」「ベトナム語入門」など、語学系の勉強会の企画・開催
  • 日本・中国・ベトナムの各国の文化に関する勉強会の企画・開催
  • 開発系メンバーが日常業務で必要とするちょっとした翻訳や、英作文の添削

などです。勉強会の開催は、ミネルヴァチームからの強力な支援を受けています。

blog.cybozu.io

そして最後に重要なことですが、このコミュニケーションエンジニアリングチームには今のところ私一人しかいません。そこで!

We're hiring!

今回の記事を読んで、異文化間コミュニケーション改善活動に興味を持った方はぜひ弊社採用ページをチェックしてみてください。

募集要項/エントリー | サイボウズ 採用情報(新卒・キャリア)

コミュニケーションエンジニアリングは品質保証部のもとで活動していますが、製品の試験をしているわけではないので、採用の判断基準は製品担当のQAエンジニアとは多少異なります。このあたりも近いうちに募集要項に反映させていきたいと考えています。

もちろん、製品担当QAエンジニアとしてサイボウズで働きたいという方もお待ちしています。海外拠点との業務で困ったことが発生したときには、コミュニケーションエンジニアリングチームが精いっぱいサポートさせていただきます。

 

QAに配属されて1ヶ月経った話

はじめまして、8月に品質保証部に配属された新人の大塚と田村です! 本記事では、配属されたばかりの私たちがこの1カ月を振り返ってディスカッションをしてみました。

品質保証部の新人2人

自己紹介

田村 ななみ

Slash QAに配属。趣味は観劇。
Slash:cybozu.com共通管理(ユーザ管理やセキュリティ設定の機能)を開発しているチーム

大塚 純平

PSIRTに配属。好きな攻撃はパスワードスプレー攻撃
PSIRT:サイボウズ製品のセキュリティ品質向上のために活動しているチーム

品質保証部がどのような役割を担っているのかについては、こちらの記事が参考になると思います。 blog.cybozu.io

最初の1カ月で何をやった?

大塚:
配属されて1カ月が経ちましたが、これまでに何をやりましたか?

田村:
私はチームで必要な知識を身に着けているところです。 メンターさんに用意していただいた研修タスクアプリに沿って進めています。 具体的には今後使うツールの使い方を学んだり、製品の機能に慣れるための課題をやったりしてます。

大塚:
製品には慣れましたか?

田村:
少しずつですね。 私はcybozu.com共通管理の画面を今まであまり触ったことがなかったので、初めはどのような機能があるのか知りませんでした。 マニュアルに沿って一通り操作をしてみて、その機能をまとめるという課題に取り組んで、製品への理解を深めることができてきたと感じています。 その中でいろいろな方にお世話になりました。

大塚:
チームメンバーの印象はどうですか?

田村:
とっても優しいです。 分からないことがあったとき、質問すると素早く対応してくれます。 先輩社員さんとコミュニケーションの時間がたくさんあるので安心感があります。 毎日朝と夕方のミーティングの時間に気軽に質問することもできますし、 メンターさんがいらっしゃらないときは質問箱のアプリに登録することもあります。 Slackを使って海外拠点のメンバーに質問もします。

大塚:
海外拠点の方ともやり取りがあるんですね。

田村:
そうなんです。週に一度テレビ会議システムを使って海外拠点の方とリモートで打ち合わせをしています。

大塚:
打ち合わせへの参加もしているんですね。

田村:
しています。でも参加しても内容が追えないこともありますね……。

大塚:
それは僕も同じです。何の話をしているのかわからないことありますよね。

田村:
そうですよね。初めは知らない単語ばっかりだったので、打ち合わせの後に毎回質問していました。 メンターさんは基本的なことでも丁寧に説明してくれますし、難しい内容を含む打ち合わせに参加するときは事前に説明を受けることもあります。

大塚:
実業務への参加はしていますか?

田村:
少しずつ参加しています。今後リリースするバージョンの試験を一部担当しているので、今取り組んでいるところです。

大塚:
やっていて何か苦労などはありますか?

田村:
製品知識がまだ少ないので手順がわからず困ることがあります。 初めてのことばかりなので慣れるまでは簡単なことにも時間がかかったり作業が止まったりしてしまいます。 ただ、そういうとき周りの方が快く助けてくれるので、不安はあまりないです。

大塚君はPSIRTでこれまで何をやりましたか?

大塚:
製品理解を深めるために、パッケージ版の製品をインストールしたり、クラウド版のkintone, Garoon, メールワイズの簡易試験をしたりしました。 また、メンターの方から1日1~2時間くらい業務内容の説明を受けています。

田村:
例えばどんなことを教わっているんですか?

大塚:
PSIRTの業務内容についての説明です。 PSIRTは意外とたくさん業務があって、そのやり方を説明してもらっています。 聞いているだけだとわからないので、メンターの方と一緒に実際に業務をしながら学んでいます。

田村:
今後はどのようなことをするんですか?

大塚:
僕は9月からkintoneの担当として少しずつ業務に取り組んでいく予定です。

インターンに参加してどうだった?

cybozu.co.jp

大塚:
研修の一環として、8月のサマーインターンにインターン生として参加しましたね、どうでしたか?

田村:
もともとQAを体験したことのない人を対象にしているので、とても説明が丁寧でした。 今までの研修で自分がやってきたことが自己流であったことや、インターン生の成果物を見て人それぞれ違うことに気づくことができました。

大塚:
もし、学生時代に戻ったらインターンに参加したいですか?

田村:
そうですね、余力があれば参加したいです。大塚君は、学生時代もサイボウズのインターンに参加してたんですよね?

大塚:
僕は2年前のインターンに参加していました。

田村:
今回も参加しようと思ったのはなぜですか?

大塚:
僕が参加したときから内容が変わっていると聞いていたので、どう変わっているのか知りたかったからです。

田村:
実際に参加してみてどうでした?

大塚:
内容もやり方も変わっていて、年々進化していますね。今回は、インターンのメンター側が準備をしているのも見ていましたが、インターン生に楽しんでもらおうと工夫されているなと感じました。

田村:
次回のインターンではメンターをやるようですね。

大塚:
そうなんです。準備段階からやっています。今回参加してくれているインターン生が2年後には一緒に働いているかもしれないんですよね。実際に、配属されてからは、2年前に参加したインターンでメンターをしてくださった方の隣で仕事をしています。そう考えると当時のことを思い出して感慨深いものがありますね。

ミネルヴァの勉強会はどう?

blog.cybozu.io

大塚:
配属されたチームでの研修とは別に、ミネルヴァチームが主催している品質保証部としての新人研修もありますよね。 テスト技法や不具合管理の方法の講義などを受けました。 ミネルヴァの勉強会に参加した感想はありますか?

田村:
研修が整っているなと感じました。 研修内容がすごく考えられていると感じています。

大塚:
どういうとき、そう感じましたか?

田村:
品質保証部の様々なチームに所属している社員さんが講師としてそれぞれ専門の分野について教えてくれて、とても勉強になります。 今まで話したことがなかった社員さんと話す機会にもなるのが私は嬉しいです。 この分野はこの方に聞けばいいんだということを知ることができます。

大塚:
確かに。勉強会を機に今まで話したことない先輩社員とも関わりを持てるっていうのはとても貴重ですね。 今後仕事をしていく上でも活きてくると思います。

田村:
わからないところをkintoneの分報スレッド(作業内容や思っていることを自由につぶやく場所)に書き込むと、それを見た先輩社員の方が教えてくれるなどフォローが手厚くてありがたいです。

大塚:
途中で僕たちの困っていることとか、やりたいことを拾ってくれて、その先の研修に反映させてくれるのもありがたいですね。

田村:
本当に新人に対する教育体制が整っているなと思います。 

大塚:
新人以外も対象にしている勉強会もたくさん開催されていて、品質保証部全体の教育体制が整っているんですね。

配属された感想は?

大塚:
QAに配属されてどうでしたか?

田村:
配属されて良かったといつも思っています。 私はもともとITの知識も少なく、QAとしての経験も全くなかったですが、周りの人が親切なので安心して働くことができています。 毎日が楽しくて充実しています。 もともと、楽しく働ける社会人になりたかったので、理想の社会人生活が送れている気がして嬉しいです。

大塚君はPSIRTに配属されてどうですか?

大塚:
配属されてよかったなと思っています。 実は、配属先の希望をPSIRTかセキュリティ室のどちらに出すか悩みました。 配属面談の前に各部署の人に話を聞いて、最終的にPSIRTを選びました。

田村:
なぜPSIRTを選んだんですか?

大塚:
セキュリティ室の業務内容は大学で学んできた内容に近いですが、サイボウズに入ったからにはサイボウズの製品に関わりたいという思いが強かったからです。

田村:
その選択は正解だったと思いますか?

大塚:
配属前に戻ったとしてもPSIRTを希望します。 僕は学生の頃からセキュリティをやりたいと思っていたので、今こうして実際にやりたいことをできていることが感慨深いです。 特に僕の場合は人との巡り合わせと運がよかったんだと思います。 多くの方と関わって今ここでやりたいことができていることに、感謝です 。

今後の目標は?

田村:
私は今はまだまだですが、QAとして戦力になりたいと思っています。 自分の意見をちゃんと言えるようになりたいです。 業務を改善していくところにも興味があります。

大塚:
サイボウズはいろいろなことに挑戦ができる環境なので、どんどん挑戦していきたいです。 やったことがないことなのに逃げてやらないとかはしたくないと思っています。 今年は海外のカンファレンスにも参加しますし、それ以外でも自分が挑戦する機会があれば積極的に取り組みたいです!

田村:
1年目から海外出張にいくんですね。楽しみですか?

大塚:
やっぱり新しいことに挑戦するのは楽しみですね!頑張ります!

まとめ

  • 配属されたチームでの研修、ミネルヴァの研修がどちらも手厚くて安心
  • インターンに参加するという経験もできる
  • いろいろな挑戦ができる環境がある
  • 品質保証部に配属されてよかった!

最後に

このように品質保証部は新人も安心して成長でき、やりたいことに挑戦できる環境があります。
本記事を通じてサイボウズの品質保証部に興味を持った方は是非こちらをチェックしてみてください!

www.wantedly.com

 

業務利用しているOSSの休日個人開発は業務か?

こんにちは、OSS推進室長の岡田(@y_okady)です。 先日公開したOSSポリシーについて、たくさんのご意見をいただきました。ありがとうございます!

その中の一つに、労務管理上の懸念についてのご指摘がありました。上長からの指示がなくても、業務利用しているOSSの休日個人開発は業務にあたるのではないか、というものです。

これについて、社員のオープンソース活動を支援する役割を担う「OSS推進室(OSPO)」で話し合って見解をまとめたのでご紹介したいと思います。

技術系イベントへの参加は業務か?

OSSの休日個人開発の話をする前に、技術系イベントへの参加について考えてみます。

サイボウズでは、業務に役立つ技術系イベントへの業務としての参加を推奨しています。イベントの規模は問わず、小規模な勉強会でも大規模なカンファレンスでも業務として参加可能です。業務として参加する場合、交通費や参加費を支給します。休日に参加する場合は休日出勤になります。もちろん、業務外で参加したいということであれば業務としての参加を強制することはありません。

この方針を明確に打ち出したのは3年前ですが、それ以前も業務としての参加を禁止していたわけではありません。しかし、業務として参加したいと申し出る人はほとんどいませんでした。参加を指示されたわけではない、自分が参加したいだけのイベントに業務で参加してもいいなんて誰も思わなかったのでしょう。

社員の自主的な取り組みを会社としてサポートすることで、社員はスキルアップや学びの機会を増やすことができ、結果的に会社への貢献に繋がると考えてこのような方針を取っています。

技術書は経費で購入可能か?技術書を読むのは業務か?

技術書の購入もこの方針に基づいて、業務に役立つ技術書を(福利厚生費ではない)経費で購入することができます。たとえばRustの勉強をしたいエンジニアがいたとして、担当業務でRustを使っていなかったとしてもRust本を購入可能です。

経費で購入した物でも私物でも、業務に役立つ技術書は業務時間中に読むことができます。休日に読む場合は休日出勤になります。一方で、業務に役立つとしても技術書を読むのは業務ではない、なんの強制もなくカフェでコーヒーでも飲みながらのんびり読みたいんだ、と考える人もいます。技術系イベントへの参加と同様に、業務外でのんびりと読んでもらって構いません。

OSSの休日個人開発は業務か?

ようやく本題です。上長からの指示がなくても、業務利用している(業務に役立つ)OSSの休日個人開発は業務にあたります。ただし、技術系イベントへの参加や技術書の読書と同様に、業務としての開発を強制することはありません。

自分の好きなOSSを自分のペースで楽しく開発したいのであれば、業務外で開発する方がきっと幸せだと思います。

おわりに

サイボウズでは、社員の自主的な取り組みを会社としてサポートすることが、社員のスキルアップや学習に繋がると考えています。また、サポートは強制するものではなく、社員が望めばいつでも利用できるものでありたいと思っています。社員には、上長からの指示ではない自主的な取り組みであっても業務になり得ることを理解してもらった上で、業務とするかどうかを自身で判断できることを期待しています。

それでは、引き続きサイボウズのOSSポリシーへのご意見をお待ちしております!

 

サイボウズのオープンソースソフトウェアポリシーを紹介します

OSS準備室長を務めていた ymmt (@ymmt2005) です。 過去形なのは、OSS準備室は 7 月末で解散したためです。

OSS準備室では、サイボウズ社員がオープンソースソフトウェアに関する活動を行いやすくすることを主な目的として、会社の基本方針を「OSSポリシー」という文書にまとめる作業を行いました。

完成したOSSポリシーはCC0 (いかなる権利も保有しない、いわゆるパブリックドメイン)で広く他の企業の方々にも活用いただけるよう以下で公開しました。本記事ではその内容と、サイボウズにおけるオープンソース活動のこれまでとこれからを紹介いたします。

オープンソースについて

オープンソースソフトウェア(Open Source Software, OSS)とは、オープンソースの定義に基くライセンスで利用可能なソフトウェアのことです。オープンソースの定義(The Open Source Definition, OSD)は http://www.opensource.jp/osd/osd-japanese.html にて和訳が公開されています。短いものですのでぜひ一度目を通していただければと思います。

OSSの利用に際して大事なことは、問題が発生しても作者が解決してくれる保証はないということです。不具合や脆弱性は、基本的に利用者自身が解決する必要があります。有償でのサポートを提供している会社もあります。

OSSポリシー策定前の状況

昨今のソフトウェア開発でOSSを利用しないことはほとんどないと思います。当社ももちろん例外ではなく、kintone や cybozu.com のインフラでは数えきれないほどのOSSを活用しています。

利用に際して当然不具合をみつけたり自前で修正するということも良くあるのですが、会社としてこうしましょうという方針はなかったため、たとえば開発元に報告するといったことは各自の判断でされたりされなかったりしていました。

具体的に、当時のOSSに関する社内規程は以下二つしかありませんでした。

  • OSSの利用前にライセンスを確認する(そしてライセンス条件に従う)
  • 自社製のOSSを公開する際は所属部署の部長の許可を得る

そんななかでも、多くはありませんが以下のような活動をしていました。

OSS準備室について

OSSがここまで発展してきたのは、多くの人が様々な形でその開発に貢献してきたからに他なりません。 私達も多くのOSSを利用するにとどまらず、OSSの発展により寄与する存在でありたいと思います。

そこで社員のオープンソース活動を支援し、また貢献を促すようなOSSポリシーの策定を目的として、昨年12月に「OSS準備室」を設立しました。法務を含め、OSSに関係する各部門の代表者からなる部署横断の組織です。当時運用本部長だった私が起案し、責任者を務めました。

以下の成果をあげたのちに、後継組織である「OSS推進室(英語名称:Open Source Program Office, OSPO)」に業務を引き継いで 2018 年 7 月末を持って解散しました。

  • OSSポリシーを策定し、全社規程として起案(承認済み)
  • OSSポリシーを補完する細則にあたる「OSSガイドライン」の整備
  • 職務著作となる条件を大幅に制限(あとで解説します)
  • 他社の貢献者ライセンス同意書(CLA)の調査
  • 経営陣並びに社員向けにOSSポリシーとガイドラインの説明会を実施
  • OSSに関する専門組織「OSS推進室」を後継組織として起案

OSSポリシーの策定にあたっては、以下を参考にさせていただきました。

OSSポリシーの内容解説

公開しているOSSポリシーは、全社規程であるため取り扱う範囲を著作権、特許、商標のライセンスに限定しています。OSSに関する業務はライセンス関係以外に多々ありますが、それらは細則にあたる「OSSガイドライン」で取り扱っています。

前文

ポリシーを定める背景と目的を書いています。短いのでそのまま転記してしまいます。

本規程の第一の目的は、当社ならびに当社従業員が OSS 関連活動を過大な負担なく行えるよう支援することである。 そのために、当社、当社従業員または他者の著作権、特許権および商標権に関する事項を定める。

本規程の第二の目的は、当社がオープンソースコミュニティにおける良き一員であるために必要な規定を定めることである。 そのために、ライセンス違反への対応方針ならびに社員が発見した他者 OSS の不具合を報告する努力義務を定める。

注目いただきたいのは「社員が発見した他者 OSS の不具合を報告する努力義務」です。 サイボウズで働く社員は、利用しているOSSの不具合を発見したら開発元に報告するよう努めねばなりません。

著作権の帰属

会社の業務で作成した著作物は会社が著作者になります。正確には著作権法の職務著作の要件に該当する場合に限られますが、当社では入社時に以下のような誓約書に同意してもらっていました。

私がサイボウズでの業務遂行上、著作物を作成したときは、サイボウズの法人著作となる場合を除き、その著作権(著作権法第27条、第28条に規定する権利を含む)を別段の意思表示を要することなく、創作時にサイボウズに帰属させます。また、著作者人格権をサイボウズならびにいかなる第三者に対しても行使いたしません。

この規程そのままですと、例えば業務中に編集した .emacs.vimrc が会社のものということになってしまいます。また当社は働く時間も場所も非常に柔軟ですので一日のうちいつ業務をしているかが人によりばらばらで判断しづらい事情があります。

そこでOSS準備室で議論し、誓約書の内容を無効化し、会社に帰属する職務著作に該当する条件を以下のように絞りこむこととしました。

2.1. 当社の著作物 以下のいずれかに該当するものについては、その著作権が当社に帰属するものとする。

当社の極秘情報を含むもの
上長の明示的な指示または承認のもと作成されたもの

この規程により、「業務時間中であっても指示なく自発的に作ったソフトウェアは個人のもの」となります。 先述の .emacs はもちろん、自発的に書いたOSSのパッチも個人の著作物となるので、会社のルールに縛られません。

次に 2.2.2 の規程:

従業員が自己の所有する OSS プロダクトに対して自己が業務で作成した著作物を取り込む場合は、前項に定める手続きをしなくとも、当社から当該従業員に対し著作権が譲渡されたものとみなす。

これは個人で開発したOSSを業務で利用していて、業務中に必要な機能を追加することを想定した規程です。

指示された業務中に開発しているので会社の著作物が個人のOSSに混ざることになるわけですが、OSSであれば会社の著作物にしなくても誰でも利用できるわけですから、手続き不要で従業員に譲渡をしてしまおうというわけです。

従業員個人の著作物のオープンソース化および当社商標の使用

社員が自発的に当社製品に関する OSS を開発することがあります。

その際「kintone」や「サイボウズ」といった当社の商標を利用することが想定されるため、無用なトラブルを招かないよう注意する点を定めています。

当社著作物のオープンソース化

当社が管理する場所(github.com/cybozu 等)であれば、自由に作ったOSSを公開していいルールとしました。従来は所属部長の許可が必要だったのですが、まだ一行もコードを書く前に形式的に申請をするケースが多かったので、社員の良識を信じて承認不要としました。

利用しているOSSにパッチを送る場合、最近は貢献者ライセンス同意書(CLA)への署名を求めるところが多くあります。CLAは多くの場合英語の法律文書ですので、主要な CLA をあらかじめ法務にて分析し、「署名可能 CLA 一覧」を作成することにしました。

署名可能 CLA 一覧にある CLA であれば、従業員は自分の判断で署名が可能です。多くの場合上長の同意も求められるのですが、個々の開発者が自分の判断で上長欄に署名して良いのです。

他者 OSS の利用

他者の OSS を利用する場合、ライセンスを確認して使用条件に従うことを書いてあります。

また前文で触れたように、利用している OSS の不具合を発見した場合は開発元に報告する努力義務を定めています。

当社 OSS への他者著作物の取り込み

当社が所有する OSS に他者の著作物を取り込むルールを記載しています。

6.1 は当社の CLA への同意としていますが、まだ CLA は準備中であるため運用していない規程です。

6.2 ではパッチをいただいた開発者への謝意をこめて、CONTRIBUTORS 等のドキュメントに明記することを定めています。

ライセンス違反への対応

当社のOSSのライセンスに違反する利用を発見しても、60日以内なら訴えませんよとしています。

逆に当社内で違反があった場合、速やかに報告・是正することとしています。

OSSガイドラインの内容

OSSポリシーは全社規程ですので、具体的なことは書かれていません。 そのままでは社員が困ってしまいますので、詳細は「OSSガイドライン」にまとめています。

以下のような内容で構成されています。

  • 著作権や特許の基本
  • OSSライセンスの種類と使い分け
  • OSSにおける英語の使いかた
  • 署名可能 CLA 一覧
  • GitHub のリポジトリ管理

社内の事情が書かれているためすぐに公開はできないのですが、広く有用な部分はいずれ公開できると良いなと考えています。

OSS推進室(OSPO)について

OSS準備室の後継組織として常設の「OSS推進室 (OSPO)」を設置しました。 Open Source Program Office は Google や Microsoft も設置している、OSS活動に関する専門機関です。

詳しい説明は opensource.com の解説記事Linux Foundation の記事にあります。Google の OSPO は先述のように OSS 活動全般の方針をドキュメントで公開してくれています。Microsoft は github.com の管理などに利用できる、OSPO のためのツールを公開しています。

サイボウズの OSPO ではポリシーとガイドラインのメンテナンスに加え、社外のOSS組織への支援などに取り組んでいく予定です。

まとめと謝辞

OSSポリシーの策定にあたっては相当な期間と手間が必要でした。 当社と同じく、これからOSSポリシーを定めていかれる方が参考にしていただけるように、策定したOSSポリシーの全文を CC0 ライセンスで公開しています。ご活用いただければ幸いです。

また、ご覧いただきました通り当社は社員のオープンソース活動を公私にわたり支援しています。 OSSに理解のある企業をお探しの技術者の方は、是非当社も候補に入れていただければと思います。

末尾となりますが、OSSポリシーの策定にあたっては、奥一穂氏(@kazuho)ならびに当社技術顧問の小崎資広氏(@kosaki55tea)にご協力をいただきました。ここに感謝の意を表します。