システム開発の品質向上をおいしいラーメンの作り方に例えて考えてみる。
稼動システムで発生する不具合は、仕様漏れ、設計漏れ、開発時のコーディングミス、テストケース漏れ、その後のハード、ソフトウェア等の環境変化によって発生する場合など多岐にわたる。
まずい（食べたくない）ラーメンが発生する場合は、食べたいラーメンがわからない、作り方を知らない、不器用、味見しない、麺が延びる等の環境変化によって発生する場合など多岐にわたる。
こう考えた場合、システム開発とラーメンの調理には共通点が多いことに気がつく。
そこで、うまいラーメンを作る秘訣を知れば、高品質なシステムが作れるのではないかと研究を行った。
おいしいラーメン屋が繁盛しているのは、そこにノウハウとレシピ、失敗談があるからであった。
システム開発の中で発生する不具合。不具合の緊急対処の後には恒久対策として是正処置を行う。是正処置を行うことで同様の不具合の再発を防止するためである。
是正処置を検討していく最中にラーメンが食べたくなり、「美味いラーメンがなぜ美味いのか」を考えていくと、そこにシステム開発の是正処置に対するヒントがあったため、まずは美味いラーメンについて研究を行うこととなった。
稼動システムで発生する不具合は、仕様漏れ、設計漏れ、開発時のコーディングミス、テストケース漏れ、その後のハード、ソフトウェア等の環境変化によって発生する場合など多岐にわたる。
開発側としては、主に
作業のフローは、「UI,SS,PS,PG,PT,IT,ST,OT」で行われる。しかし、各工程にはV字の関係があり、例えばUIで作成した設計書を元にSTを行う。 SSで作成した設計書を元にITを行う。PSの内容を元にPTを行うといった関係がある。
| UI | -- | -- | -- | -- | -> | ST |
| SS | -- | -- | -> | IT | ||
| PS | -> | PT | ||||
| PG |
本来、バグが発見される工程はテスト工程ではあるが、その根本原因の工程は設計工程や開発工程で発生していたことが多い。
STで簡単なロジックミスが発見された場合には、PTのテストケース漏れではあり、発見されるべき工程はPTではあるものの、原因工程はPSやPGである。
まずいラーメンができる原因は、食べたいラーメンがわからない、作り方を知らない、不器用、味見しない、麺が延びる等の環境変化によって発生する場合など多岐にわたる。
システム開発の各工程にまずいラーメンができる原因を当てはめるとこうなる
ラーメンといっても、スープが醤油や味噌、魚介、とんこつ、コーンバター……様々である。
あっさり系やこってり系という表現で、食べたいラーメンを表現する人も多い。
細麺に太麺、麺のゆで方。具の中身まで要求する人もいる。カスタマイズでネギや煮玉子までつける人までいる。
せっかく美味しく作ってるのに、コショウで味を変えたりする人もいたりする。
「ラーメン食べたい！」これだけでは、何のラーメンを食べたいのかわからない。
近場のラーメンでいいのか、遠出の美味いラーメンがいいのか、安いラーメンがいいのか、カップラーメンがいいのかすらわからない。
「麺類がいい！」こうなると、うどんやパスタも加わってますますスパゲッティである。
食べたいラーメンを聞いてあげるのが大切だ。
もちろん、自信のある人は相手に聞く必要はない。うまいラーメンを相手の目の前に出してあげるだけでいい。
「自宅で作ったとんこつラーメンが食べたい」
ちょっと待て。自宅でとんこつラーメンなんか作れるかよ。
せっかく食べたいラーメンがわかっても、作れなければどうしようもない。
最悪、出前かカップラーメン、即席めん等で作ればいい。
どうしても自宅で作りたいならレシピを調べればいい。
作り方がわかれば、あとは作るだけである。
「（つくろう思ったけど）自分不器用なんで」
最初から美味く作れる人なんていないのである。
過去の経験や知識、ノウハウで美味くなってくるのである。
自分で作れないなら、人に作ってもらえばいいのである。
とんこつスープの元とか、ゆでた麺とか出来合いのものを用意するのも手ではある。
次は味見である。一応、具そのものの味とか少しはここで確認しておいて欲しい。
余談ではあるが、こだわる人は麺まで自分で作るのである。
既にあるものは使わず。自分の作ったもののみを信じ、使うのだ。
他人の作ったものは、合成着色料やアレルギー性物質が含まれていそうとか、汗やばい菌があるとか。
ついつい、自分の作ったものはなによりも優れてしまう。そう思うのだ。
自分が作ったタマゴご飯に「究極の味！」と感じた経験はないだろうか。
「できたから、食べて」
ちょっと待て。味見くらいして欲しい。毒味しろとまでは言わないから。
「まずは作り方が間違っていないかくらい確認してはどうだ？ チャーシューはチャーシュ自体の味を逃がさないために最後に入れろ」ってあんだけ言ったのに……。
そこまで聞いていないよと言いたくなる。それにそこは好みの問題である。
相手の要求をさりげなく満たす。そんな感動を与えるラーメンってのはまた食べたくなるもんである。
なにはともあれ、レシピやメニューの行間を読む、ノウハウを知る、相手の好みを知ることは大切である。
そこまでしなくても一度味見して、調味料の調整はこの辺でやっておいて欲しい。
「自分はこの味がいいんです！」と貫くためにも。
失敗談と言うものは何事にでもあるもの。
失敗は成功の基。次に活かすことが大事。
行列ができるようなラーメン屋には師匠がいたり、経験知があったり、過去の失敗談を活かしていることが多い。（もちろん、その他の要素も多い）
繁盛しているチェーン店では既にスープの素が配送されていたり、レシピが決められているものである。
誰が作っても同じ味になるカップラーメン、即席めんの味も度重なる研究の成果である。
また、自分だけが食べるのなら自分が作ったラーメンが不味くても、我慢して美味いように食べれるのである。
本当に美味いのか味見してもらって、確認することも大切。
おいしいシステム開発を行うためには、美味いラーメンの秘訣を当てはめてみる。
| 師匠 | （狭義では）先輩PGやSE |
| 経験知 | ガイドライン（基本となる物の考え方、概念） |
| 過去の失敗談 | ノウハウ集、失敗談 |
| レシピ | 具体的な手順書 |
| 即席麺 | テンプレート化、定型化 |
| 味見 | レビュー |
先輩PGやSEの知識、過去の資産のノウハウを得ることが大事である。
ソースを眺めることも大事。ソースにかかれていない背景（速度重視か可読性重視なのか等）も重要であったりする。
プロジェクト、社内に限らず、偉大な先人はこの世の中には数多く存在する。知らないフリをするのはもったいない。
例外処理の動作やテスト方法の考え方（入力値のテストの観点）などをガイドラインとして作成することで、プロジェクト共通の知識としてプロジェクト全体のレベルアップをはかる。
ものの考え方を伝えることで、新たなアイディアの発見と短時間で共通の認識を持つことができる。
当たり前のことが問題になることは少ない。なぜなら数多くの確認作業をすり抜けたケースであるからである。
システム開発においてはレアなケースが問題になることが多い。
過去の失敗談やノウハウ集を作成することで、ハマリや漏れを無くすことができる。
よくあるレアケース集という……わけのわからない資料である。
IT業界では毎年、新人への期待度が高まっている。自分たちで残してきたノウハウを新人は既に知っていなければならない。
はじめからできる人なんていない。そんな時に具体的な手順書が必要である。
ガイドラインは抽象的に記述し、手順書は具体的に記述すべきだと考える。
誰がやっても同じ結果が返ってくる。これが求める形の1つである。
熟練者や新人、誰がやっても規定レベル以上の結果が返ってくる。
コードの記述方法やコードのチェック基準のテンプレート化はもとより、 テスト仕様書等もテンプレートから作成できれば規定レベル以上のテスト仕様書を作成することができる。
ケースに応じてチェック項目が確認できるような資料があればよいと考える。
セルフレビューは甘くなりがちである。
自分の作った資料の誤りが気がつきにくく、他人の資料の誤りには気がつきやすいものである。
レビューを行うことで、被レビュー者だけではなくレビュー者の成長もできる。
レビューは行うべきではあるが、そのリソースがないのが現状である。
共通のセルフレビューのチェック票を作成するのもひとつの方法である。
時間と金と技術力とやる気があれば、いいものは作れる。
完璧ではないところを除けば完璧なシステムが創れるのである。
完璧ではなくても、あるラインまでは完璧と言えばいいものである。
合格点が80点なら、80点以上で合格なのである。
本当においしいシステムは、利用者も作成者もWin-Winの関係である。
おいしいシステムは、また食べたくなるものである。
