Speee DEVELOPER BLOG

Speee開発陣による技術情報発信ブログです。 メディア開発・運用、スマートフォンアプリ開発、Webマーケティング、アドテクなどで培った技術ノウハウを発信していきます！

SpeeeのOSS開発実例 - サポプロによる楽しく高速な知識習得

こんにちは。Speeeエンジニアの香川です。SpeeeではUZOUという広告配信プラットフォームの開発をしています。Speeeはクリアコードの須藤さんにOSS活動をサポートして貰っています。

この記事ではサポプロ（サポートプログラミングの略）と私達が呼んでる形式でOSS活動を須藤さんにサポートしてもらった事例についてサポートして貰った側（私）とサポートした側（須藤さん）の視点で紹介します。

当時、私はred-arrowというApache ArrowのRuby実装に足したい機能がありPRを出したかったのですが、難しすぎて断念した事がありました。それを須藤さんに相談した所、じゃあ詳しい人（須藤さん）が適宜アドバイスしながらやってみるのはどうでしょうか？？と提案して貰い、お言葉に甘えてサポプロという活動が始まりました。

サポプロってなに？

サポプロはペアプロ（ペアプログラミングの略）のドライバー+ナビゲータのような形で進める開発スタイルです。 ただしドライバーは私固定で適宜不明な所で須藤さんのアドバイスや解説を貰いながら進めるというスタイルがペアプロとは異なります。なので私達はペアプロとは呼ばずにサポプロと呼んでます。

サポートして貰った側の視点

どのようにやっていたか

やってく中で適宜スタイルは変化していったんですが、最終的には以下のようなスタイルに落ち着きました。

  • 隔週でサポプロの時間(リモートで1時間)を設ける
  • サポプロの時間で解説を貰いながら進め方の大方針を決めたり、詰まっている所の実装を進めたりする
  • サポプロの終わりに、やろうとしていること、やったこと（学んだこと）、次やることをメモっておく
  • サポプロとサポプロの間の期間で一人で進められるところは進めておく
    • とはいえガッツリ時間使ってやっていた訳ではなく正味4時間分くらいを余暇を見つけてチマチマ開発していた
  • メモに、この2週間で進めた所と疑問点を追加しておく
  • 次のサポプロの時間で疑問点など取っ掛かりに解説してもらいながら実装を進める
    • 以後ループ

メモはこんな感じで書いてました。

# 20210726

## TODO

- extの実装
  - test/valuesの追加
  - test/raw-recordsの追加
  - extのmap実装
  - test/values, test/raw-recordsの他の型のテストにMapを追加
  - extの他の型にmapを追加

## やってること

- extの実装
  - booleanのvaluesのテストを通す

### 質問

- Mapの場合、keysとitemsでそれぞれのarrayは取れるからそれをAcceptした後にhb_hashに詰めればOKな理解
  - Acceptはkeys, itemsそれぞれをarrayで変換するから、それをどうrb_hash_asetで詰めるか？
    - keys/itemsをループ？
    - rb_hashに複数セットバージョンある？？
  - convertにはNull値をいい感じに変換する役割があるが、それはListArrayの実装をそのまま使えそう？

### やったこと

- extの実装
  - map_array_value_converterのconvertメソッド実装
  - converter使いまわし時の工夫やRubyObjectをCの世界から触る方法など

## 次やること

- test/valuesに諸々の変換追加
- test/raw-recordsに諸々の変換追加

当初はサポプロのタイミングだけ実装するスタイルでいいんじゃないですかね？？みたいな感じだったんですが 実際にやってみると何も取っ掛かりがない状態で解説を聞いてもなかなか頭に入って来なかったので、最終的にはちょっと進めて疑問点作って、サポプロに挑むというスタイルに変化しました。 個人的にはこのスタイルが進めやすくて良かったように思えます。

成果

最終的に無事開発が終わりPRを出してマージされました 🎉

https://github.com/apache/arrow/commit/1248228e9d5a72b8354e0a95620fd53f90796872

Apache Arrowの次のバージョン(6.0.0)で使えるようになる予定です。

良かったこと

  • Apache Arrowのデータ構造やコードの構造など、なんもわからんという状態でしたがエキスパートの解説を適宜聞きながら進めることで、この辺を見ればいいんだな？というのが徐々にマッピングできていった
  • Apacheプロジェクトにコントリビュートできたというのはテンションあがる
  • Apache Arrowに直接紐付かない知識も色々身についた
    • Homebrewのビルドシステムとか

結構時間はかかったんですが、全体的に楽しく開発できたしめっちゃ良い体験でした。

と、ここまではサポートして貰った私の視点で、以後はサポートした須藤さん側の視点でこの取組について紹介してもらいます。

サポートした側の視点

須藤です！ここからはどうしてサポートプログラミングを考えたのかをまとめます。私がこういうアイディアを思いつくときは、最初に実現したいことがあります。実現したいことをどうやったらうまく実現できるかなーと考えて、「あ！これでうまくいくかも！」と思いつきます。ということで、このアイディアにも実現したいことがあります。

実現したいこと

このアイディアで実現したいことは「ある程度知識・経験のある人が新しい分野の知識を獲得する速度を上げる」です。

実現したいことを明確にしておくとアイディアをブラッシュアップするときの判断基準に使えます。「ここのやり方をちょっと変えてみるのはどうかな？知識獲得の速度は上がりそうかな？影響なさそうかな？」とか考えることができます。香川さんのパートにもあるとおり、実際、やりながらやり方をブラッシュアップしながらやっています。そういうときに役立つのです。

前提

私がアイディアを考えるときは前提を設定することが多いです。誰にでもどんなシチュエーションにもマッチするアイディアよりは限定した方がより特化した（より効果が高い）実現方法を選びやすくなるからです。今回は次のような前提をおきました。

  • 対象の人はある程度知識・経験のある人
  • プログラミング対象は対象の人があまり知らない分野
  • サポートする人はプログラミング対象に知識・経験のある人

背景

サポートプログラミングの説明の前にどうしてサポートプログラミングを思いついたかをまとめます。

対象の人はある程度知識・経験がある人です。このような人は知らないことでも自分で調べて理解していくことができます。しかし、できるからといってそれが速いかというと必ずしもそうではありません。理解できるまでにいろいろ試行錯誤したり必要そうな関連情報を集めたりするからです。

では、どうすれば新しい分野の知識を獲得する速度を上げられるでしょうか。試行錯誤を少なくできるとどうでしょうか。必要そうな関連情報ではなく必要な関連情報だけを理解できるとどうでしょうか。試行錯誤や必要そうな関連情報を理解することがムダだとは思いませんが、ある程度理解してからそのようなことをしたほうがより理解が進みそうではあります。

どうすればそのような進め方をできそうかを考えたところ「すでに知っている人に教えてもらう」というアイディアが浮かびました。しかし、1つ懸念点がありました。それは「自分で調べられる人はなかなか他の人に聞かない」傾向があるということです。自分で調べることができるのである程度調べてからではないと聞かない傾向があります。この懸念点を解消し、できるだけすでに知っている人の知識・経験を獲得する進め方として考えたのがサポートプログラミングです。

進め方

それではサポートプログラミングの進め方について説明します。

対象の人とサポートする人が同じプログラミング対象について一緒に作業します。そのため、ペアプログラミングと似ています。ペアプログラミングのストロングスタイルに似ていますが、前提が違います。

ストロングスタイルはドライバーが初心者ですが、サポートプログラミングでのドライバー相当はある程度知識・経験のある人です。サポートする人は対象の人が知らないことを随時解説していくのでストロングスタイルのナビゲーターと似ていますが、考えるのはナビゲーターだけというのは違います。サポートプログラミングは対象の人が新しい分野の知識を獲得する速度を上げることが重要なので、対象の人は新しい分野のことについてたくさん考えます。わからないことがあったらすぐにサポートする人に聞きます。すでに聞き始めている・すぐに聞ける状態になっているので、自然と自分で調べる前に聞くことができます。

サポートプログラミングは次のように進めます。

作業をするのは基本的に対象の人だけです。なにか調べごとをするときもサポートする人が「ちょっとこのファイルを開いてもらえますか？」と言って対象の人と一緒に調べます。「ちょっとまっててください、調べてきます」とはしません。新しい分野ではわからないことをどのように調べるかも重要な知識なので一緒に調べることでどう調べればよいかを使える機会として活用します。

一緒になにをするか（新機能を追加するとか、問題を直すとか）や作業の流れはサポートする人が考えます。対象の人はどんな内容をどの順番に作業すると理解が深まりそうかの土地勘がないからです。これらは対象の人の知識・経験・興味を元に検討します。なにかしらきっかけがあった方が対象の人が理解しやすいからです。

作業内容と作業の順番が決まったら一緒に作業します。作業の中でサポートする人は対象の人が知らないことを随時解説します。たとえば、「ここはこういう仕組みになっています」、「ここを理解するためには別の○○を知っていた方が理解が進むので先にそっちを説明しますね」、「ここは動かしてみた方が理解が進むのでサンプルデータでちょっと動かしてみましょう」といった具合です。

対象の人はわからないことや追加で気になったことがあればその場で質問します。サポートする人がその話題は後で扱った方が理解が進みそうと判断しない限り、基本的にそれらの話題を後回しにせずにその場で解説し理解してもらいます。そのような話題が、バラバラだった知識をつなげて全体の理解を進めるきっかけになる可能性が高いからです。また、対象の人にわからないことを自分で調べずにすぐに聞いていいということを実感してもらう機会にもなります。

あとはこの進め方を繰り返して一連の作業内容を完了します。完了する頃には新しい分野に関する知識の理解が進んでいるはずです。ただし、自分だけで調べた場合と比べて網羅性に欠ける可能性があります。自分だけで調べた場合は必要そうな関連情報を広く調べることで作業内容以外のことについても知る機会があるからです。このあたりは、サポートプログラミング中に関連知識についても伝える機会を増やしたり、別の作業内容も一緒に作業してみたりして対応します。

また、サポートプログラミングとサポートプログラミングの間に間隔を開け、対象の人だけで作業する時間を少し設けることが効果があるフェーズもあります。対象の人だけで作業する時間は、（説明を聞くのではなく）実際に手を動かす時間を多めに確保して理解を進めたり、自分で理解が足りない部分に気づく時間になります。

進め方のおさらい

まとめるとサポートプログラミングは次のように進めます。

  1. 対象の人の知識・経験・興味を元にサポートする人が作業内容・進め方を決める
  2. 対象の人が作業をする
  3. サポートする人は対象の人が知らないことを随時解説する
  4. 対象の人は知らないことを随時サポートする人に聞く
  5. 必要であればサポートプログラミングとサポートプログラミングの間に対象の人だけで作業する時間を設ける

うちの会社でもこんな感じのサポートをして欲しい！と思った人はクリアコードにお問い合わせください！違う会社でのサポートの知見をSpeeeさんのサポートでも活かすのでSpeeeのみなさんも違う会社のみなさんもうれしくなるはずです。

終わりに

ここからは再び香川に戻ります。 以上がクリアコードの須藤さんにOSS活動をサポートして貰ってる実例の紹介でした！

こうしてブログにまとめた今思うことは、サポプロは普段の業務でもどんどん使っていった方が良いなということです。 例えば私であれば今のチームメンバーの中で比較的にインフラが得意であるため、インフラで何かしらの問題が起きたときに「対応しておきました！」では無く、興味のある人を捕まえて「サポートするので対応してみませんか！？」というスタイルを取り、もっと相互に知識を伸ばしあえるような組織にしていきたいと思っています。

Speeeのエンジニアに興味が出たよという人がいたら募集中の職種をチェックしてみてください！