見出し画像
Photo by algo2020

「100日後に退職する47歳」について、47歳の大学教員が解説 〜ことはじめ〜

sozo@IT×介護×情報処理学会

最近話題です。トラブル対応に追われるITエンジニアのTwitter漫画「100日後に退職する47歳」。同じような経験をしたITエンジニア界隈で、「心臓が痛くなる」と・・・。

すでに完結し、書籍化もされたようです。

この漫画で出てくるような体験は、体験したことのあるITエンジニアからすると、ドキドキ、ヒリヒリするような経験ではないかと思います。AIで業務は自動化され、仕事を奪われる、とも言われていますが、そのAIのベースとなるITシステムの舞台裏では、こういうITエンジニアが神経をすり減らしているんですね。

私自身は、大学で教鞭を執る立場の47歳ですが、これまで研究プロジェクトでいろいろな実験システムを現場に入れてきたので、この漫画で出てくるようなトラブルは、ほぼ全て経験したことがあります（自慢できることでもないですが・・・）。

なので私もこの気持ちがよく分かります。これからプログラマを目指す方や、ITに興味のある方、それ以外のITを利用している全ての方に、知っていてほしい内容だなぁと思います。

でも、実はこの漫画、IT用語のオンパレードなんですね。業務を描写しているので当然なのですが。私も何度か読んでみて、業界の外の方が見たら、分からないだらけだろうなという気がしてきました。

そこで、プログラミングを始めたばかりの大学生に、

「いいかい、プログラミングっていうのはね、建築でいったら犬小屋の作り方みたいなもんだよ。本格的なITシステムを作るのとはね、高層ビルを作るくらいに違うもんなんだ」

と教えていた私が、この漫画を、一般の方にも少しでも分かっていただけるように、ITシステム業界での常識、の解説をしてみたいと思います。

では、おつきあいいただければと思います。

ITシステムができるまで

まず、ITシステムができあがるまでって、どういう工程を経るのでしょうか？

プログラムを書く？・・・それも正解ですが、プログラムを書くのは、全体の工程の2割程度にすぎません。

1. システムの設計、つまり仕様を策定
2. プログラムを書く（コーディングと呼ぶ）
3. 仕様通りにできたかどうかの試験（テストと呼ぶ）
4. 試験に合格したら、公開する（リリースと呼ぶ）

建築でも、まずは1. 設計士さんが設計図を書いて、2. 建築士さんがその通りに作って、3. 最後に現場監督や設計士、お客さんが、その通りにできたかを確認しますよね。それと同じです。1と2が同じかを検証する3というステップが重要になるんです。

この3つのステップは、どの製造業にも共通しますから、製造業に少しでも関係する方なら分かるかと思います。そうでなくても、営業などで、1. お客さんから注文された発注書にしたがって2. 商品を用意して納品し、3. お客さんの検品を受ける、というステップに似ているので、分かりやすいかと思います。

ただ、ITシステムは作って終わりではない

ただ、インターネットが当たり前となった今では、やっかいなことがあるのです。それは、

作った後で何度でも作り直し（バージョンアップ）できる

ということです。これは、ITエンジニアにとっては、良い点も悪い点もあります。良い点は、バグのあるシステムを公開してしまっても、あとで修正することができる点です。普通の製品なら、謝罪して回収して、と莫大な費用がかかる製品の改修を、だれも気づかないうちにこそっとやることも可能になります。

一方で悪い点は、公開した後も、ITエンジニアの仕事がなくならない、ということです。普通の製品なら、営業マンやサポート窓口が、製品の使い方や故障、改善の要望のやりとりをすればよく、開発者（エンジニア）は次の製品開発まではのんびり（？）していて良かったはずです。

ですが、ITシステムでは、不具合があればすぐにでも対応してバージョンアップしないといけない、不具合がなくても利用者の要望に応じて、機能改善や拡張をできる（しないといけない）という状況で、ITエンジニアが休まる日はない、ということになってしまうのです。

漫画の1日目から何度も、「リリース」っていう言葉が出てきますよね。

漫画の26日目に、社長からの依頼で問題をすぐに直してほしい、などという依頼もきていますよね・・・。

正しいITシステムは、だれも知らない

ただ、ここでまた問題があります。それは、

1の仕様を完全に書くことはほぼ不可能。

なことです。昨今のITシステムはとても複雑ですから、その機能を全て書き出すことは、かなり大変なのです。

例えば、漫画では、30日目に、新米のEさんは「こんなところにマイナスの値を入れる人いるんですか？」と言っていますが、例えばこの値が体重なんかだとしたら、人間はマイナスは入力しないと思うでしょう。でもシステムはそういうことが分からないのです。

もし仕様をちゃんと書くなら「取り得る値は0以上最大?桁である。それ以外の値は提出時にエラーメッセージを出さないといけない」と書かなければいけません。さらには、「エラーメッセージ機能」の仕様を加えなければいけません（最近は開発フレームワークというしくみでエラーメッセージ等は簡単ですが。）

このような具合ですから、特にリリースが近々に控えているような現場では、1の仕様もそこそこにある程度のところまで書いて、それで進めるしかない場合も往々にあるわけです。それが原因で上のようにトラブルになることもあるわけですが、それでも仕様を全て書いてテストするのに比べれば、トータルの時間も費用も少ないことが多いわけです。1の仕様の決め方も、高度な経験とセンスが求められることになります。

新米のEさんは「これは仕様と言えるんじゃないですか？」と聞いていますから、要は仕様に書いていないのだけど本当は仕様だ、と言うことなんですね。仕様を読む側もスキルが求められます。

それだけではありません。発注者がITに疎いほど、求める物があいまいだったり（データを確認できるようにしてほしい、（どの？誰が？いつ？）など）、矛盾していたり（あるときはボタンが上にほしい、あるときは下にほしい、など）します。

この漫画では、お客さんからの要望（要求・要件と言ったりします）が曖昧だったり矛盾があったりする例はないですが、少し関係があるのは、この漫画でダークサイドっぽく描かれている、別チームのCさんが、15日目に問題を突っぱねたことです。

ここでCさんは「平均応答時間は仕様を満たしている」と対応要望を突っぱねたわけですが、そもそも「平均」ということは、最大でどのくらいかは書かれていないわけですね。いくら平均が妥当な値であっても、大きなばらつき（分散）がある場合は、やはり周りに悪影響を与えることもあります。なので、ある意味、仕様があいまいだったといえます。（だからCさんも誠意を持って対応すべき、だと思いますが、Cさんの人間性についてはそのうち、書いてみようと思います。）

このように、1の仕様が完璧にはできない、だから2のコーディングができたとしても、3でテストを完璧にすることができない、ということになってしまいます。ITってもっと賢いかと思ったけど、案外不完全な世界なんですね〜。

バグと、テストについて

システムが完璧でない、つまり不具合があることを、バグがあると言います。つまり、これは1の仕様（これは理想のものであるとして）にそって2のプログラムができていないことを指しますが、このバグを、どのように3のテストで確認するのか、について色々な言葉が漫画でも出てくるので、少し説明しておきます。

まず、人が書いたプログラム（ソースコード）は、そのままではコンピュータは実行できません。プログラム言語によって、次の２つの方式に分かれます。

・コンパイラ型：プログラムを、一旦コンピュータが実行できる形式に翻訳（コンパイル）する方式。C言語とかJava言語（Java言語は正確にはインタプリタの性質ももあるのですが、コンパイルはします）。
・インタプリタ型：プログラムを、コンピュータが実行できる形式に同時通訳してその都度実行する方式。PHPとかJavaScriptとか。

このうち、コンパイラ型では、プログラムをコンパイルするときに、文法がおかしい、などと失敗（コンパイルエラー）するので、そこでバグを発見することができます。インタプリタ型では、実行時にエラーがでます（実行時エラー）が、コンパイラ型でも、実行時エラーはあります。

さて、問題なのは、実行時エラーは実行してみないと、バグが発見できないことです。例えば存在すると思っていた物が存在していなかった（Null pointer）り、10個しか入らないところ（配列）に11個目を入れようとしたり、-1番目を取り出そうとするのは、コンパイル時には見つからなかったりします。

漫画でも3日目に、5年前のバグが見つかっていますよね。

なので、それらのバグをリリース前にできるだけ見つけるために、いろいろなデータ（テストパターン）を用意して、3で試験（テスト）するわけです。

いろいろなテスト

3のテストにも、いろいろなものがあります。ここでは漫画に出てくる用語が分かる程度に、簡単に紹介します。

まずは、そのテストの規模での分類です。

A) 単体テスト：ソフトウェアの部品ごとに行うテスト。
B) 結合テスト：部品をつないだときにちゃんと動くかのテスト。
C) システムテスト：システム全体を使ったテスト。

漫画では、単体テストは、担当者が一人でやっていますね。
例えば28日目に、新米のEさんが「修正終わってます！」と言っていますが、単体テストが終わっておらず、それどころかテスト以前に、コンパイルエラーが出ているもので、2のコーディングもまだ終わっていない、ということになります（新米がやりがちな、かんちがいですね。）。

別の分類として、こういう分類があります。

・機能テスト：システムが何を（What）するか（機能）に対するテストです。
・非機能テスト：システムがどのように(How) 動作するかに対するテストです。

機能という言葉をきちんと定義するのは難しいのですが、例えば自動販売機であれば、お金を入れてボタンを押したらジュースが出てくる、おつりレバーを引いたらおつりが出てくる、といったことをテストするのが機能テストで、ジュースが冷たく冷えていること、とか、ボタンを押したら5秒以内に出てくること、といったことの確認が非機能テストになります。まぁ、「機能＝プログラムで直接書けること」という意味だと思っておけば間違いないでしょう。

実を言うと、上記のA)単体テストとB)結合テストでは、ほとんど機能テストしか行いません（ここのところは、私が間違っているかもしれません。ご指摘歓迎します。）。なぜならAやBではシステム全体でテストしないからです。自動販売機のボタンのテストだけでは、5秒以内に出てくるなどとは確認しにくいですよね。

だから、実はC)システムテストが、非機能テストに関して多くの責任を担っている、ということになります。

このC)システムテストですが、さらにいろいろなテストに分かれます。漫画に関係ある主なところだけを上げると以下のような感じです。

・C)システムテストでの機能テスト：いろいろあるようですが漫画では出てこないので、触れません。
・D)システムテストでの非機能テスト：安全性を確認するセキュリティテスト、使いやすさを確認するとユーザビリティテスト、処理能力を確認する性能テスト、大量の処理をさせてみて確認する負荷テスト、長時間の稼働に耐えられるかを確認するロングランテストなど。。。

一言で3.テストと言っても、いろんな種類があるんですね。漫画では、性能テストと、負荷テストが出てきて、チームで対応してますね。

漫画の2日目では、「負荷テストできてない」なかでリリースをして、すぐにログインできなくなっていますね。（実は実稼働しているシステムの負荷テストって、別の同様の環境を用意してあげないといけないので、準備の手間的にもなかなか大変なのですよね。）

そして、8日目には、性能テストと称して、負荷をかけています。

しかし、13日目にリリースするもののすぐ不具合が出ます。ダークサイドCさんチームのサーバの応答が遅かったとのこと。

これの解釈としては、負荷テストはやったものの、性能テストでやるべき（Cさんサーバとの連携も含めた）十分な項目をテストできていなかった、ということでしょうか。

ITエンジニアは知っているタイムマシン

ここまで、ITシステムができるまでのステップと、それの完成をテストする考え方について補足しました。プログラマを目指す方や、そうでない方にも、この漫画を読んだITエンジニアの気持ちが、少しでも分かっていただければなと思います。

さて、この漫画でのITエンジニアの環境を理解するにはもう一つ大事な概念があります。それは、ドラえもんのタイムマシンのように、今のシステムと過去のシステム、そして複数人で開発中のシステムを自由に行き来できるバージョン管理システム、の概念です。だいぶ長くなってきたので、また要望があれば、少し書いてみたいと思います。

最後に

他にも、この用語って何？と言う質問があれば、コメント欄にお願いします。できる範囲で、お答えしてみようと思います。

この記事は、気が向けば、「プロジェクト編」「生き方編」と続けていこうかなと思いますので、ご興味がある方向があったらコメントいただければと思います！


この記事が気に入ったらサポートをしてみませんか？