ペアプロにはレビューとは違うものがありそうなメモ2

分かるまでのプロセス

「分からない」から「分かる」にいつる間に次の5つのステップを踏むと想定されている 1. ある事物や物事が果たしている機能の1つを「同定」する 2. 同定した機能について、その仕組みを「疑問視」する 3. 仕組みをより詳しいレベルでの機能のつながりとして「探索」する 4. 説明の候補になる機能のつながりを「提案」する 5. 提案した説明が十分正しいかどうか「確認」する

これらを行うにはペアで行ったほうが良さそうである。

問題を解く時に、2人の方が1人よりも有利になる条件

そもそもコードを書くのは問題を解くのとは異なるが、それは置いておく。
12章では、2人の方が1人よりも有利になる条件の話が書いてある。
2人で行った場合に時間が半分になったり、正答率が二倍になることはそうそうない。2人の手が見えやすい作業を行なった方が、回答に早く辿りつくようだ。逆に2人の手が見えない場合は1人で行うのと同程度の時間で回答にたどりつくようだ。

このことから、2人で作業することで確実に効率的とは言い難い。ただ、常に2人の考えていることを共有しながら作業を行うことによって相互作用を発生させやすいと思われる。

ペアプロにはレビューとは違うものがありそうなメモ

まだ調べ中なのです

経緯

教育心理学概論を読んでいて、

と呟いたら興味深いと言われてしまったのでメモしながらまとめることにした。
この本はまだ9章までしか読んでいませんが、6章と9章がおすすめです。

本の内容

教育心理学概論 の6章2節に建設的相互作用論というものが出てきます。ミシンが縫える仕組みの理解を扱った研究と折り紙を使った計算を扱った研究が出てきます。
ミシンが縫える仕組みの理解を扱った研究では、ペアでミシンが縫える仕組みを納得いく説明を作って欲しいと依頼する。最も詳しく分析できたのは、ミシンは物理的に不可能な機械だと主張した大学院生と修理までしたことがある客員研究員だった。
折り紙を使った計算を扱った研究では、折り紙を渡して「3/4の2/3」に斜線を引いてくださいと依頼する。折り紙を追ってもいいし、1/2と計算してから斜線を引いてもいい。9割以上の人は折り紙を折った。第二試行として「2/3の3/4」を依頼しても、2割りしか計算してから斜線を引くことはなかった。ペアで同じ試行を行わせた場合は、第二試行で7割が計算してから斜線を移行した。

感想

ミシンの話で言えば、新入社員とペアで既存部分のドキュメントの作成するのが良さそうだ。
折り紙の話で言えば、レビューするのは異なる二人で同じような作業をしてすり合わせるような作業だと思って、「1/2と計算して斜線を引く」を思いつくのは確率は2割づつ(4割弱)あるが、ペアで作業したら7割に上がることになる。そんな単純な話でもないだろうが、相互作用による効果はそれぞれ考えるレビューより、ペアで作業した方が高まりそうな気がする。

知らないなら聞きましょうの精神

知らないことは、恥ずかしいことではない。

 社会人はプロフェッショナル集団である。それぞれの専門性を束ねて金儲けをする。それぞれの専門性があり、それぞれ知っていることが異なる。同じプロジェクトや目標に向かうときに共通の知識としてあった方がいいことはある。知っていることが異なるのため知らないことがあるのは当然である。知らないことは当然あるものとして扱うべきで、恥ずかしいことではない。
 学生の頃に授業でやっていないことを知らないことは恥ずかしいかもしれない。テストで良い点が取れなかったら恥ずかしいかもしてない。しかし、会社は学校ではない。均一に教育されない。仕事は授業ではない。知らないことは大した問題にはならない。業務を推敲できないことが問題になる。推敲するために必要なことをすべきで、知らないことを恥ずかしがっている場合ではない。

自分も聞くし、相手も聞く

 聞くことに対してハードルがある。年齢とか性別とか入社歴とか役割とかとか。聞くためにハードルを超える必要がある。お互いに聞けるような関係性を築いていった方がいい。

聞かれたら嫌がってはいけない

 自分が聞いた時に嫌がられたら次に聞くときのハードルが上がってしまう。聞かれた側は、聞かれたときに嫌がるのはよくない。可能な限り丁寧だが短くすますようにするべきだと思う。解るように説明してあげる方が、そこに労力を割くと疲れてしまう。1000文字書くよりもリンクを貼る方が楽だしわかりやすい説明になりがちである。1000文字書く必要があるのなら、ブログにしたり社内wikiにしたりいつでも検索して取り出せるようにしておいた方が良い。一度聞かれたことは、何度も聞かれがちのことである。
 「前にも言った」「何度も言った」「検索してみて」とかはよくない対応だと思う。 それで解決するならわざわざ聞いてはいない。  リンクを読め見てもわからないと言われたのに「リンクを読め」というのもよくない対応である。二度と聞く気にはならない。

終わりに

「知らないなら聞きましょうの精神」ってなんか長いのでもうちょっといい感じの表現があるといいなと思う

iOSの社内ライブラリをやめる

この記事の社内ライブラリはアプリとは別にリポジトリを分けて管理しているコードで、CocoaPodsやCarthageでアプリにインストールできるようにしているが、社内のアプリにしか使っていない物のことです。

なぜ社内ライブラリが必要だったか

大抵の会社ではアプリを一つだけ作っていることは少なく、複数のアプリを開発していることが多い。複数のアプリで社内のAPIにつなぐための通信コードやドメイン関連のコードは共有したい。1つのアプリは1つのリポジトリで管理することが多い。。そのため、共有したいコードをライブラリとしてアプリとは別のリポジトリに切り出して、ライブラリ管理ツールを使ってアプリににインストールして解決している。

アプリを一つのプロジェクトで管理する

具体的なやり方は以下のリンクをみて欲しい。 recruit-tech.co.jp

Xcodegenを使えば複数のアプリを一つのXcodeプロジェクトで管理することは比較的簡単にできるような環境が整ってきている。共通に使うコードをframeworkとして複数のアプリで扱うことができる。

社内ライブラリをやめる

全てのアプリを1つのプロジェクトで管理することができれば、全てのアプリを1つのリポジトリで管理することができます。1つのリポジトリでアプリを管理しているため、社内ライブラリをリポジトリに切り出す必要はなくなります。ライブラリに切り出していたコードも一つのリポジトリで管理できるので、社内ライブラリをやめることができます。

終わりに

私はやりましたが、全ての会社で当てはまるような話ではないと思ってはいます。

openapi-generatorで生成されたSwiftのコードが動かないので回避方法

2020年1月20日現在の話です。

OpenAPI(Swagger)で書かれた定義ファイルからswiftのクライアントコードを生成する場合に、openapi-generatorを使おうと考えると思います。しかし、下記のようなコマンドで生成されるコードはコンパイルはできるもののそのままでは動いてもレスポンスを返すことは決してないコードが生成されます。この回避方法を2つ紹介します。

openapi-generator generate -i openapi.yaml -o src/ -g swift5

--library を指定する

生成されるコードにlibraryを指定することによって、デフォルトに指定されている。URLSessionを使った壊れた実装のコードを回避します。libraryで指定できるのは現状だと alamofire だけのようです。

openapi-generator generate -i openapi.yaml -o src/ -g swift5 --library alamofire

swagger-codegenを使う

openapi-generatorを使うのを諦めてswagger-codegenでコードを生成することで回避する方法です。openapi-generatorで生成されるコードと大体同じものが生成されます。

スクラムマスターの役割と違和感

深夜のノリで書いているのであまり真に受けないで欲しい。

私が思っていた違和感が、スクラムガイド2020年版がでて変更によって言語化できると思ったので書きました。

スクラムマスターは日本的なリーダーではない

 と思う。スクラムガイドにはサーバントリーダーや真のリーダーと書かれているけれども日本的なリーダーではない。つまり、役職的な上位のものがスクラムマスターになるわけではない。偉いわけでもないし、インクリメントの出来に責任も取らない。自己改善していけるスクラムチーム作りに責任を持つ。

 スクラムチームが目指していくべきことは、自分たちを改善していけるようにすることである。スクラムマスターはより良いスクラムをするためにリードする人である。スクラムマスターはより良いスクラムをするために支援し導く人である。それをするために、複数チームに跨っていたり、逆に1チームに複数いてもいいと思う。会社としての役職はリーダーである必要はない。スクラムの概念に会社の役職としてのリーダーはない。

インクリメントの範囲が狭すぎる

 スクラムマスターが開発者の開発速度を測ったり改善するためのツールを開発したり探してきたりすることがあると思う。この仕事はスクラムマスターがする仕事ではないと思う。スクラムチームが目指していくべきことは、自分たちを改善していけるようにすることなので、開発者が開発者のことを改善するためのツールを開発したり探してくることは、開発者がやるべきことである。

 同様に、プロダクトオーナーがプロダクトをより良くするためのことは、プロダクトオーナーなり開発者がやればいいことなのでスクラムマスターがやる必要はない。

 自分たちを改善を行う何かをインクリメントとして含めるべきである。そうすれば、開発者を行う理由ができる。プロダクトは、コードだけの部分をさす言葉ではない。付随するサービスもさす言葉である。開発者は、利用可能なインクリメントのあらゆる側面を作成することを確約する。「あらゆる側面」を狭めるべきではない。

経験的にスクラムマスターがやれば早いできるかもしれないが、やる必要はない。

スクラムマスターは何をするのか?

 個人的には最終的には自分自身をクビにすることだと思う。要らなくていいなら要らない役割だと考えている。開発者とプロダクトオーナーがより良いスクラムを自分たちで改善していけるなら、スクラムマスターは必要ない。

 別のチームに行ってたまに様子を見にいくくらいになればいい。別のチームないなら元の役割に戻るなり、社内ニートするなりしていいと思う。

というか社内ニートを目指すべき