システムを創る仕事をリスペクトを込めて知ったかぶりする

システム開発に携わることが多く、その都度エンジニアの方をリスペクトする出来事がある。以下はQiitaというサイトで私が書いた文章を改編しており、自分の想いとしてこちらにも投稿する。システム用語に通じていないと読みにくい文章ではあるが、最後の太字の文章だけでも読んでいただけたら。そして自己紹介のときと文体が変わってごめんなさい。

参考にした本
チーム開発実践入門 ~共同作業を円滑に行うツール・メソッド (WEB+DB PRESS plus)出版社: 技術評論社　– 2014/4/16　池田 尚史 (著), 藤倉 和明 (著), 井上 史彰 (著)

私は昔、VBプログラマだった。最初に入った会社でプログラマという職種で仕事をし、そのあとも、システム系の仕事にはまることが多かった。転職した会社ではユーザー部門のシステム発注担当という立場も経験し、今ではまたベンダー側のシステム導入時のアドバイス担当である。 そんな私が常々思うことは、全ての、システムを使うユーザーという立場の人は、システムはチーム、つまり複数人がオーバーラップし、引継ぎを重ねて作り上げるものであることを、知った方が良いということだ。

システム開発および運用時に管理するべき要素は、ソースコード、データベーススキーマ、設定ファイル、依存関係、要件書や設計書といった、それぞれに役目がある膨大な要素が存在している。それらを、エンジニアの方々は「タグを埋め」「ブランチを切って」、システムのバージョン管理を行っている。またチーム開発として、「チケット」というものでタスクを役割分担し、管理を行い、プロジェクトとして統合させたりしなければならない。このように複雑な要素をタスク化してプロジェクト管理していくマネジメントシステムが、世界共通的に出来上がっている。これを継続するために重要なことが、「テストコード」「CI」「リファクタリング」という三種の神器とされ、エンジニアの方々が、炎上案件で何度も丸焦げになって、生み出されて来た仕組なのである。炎の中から生まれたこれらの神器たちを心の底から崇めたい。

エンジニアという作り手側には、他者が作ったものを直す、付け加えて拡大するという作業を、効率的且つ品質高く行うための専門的ツールが山のようにある。ツール自体ももちろん日進月歩である。エンジニアの仕事は、ユーザー要望をシステム仕様に落とし、設計し、ソースを書くだけではない。作る過程を効率的にするため、作ったものを保守し続けるための配慮を行う必要がある。それをサポートするための専門的なツールが山のようにあり、それぞれを、プロジェクトやチームの規模・レベル感によって組み合わせる工夫を行うことに日々血肉を削っているのである（たぶん）。

非エンジニアも、ワードやエクセルファイルを複数人が同時に編集して上書きされてしまったことなどあるだろう。ある仕事で私が昔携わっていた仕事では、共有しているエクセルファイルを編集する前にメールで「編集するから1時間程度触らないでください」と関係者に一斉送信し、終わったら「終わりました」というメールを流す、ということをやっていたが、このやり方ではシステム開発は不可能である。

Gitという現代のエンジニアにとっては常識中の常識であるバージョン管理の仕組みは、全世界共通のものである。こういう共通仕組みが存在するということは、全世界から知恵を集め、システムを改善していくことが全世界共通的に出来るということである。だからITは飛躍的に発展しているわけだ。プログラムのことが判らない人も、こういう仕組みが存在していることを知るべきだ。自分が作ったものをリリースしてソースが世界中の目にさらされて改善されていく仕組みがあるとは、ものすごい勢いで世界が改善されているということである。これこそ神の仕組みと言えるのではないだろうか。（業界ではすでに常識中の常識）

タグとブランチという方法で、障害発生時の原因究明やロールバックを行いながら同時に新規開発を進める、ということを実現することができる。何か想定外があったとき、ここが戻る箇所になるということを考えながら、エンジニアの方々は、タグを埋めたりブランチを切ったりしながら、日々ソースを書いている。たぶん。 設定ファイル、依存関係という、システム発注担当者・ユーザー担当者からはほぼ目に見えない、ソースの根幹ではない部品たち、その管理方法もソースの管理のように注意を払う必要があり、それぞれに注意点がある。膨大すぎる。

昔は、メールで不具合発生連絡や修正・リリース連絡を行っていた。今でも、エクセルで表形式で課題管理を行う管理は、まだまだ存在している。私の管理プロジェクトでも、この方法が生きている。でも、上記のようにバージョン管理とつなげていくためには、スタートとなるタスクの依頼から、丁寧に管理していかなければならない。タスクとは、現時点でどういう問題が発生しており誰が何をいつまでに行うか、ということである。簡単なことのようだがこれができていないために、プロジェクトは炎上する。タスクは検索性の観点も重要である。過去の改修の経緯が判りやすいことが、継続性を担保し、私たちの未来へとつながっていく。

最初の開発が終わりシステムがリリースされ、運用保守フェーズに入っても、様々な管理のフローが必要である。例えば、新機能の開発、バグ修正時のワークフロー、開発規模に応じたワークフローが存在する。ユーザー目線では、自分が依頼したタスク（チケット）が、そのあとどんな工程を経て、自分が使える状態としてリリースされるのか、ぜひ追いかけて欲しいと思う。できれば、このチケット管理のワークフローもユーザーにも見える化してしまい、ユーザーにも全体が共有されるくらいが良いと思う。 チケット・バグ管理・要求管理のそれぞれの違いと管理上の注意が必要だ。この観点は、ぜひユーザー側にも知っておいた方がいい。一括りにして、「動きがなんかおかしいから直して」とエンジニアに話しかけるのは、紙芝居を創るためにテレビ局の制作部門に依頼するようなものである。

バージョン管理は素人には入るのが難しい領域なのでプロにお任せした方がいいかもしれないが、テストコードについてはある程度はユーザーでも理解した方がいい。なぜなら、ロジックを元に作り上げられたソース（システム）は、場合によってはユーザーの操作要件と乖離することがあり得るからだ。上記のような複雑な管理をされているソース（システム）は、場合によってはその管理に耐えるためにシンプルにさせられてしまう。その結果、ユーザーにとっては当然の、あるいは逆に想定外の操作で重要な不具合が発生することがあり得る。ユーザーとして考えている標準的な操作・運用をできるだけ伝え、それが「テストコード」に表現されているか、確認することが重要で必要だ。自分はやってないけど。

CIという自動テストの仕組みを使うことで、デグレのリスクも減るが、結局はユーザーのテストも省力化される。この仕組みのおかげで、ユーザーは、運用のために省力化されたテストの時間を使うことができる。ユーザーもエンジニアの方々といっしょに、CIの神様にも感謝を捧げた方がいい。

更に技術は進み、自動化は進み、ブートストラッピングというものが産まれる。これはサーバのセットアップの自動化と、仮想化技術を利用した環境構築の自動化ツールのこと。サーバを100台入れる時とか、超便利！って、そんな規模の開発案件、身近にそうはないんだけど。きっと銀行のATMシステムとかでは使いそうなので、私は今後ATMでお金をおろすときに、ブートストラッピングの神様と自分の給与の原資を生み出しているお客様に感謝することにする。違ったらやめる。

以上のように、エンジニアという種族の方たちは、ユーザーの問題解決をフローチャート化し、ロジックに落とし、最適技術を探求し、且つ、完成品のテストを見据えたコードの記述＋テストを繰り返すことを想定した仕組み＋将来的な不具合や機能改善を見越したバージョン管理、などを日々考え、実行しているのである。 ユーザーも、このようなことを理解して、（あるいは理解したフリをして）このような世界に心血を注いで、そして私たちの業務をラクにしてくれるITシステムとその作り手たちに思いを馳せ、毎日PCに電源を入れる時に手を合わせ、ログインするときに感謝のことばを述べ、リスペクトした方が良い。ごはんを食べる時に食べ物と作り手に対して手を合わせ、「いただきます」と言うように。