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

 

OSSへの寄付のススメ ~ サイボウズのOSSへの寄付戦略

はじめに

こんにちは、OSS推進チームのsatです。本記事はサイボウズが5年間取り組んできたOSSへの寄付をする取り組みについて紹介します。具体的には寄付をする理由、どのようなポリシーで寄付額や各プロジェクトへの寄付額の配分をするのかについて共有します。

なぜ寄付をするのか

サイボウズでは様々なOSSを利用していることもあり、以前お伝えしたようにオープンソースソフトウェアポリシーというものを定めています。

blog.cybozu.io

cybozu-oss-policy.readthedocs.io

この文書の中で、次のような記述があります。

本規程の第二の目的は、当社がオープンソースコミュニティにおける良き一員であるために必要な規定を定めることである。

この「良き一員」となるためにOSSに貢献するには様々な方法があります。直接的にはバグ報告、修正、機能追加、ドキュメント追加などによって人的リソースを出して開発に参加することが考えらます。これ以外にも方法はたくさんあり、そのうちの一つが本記事のタイトルにもある、寄付です。人的リソースではなく金銭的リソースを提供する、というわけです。

OSSは無償で利用できるのですが、それは裏を返せばOSS開発者はユーザが得る利益の対価を受け取っていない場合があるということを示します。OSSといっても様々で、企業のバックアップを受けてリソースが潤沢にあるものもありますし、個人が無償で開発しているようなものもあります。後者のようなOSSは長期的に見ると安定した開発の継続は難しいでしょう。このようなOSSのユーザにとっては、対象OSSに依存していればいるほどシステムの安定運用を将来的に脅かすリスクが高まります。

OSS開発にリソースが足りないことによって発生する問題の良い例として、2014年に発生した世界中を震撼させたOpenSSLの脆弱性、Heartbleedがあります。

ja.wikipedia.org

この問題が発生した主な理由の一つにOpenSSLプロジェクトには開発リソースも人的リソースも足りていなかったということがあります。これを重く見た複数の大企業が協力してCore Infrastructure Initiative(現在の Open Source Security Foundation)を組織して、このような問題をなるべく発生しないようにという対策をとりました。

news.mynavi.jp

openssf.org

このような事例からわかるように、OSSの受益者であるユーザがリソースを提供することは非常に大事といえます。サイボウズにとっても事情は同じなので、前述のポリシーに基づいて様々なOSSに可能な限り貢献するようにしています。その貢献方法はさまざまで、開発に深く関与することもありますが、人的リソースは有限なので、それができないものについては後述するポリシーに基づいて寄付をするようにしています。

寄付額の決定方法

ひとくちに寄付をするといっても「寄付の総額」、「どのプロジェクトに寄付するか」、および「それぞれのプロジェクトへの配分」など、様々なことを決めなければいけません。本節ではサイボウズがどのようにこれらのことを決めているのかについて共有いたします。

まず最初に、これらのルールを決めるにあたって、とくに正解は存在しません。正解がないものについて最初から細かいルールを定めても機能しないだろうという考え方に基づいて、なるべくシンプルなルールにするように心がけました。また、OSS推進チームのメンバは全員が様々なチーム/プロジェクトから兼務として集まっている都合上、正解がないものにあれこれ悩んで膨大なコストをかけてるのは避けたいところです。

寄付の総額は現在は売り上げの0.05%にしています。なぜ利益ではなく売り上げなのかというと、利益が出ているかどうかにかかわらずOSSを使っていることには変わりがないので、利益よりも売り上げをベースとしました。0.05%というのも「このくらいの額なら事業継続に深刻な影響はないだろう」とエイヤで決めた額であって、複雑な計算に基づくような数値ではありません。

どのプロジェクトに寄付するかについては、OSSのユーザである社員たちから寄付先を募集した結果をもとに決めています。サイボウズが依存しているOSSは大量にありますが、ひとまずは直接のユーザである彼らが望むプロジェクトに寄付しようという考えに基づいています。寄付額は基本的に寄付先として決めたプロジェクト間で均等配分しています。2018年から現在までの寄付先は以下サイトの「寄付」節において公開されています。

tech.cybozu.io

杓子定規にこれらのルールを当てはめているわけではなく、社員が「ここにこれだけの寄付をしたい」という熱い思いを持っていた場合は、例外的に特定のプロジェクトに特定の額を寄付することもあります。

blog.cybozu.io

上述した現行のルールは穴がたくさんあることはもちろん承知していますが、まずは、とにかく「サイボウズがお世話になっているOSSに貢献する」という意思を示し、かつ、行動に移すのが重要であると考えています。また、これらのルールは永久にそのままというわけではなく、必要に応じて適宜修正していく予定です。

おわりに

本記事ではサイボウズのOSSへの寄付戦略について、なぜそうしたのかを含めて書きました。本記事がみなさまにOSSへの寄付についての重要さを認識していただく一助となるとともに、現在OSSに寄付しようとしている、あるいは寄付をしているかたがたに、何らかの参考になることを願います。また、これをきっかけにリソースが足りていないOSSの開発者が少しでも報われるようになることも願います。

 

最速でフロントエンドを刷新するための開発フロー

こんにちは、フロリアでQAエンジニアをやっている中園です。

現在サイボウズでは kintone のフロントエンドリアーキテクチャプロジェクト(フロリア)と称して、Closure Tools から React へと置き換えるプロジェクトが進行中です。

フロリアの詳細については 次の記事をご覧ください。

今回は、フロリアのチームの一つで、利用者に気づかれない形で React への置き換えを行っている Mira チーム1の開発・テストフローの紹介をします。

"最速で" React に置き換えたい

Mira チームはただ React に置き換えるのではなく「最速で React に置き換える」という目標があります。

フロリアの各チームはそれぞれのチームごとにオーナーシップを持っており、チームごとに意思決定を行っています。Mira チームでは「最速で置き換える」という目標に向かって、開発スピードを向上させるべく開発・テストのフローを最適なものにしようと試行錯誤を繰り返しています。

試行錯誤を繰り返すうちに、kintone の開発チームで行っていた開発・テストのフローとは異なる形になりました。

kintone の開発・テストフローについて

kintone の新規機能を開発をしているチームは、エンジニア・QA のスクラムチームが複数あり、一週間のスプリントで新しい機能の開発を行っています。

プロダクトバックログアイテム(PBI)の「完了」の定義は機能実装完了までとなっており、エンジニアの実装が完了したあとに随時 QA が PBI ごとに機能テストを行うフローになっています。

kintone新規開発チームの開発フロー

受け入れテストは自動化されていますが機能テストはすべて手動で行うため、テストが「完了」になるタイミングは PBI のボリュームによってバラつきがあります。

Mira チーム の開発・テストフローについて

フロリアではチームごとに独立した意思決定を行っています。チームがオーナーシップを持って独自のフローで開発とテストを行えることで改善が行いやすい体制になっています。週に一度の振り返りではエンジニア・QA・PO(プロダクトオーナー)のそれぞれの視点から改善点が出せており、その都度自分たちのチームに最適なフローに変えています。

次の図は Mira チームが現在行っている開発のフローです。

1 つの PBI を完了するまでの流れ

PBI の着手時、まず行うのはテストの設計です。QA が事前に用意したテスト仕様書をもとに、QA とエンジニアで設計を行います。テストはできるかぎり自動化する方針ですが、自動化が難しかったりコストがかかりそうなものは手動でテストを実施します。この PBI でどういったテストが必要になるのか、着手段階で QA とエンジニアの間で認識を揃えます。

実装フェーズでは、自動テストとしておもに Unit テストと Integration テストを同時に書いていきます。Mira チームでは Unit テストを「一つのコンポーネントに対してのテスト」、Integration テストを「複数のコンポーネントにまたがるテスト」としています。

機能の実装と自動テストを反復して繰り返し行うことで、より素早くフィードバックを得られます。開発はモブ・ソロのどちらかにこだわることなく、その時々に合った方法を用いています。

詳細な内容については、次の記事をご覧ください。

機能の実装と自動テストの実装が完了したのち、 QA は意図通りにテストが自動化されているかを確認するとともに、自動化できなかった部分の手動テストを行います。また、アクセシビリティやセキュリティのテストはそれを専門とする Design Technologist2 や PSIRT(Product Security Incident Response Team)のメンバーが行います。

Mira チーム では PBI の「完了」の定義に「テストの完了」を含めています。一週間のスプリントですべてを完了させる必要があるため、一つの PBI ができるだけ小さくなるようにしています。PBI を小さくすることで、扱う必要のある範囲が非常に小さくなり、実装・テストがしやすくなるという恩恵がありました。

Miraチームの開発フロー

不具合を見つけられるタイミングが早くなった

開発の段階から自動テストを書くことで実装に対してのフィードバックが早めに得られるようになり、不具合を見つけられるタイミングが早くなりました。

QA による手動テストを実施するタイミングで不具合がほとんど見つからなくなるほどの効果がありました。これによって手戻りが大きく減り、一週間という短期間のスプリントでもテストの完了を含めた PBI の完了が実現できています。

アクセシビリティやセキュリティのテストも同じスプリント内で行いますが、悩んだときには都度専門メンバーに相談できる体制があるので、ここでも手戻りを少なくできています。

実装とテストを短いスパンで繰り返していることからテスタビリティの高い実装ができているので、コードレベルでの保守性も上がっているように感じます。この開発・テストのフローになってから、エンジニアから「自動テストが充実しているので、コードのリファクタリングが怖くなくなった」という声もありました。

既存フローとの整合性が今後の課題

チームが独自のフローで開発を行えていることはよいことだと感じていますが、リアーキテクチャプロジェクトという性質上、置き換えの対象である kintone のデプロイやリリースのフローに合わせないといけない部分も出てきます。こういった点も考慮しながらより開発・テストがやりやすいフローを目指していきたいです。

まだ先の話になりますが、リアーキテクチャがすべて完了したあとの成果物や開発・テストのフローを、 kintone の新規開発チームとどう整合性をとっていくかは今後の課題になりそうです。

一緒に挑戦しませんか?

kintone のフロントエンドリアーキテクチャプロジェクト(フロリア)では、挑戦したいことや課題がまだまだあります。一緒に挑戦するメンバーを次のポジションで募集していますので、気になった方はぜひ応募してみてください。

cybozu.co.jp

cybozu.co.jp

 

スクラムチームで実践しているソロプロとモブプロを両立したスウォーミングの紹介

みなさんこんにちは。kintone フロントエンドリアーキテクチャプロジェクト(フロリア)で、エンジニア兼スクラムマスターとして活動している村田(@mys_x101)です。

現在、フロリアには兼務も含めて約 30 人のメンバーが参加しています。フロリアは小さな 4 つのクロスファンクショナルチーム体制で、それぞれが独立したスクラムチームとして活動しています。

今回はその中のひとつのチームである、サイレントリリースを部分的に試みているチーム(Mira チーム)で取り組んだ、ソロプログラミング(以下、ソロプロ)とモブプログラミング(以下、モブプロ)を両立したスウォーミングの実践事例を紹介します。

スウォーミングとは?

まずはスウォーミングという言葉について説明します。

Swarming を直訳すると「群れる」です。ソフトウェア開発の文脈では 1 つの問題やタスクを皆で群がって解決するという意味合いになります。

scrum.inc では次のように定義されていました。

スクラムにおけるスウォーミングの定義とは?スウォーミングは、できるだけ多くのチームメンバーが同じ優先項目で同時に作業可能なときに発生します。その 1 つの項目が完了するまで、彼らはその項目にだけ取り組みます。

What is the definition of swarming in scrum? Swarming occurs when as many team members as possible work simultaneously on the same priority item. And they work on just that one item until it is done.

引用:Swarming: How To Instantly Boost Your Scrum Team’s Productivity

実践しているスウォーミングの紹介

最も優先順位が高いタスクを最速で完了させることを目的に、Mira チームでは次のような流れでスウォーミングを実践しています。

1.スプリントの始めにプロダクトバックログアイテム(PBI)をスプリントバックログアイテム(SBI)に分割する。優先順位をつける。

1.を説明する図

2.優先順位の高い SBI から担当者を割り当てる。最も優先順位の高い SBI に着手している担当者がキャプテンになる。

2.を説明する図

3.基本的にソロプログラミングで SBI を完了させる。

3.を説明する図

4.キャプテンからのモブプロ・相談・レビュー依頼があれば、メンバーは着手中の作業を止めて最優先で対応する。誰もキャプテンの作業を邪魔してはならない。

4.を説明する図

5.キャプテンが担当している SBI が完了したら、次点で優先順位が高い SBI に着手している担当者がキャプテンになる。元々キャプテンになっていた担当者は次に優先順位の高い SBI に着手する。

5.を説明する図

6.例外として、キャプテンが担当している SBI より先に他の SBI が完了しそうなときはそちらを優先してレビューする。これはリリース可能になったものは最速でリリースし、在庫を抱えないようにするためである。

6.を説明する図

現在は 1 スプリント = 1 週間でスクラムを実践しています。朝会では SBI の進捗状況、優先順位、キャプテンを担当する人を確認しています。

スプリントの途中で追加でタスクが差し込まれた場合は、まずそのタスクの優先順位を決めて SBI を並べ替えています。スプリントで着手する SBI はすべて完了する前提の元(※実際には終わらないこともありますが)、最初に決めた SBI の優先順位は途中で入れ替わることを許容しています。ただし、優先順位の変更を頻繁に行うとすべての SBI の完了が全体的に後ろに倒れるため、優先順位の高い SBI はなるべく早く完了にして次の SBI に意識を向けるようにしています。

これらの流れをスプリントで繰り返し、すべての SBI の完了を目指して開発しています。

ここからはどのような流れで現在の開発フローになったのかを解説します。

モブプログラミングオンリーから徐々にソロプログラミングを併用するようになった

チーム結成時はフロントエンドの設計を話し合いながらコードに落とし込んでいく作業が大半を占めていたため、常にモブプロで開発を進めていました。しばらくの間はモププロが効果的だったのですが、大枠の設計が形になってくるとメンバー同士で相談することが徐々に減少し、「同期コミュニケーションの時間を減らして非同期で開発を進められるようにしたいね」という意見が出てくるようになりました。

スプリントで優先すべきは不確実性の高いタスクです。着手する SBI で不確実性の高いタスクが出てきた場合、必要に応じて群がって解決を試みるようにすれば並列で着手しても問題ないだろうと考えていました。スプリント単位で見れば PBI の粒度でスウォーミングできていることになるため、フロー効率を維持したままリソース効率を高められると考えていました。

このように、開発が進むにつれてチームメンバーは基本的にはソロプロで、適宜必要なタイミングでモブプロを実施できる開発フローを求めるようになりました。

ソロプロとモブプロを臨機応変に使い分ける方針にしたらリードタイムが伸びた

各々のメンバーが並行して開発を進められるように、次のルールを設定しました。

  • スプリントの開始時にスプリントで着手する PBI を 並列着手可能な単位で SBI に分解する。
  • SBI に担当者を割り当てる。
  • 必要に応じてモブプロを行う。

このルールに則って実践してみたところ、実装が完了するまでのリードタイムが伸びました。

Miraチームでは PBI の完了条件にテスト、アクセシビリティチェック、脆弱性検証を含んでいます。PBI 完了までの開発フローは次の記事をご覧ください。

blog.cybozu.io

スプリントの終了日間近にテスト、アクセシビリティチェック、脆弱性検証が集中すると、すべての項目を検証する時間が不足するため、スプリントの中盤にはいくつかの PBI の実装が終わっている状態が求められていました。しかし、実装の完了が全体的に後ろに倒れてしまったことでスプリント終了日間近に業務負荷が増加。PBI が完了できなくなる懸念が生じるようになりました。さらに、いずれかの工程で手戻りが発生した場合には、それを修正するための時間が足りず、PBI が完了にならない事態も発生するようになりました。これではベロシティは安定しません。

原因は、都度モブプロや相談、レビューが発生することによって、他のメンバーの開発がブロックされ、1 つ 1 つの SBI の完了が全体的に後ろに倒れたことだと考えられます。

割り込みでメンバーの開発がブロックされている様子

必要なタイミングでモブプロ、相談、レビューを行うと、他のメンバーのタスクを妨げることになり、実装の完了が全体的に後ろに倒れることが分かりました。スプリント終了日間近に慌ただしく PBI を完了していたチームメンバーは、このような経験を得て最も優先順位が高いタスクを妨げない開発フローを求めるようになりました。

群がるタイミングと対象の粒度について考える

基本的にはソロプロで、適宜必要なタイミングでモブプロを実施できる開発フローでは、必要に応じて闇雲に SBI に群がっていました。改善後のフローでは、必要に応じて最も優先順位が高い SBI に群がることを目指しました。

フローを考える上で参考になったのは Swarming: One-Piece Continuous Flow** に記載されていたキャプテンの仕組みです。

プロダクトバックログの 1 つの項目にチームの最大限の努力を集中させ、できるだけ早く完了させる。この項目を担当する人は、チームのキャプテンである。全員が可能な限りキャプテンを助けなければならず、誰もキャプテンを邪魔してはならない。キャプテンが Done になったらすぐに、次のバックログ項目に責任を持つ人がキャプテンになる。

Focus maximum team effort on one item in the Product Backlog and complete all known work as soon as possible. Whoever takes this item is Captain of the team. Everyone must help the Captain if they can and no one can interrupt the Captain. As soon as the Captain is Done, whoever takes responsibility for the next backlog item is Captain.

引用:Swarming: One-Piece Continuous Flow**

記事では PBI にキャプテンを割り当てていますが、我々のチームでは SBI にキャプテンを割り当てることにしました。群がる対象の粒度を考えると PBI は大きすぎると判断したことが理由です。PBI にキャプテンを割り当てるとサイズによってはスプリントの最初から最後まで同じ人がキャプテンを担当する懸念がありました。キャプテンは頻繁に交代したいと考えており、SBIのサイズは並列な可能な単位で細かく分割したものを用意しています。

また、チームとして最優先のタスクを最速で完了させるために、キャプテンからのモブプロ・相談・レビュー依頼に対して、メンバーは着手中の作業を止めて最優先で対応することにしました。全メンバーの招集をキャプテンの特権にすることで、最も優先順位の高い SBI に割り込みを発生させないようにする狙いがありました。

キャプテンの招集に応え、最優先のSBI(=キャプテンのタスク)を妨げなければメンバーのタスクの進め方は自由です。全メンバーを巻き込む必要のない簡単な相談はメンバー同士でその都度実施してもらっています。キャプテンの参加は任意です。

ただし、レビューが終わると完了になる SBI は例外としてキャプテンにも優先的にレビューをしてもらっています。これはリリース可能なものから逐次リリースし、在庫を抱えないようにするためです。

ルールをまとめると次のようになります。

  1. 優先順位が最も高い SBI の担当者がキャプテンになる
  2. キャプテンからのモブプロ・相談・レビュー依頼に対して、メンバーは着手中の作業を止めて最優先で対応する
  3. キャプテンが担当している SBI が完了したら、次点で優先順位が高い SBI に着手している担当者がキャプテンになる
  4. レビューが終わると完了になる SBI は優先的にレビューする

我々はこのルールをキャプテン制度と名付け運用することにしました。

キャプテン制度を運用して得られた効果

PBI がスプリントの中盤から完了するようになり、ベロシティが安定するようになりました。

PBIのDone積算傾向

開発メンバーからも肯定的な意見が見受けられました。

開発メンバーからのフィードバック

肯定的な意見が多かったですが、もちろん問題点もあります。招集権を持つ人(=キャプテン)が一人でタスクを抱えて手が止まってしまうと全体が遅延する点です。キャプテンは最速で SBI を完了させる責任を担っており、能動的にチームメンバーに頼る立ち振る舞いが求められます。ときにはメンバーからキャプテンに何か困っていることはないか様子を伺うことも重要です。チームの心理的安全性を高め、些細なことでも質問しやすい雰囲気を構築することがスウォーミング成功のカギとなります。

さいごに

今回はソロプロとモブプロを両立したスウォーミングの実践事例を紹介しました。

最も優先順位の高いタスクの担当者をキャプテンとし、周りのメンバーがキャプテンを全力で援助する体制を作ることで、基本的にソロプログラミングでもフロー効率が高い開発ができるようになりました。

チームによって PBI、SBI のサイズや、そもそもの開発の進め方が違うのでこのフローをそのまま適用させることは難しいと思いますが、開発フロー改善のきっかけや参考になる点があれば幸いです。

 

iOSアプリのためのログインフレームワークを1から作り直した話

モバイルチームのオジマです。

サイボウズでは複数のモバイルアプリをリリースしています。モバイルチームではログインを司る機能をフレームワークとして切り出し、製品を横断して利用しています。今回は、そのログインフレームワークの作り直しについて紹介します。

既存のログインフレームワークの問題点

はじめに、フレームワークを作り直す原因となった既存のログインフレームワークの主な問題点について説明します。

既存のログインフレームワークは以下に示す問題を抱えています。

  1. エラーのハンドリングが困難な設計になっている
  2. 処理の流れを追いづらい
  3. ログインとは直接関わりのない責務まで担っている
  4. テストやドキュメントが十分に書かれていない

それぞれについて詳しく見ていきます。

エラーのハンドリングが困難な設計になっている

既存のログインフレームワークでは、主なエラーを階層構造にした上で直積型で定義しているため利用者側でのハンドリングに多くの手間を要しました。適切なエラーの型を得るためには、階層を適切に深堀り、適切な型でキャストする必要がありました。 また、エラーがメソッドの戻り値として返却される場合と共有インスタンスから返却される場合の2種類あるという問題もありました。さらにメソッドの利用者はそのメソッドがエラーを返すのかどうかを静的に判断できませんでした(これは使用しているサードパーティーライブラリに起因する問題ですが)。

これらの問題により、フレームワークの利用者は1つ1つの処理ごとに注意深くエラーハンドリングを考える必要がありました。

処理の流れを追いづらい

ログイン処理は以下のような形で提供されていました。

loginModel.login()

これは一見すると利用者から見てログインの機能が隠蔽されていて使いやすいようにも思えるのですが、この1つの命令の中で2要素認証やパスワード再設定の処理など全てを一連の流れとして内包しているため、今どのような状態にあるのかを把握することが容易ではありませんでした。また、フレームワーク内部の実装はモデル同士が複雑に依存しており読みづらいものでした。

ログインとは直接関わりのない責務まで担っている

ログイン時に用いた認証情報をローカルストレージに保存する処理や、保存された認証情報のマイグレーションなども既存のログインフレームワークは担っていました。これらはログインと間接的に関わりのある機能ですが、ストレージへの保存方法や保存する際のフォーマットは製品の裁量で実装を決めたいことが多く、これらの処理を完全にフレームワーク内で隠蔽することは困難でした。それぞれの製品で使いやすいようにメンテナンスをしてきましたが、コストの高い作業でした。

テストやドキュメントが十分に書かれていない

テストやドキュメントの整備はあまりされていませんでした。ハッピーパスのテストもおおむね書かれておらず、ドキュメントが整備されていないので人づてに挙動を確認することも度々発生していました。

新しいフレームワークのコードポリシー

上記の問題を改善するために新しく作り直すフレームワークでは3つのコードポリシーを定めています。

  • 簡単なフレームワークではなくシンプルなフレームワークにする
  • フレームワークを利用するサンプルアプリを提供する
  • 十分なテストとドキュメントを書く

簡単なフレームワークではなくシンプルなフレームワークにする

このポリシーは問題点の1., 2., 3. を解決するために定めています。

ここでの簡単なフレームワークとは、内部構造を知らなくても1つのメソッドで完結する構成を表しています。一方でシンプルなフレームワークとは利用者から見てこのメソッドを叩けば何が起こるのかが明らかな構成を表しています。

既存のフレームワークのように1つの大きなメソッドによって全ての処理を行い、また全てのエラーを大きくまとめるのではなく、いくつかの単純な処理を組み合わせて利用することでログインを行うフレームワークにしました。これにより、処理の流れが把握しやすくなりエラーのハンドリングも容易になると考えました。また、ログインとは直接関係のない処理はフレームワークが担うのではなく、各製品ごとに実装する方針としました。

フレームワークを利用するサンプルアプリを提供する

これは前述のポリシーを補強するために定めています。

シンプルなフレームワークになっているかを実装と合わせて実際に利用してみることで確認し、より使いやすいフレームワークを目指しています。また、サンプルアプリはドキュメントと合わせてフレームワークの挙動や利用方法を確認することにも役立ちます。

十分なテストとドキュメントを書く

このポリシーにより4. の問題点を解消します。

技術選定

コードポリシーを意識しつつ技術選定を行いました。

  • テストフレームワークとしてXCTestを用いる
  • ドキュメントはDocCで記述する
  • サンプルアプリはSwiftUIで提供する
  • 非同期処理機構としてasync/awaitを用いる
  • Linuxでビルド可能にする

XCTest、DocCとSwiftUIはチームメンバーが無理なく理解でき、またAppleが提供しているため今後も長期的なサポートが期待できるという理由で選定しました。非同期処理機構とLinuxでのビルドはそれぞれ以下のような理由から決定しました。

非同期処理機構としてasync/awaitを用いる

ログインフレームワークでは、ログイン基盤であるサーバーとの通信を行うため非同期処理は必須な処理です。非同期処理機構として候補は3つありました。

  1. RxSwift
    kintoneモバイルで利用実績があるフレームワークです。

  2. Combine
    Office 新着通知で利用実績があるフレームワークです。

  3. async/await
    サイボウズのプロダクトで利用実績はありませんが、Swiftの言語機能として注目していました。

RxSwiftとCombineはそれぞれサイボウズのプロダクトで利用実績があるフレームワークでしたが、Swiftの言語機能として今後も安定したインターフェースが提供されることや最新の技術の知見を貯めるという観点から、今回はasync/awaitによる実装を行うことにしました。

Linuxでビルド可能にする

この方針は、主にCI環境の利用金額に依存した決定です。

現在モバイルチームでは複数のプロダクトでGithub Actionsを主なCI環境として利用しています。Github ActionsにおけるmacOSインスタンスとLinuxインスタンスの単位時間あたりの利用金額は10倍の差があります。利用金額に気を取られ書きたいテストが書けないという状況は避けなければなりません。

そのため、今回はできる限りLinuxでビルド可能なフレームワークとして開発することにしました。

作り直しを行った成果

作り直しを行った新しいログインフレームワークでは、ログインを以下の流れで行えるようになりました。

let sessionProtectionDetector = SessionProtectionDetector()
let protection: ProtectionMethod
do {
    protection = try await sessionProtectionDetector.detect(from: URL(string: "https://example.com")!)
} catch {
    ...
}

let credential: Credential
switch protection {
case .none:
    let authenticator = UsernamePasswordAuthenticator()
    credential = try! await authenticator.authenticate("username", and: "password")
case .clientCertificate:
    let authenticator = ...
    credential = ...
}

これまでのログインフレームワークでは1つの巨大なメソッドで表現されていた部分を、役割ごとにそれぞれ分けることで、利用者が処理の流れを追いやすいようになりました。また、メソッドごとにthrowsでエラーを返すようになったためエラーハンドリングも容易になりました。

さらに、ログイン以外の処理をフレームワークに含めず製品側での実装を必要とする形にしたため、フレームワークの機能追加や修正などを他製品と協調しながら行う必要がなくなりました。

今回の作り直しによってユニットテストやドキュメント、サンプルアプリを充実させたので、実際に製品に取り込む際の悩むポイントも改善されたのではないかと期待しています。

実装を通して得た学び

ドキュメントを書く大切さ

今回の作り直しでは、フレームワークを利用する際やフレームワーク自体のメンテナンスの際の手助けとなるために、ドキュメントの整備を心がけました。

コードと共にそれにまつわるドキュメントを書くことは、利用時やメンテナンス時のメリットはもちろんありますが、それ以外のコードを書くという視点でもよい効果があると感じました。ドキュメントが書きづらく自然言語で説明しづらい部分のコードは、変数名やデータ構造・アルゴリズムが最適ではないかもしれないとリファクタリングのきっかけになることが多くありました。ドキュメントをきっかけに行ったリファクタリングはおおむねよいものばかりだったと感じています。

今後は、フレームワーク以外のプロダクトコードでもドキュメントを書く試みを模索したいです。

Linuxビルドを担保する難しさ

技術選定の段階から、フレームワークをLinuxでビルド可能にすることを目標としていました。LinuxビルドとmacOSビルドの大きな違いはFoundationライブラリの実装差異です。macOSでビルドする場合、Objective-Cで実装されたFoundation(Cocoa Foundation)を利用しますが、LinuxビルドではCで実装されたFoundation(Core Foundation)を利用します。おおむね同等の機能が提供されていますが、いくつか利用できない機能も存在します。

Core Foundationを利用する上で、URLSessionのasync/awaitインターフェースがまだ実装されていないことや、クライアント証明書を利用したネットワーク通信をサポートしていないことは、今回の作り直しにおいて大きな障害でした。これらの障害はそれぞれasync/awaitインターフェースのextensionによる追加実装とクライアント証明書を利用したネットワーク通信のモック化により回避しましたが、解決に多くの時間を要してしまったのは反省点だと感じています。

まとめ

この記事では、モバイルチームで利用しているログインフレームワークの作り直しの取り組みについて紹介しました。今後は、新たに作ったログインフレームワークを各製品に取り込んでいき、使い心地を確認していく予定です。取り込む過程でより良いフレームワーク改善を進めていきたいと考えています。

 

ユーザーリサーチ勉強会:「ブレインストーミング」を学習する

こんにちは!モバイルチームの松元(@daikimat)です。

今回はモバイルチームとデザインチームの有志で行っているリサーチ勉強会の活動の中からブレインストーミング(以下ブレスト)について紹介します。

モバイルチームで活動している「リサーチ勉強会」についてですが、なぜこの勉強会を始めたかの経緯は、過去の記事にて紹介しておりますので、興味があればご参照ください。

blog.cybozu.io

ブレストはアイデアを引き出すフェーズで使用するもので、汎用的なスキルとなります。
私たちはIDEOのメソッドを参考にブレストの練習しました。 これは完璧なアイデアではなく、多くのアイデア、コラボレーション、突飛なアイデアへの解放を目指したメソッドです。 デザイン&リサーチチームの方に主導していただきブレストを練習した時のやり方を紹介します。

ブレストの基本ルール

最初に IDEO.org のブレストルールについて確認しました。
メソッドには次のようなルールが記載されています。詳細はIDEOのサイトを見てください。

  1. 判断は先延ばしにしよう
  2. 突飛なアイデアを歓迎しよう
  3. 他人のアイデアにアイデアを重ねよう
  4. アイデアをみじかい表現にまとめみよう
  5. 話すときは一度にひとり
  6. 視覚的に表現してみる
  7. 量を求めよう

私たちが定義した「参加者がやること」

上記のルールを参考にしつつ、私たちが追加で定義した「参加者がやること」を紹介します。

書記とファシリテーターを用意

今回、私たちは初めて IDEO.org のメソッドでブレストを行う状況で、 かつオフラインとリモートのハイブリット開催という状況でした。
書記とファシリテーターを用意し、より円滑にブレストができるように工夫しました。

書記
アイデアが出たら付箋に書いてホワイトボードに貼ります。リモート参加の方にもよく見えるようにしアイデアを可視化します。

ファシリテーター
基本ルールに則って運用がされているか確認しつつ、メンバーにアイデアを出すように促します。

  • 複雑なアイデアの場合、「それをわかりやすく一言で表すと?」などと問う
  • ブレストに慣れていないメンバーへのインストラクションとして身をもって例を示します
    • 「いいねぇ~!」を連呼(後述するポジティブ原則の実施)
    • 突飛なアイデアを事前に用意しておき、盛り下がった時を見て投入する

ニックネームをつける

普段使っていない呼び慣れていないような呼び名をつけます。
ブレストに参加する皆が対等であることを意識するための工夫です。 頭を柔らかくするストレッチ的な効果もあります。

実際に使ったニックネームの例

  • らっち
  • Body Builder
  • ボストン
  • はっぱ
  • シトロエン
  • お嬢
  • ジーコ

スタンディング推奨

リモートでの実施だと難しいこともありますが、立つことが可能な人は立って参加します。
発言がしやすいフランクな雰囲気になりやすいです。

アイデアを思いついた時にすべきこと

  • 思いついた人から、アイデアをはっきりと発表をする
  • 1人で喋りすぎない

他の人のアイデアを聞く時にすべきこと

  • 他の人の発表をよく聴く
    • 自分のアイデアを考えることに没頭しない
    • アイデアの拡張または追加に集中する

全体を通して意識すること

ポジティブ原則

  • 発表をし終えた人へ、「いいねぇ~!」で返す
  • 思いつきを出し、発表することでおたがいに場をもりあげる
  • 心配(笑われるかも、恥ずかしい、人格を疑われる、考えが浅いかも)は捨てる

4つの壁を意識する

ブレストを失敗に持っていく可能性のある4つの壁があります。
これらの気持ちになっていないか常に確認し続けます。

  1. 正解を一発で出す
    • いくつものアイデアを修正、廃棄、発展させたものが、優れたアイデア
  2. 失敗=悪い
    • ナイストライ、いい失敗と考える
  3. 「まじめ」や「客観的」が正しい
    • 真剣にかつ楽しみながら取り組むことはできる
    • 必ずしも客観性が正しさにつながるわけではない
    • 独自の見方や考え方も持ち寄ろう
  4. 範囲・枠にこだわる
    • 担当や、専門性など自分に関する枠を意識しすぎるともったいない

実際に行った時の様子

状況

コロナ禍で多くのメンバーが在宅勤務でしたが、このブレストを行っている時期は、数名は出社していていました。
一部メンバーは物理的な会議室に集まり、残りはリモートでzoomで繋いで実施しました。 書記とファシリテーターは物理的な会議室から参加し、ホワイトボードはカメラで映して全員が見える形で実施しました。

議題を選ぶ

今回はブレストを体験してスキルをつけること(ブレストの練習)を目標としているため、ブレストの議題は明確な答えがないもの、かつ身近で考えやすいものをいくつか用意しておきました。

  1. もっとしあわせになる感染予防策とは?
  2. まだ見ぬ〇〇なリモートワークインフラ
  3. 食料廃棄は〇〇で撲滅?

実際に議題にするテーマはその場で参加者に選んでもらいました。 今回私たちが選んだテーマは「③ 食料廃棄は〇〇で撲滅?」です。

ブレストの実施

ブレストは同じテーマで2回繰り返し行いました。
1回目が終わると、出たアイデアの簡単な分類分けや、ブレストそのものの振り返りを挟みました。
ホワイトボードをZoomで共有している様子

このブレストで得られた「食料廃棄は〇〇で撲滅?」に対してアイデアの例​です。

  • マントルで燃やす​
  • 宇宙人にあげる​
  • 食料廃棄権シール(有料)​
  • カロリーに課税​
  • 食料を国で管理​
  • ゴミセンターで再度食事に変える​
  • めちゃくちゃ食べる犬を飼う​
  • 完全栄養食にする​
  • 全部スムージーにする、カレーにする、ピザにする​
  • 土を食べる​
  • 食べるといいねーと言ってもらえる​
  • コンビニ廃止​

他にも80以上のアイデアが出ました。

やってみた学び​

IDEOのルールの効果

ルールを頭に入れた上でブレストを行うことでアイデアの量が多く出ることを感じました。
中には突飛だけど可能性を感じるアイデアも出て面白かったです。
ポジティブ原則のおかげで躊躇せず思い付いたことを出すことができ、また人のアイデアからどんどん発想が広がっていきます。
アイデアを思い付いた瞬間に感じる喜びに連鎖性があり、複数人でその感覚を共有していて単純に楽しい!と思いました。

アイデアを出すスキルは鍛えられる

今回は同じテーマで2回ブレストを繰り返したのですが、後半の方がより多くの意見がでました。 個人の体感的には2回目の方がブレストの習熟度が上がっていてどんどん新しいアイデアを出しやすくなったように思います。普段使っていない脳が活性化されたような感覚です。アイデアを出すスキルは訓練することでスキルアップできる能力だと感じました。

改善点

実施後の振り替えりにて、物理的に1箇所に集まっているメンバーとリモートから参加したメンバーとの間で温度感を感じにくいという感想が出ました。

  • 参加者の表情が読み取れない
  • ホワイトボードの視認性の低さ
  • 音響の分断

などといったリモート会議とリアル会議の差で起きる一般的な課題でした。
今後は物理ホワイトボードに代わるオンラインサービスを利用するなど、オンラインのみで成立するブレストの方法の模索をしていきたいと思います。