「チーム開発実践入門」を読んだ
私は昔、VBプログラマだった。最初に入った会社でプログラマという職種で仕事をし、そのあとも、システム系の仕事にはまることが多かった。転職した会社ではユーザー部門のシステム発注担当という立場も経験し、今ではまたベンダー側のシステム導入時のディレクション担当である。そんな立場として、本書を読んだ。
この本を読んで最初に思うことは、全てのユーザーは、システムはチーム、つまり複数人がオーバーラップし、引継ぎを重ねて作り上げるものであることを、知った方が良いということだ。システム開発および運用時に管理するべき要素は、ソースコード、データベーススキーマ、設定ファイル、依存関係、要件書や設計書といった、それぞれに役目がある膨大な要素が存在している。それらを、タグとブランチというものを駆使してデバッグや機能改善に適したバージョン管理を行い、またチーム開発として、チケット管理を行いプロジェクトとして統合させたりしなければならない。そして、複雑な要素をタスク化してプロジェクト管理していくマネジメントシステムが、世界共通的に出来上がっているのだ。これを継続するために重要なことが、テストコード・CI・リファクタリングという三種の神器とされ、エンジニアの方々が、炎上案件で何度も丸焦げになって、生み出されて来た仕組なのである。
ユーザー目線で考える、エンジニアの仕事とは
エンジニアという作り手側には、他者が作ったものを直す、付け加えて拡大するという作業を、効率的且つ品質高く行うための専門的ツールが山のようにある。ツール自体ももちろん日進月歩である。丁寧なこの本の中では、それぞれのツールのオススメを、丁寧に、場合分けしながら、具体的実践的な使い方を提示してくれている。
エンジニアの仕事は、単に、ユーザー要望をシステム仕様に落とし、設計し、ソースを書くだけではない。作る過程を効率的にするため、作ったものを保守し続けるための配慮を行い、それをサポートするための専門的なツールが山のようにあり、それぞれを、プロジェクトやチームの規模・レベル感によって組み合わせる工夫を行うことに日々血肉を削っている。（たぶん）それを細やかに具体的に紹介したものが、本書である。
世界を良くするため、埋めたり切ったり
非エンジニアも、ワードやエクセルファイルを複数人が同時に編集して上書きされてしまったことなどあるだろう。ある仕事で私が昔携わっていた仕事では、共有しているエクセルファイルを編集する前にメールで「編集するから1時間程度触らないでください」と関係者に一斉送信し、終わったら「終わりました」というメールを流す、ということをやっていたが、このやり方ではシステム開発は不可能である。
規模が大きいシステムプロジェクトだと、デバッグ・新機能開発・保守作業で様々な要素を同時編集しなければならない場面が日常的に発生する。差分の中で想定外の不具合が発生した場合、任意の時点まで巻き戻せるということも必須である。前述の私の「ファイル変更をメールで告知」方式だと、絶対無理である。
Gitという現代のエンジニアにとっては常識中の常識であるバージョン管理の仕組みは、全世界共通のものである。こういう共通仕組みが存在するということは、全世界から知恵を集め、システムを改善していくことが全世界共通的に出来るということである。だからITは飛躍的に発展しているわけだ。プログラムのことが判らない人も、こういう仕組みが存在していることを知るべきだ。自分が作ったものをリリースしてソースが世界中の目にさらされて改善されていく仕組みがあるとは、ものすごい勢いで世界が改善されているということである。
タグとブランチという方法で、障害発生時の原因究明やロールバックを行いながら同時に新規開発を進める、ということを実現することができる。何かあったとき、これらは戻る箇所になるということを考えながら、エンジニアの方々は、タグを埋めたりブランチを切ったりしながら、日々ソースを書いている。
この本では、何をバージョン管理すべきか、ということも触れている。ソースコード、要件書設計書などのドキュメント、データベーススキーマとデータ、設定ファイル、ライブラリなど。やり方はひとつではなく、場合によって変えていく必要もあるとして、要素と場合分けを具体的に例示している。
設定ファイル、依存関係という、システム発注担当者・ユーザー担当者からはほぼ目に見えない、ソースの根幹ではない部品たち、その管理方法もソースの管理のように注意を払う必要があり、その注意点などが記されている。つくづく丁寧な本だと思うが、エンジニアにはそういう丁寧さが要求されている、ということなのだろう。
チケット駆動開発は、ユーザーとエンジニアを繋いでいる。
昔は、メールで不具合発生連絡や修正・リリース連絡を行っていた。今でも、エクセルで表形式で課題管理を行う管理は、まだまだ存在している。私の管理プロジェクトでも、この方法が生きている。でも、上記のようにバージョン管理とつなげていくためには、スタートとなるタスクの依頼から、管理していかなければならない。タスクとは、現時点でどういう問題が発生しており誰が何をいつまでに行うか、ということである。簡単なことのようだがこれができていないために、プロジェクトは炎上する。
タスクは検索性の観点も重要である。過去の改修の経緯が判りやすいことが、継続性を担保し、未来へつながっていく。
丁寧なこの本では、運用方法についても具体的なフローを提示してくれている。例えば、新機能の開発、バグ修正時のワークフロー、開発規模に応じたワークフローなどが例示されており、非常に参考になる。ユーザー目線では、自分が依頼したタスク（チケット）が、そのあとどんな工程を経て、自分が使える状態としてリリースされるのか、ぜひおいかけて欲しいと思う。
できれば、このチケット管理のワークフローもユーザーにも見える化してしまい、ユーザーにも全体が共有されるくらいが良いと思う。
丁寧なこの本では、チケット・バグ管理・要求管理のそれぞれの違いと管理上の注意も触れている。この観点は、ぜひユーザー側にも知っておいた方がいい。一括りにして、「動きがなんかおかしい」とエンジニアに話しかけるのは、紙芝居を創るためにテレビ局の制作部門に依頼するようなものである。
とてもとても重要な、「テストコード」
バージョン管理は素人には入るのが難しい領域なのでプロにお任せした方がいいかもしれないが、テストコードについてはユーザーでも理解した方がいい。なぜなら、ロジックを元に作り上げられたソース（システム）は、場合によってはユーザーの操作要件と乖離することがあり得るからだ。上記のような複雑な管理をされているソース（システム）は、場合によってはその管理に耐えるためにシンプルにさせられてしまう。その結果、ユーザーにとっては当然の、あるいは逆に想定外の操作で重要な不具合が発生することがあり得るからだ。ユーザーとして考えている標準的な操作・運用をできるだけ伝え、それが「テストコード」に表現されているか、確認することが重要で必要だ。自分はやってないけど。
CIという自動テストの仕組みを使うことで、デグレのリスクも減るが、結局はユーザーのテストも省力化される。この仕組みのおかげで、ユーザーは、運用のために省力化されたテストの時間を使うことができる。ユーザーもエンジニアの方々といっしょに、CIの神様に感謝を捧げた方がいい。
更に技術は進み、自動化は進み、ブートストラッピングというものが産まれる。これはサーバのセットアップの自動化と、仮想化技術を利用した環境構築の自動化ツールのこと。サーバを100台入れる時とか、超便利！って、そんな規模の開発案件、そうはないんだけど。丁寧なこの本、本当のターゲットは誰なんだろうか。きっと銀行のATMシステムとかでは使いそうなので、私は今後ATMでお金をおろすときに、ブートストラッピングの神様と自分の給与の原資を生み出しているお客様に感謝することにする。違ったらやめる。
最後にもう一度、エンジニアの仕事を考える🤔
以上のように、エンジニアという種族の方たちは、ユーザーの問題解決をフローチャート化し、ロジックに落とし、最適技術を探求し、且つ、完成品のテストを見据えたコードの記述＋テストを繰り返すことを想定した仕組み＋将来的な不具合や機能改善を見越したバージョン管理、などを日々考え、実行しているのである。
ユーザーも、このようなことを理解して、（あるいは理解したフリをして）
このような世界に心血を注いで、そして私達の業務をラクにしてくれるITシステムとその作り手たちに思いを馳せ、毎日PCに電源を入れる時に手を合わせ、リスペクトした方が良い。ごはんを食べる時に食べ物と作り手に対して手を合わせ、「いただきます」と言うように。