はじめての執筆振り返りと、書籍”エンジニアチームの生産性の高め方”のご紹介

そして、その一章分の量を執筆する労力という観点については、論文一本書く労力と変わらなかった印象だった。論文は限られたページ数にギュッとまとめて主張すべきことを書く（論文とは、を語るほどの実績なくてあれですがご容赦ください）。一方で、今回の執筆に関していうと、ギュッとしてる部分を紐解いて丁寧に説明する方向で執筆を進めた。もちろん作業量はあるけど、目次を書いている頃から多分その方向性で大丈夫だろう、と考えていた。そして、実際に執筆が始まってからはその予想通りだった。

"執筆、楽勝だったぜ"

ということではなくて、

"このしんどさは知ってるぞ"

という意味で、なんとかできるな、とすぐに思った。

どんな辛さか知ってるわけだから、その辛さとの向き合い方もわかっている。そこまでの負担はなかった、と述べたのはそういうこと。

執筆のリズム

そういうわけで、執筆自体は大変なので、早いところ執筆のリズムを掴むことに集中した。具体的には1日1,000字あたりを目標にして、それを毎日書くことを続けた。

執筆のリズムのことも含めて、執筆してる時に気をつけてたことをまとめると以下の通り。

1日あたり1,000字程度を執筆する（できない日もあって良いが、目標としてはこれ）
パラグラフライティング
論文を書くときよりももう一歩か二歩、説明を多めにする（丁寧にする）
実践した内容とその結果をしっかり述べる
可能そうなら汎用的な手法をまとめる

論文だとページ数の制限が厳しいが、書籍の場合はもっと余裕はある。もちろん書籍の場合も制限はあるけど、論文ほどではないから読者の目線を意識して、どこから説明すべきか、ということはずっと考えながら書いていた。

この方針で書いていたら、自然とページ数はちょうど必要な枚数になっていた。今振り返ると、もうちょい補足しても良い部分（UML Testing Profile、UTPの部分など）があったけど、執筆する時間が年末年始のまとまった時間のみだったので、力尽きてしまった感がある。

書籍のご紹介

最後に書籍について。

ソフトウェアを作るのって難しいな、といまだによく思う。学生時代から数えてもう20年ほどは同じことゴニョゴニョしてるのに、いまだにわからないこともあるし、相変わらず上手くソフトウェアを作れないことがある。ほんと難しい。

"どうしたら上手く進むのかな"

"この課題どう解決できるのかなー"

ということはいつも考えていて、この何年かは結果的にプロセスの改善をしていることが多い。今回僕が書いた第4章 "リアーキテクトにおけるテスト戦略" に関してはその一例。限られた期間で良い品質のソフトウェアをどう提供するか、という課題に対する実践例を述べた。開発効率の向上に取り組んだ実践例、ということになる。

実践ソフトウェアエンジニアリング (第9版)では、開発プロセスについて以下のように述べられている。

品質に焦点を合わせること（quarity focus）、これがソフトウェアエンジニアリングを支える基盤となる。

ソフトウェアエンジニアリングの土台はプロセスである。ソフトウェアエンジニアリングプロセスは、技術の層を１つにまとめる役割を持ち、ソフトウェアが合理的かつ納期通りに開発できるようにする。

引用：実践ソフトウェアエンジニアリング (第9版)

開発プロセスはソフトウェアエンジニアリングの土台であり、個々の技術とチームメンバーを繋ぐ。その開発プロセスがしっかりしていないと最終的には良いプロダクトとならない。すなわち、開発プロセスと開発効率の関係は強く、開発プロセスを改善することは、生産性の向上へとつながっていく。

ソフトウェア開発における生産性の話ってなかなか難しい。ただ、この話題はソフトウェア開発が工学（エンジニアリング）として成熟していくために必要な要素だと思う。同じことは3章で若狭さんも述べていて、非常に興味深かった。（先日のパネルディスカッションとかでもこの話を若狭さんとしたかったけど、時間がなかった。）

工学として成熟していくために、という話については、色々な方面での議論と体系化が必要だろう。その方向性とは、現在の技芸に頼るソフトウェア開発（プロダクト開発）ではなくて、工学（エンジニアリング）的にプロダクトを作ろうね、ということ。「技芸から工学へ」と 2019年SRE考 - ゆううきブログでゆううきさんが述べていたのと同じ。ソフトウェア開発は柔軟さ（ex. 製造工程においても仕様変更が可能）があるけれど、その柔軟さゆえの不安定さが他の工学と比べてあるんだと思う。だからソフトウェア開発が面白い、というのはありそうだけど、趣味での開発ならいざ知らず、製品開発（プロダクト開発）でそれでは困る。とはいえ技芸は必要だろうけども。

今回共著者として参加したエンジニアチームの生産性の高め方〜開発効率を向上させて、人を育てる仕組みを作るでは、第１部で著者らが実践してきた開発効率やプロセスを改善するHowを示しつつ、第２部ではそういったことを実践する組織文化の醸成やチーム作り、そしてそれらを支援する仕組み作りの話がされている。前述した通り、生産性というのは難しい話題であるけれど、本書がどなたかの気づきにつながる書籍であれば大変嬉しいです。

長文となってしまいましたが、面白い本になってると思いますので手に取っていただければ幸いです！