このあたりの生産性の問題は、リモートワークと社内出社の双方に意見の食い違いがあり、佐藤氏のいう「誰かが顧客要件をキチンとまとめ～」に掛かってきているのかな、というのがある。
著作を出しているので、こっちも踏まえて議論を残しておこう。
主に議論になりそうなのは、第3章からの具体的な開発プロジェクトの話になる。ここの中でリモートとか設計とかコミュニケーションの話がでてくるので、それでよいだろう。
第三部では「現場で役に立つ周辺知識」としてマネジメントの話がでてくる。
- 第9章 チームビルディング
- 第10章 設計
- 第11章 Gitによるリポジトリ管理
ということで前半の技術的な要素（ReactやDjango）とは違い、それらのWebアプリを具体的にどのように会社で開発しているのか？という紹介に近いものになる。
書籍の中には、アジャイル開発、イテレーション開発のような一般的なソフトウェア開発の用語はでてきるのだが「スクラム」や「PMBOK」のような用語はでてこない。これはあえて外したのか、既存のスクラムとはやり方が異なるために「スクラム」という用語を外したのかどうかはわからない。が、第9章や第10章を読む限り、
- 開発自体はアジャイル開発でやっている模様
- 顧客とのやり取りやプロジェクトメンバとの情報共有のため文書を積極的に作っている
- 実際のタスク管理や進捗管理はチケット方式を使っている模様
- プロジェクトメンバは5名程度で、単独ではない。あるいは大人数（100名とか）ではない。
ということがわかる。
一般的にアジャイル開発でのスクラムやXPなどがうまく回る人数として5～10名程度というものがある。それ以上になると、スクラムチームを分割して別途プロダクトオーナー（社内であればプロダクト・マネージャとか）が担うということなる。これは社内開発＝製品開発なのか、受託開発を含めた請負であるのかにもよる。また、本格的な顧客参加型のスクラムチームであるのかにも依るだろう。
なので、「実装に学ぶフルスタック～」にあるソフトウェア開発が適当であるかどうかは、時と場合による。逆に言えば、株式会社オープントーンでは、この方式でうまくいっているという事例となる。
「誰かが顧客要件をキチンとまとめ～」の部分の生産性を考える
先のツイートから伺い知るに、既にチケット化されているものに対して自宅などを使ったリモート環境ではうまく生産性を上げることはできるが、それ依然のチケット化する工程において（設計や要件定義など？）ではリモートワークでは難しいのではないか？という話だろう。第9,10章を読むと、「他メンバーの課題・問題を感知しにくくなる」や「リモートでは仕様書の文書化を意識的に取り組む必要ある」という書き方があるので、プロジェクト内での情報共有や相互のサポートに難点が感じられたのであろう。また、「タスクマネジメントしづらい」という点を挙げていて、手が空いている人にタスクをうまく割り振りにくいという書き方もされている。つまりは、暇な人と忙しい人の見わけがリモートワークでは見つけづらいという難点をあげている。
ここの点からいえば、チケット駆動であれば本日こなすチケットを自らが取りに行くという方式がとられるし、スクラムであればスクラムミーティングというものが存在する。リーダーあるいはマネージャがタスクを割り振るのではなく、メンバー自らがタスクを取りに行くのだ。このあたり、スクラムの手法に沿っていないゆえの懸念点のような気もするのが、うまくいっているのであれば別に大丈夫なのだ。
論点は、それ以前のチケットを作るときの問題となるだろう。
顧客要件をまとめる、おそらく要件定義をまとめたり設計をまとめたりした段階で、WBSに落としていると思われる。この割り振りを誰がするのか？という話になると思うのだが、一般的なアジャイル開発（特にスクラム）の場合は、
- 顧客の達成目標がプロダクトオーナー＝顧客自身が立てる
- スクラムマスターが、達成目標を適宜ピックアップして、スプリントする
- スプリントの中で、チームのメンバーがタスクに落とす
という手順になる。なので、チケット（あるいはWBS）に落とすのはメンバー自身だし、つまりは顧客要件＝達成目標をブレークダウンするのは、スクラムマスターとメンバーの共同作業となる。
が、先のようにマネージャが顧客の達成目標（つまりは要件定義など）をブレークダウンしようとすると、そのWBSを誰がやるのか？＝マネージャがやる、WBSをどうやって計画通りに割り振るのか＝マネージャがやる、というスタイルにならざるを得ず、そのために「誰かが顧客要件をキチンとまとめ～」という誰か＝マネージャという主張となってしまう。
どうやら、このツイートを受け取った開発者（マネージャも含む？）の意見が分かれるのは、この部分で、
- チケットはマネージャが作成し、メンバーに割り振る
- 達成目標はメンバーがブレークダウンして、メンバー自身がチケットを受け取る
という開発スタイルの違いに他ならない。
ゆえに、そこの「生産性」も違ってしまうのだ。
では、プログラマ自身の生産性はどうなのか？
プログラマはプログラムを書くことだけが仕事ではないが、主な仕事はプログラムを書くことだ。昨今では、いろいろな仕事を平行で動かすことも必要なのだが、まあ、最終的にコードを書かないとソフトウェアというものは動かないのは確かだ。
まあ、例外的にノーコードっていう方法もあるけど、それはまた別の機会に。
で、私のツイートした「正直言うと～」の部分を解説しておこう。要するに、ソフトウェア開発のスタイルで、一番高速にモノができあがるのは「ウォーターフォール開発/計画駆動」であることを忘れてはいけない。これには異論があるだろうが、つまりは
- 事前に完全な計画ができあがること
- 計画通りのタスクを分割できること
- タスクは計画通りに進み、手戻りや遅延がないこと
が、最高速にプロダクトができあがっていく計画駆動の条件となる。つまりは、自動車工場におけるオートメーションをソフトウェア開発に応用すればよい。ソフトウェア開発の大量生産工場のできあがりである！
のだが、そんなことは不可能だ。ということは皆わかっている。今では皆わかっているが、かつてはそうしていたのだ。丁寧な設計書や丁寧なフローチャートや綿密なレビューを繰り返していたのだ。
で、実際のところ、長期では難しいのが1週間程度あるいは2,3日程度の短期間であれば、この計画駆動は実に高速に動く。
これが「正直に言うと～」の前半の部分である。
後半の部分は、実際このようなキリキリに詰めた状態だと、うまくいくのいくのだが、非常に疲れるのである。疲労困憊だし、何度も続けてできるわけではない。最終的な納品直前に馬鹿力を発揮できるぐらいである。
なので、トップスピードを保つことはほとんどやらない。特にアクセルを踏むが、たいていの場合は、ブレーキのほうを踏んだままだ…と前に進まないので、オートマの自動走行位のスピードの気持ちでやることが多い。
それって、生産性が悪いんじゃないですかね？という意見もあるだろうが、長期的に見ればこのほうが生産性がよいのだ。体の故障は少ないし、他の人の気配り（手伝いやアイデアだしなど）の余裕ができる。つまり「ゆとりの法則」ができるわけだ。きちきちの作業をやるだけでは、ピースは全く動かなくなっていまう。ある程度の余裕がないとチームはうまく動かない。
わたしの場合は、フリーで仕事を受けることになるので、多数の仕事が平行で走る。シングルタスクの最速スピードよりもマルチタスクのスレッド操作のほうが遅くなるのは IT 屋では周知の事実だと思う。思うが、実際のところは
- お客からの回答待ちなどで、こっちに待ち時間が発生する
- 開発が先にできあがっても、お客の都合でリリースなどで待たされることが多い
- 協力しているメンバーの進捗スピードなどで、待たされることも多い
ということで、結構な確率で「待ち」が挟まってくる。この場合、会社に居れば、待ちの状態でぼんやりと椅子に座っているのも可能（だとまずいんだけど）なのだが、リモートワークをやっていると、じゃあ気分を変えて別のに手をつけておくか、という形にできるわけだ。
ある程度、開発力があればシングルタスクで仕事をやるよりも、ある程度のマルチタスクのほうが作業効率がよいことがわかるだろう。新人レベルならばひとつの仕事べったりのほうがいいだろうが、ある程度年季が入ったプログラマならば、マルチでやらないとちょっと無駄が多いわけですよ。
アジャイル開発スクラムやチケット駆動、PMBOKの基本的なところは下記の本に書いたので、それを入口にして本格的なスクラムやPMBOKの書籍にあたってみてください。もちろん、いきなり「アジャイル開発スクラム」にあたるのもよいです。
