ＷＥＢ＋ＤＢ ＰＲＥＳＳ Ｖｏｌ．１０２ 特集ペアプロ／モブプロ｜サービス改善｜Ｒｅａｃｔ Ｎａｔｉｖｅ

投稿元：

レビューを見る

今号の特集は、以下の3つ。

# はじめてのペアプロ／モブプロ

ペアプロ、モブプロのやり方やコツが紹介されている。

* いきなりコードに入らず、最初に二人でTODOリストを作った方が良い。
* 喋りながら（考えていることを共有しながら）開発を進めると上手くいく。
* 結果だけではなく、制作過程の共有が大きな学びになる。

など、様々な知見を得ることができる。

自分は昔に一度だけペアプロをしたことがあるが、どうにも足を引っ張っただけで、正直良いイメージは無かった。
だがこれらの知見を知った上でやれば、上手くいきそうな気がする。

とても良い経験になりそうなので、機会を作ってまたやってみたい。


# サービス改善ノウハウ大公開

様々なアプリで、実際に改善やリニューアルを行った際の体験談が書かれている。
中でも良かったのは、「なぜリニューアルするのか」という話。

どんなに良いデザインでも時間が経つと古くなり、やがてUIのトレンドから外れてしまう。
そうすると、「他のアプリでは出来て当たり前の操作」ができないという状態になる。
それはユーザーに余計なストレスを与えてしまうため避けなければならない、ということだ。

これは大事な考え方だと思う。
UIに限らず、常に他のアプリを知り、最新に追随する姿勢を持たなければならない。


# React Native 実戦投入

React.jsを元にネイティブアプリ開発が行えるようになった「React Native」の紹介。
さわりだけ実際に作ってみたが、とても良い感触だった。

自分はWeb畑の人間なので、Unity等よりもこっちの方が作りたいものを早く作れそうだ。
とても良いものを教えてもらった。今度これでアプリを1本作ってみたい。


また特集以外では、「継続は力なり」のコーナーで触れている「マネージャーマネジメント」の考え方が興味深かった。
つまり良い職場環境が欲しいならば、こちらからマネージャーをコントロールしていこう、という話である。

中でも、理想の状態を「成果は出すからほっといてほしい」としているのが面白かった。
なんともエンジニアらしい考え方だが、確かに事実ではある。
真のプロフェッショナルならば、裁量を大きく与えたほうが上手くいくはずだ。

このことは、マネージャー側にもぜひ理解してもらいたい。
やたらと手間のかかる付き合い方を強要するマネージャーもいるが、時間をかけることが良いマネジメントではないはずだ。

投稿元：

レビューを見る

ペアプロ／モブプロの特集が良かった。注目された背景から具体的な話まで書かれておりとても参考になった。

投稿元：

レビューを見る

pull requestの限界はここ数年で見えてきてるから、ペアプロ、モブプロは次のプロジェクトで積極的に試したい。 実装段階前の教育はなかなか当事者意識がでなくて右から左なことが多いから、やりながら教えるのが効果高い気がする。

投稿元：

レビューを見る

P10：ペアプログラミングとは何か
ペアプログラミングとは、2 人でプログラミン グ(および分析、設計、テスト)とプログラムの 改良を同時に行うやりとりのことである。
── Kent Beck、Cynthia Andres 著/角征典訳『エクス トリームプログラミング』オーム社、2015、p.40

P11：モブプログラミングとは何か
モブプログラミングの「モブ」とは群衆のことです。 モブプログラミングでは、ペア(2 人)ではなく、モブ(チーム全体)でプログラミングを行います。モブ の人数は 3 人から 5 人くらいを想定しています。ペア プログラミングと同様に、コードを書くだけではなく、すべてをモブで行います。開発作業だけでなく、 関係者へのデモンストレーションや顧客へのインタビューまでもモブで行うことがあります。

P11：ロール ── ドライバーとナビゲーター
黙って隣に座っているだけではペアプログラミン グにはなりません。ペアプログラミングでは、キー ボードの前にいる人と隣に座っている人にはそれぞ れロール(役割)があり、名前が付いています。
- ドライバー ：キーボードの前にいて、コードを書き進めていく人
- ナビゲーター ：ドライバーの隣に座り、ドライバーと会話しながら導く人

ペアプログラミングでは、互いのロールを 交代しながらコードを書いていきます。 モブプログラミングでも、キーボードの前にいて コードを書き進めていく人をドライバーと呼びます。 そして、ドライバー以外でモブの中にいる人をナビゲーターと呼びます。つまり、モブプログラミング ではナビゲーターは複数人います。多様なスキルを 持ったチーム(ビジネス判断ができる人、開発ができ る人、エッジのテストパターンを挙げられる人など) が共同で開発に取り組みます。

・P17：在庫を減らし、 スループットを 最大化するペアプロ/モブプロ
稼働率を高めるための並列開発とPull Requestの レビューが、ボトルネックと在庫を生んでしまいま した。在庫である間、そのコードは価値を生みませ ん。ならば、むしろコードレビューをリアルタイム に常時行うことによって、書かれていくコードがす でにレビュー済みである状態を作り、コードが完成 したら即リリースできる態勢にするほうが、全体の スループットは上がるのではないか、という考えに たどり着きます。この考え方こそが、10 年以上前に 流行したペアプログラミングに再び光を当て、モブプログラミングに進化した背景にあったのではないかと考えています。