義理と人情
前に知り合いの営業マンから突然連絡が来たことがある。私を必要としている案件があるというものだったが単価が安くて断ろうとした。
然し彼女は面談だけでも出て欲しいと食い下がる。どうやら彼女のビジネスパートナーが技術者を紹介して欲しいと彼女に云っているらしくその依頼を断れなかったのだ。
それでも私が断ろうとすると、彼女はこう云った。
「あなたがその案件を引き受ければ私に対して貸しができるのだからいいじゃない。」
なんと自分勝手な理屈なんだろうと思った。もちろんそんな貸しに興味などない。だが以前に彼女には多少世話になった義理もあり怒らせても得策ではないと思い面談だけということで引き受けた。やはり私も日本人。義理と人情で動いてしまう。
鬼平にみる営業の苦悩
鬼平犯科帳に「盗賊二筋道」という話がある。
あらすじはこうだ。
高萩の捨五郎という盗人が子供を助けようとして侍に切られてしまう。捨五郎は怪我を理由に盗みの手助けという仕事を断るのだが、それを逆恨みされ、口合人の寺尾の治兵衛と共に命を狙われてしまう。捨五郎は治兵衛を助けようとして命が狙われているから逃げろと云うのだが、治兵衛は逆に捨五郎に、本当はこんな汚い仕事は断りたかったのだが浮世の義理で断りきれなかった、すまなかったと詫びる。
口合人は今で云えば仲介の営業マンである。その口合人が今回の仕事は義理で断り切れなかったと云う。治兵衛が如何に義理を大切にしているかがわかる。義理とは仕事の大切な道具なのだ。然しそれによる苦悩もある。
現代に於いても、この義理人情があるからこそ仕事になるというのは変わらない。また、その苦悩も変わらない。これが日本流の営業なのだ。
義理人情とは如何にも日本的な営業指針である。
論外な人たち
システム開発に於いてもしもプラットフォームやフレームワーク、開発ガイドがないならスクラッチで作るしかない。つまり技術者の属人性に頼りはじめから作るしかない。
現代のシステム開発で其れは非現実的である。何故ならプロジェクトのメンバーを自社社員だけで構成することは稀だからである。
協力会社に応援を要請し技術者を確保する場合、その技術者のレベルは低くても高くても問題となる。低いのもまずいが高けれいいというものでもない。彼等の書いたプログラムや設計のレベルが高過ぎて自社社員の開発メンバーがついていけないならやはり其れは問題となる。だからそうした事がないように開発ガイドやフレームワークを用意し品質の均一化を図る。
例えば良いシステムはログの書き方や実装の仕方をフレームワークや開発ガイドが示しているので、何処の同じ形式となり見やすく、詳細に書かれており追跡も容易になる。これは開発者にも運用者にも優しい。もしフレームワークや開発ガイドがないなら、まともなログが吐かれないかもしれない。例えまともでも形式が異なれば可読困難となる。
所で独自フレームワークをベースに開発したシステムの大半は追跡できないログを吐く事や苦労の末に追跡出来てもその問題を対応できない事を皆さんはご存知だろうか。もちろんこの原因は独自フレームワークの未熟さにある。
ログがまともであればそのログ解析や対応にかかるコストは減る。そうなれば開発者や運用者は残業しないで済む。
多くのプロマネはそうした事を分かっていないのだ。むしろ残業すれば済むことは大した問題ではないと思っている。そもそも残業しなければならなくなった原因は開発者や運用者にあるのだからそんなものはやって当然で、自分達の無能さ故に遅延した問題の対応にも我々は作業代を払っているのだ。感謝してもらいたいくらいだ。と思っているかもしれない。
もちろん其んな考えは論外である。
GOA
どうすれば曖昧な仕様書を見つけることができるか。
この問題に対する答えは簡単ではない。これまで多くの者が取り組み、そして挫折してきた。
しかし出来ないことではない。画面の必須項目チェックや桁数、型、和名、英名などの制約、関連性や整合性など、仕様書の明確な項目(センテンスを含まない箇所)を「ツール」を使ってチェックし曖昧さを除去することはできる。場合によってはセンテンスでもチェックは可能だ。
こういうと「いくらなんでも全てを明確には出来ないだろう」と思う方もいるかもしれない。勿論そうだ。全てを明確になど出来ない。だがする必要などそもそもないのではないだろうか。最初は一部で良いのだ。それだけで仕様書の精度はあがる。そしてそれを確認したら徐々に範囲を広げていく。最終的には仕様書の全てをカバーする。
また精度の高い仕様書はプログラムの自動化を可能にする。パターンに合致した仕様をプログラム自動生成することは難しいことではない。
仕様書チェックツールで仕様書の曖昧さを除去し、ジェネレートツールで仕様書からプログラムを生成する。私はこれをGOA(Generator Orientaed Aproach)と呼んでいる。GOAはこれからのシステム開発の基軸となる可能性を十分秘めている。
仕様書の曖昧さに気づくことの重要性
昨日は曖昧な仕様書に気づかない技術者の話をしたが、ではどうすれば曖昧な仕様書を見つけることができるのだろうか。いや、そもそもそんなことができるのだろうか。
答えはYESだ。勿論簡単ではない。これまでその問題に多くの者が取り組み挫折してきた経緯から考えてもそれは自明だ。しかし、出来ないことはない。ではどうやって？
一つの方法は明確なルールとチェックツールの導入である。
例えば画面の必須項目や桁数、型、和名、英名など。記述すべきルールを明確にし、それを守らない箇所を見つける「仕様書チェックツール」を使ってチェックするのだ。こういうと「仕様は必ずしも全てを明確には出来ないものだ」と反論をしたくなる方もいるかもしれない。しかし、そのような仕様は存在しないし、仮に存在するのならそのようなしよい仕様書をプログラムするのは不可能なのである。仕様書は全て明確にできる。
ではなぜこの世には曖昧な仕様書が蔓延っているのか。それは仕様書を書く技術者達が文章の「明確さ」より「エレガントさ」を選ぶからである。
仕様書を理解していない技術者
皆さんは、自分が仕様書を本当に理解しているか自分自身に問いかけをしているだろうか。
先日、私はある仕様書について担当者に質問をした。その仕様書は酷く曖昧で一目ではとても理解できない内容だったからだ。するとその担当者は「これは〜という意味ですよ。こんな簡単なことも分からないのですか？」と嫌味たっぷりに教えてくれた。だが彼の説明では全く理解できなかった。
そこで今度は「先程、貴方が言ったのはこのような意味ですか？」と具体例を示し、ついでに表と図も提示して質問してみた。すると彼はようやくその仕様書が曖昧であることを理解し、彼自身もその仕様書を理解していないことに気付いたのだ。そして黙ってしまった。それから暫くして
「うーん、この文書は曖昧ですね。これじゃ分からない。一体誰が書いたんでしょう。それにしても、よくもまぁこんな酷い文書を今まで誰も指摘しなかったものです」
と、被害者面をしてこう言ったのである。「こんな簡単な事も分からないのか」と言った舌の根も乾かぬうちに放った台詞がこれである。私は呆れた。恐らく彼は数分前に自分が言った台詞など覚えていないに違いない。
残念ながらこのような御仁は業界にはごまんといる。だが彼等を我々は笑えるだろうか？
これは他人事ではない。我々はいつ彼等に会うかもしれない。いや、それならまだましだ。もしかすると我々自身が加害者になるかもしれないのである。
