ときどきブログ

サイゴンの行方

先日、数年ぶりにヴェトナムを訪れて気づいたことがあった。
この社会はかなり速いスピードで消費社会に変貌している。
消費が増えて経済が活性化すればさらに豊かになれるわけで、これは歓迎すべきことだ。
富めば暮らしぶりに余裕が出るのか、路上の交通マナー一つとっても以前より秩序が感じられるようになった。
変な話だが、都市部ではバイクが洪水のように走っているサイゴンでは、数年前までヘルメット着用義務がなかった。
たとえば父ちゃん母ちゃん子供たちで４，５人で一つのバイクに全員ヘルメットなしで乗っていたり、交通安全を考えた場合にはあり得ない光景が寧ろ普通であった。
今は殆ど全員がヘルメット借用だし、無茶な家族全員での乗車などもあまり見かけなくなった。
信号機というものも殆どなく、十字路でのバイクの大群の行き来はもはや交通というより弱肉強食という言葉を連想させるものだった。
それが各所に設置された信号機の制御に皆が従い、赤信号なら皆ちゃんと待っている。
そうしたインフラの正常化をうけてか、公共の乗り物である路線バスが活発に運行するようになり、交通事情は大きく変化しているようである。
サイゴンのど真ん中に地下鉄の駅を作りサイゴンの街を縦断する路線を５年くらいかけて建設中とのことである。
これに関して住民は冷ややかというか冷静である。「５年といって５年でできると思えない。だってここはヴェトナムだ。」と異口同音に言う。
メコンデルタに近い決して固くはない地盤だと思うが地下鉄を掘るだけしっかりしているのか、部外者なりに心配だがかつて海辺であった東京でもどれだけの地下鉄が地下に走り回っているかを考えれば問題ないのかもしれない。
街は再開発が進みスラムのようだった場所がきれいな景観に変わった。
大手のショッピングモールなどが進出して外国人ではなく一般の人たちで賑わうようになった。
これは喜ばしいこと　のはずだ。

こんなサイゴンの現状を見て何とも表現しにくいけれども、何故かどことなく寂しさを感じた。
以前感じられた強烈な臭気にも似た生々しさが感じられないのだ。
地方に行けばまた違うのだろうが、サイゴンは間違いなくアジアの大都市への道をひた走っている。
その反映の影で逆に失うものがあるとすれば、それこそが「サイゴンらしさ」の部分かもしれない。

経済発展の影で貧富の差が広がり、貧しい人は一生チャンスが得られない社会。
せいぜいスリ引ったくり程度だった犯罪がより高度化し、一見普通に見える凶悪犯が街を跋扈する社会。
効率、利益を追求するあまり人の心や繋がりを軽視する社会。

我々日本人は高度成長の果てに社会がそれまであった人の心の豊かさを、人の優しさを、そして人の繋がりを捨てる経験をしている。
一見暮らしやすくなったように感じても、その底流に流れている人としての大事な何かを失ってしまっている。
発展の影で起きること、私たちがこの数十年日本で体験してきたことがまさにヴェトナムでこれから起きようとしているように思えてならない。
ゆえに寂しく感じるのかもしれない。

日本が失って取り戻せないもの、それも何よりも大事なもの。
豊かさを享受する代わりにそれを失わないでいてほしい、そう願うばかりだ。

ヴェトナムオフショア開発のツボ（13）

成功を導くために

不連続ドラマ：とあるオフショアプロジェクト 3

Y君は自社内システムの新規開発のためオフショア開発のプロジェクトに参加することになった。
会社が選んだマネジメントの担当者は誰よりも血の気が多く、開発部内の喧嘩屋S主任だった。
その人選に目眩を覚えるY君。。。

プロジェクトの体制が決まった時、Y君はS主任に挨拶に行った。
その時のS主任はいつもの「面倒なことに巻き込みやがって」という表情ではあったものの、数日後のキックオフのミーティングではメンバーのみんなと握手をするなど意外に”まともな”振る舞いを見せた。

その後プロジェクトのタスクを洗い出しスケジュールを決め、部内での承認ももらった。
タスクの洗い出しでは、S主任は周囲の予想を裏切るやり方で誰もを驚かせた。
基本的な要件をまとめた資料だけを事前に配布、あとはメンバー全員を集めてブレインストーミングを行ったのだ。
メンバー各自が想定するタスクを上げていく。
S主任はそれをひとつひとつ大きな付箋に書いてホワイトボードに貼っていく。
発言が出尽くしたところで付箋を手早くグルーピングしていくのはS主任が自ら行うのだが、発言者に「これはこのグルーピングで意図はあってるかな」と確認する。
そこには喧嘩屋の面影はなく、Y君はS主任のことをちょっと誤解してたかもと思った。
海外発注に際しての契約面での交渉ごとについて発言したメンバーもいたが、そのあたりは普段のプロジェクトではエンジニアがスルーするところなので、なるほどオフショアではそういうところも視野に入ってくるかなという新鮮な驚きがメンバーにはあった。
また、終始発言のないメンバーもいて、気になったのでY君はなぜ黙っているのかと訊いてみた。
そうすると、オフショアであろうが何であろうが、開発でやることは同じ筈なので、特段発言すべきようなことが見当たらないという。
それは誰もが暗中模索な中尤もな話ではあるが、イマジネーションの有無はプロジェクトをすすめる上では重要だ。
成長という観点でいえば、その彼にはむしろ最前線に立ってベンダーとやり取りさせたりする方がいいかもしれないと思った。

そしてブレインストーミングの産物であるタスクのグループは補填され収束され大線表となり、いよいよ最初のフェーズである設計の作業に入った。
今回のシステムの元となる現行のシステムに関しては、現状の仕様にあった設計書というものが存在しない。
過去に多々の改変改変を繰り返しているが、当初の設計書に反映されることはなく、差分の仕様のみが管理されている。
つまり、今まさに動いている仕様を把握するためには、過去からの仕様変更差分の履歴を時系列にたどるしかない。
この現行仕様をどうやってベンダーに伝えることができるだろう。
そのやり方をどうするかについての議論のさなかにS主任の喧嘩屋の本性が現れる時がいよいよやってきてしまった。

Y君は現行の仕様を差分の状態からまとまった仕様書にし、それを元に新しい設計を起こすことを提案した。
ところが、S主任はそれは不要で、現行システムにゲストログインして遠隔からでも制限付きで使えるようにし、仕様の細かいところはQ&Aでこなせばいいというのだった。
前者は設計書のまとめの時間がかかるし、実装の立ち上がりまでに間に合わせるのは大変だが、できないことでもない。
何しろ決定版の設計書が残ることは後々メリットがある。
後者はドキュメントの作成など最小限にするため、プロジェクトのパフォーマンス優先である。
しかし、Q&Aで対応するのにも夫々時間を必要とするため、その負担は仕様がどれだけ明快かという程度にもよる。

「とうとう面倒くさがり屋が本心を出したな」と思ったY君は少々ムキになって反論したが、S主任は当然きかない。
逆にS主任のきつい言葉を集中的に浴びせられて反対派は一人一人と陥落、結局はどうみても負担の軽い方法であるS主任の主張にプロジェクトの方針は決まった。
「まったくお前の話は古いよ、何時代の話だよ」というS主任の罵倒の言葉に打ちのめされてしまったY君は、すっかり意気消沈してしまった。
早くもこのプロジェクトに暗雲が立ち込めていた。

（続く　といいが）

ブレインストーミング

方向性を探るとき、問題点の整理をするときなど複数人でブレインストーミングを行うと効果的だ。
漠然したテーマで、そのテーマに関する各人の意見を出してもらう。
原則的にはどんな発言でもいいが、ルールはただ一つ、批判をしないことである。
意見を出す上で公平であることで、多様な意見を出させ、あとでそれを分類・分析する。
上記の例ではブレインストーミングとKJ法を部分的に取り入れているが、これはどのような形にしてもよいと思う。
ここでは誰もが経験したことのないプロジェクトで、どんなことをするかという目測に使っているが、こういう場合には最適ではないかという思いがあったのでこのフェーズでブレインストーミングの手法を入れてみた。

Y君とS主任の意見の相違

既存のシステムの仕様に関する議論については、まだここで決着はつけない。
後の話が続けばいずれその良し悪しについては触れるつもりではいる。
この場合、主張をぶつけあっている両者の意見はそれぞれに切実な理由がある。
それは決して相手を罵倒して自分の意見を通すことが正しい方法ではないことは明白なので、この場合Sさんのやり方には賛成しかねる点はある。
この場合、Sさんが「古い」といったのはあくまでY君の提案した方法のことである。
設計書をとりまとめるという作業には文書化という重要な意味があり、それがまずプロジェクトを動かす前提となっている場合も多々あるということは事実だ。
この足場にあたる部分をまずしっかりさせようというのがY君の意見。
設計書とはいっても、もしもその存在意義があまりない文書だとしたら、パフォーマンスを犠牲にしてコストをかけてまでやる必要がないという判断が出てくるのも当然である。
それならパフォーマンス優先で設計が理解できる他の方策で代用し先へ進もうというのがS主任の意見。
どちらが正しいかは一概には判断できず、Sさんのいうような新しいか古いかの価値観の問題でもないが、S主任はY君のやり方は古いと感じているのは確かだ。
果たしてそうなのか。。。これも重要な問題である。

ヴェトナムオフショア開発のツボ(12)

成功を導くために

不連続ドラマ：とあるオフショアプロジェクト ２

Y君は自社内システムの新規開発のためオフショア開発の計画書を作ることになった。
そして自分が作った開発書についての開発部長の話を思い出している。

部長：みんなオフショア開発っていってるけど、国内でやるのとは、どう違うのかな。

Y：はい。開発拠点が外国であるということは、まずは言葉の壁があるかと思います。

今回検討に上げているヴェトナムについていうと、一般的な会話はヴェトナム語ですが、業務的なコミュニケーションは英語になるようです。

部長：そうか、システム開発部には英語の堪能な人材はいたよな。。。

Y：全員とはいいませんが、まあ、なんとか対応可能だと思います。中には留学経験のあるものもいます。

部長：頼もしいな。ほかにはどういう違いがある？

Y：時差があるので現地の作業時間帯が日本とはずれると思います。

部長：ふむ。以前インドのベンダーを検討したことがあるんだけど、インドのオフショアが伸びた一つの要因として発注元の北米とは昼夜逆ということ があると聞いたことがある。
つまり、寝て起きたらあくる朝には進捗してるといった具合だな。その毎日ノンストップになる時間配分が絶妙に効果的だったということだ。

Y：。。。

部長：日本とヴェトナムでは、せいぜい２時間てところだ。この時差はどうなんだろう。どう思う？

Y：当然、北米対インドとは異なります。むこうが２時間遅いだけですから、ほぼ同時作業です。でも、日々の作業の結果は翌日以降に確認する形になります。

部長：そうだね。エンジニアの気質とか、そういうのはどうなんだろう。やっぱり違うのか。

Y：基本的には違うようです。ソフトウェア業界のモデルとしてはやはりアメリカとか見てますから、非常にビジネス指向の強い考え方で接してくると思います。
無茶な仕様変更とかは対応してくれないかもしれません。

部長：それで業務委託にするわけか。

Y：今までのうちでの開発のいきさつを見ているとすんなりいかないことが多かったように思いましたし。。。
部長：思ったより情報を収集しているようだな。じゃ、ちょっとシステムの概要について手短に説明してくれるかな。

そうして諸々の説明をし終わったあと、部長がY君にこう切り出した。

部長：そもそも君はオフショアの経験があるのかね。

Y：いいえ。ありません。

部長：よしわかった。基本的にこの方向で進めるが、マネージメントはS主任がやる。君はその下で動いてもらいたい。

S主任というのは、開発部の喧嘩屋ともいわれる人である。血の気が多い。他人とは絶対に連まないし、無理があるように思えることでも一度言い出し たら誰の言うことも聞かないクセものだ。

Y：え、Sさん。。。ですか。

部長：まあまあ、そんな顔するな。きっと彼は頑張るよ。

Y：はあ。

部長：あ、あと、業務委託では出せない。れっきとした開発請負でいく。これは会社の都合だ。それ以外はおおむねGOだ。じゃあね。

去っていく部長。その後ろ姿を見送るY君。
「Sさんかあ。まいったな。」

急転直下、とんでもない厄介者と仕事をするはめになったY君。彼の葛藤は解決するのか。

（また続くかも）

言語の壁

重要な話が出てきた。言葉の違いについてだ。
エンジニアたちが話す言葉が理解できれば確かに仕事はできる。ヴェトナムだからヴェトナム語、中国だから中国語、と語学に振り回されては時間が もったいない。
エンジニア間のコミュニケーション言語はそれとは別にあってもいい。英語が役立つならばそれを使えばいい。
実際中学から約十年英語を勉強している我々より英語を使うヴェトナム人の方が英語は一般的に流暢だ。
英語が苦手だからとか恥かきたくないからとかプライドがあって日本語で押し通すスタイルもあるかもしれないが、片言でも外国語に踏み込んだ方が圧 倒的に仕事上有利である。
寧ろ一方的な歩み寄りだけを期待するのははっきり不適切なやり方だと断言する。

時差

時差は両方の地を行ったり来たりする人には身体的に堪えるものだが、作業上で連携をする場合もなにかと制約がつきまとう原因となる。
Y君の話にもあるが、相手の標準時間が遅ければ、作業の終わりを待つことはそもそも無理だ。２時間の時差があるなら、相手が夜8:00でもこちら は夜10:00となり、いつも作業の終了を待っていては生活が破綻してしまう。
相手の時間が早ければその逆になるわけだが、東側を太平洋に面している日本という国の地理的な条件としてそれを考える意味はあまりないだろう。
時差のある相手とはどのように時間を使うか、こちらの時間、相手の時間と時計を二つ書いて簡単な作業シミュレーションをするといいと思う。
作業の流れがおぼろげにでも掴めたら、体制を組むのにも役に立つだろう。

その他

不意の呼び出しでの話にも関わらず、Y君はあらかじめいろいろとベンダーを絞り込むための情報収集をしていたようだ。
部長のちょっと意地悪な質問にも精一杯自分なりの意見も重ねつつ答えている。
これは大事なことだ。
システム開発の世界のことはいずれわかることとしても、実際に仕事が始まってから驚かされるのはむしろそれ以外の側面である。
仕事についての考え方、問題解決のこれがよくも悪くも裏切られていったわけだけれど、大して具体化したイメージがなくともなんとかなるといえばな る。
これがよくも悪くも裏切られていったわけだけれど、大して具体化したイメージがなくともなんとかなるといえばなる。
姿勢、経済観念など仕事としてわりに重要なファクターもあり、さらには一般的な国民はどんな暮らしぶりか、普段何を食べて、何に興味を持っている か、そんな一見取るに足らないような情報であっても、それが相手の具体像をイメージする上で非常に役に立つ。
私が個人的に抱いていたヴェトナム人のイメージは最初こうだった。

1 基本的に貧しく勤勉。
２ アメリカ好きで中国嫌い。
３ 牛を飼っている。（笑）
4 街にはたくさんの泥棒。

非常に偏っているといえる。故に点の導きかよくよく人間観察をするべく現地に足繁く通うことになったわけだ。
ちなみに都会で牛を飼っている人を今まで見たことはないが、実際に目にするまで都会といっても少し外れたら郊外になって水牛が田畑を耕している絵 を想像していたのだから我ながら可笑しい。
つてなどあれば、留学などで日本に来ている実際のその国の人たちと会って話す機会などあるといいだろうと思う。

また、金額の話をするのであれば、エンジニア単価の相場なんかは熟知しておいて悪いことはない。
知らないことは寧ろ罪になるだろう。

プロジェクトが始まる前はなにかと忙しい。
その時期に観光ガイドや語学の本を必死に眺めている人がもしいたら、Y君のような人かもしれない。
心の中でもいいから応援してあげたいと思う。

ヴェトナムオフショア開発のツボ（１１）

成功を導くために

失敗談をまとめてからあと、長らく中断してしまった。それも非常に長く。

この間仕事が忙しくなったというのは表向きの話で、その「どうやったらうまくいくか」というテーマの重さによって行き詰まったというのが実際のところだ。

そもそもソフトウェアプロジェクトに、こうやったらうまくいく、なんて話はあり得ない。

ここからは体験談という範囲を超えるけれど、一般的な開発手法的な話なら他にいくらでも情報はある。どう手を出すかを迷ってしまうところだが、この執筆で何に対して責任を持つというわけでもないし、逆に自分の思うように展開すればいいんじゃないかという開き直りのような心境になった。

．．．まあ、それしかできないのだけど。

そういうわけで、持論をまとめつつというアプローチで進めてみようと思う。

 

不連続ドラマ：とあるオフショアプロジェクト

長年開発に携わっていたシステム開発部があるが、フレームワークにあたる部分から自作ですべて賄っていた時代は過ぎ去りオープンソース開発が一般的になっている。それに伴い、メンテナンスをする対象の規模が小さくなり開発チームの規模をも縮小している。

しかし、旧来の業務支援システムをWebのシステムに乗せ替えて１０年。近年システムの負荷が増大し、しばしばトランザクション集中時にパフォーマンスが激しく落ちる事態になってきているので、システムのパフォーマンスをアップさせ、処理ノードは負荷分散し将来的にもスケーラビリティを確保できるような仕組みに移行する変更が必要になった。

ここでシステム開発部15年目のベテランY君が検討を開始することに相成ったが、そもそもこの10年を数人の人員でシステムのメンテナンスだけ行ってきた。検討を始める以前にどうやっても対応人員が足りないのは明白だ。これからそこそこの規模の開発人員を社内で調達するほどリソースの余裕もない。そこでY君は今回の開発をオフショア開発にすることを盛り込んだ計画書を作成した。計画書には、まとまった人員の確保、コスト上のメリット、システムの性質上開発の拠点は特に問わないことなどを強調した。オフショア先はインフラも整いつつありカントリーリスクも少ないヴェトナムを一推しとした。

この計画書を見た上司はY君の説明をほとんど聞かずに「これでは上を納得させられない。うまくいけばの話ばかりが書いてあるように見えるな。困難な状況になったときのヘッジについて考慮してるならその点もちゃんとアピールしないと。」と言った。もっともな意見だと思いながらも、Y君は考え込んでしまった。品質、費用対効果、保守性．．．考慮することはいくつもありそうだ。

Y君はさっそく対策を検討することにした。さて、Y君はどのようにして上司を説得できるのだろう。

オフショア開発が失敗してもなんとかリカバリする対策なんて沢山そうあるものではない。効果のほどは状況により様々だがとりあえず挙げてみよう。

 

１．開発先のエンジニアを設計に参加させる

オフショアでは設計内容のスムーズな理解が最も効果がある。その意味でこれはいい作戦だ。多くの設計工程のトラフィックなしにイテレーティブな開発に移行できる。問題はファーストコンタクトではどこの誰かわからない人材を設計に参加させる形になるので、事実上は不可能だということ。つまり実績が認められているベンダとの間にのみ有効ということだ。また、設計に参加した人材がいつまでもその会社に居続ける保証は低い。離職した場合にはすべて無に帰するリスクもある。

２．複数のフェーズに分けて開発する

全体をいくつかのフェーズに分けて設計・開発することにより、危険信号が点ったらその時点でプロジェクトを巻きとれるようにしておく。開発コストの点での痛手が解消されるように思えるが、冒頭で失敗した出来損ないを捨てるにしてもまともなモノにするにしても多くのヒトと金がまず間違いなくかかる。したがって、これは実効性のない対策の典型といってもよい。

３．複数の開発先に負荷分散する

すべてを一社に発注すると成功するか失敗するかはAll or Nothingである。だから複数のベンダに分けて開発を委託する。分割するポイントが重要で、これを誤るとインターフェースで矛盾が起きたときの収拾に一苦労が待っている。また、分割でなくまったく同じものの開発を複数のベンダに冗長的に委託するという荒技もある。この場合、コストがデメリットとなるだろう。

４．請負でなく構築支援として業務委託する

システム構築そのものを要件とせず、構築支援のような形での業務委託にすることで、要件の変更、工程の変更に柔軟に対応できるようにしておく。仕様が半端な状態での見切り発車には効果的かもしれない。ただ、一応のマイルストーンを決めて走り出さなければ無計画なプロジェクトになる恐れがある。プロジェクトを管理する側も相手側もその状況をよく理解して動くだけのナレッジが必要ということもあり、最もハードルが高い方法といえる。

 

これらの事をよく考慮して、プロジェクトの性質・目的にあった効果の期待できる方法を選ぶ。決して目に見える目先のコストだけが重要ではないことを理解している有能なマネージャであればよりよい対策を導き出す助け舟を出してくれるだろう。

Y君は開発先とは4.の業務委託の形にすることを計画書に盛り込み、オプションとして1.開発先の設計参加についても「可能であれば」との但し書きで追記した。また、発注先のベンダの情報については、数年前からオフショア開発を手がけている学生時代の同業の友人にアドバイスをもらっておいた。これを参考という形で記載しておいた。

 

件の計画書を清書し提出してから数日後、Y君は上司から呼び出しを受けた。行ってみると、そこには開発部長が同席している。

「忙しいとこすまない。例のプロジェクトの計画書の件で訊きたいことがあるのでね。」

Y君は「いよいよ来た！」と思った。

...

そして30分後、自席に戻るY君の心の中にはある葛藤が生じていた。

 （続くかも）

 

ここで重要なことはシンプルだ。

何事もメリットだけではない。デメリットの部分もよく照らしてみてから実行しようということだ。

そうすると、予想外の展開は予想外でなくなる可能性が高くなる。

次の一手

NRIがタイに現地法人、集積進む製造業などに狙い
http://itpro.nikkeibp.co.jp/article/NEWS/20130215/456525/ @nikkeibpITpro さんから

ニュースを読む限り、今回NRIがタイに乗り込むのは今までのIT企業のオフショ ア開発拠点などの展開とは異なる。
現地の製造業やサービス業へのITサービスの提案とあるから、これは海外を下請けとみるのではなく、マーケットとみている行動だ。
日本企業に資本力があって、海外に仕事の一部を持ち込むことでギブアンドテイクの共生を図ってきたのがこれまでとすると、いよいよ資本力は底をついてきており、海外のマーケットで稼いで生き残りに賭けようという”次の”動きなのだと思う。
日本企業の落日も明白な昨今ではあるけれど、投資動向にはもちろん敏感であるNRIがこうした展開をいち早く進めるということは、この動きが他の企業にも多いに影響するということになる。
内容としては決して新しいものではなく、ERPなどの展開とともに現地企業のコンサルティングにも手を伸ばしていくということで、欧米企業が従来とっていた路線の継承ではないだろうか。
欧米が取り残していたパイをとられる前にとっておきたい。。。そういう意味でインドに次ぐ東南アジアの大国、タイに進出するというのは当然の戦略だろう。
また、ミャンマーが民主化を進める動きを見せている中で、タイとミャンマーの隣同士の国での強力関係を日本企業の手によって築くという効果もあると思う。
また、政権移行中の中国の”これから”が見えないという不透明感も大きいだろう。
おそらくこれから経済成長が明らかに鈍化していくであろうこの中国という超巨大マーケットは、実際には日本の資本を必要としながらも政治的な圧力によりそれを拒否せざるを得ない抜き差しならない状況に陥る可能性がある。
だから、”中国の次”となり、この点でもタイが浮上したのかもしれない。

何にしても日本のこうした動きはASEANの国々にとっては歓迎に値する話ではないかな。

レビューはつらいよ

序章　レビューの観点を絞り込むと効果は上がるか

http://itpro.nikkeibp.co.jp/article/COLUMN/20120808/415153/

@nikkeibpITproさんから

日本には俳句という文学がある。
五七五の簡潔な言葉で情景や感情の表現などを凝縮する高度な言語力を求められる芸術だと思う。
極限にまで簡潔に絞られた言葉で多くの情報が語られるわけである。

さて、設計レビューはことのほかキツい作業だ。
ソフトウェアの開発プロセスの工程の前の方で問題を摘出しておいた方が問題の修正にかかるコストが低いことから、設計時の問題は設計工程の中でレビューという形でチェックするのが普通だ。
しかし、設計書といっても国際規格で「こういうもの」と決められているわけではない。
この設計書が仕様とあっているかをどのようにチェックするか、その具体的な方法はプロジェクトの数だけ、レビューする担当者の数だけあるといってもいい。
観点をより明確に絞ることで設計レビューとしての精度を上げようということだが、レビューする担当者の負担も軽減する、しいてはプロジェクトのコストの負担をも軽減する試みでもある。
そうはいっても、誤字脱字だらけ、意味不明なチャート満載の設計書などなら、本質的な部分はまったく見えてこない。
無理にレビューしても体裁の部分だけ指摘事項が挙がるだけで逆効果になる。
やはり前提として、ある程度の文書としての質が必要ということなのだ。

文章力、あるいは言語力というのか、まず言葉を使って物事を表現することにもっと普段から注意を傾けていくことが大事だ。
私の場合、日本語で書かれたドキュメントを初めて英語に翻訳したときに言語力の乏しさに愕然としたものだ。
それから、なるべく文章に触れるようにしているが、依然道半ばのまま、的確な言葉で的確に相手の理解を助ける表現方法というのは奥が深いと感じる。
そのうち、システムの世界でロジックを表現するならば言葉よりチャートや表など見たまま論理的である表記が優れていると思った。
その形式ならば、万が一言葉の間違いがあっても大きな誤解は避けられるかもしれない。
旧来の文章で書き連ねる設計書よりUMLなどの記法が優れているのはこういった直観的効果だと思う。
その内容はあれこれと例外的な内容を細々と書き入れるよりも簡潔な方が効果が上がるだろう。
これは俳句の世界と同じ究極のシンプルな表現の世界でもある。
何を書いて何を書かないか。
この鍛錬は書く側にも書かせる側にも必須のスキルだと思う。


ここで急に思い出した。
文章の表現ということでは、バーバラ・ミント氏のピラミッド原則なども参考になるかもしれない。
情報を整理するための素晴らしいメソッド。

http://www.amazon.co.jp/%E8%80%83%E3%81%88%E3%82%8B%E6%8A%80%E8%A1%93%E3%83%BB%E6%9B%B8%E3%81%8F%E6%8A%80%E8%A1%93%E2%80%95%E5%95%8F%E9%A1%8C%E8%A7%A3%E6%B1%BA%E5%8A%9B%E3%82%92%E4%BC%B8%E3%81%B0%E3%81%99%E3%83%94%E3%83%A9%E3%83%9F%E3%83%83%E3%83%89%E5%8E%9F%E5%89%87-%E3%83%90%E3%83%BC%E3%83%90%E3%83%A9-%E3%83%9F%E3%83%B3%E3%83%88/dp/4478490279/ref=sr_1_1?s=books&ie=UTF8&qid=1358180556&sr=1-1

クラウドソーシング

［1］オフショアを超える海外クラウドソーシング、国境なき時代の危機感と
チャンス

http://itpro.nikkeibp.co.jp/article/COLUMN/20121219/445423/

従来オフショアといえば、見慣れない国に飛んで見慣れない人たちと会い、信頼
に足る人たちなのか、相互に誤解がないかそんなことを自分自身の目で 見極め
る必要があった。
一つ二つ山を越え、相手の様子がわかればようやく遠隔からでもオファーが出せ
るようになる。
それでも裏切られることがあるのもまた一つの事実だが、大体このようにして関
係を築くしかなかったのだ。

しかし、今や海外エンジニアはクラウドの中で簡単にオファーができるように
なった。
「○○サイトの△△の処理のバックエンドのトランザクション作ってくれる人！」と
いえば、どこからともなく「いくらいくらで引き受けます」という 反応があ
り、そのうちの誰かに依頼するとする。
次の日には「××のリポジトリにコミットしています。確認して下さい。」とメー
ルが入る。
まさにオークションサイト同様の状況といってもいい。
従来物理的にも手間暇のかかったビジネスがそんなスタイルに変化しているとい
うことなのだ。

しかし、うまくいくケースだけならいいが
思い通りの結果が得られないこともあるかもしれない。
バグなのか、バグでないのか。誰が改修の責任を負うのか。。。
そうしたときのヘッジがそれだけできるか
そこの所もオークションサイトと同じ問題点があるという気もする。

とにかく時代の流れは確実に加速しているということを感じる話だ。

ヴェトナムオフショア開発のツボ（１０）

３．失敗に学ぶ

長々と書いてきた失敗談はここで終わりにして、次は成功に導くための道について考えていきたいと思う。

しかし、立つ鳥後を濁さず － 散文的に書き綴ってきた失敗談をおさらいしてからでもそれは遅くはないだろう。というわけで、いま一度メモを片手に振り返ってみようと思う。そう、何か忘れていることはないか。

情報を正しく伝える

付加価値のあるプロダクトを生み出すために、何を目指しているのか全員が認識を共有することは大前提であり達成するのは容易ではない。ここで言語の壁が大きな障壁となる場合が多く、伝えたいことが伝わらないばかりか、かえって混乱を招くこともおおいにある。

設計書や資料を作成するとき、言語表現上で「ゆらぎ」が発生しないよう厳格かつ表現は平易な書き方を習得する。そのような文書の作成は、簡単にみえて実は結構難しい。

厳格かつ平易に書くということは杓子定規にだらだら書くこととは違う。厳格とはもちろん虚偽の内容が含まれないこと、そして誤解を招く表現がないこと。

一つ一つの記述内容に関して必要な情報量というのは実は思ったほどは多くない。つきつめれば数行でこと足りることもある。正確な情報だからとひたすら文字を連ねて書かれているドキュメントは一見して読む気をなくさせる代物である。読んでほしい内容は何かを整理し、関連する事柄は極力簡潔にするよう構成する工夫が必要なのだ。

そして、平易な表現ということで重要なキーワードはヴィジュアル。視覚的にすぐれている内容ならば多くを文章で語る必要がない。末端の細かいスペックは文字に頼らざるを得ない部分になるだろうが、全体の構成、流れ、関連性、分岐条件などは視覚的に表現するべきものだ。とはいえ、一朝一夕にドキュメンテーションの方法を変えることは容易ではないのも事実だ。ここは試行錯誤が必要になるだろう。

 

論理の共有

論理を共有することにリスクがあるというより、むしろコミュニケーション上の妥協が発生するリスクがある。もちろん妥協が必要な場合というのもあるかもしれないが、非常に稀なはずだ。私がしたような根気負けは最も愚かな類で、そもそもコミュニケーションで時間労力で根負けするほどの内容は場違いだと認識しよう。前項で書いたとおりここでも視覚に勝るツールはない。数百ページの文章をひとつの図で表現することだって可能だ。手書きの情報の画像でも充分使える。細かい部分のディスカッションをSkypeやSNSなどの場を使って行うのも良しといったところだ。体系立てて情報を整理していく点では不向きだが、離れたロケーションにいる者同志が時間を共有するという点では大きなメリットがある。

躓く石にたとえた大小の誤解のリスクについては、経験値が大きくものをいうので多く自分でも躓いてみるしかないのだけれど、一つ確実なことがある。

期待していたリアクションと違うリアクションに遭遇した場合は問題が何かある。さして困難でもないと思うのに難解だと指摘されたり、そこそこ難解かと思っていたらあっさり理解したという場合など絶対どこかに誤解があるとみるべきだ。そういう躓きの石を敏感に察知する力もまた珠玉の如く価値のあるものなのだ。

全体を俯瞰する

回り道に感じても、全体像を共有することはより複雑かつ規模の大きい案件になればなるほど必要性が増してくる。ここを意識的なハードルに感じて避けようとする傾向があるとすれば残念な話だ。

これこそが最終的にゴールを遠ざけない道なのだ。とはいえ、具体的に実行しようとしたとき、方法はなんでもいいというわけにはいかない。

理路整然として設計資料の類は見た目にすこぶる格好いいが、それだけでは伝わらないものがあるのは事実だ。資料とホワイトボードを武器に何度も悪戦苦闘してきた経験からいうと、一見システマチックでない泥臭いコミュニケーションではあってもそこから得られるものは大きい。

まず自分の言葉で、自分の考えているイメージを伝えるところからまずチャレンジするのがいい。そうして表現の仕方などは経験を踏まえ工夫していくアプローチが現実的だと考える。

 

「できる」の意味するところ

 「できる」「できない」の言葉の意図するところは日本語では曖昧であることを認識しよう。相手のいう「できる」は約束とはならない。このことには十分注意する。また、気質、習慣を含め異文化の世界の出来事である。基本的な考え方・感じ方の領域での違和感はどうしてもつきまとう。許容できるところは許容し、その中で効率的に進めていくスタンスが効果的だ。ずっと長期的に取り組んでいく心積もりならば、最初のプロジェクトで少々躓いてでも得るものは大きいはず。最初感じた違和感が「そう、そうなんだよな」に変わってきたら読めてきた証拠だ。それが歩み寄りというものかもしれない。

 

チームプレー

日本人は長年の知り合いでも実年齢を知らず、何かのきっかけに「えっ！年下だったのか」と気付くなんてことがある。しかしヴェトナム人は違う。初対面で自分の年齢と相手の年齢を確認する。まず年齢を基準に相手をなんと呼ぶか決めるためにこういうことは起こらない。この世界では関係性というものがまず先行する。このように最初に立場も距離感も決まってしまうという点はアジアではよくあることだが、ヴェトナム初体験の場合は基本として押さえておくに越したことはない。

こうした個人の関係の積み重ねとして出来上がっているチーム、その性格はそれぞれのチームによって異なるものである。従って１つのチームに着目した考察はオールマイティなものではないことは云うまでもな い。

チームとの関わりという点でさらに述べさせてもらうと、あくまでも一般的にヴェトナム人のチームを相手にする場合、外国人である”あなた”とチームとの距離感はおそらく多くの場合において大きな意味を持つだろう。あなたが立ち位置を見つけるためにチームとの距離感を探っているとき、彼らもあなたをじっと観察していることは間違いない。

いずれにしろ年齢の高低、組織上の地位によるルールを基本とした人間関係を意識した振る舞いがその基本ステップになる点は留意するべきだ。逆にルール無視の振る舞いにはさまざまにデメリットがつきまとうので各々賢く判断すること。

 

不可解な引力

プロジェクトが不可解かつ不合理な引力に弄ばれることはないだろうか。正論では太刀打ちもできず、流されるままになることはないだろうか。これはおそらく世界の共通課題である。まさに強大な敵に挑もうとしているその時、軍は出撃の命令を今か今かと待っている。一方、軍を統帥する立場の人間は戦地とは遠く離れた場所の人間たちと内部の政治駆け引きの真っ最中でその機を見る余裕がない。果たして士気のあがっていたはずの軍は散々に打ち破られ緒戦から見るも無残な大敗北を喫する。そんなケースは歴史上よくある話だ。こうした組織の方向性を大きく狂わせる要因がこの”引力”なのだ。自分がいま下そうとしている判断が、こうした不条理を引き起こすか否かの認識が得られない人は残念だがきっぱり退場いただくか平身低頭有識者に知恵を借りて切り抜けるなどよく考えなければいけない。

目を曇らせないだけの見識を普段からよく養う　とりあえずはそれしかない。日々の研鑽は蓄積するとやはり大きくモノをいうわけだ。

 

以上、とりとめなく書いてきたものをまとめても結局とりとめがないということがわかった。

その時々感じたことをできるだけ率直に書いているつもりだけれどももっとじっくり落ち着いて書き込んでいきたいものだ　と反省。

論理の共有

ヴェトナムオフショア開発のツボ（９）

３．失敗に学ぶ

不可解な引力

賢い開発言語があっても、優れた管理手法があっても、抜きん出たスペシャリストがいても、それだけではなかなか上手くいかない、それがソフトウェアの世界。我々はしばしばソフトウェアの現場で不可解な引力で判断を誤ってしまう。なぜそんなものが存在するのか考えてみよう。

プロジェクトの分割

そこそこの規模の開発プロジェクトでは、複数のベンダーがサブシステムやコンポーネントごとに分割して並行に開発するケースが少なくない。この場合、それぞれが依存するシステムの要素が論理的な疎結合の状態であれば仕事が進めやすく良好な結果を得られやすい。逆にそれぞれが相互に依存していたり、論理的に密結合の状態になっていたりすると分割は命取りになるといっていい。

長年設計・開発をしているエンジニアは設計の概要を見ると、どの部分とどの部分が密、どこが疎であるか経験的・感覚的に鼻がきくようになる。そして、それは多くの場合実際その通りなのだ。そして、部分部分を適切な開発スキルを持ったチームへとそれぞれ引き渡し仕事が始まる。この判断基準は様々である。

• ドメイン

業務サイドの要件に着目することにより論理的な境界線を設ける場合、業務ドメインの知識がその基準となる。業務システムでは仕事の流れで機能がグループ化されるため、たとえば顧客管理、販売管理、財務管理などのくくりでシステムを分割することが出来る。開発にあたってはデータフローなどを駆使して業務の関連をよく把握した上で順序整理、分割単位の整理をする。

• 階層

 分かりやすい例としては、ネットワークの階層図がある。役割を下位から上位までいくつかの層に分けて機能を定義する。各階層での機能と階層間のインターフェースを明確に定義することで分割した開発が可能になる。

• プラットフォーム

 いくつかのコンポーネントで構成されるシステムでは、複数のプラットフォームに跨った開発を行うことがある。端的には、サーバがUnix系、クライアントがWindowsあるいはMacなどという場合はクロスプラットフォームといってよいだろう。こうした場合、サーバ側とクライアント側の実装主体は分割の対象となる。

• 開発言語

 同様に、いくつかの開発言語が使用される場合、分割の対象となる。今時のプログラマーは一つの言語しか使えないなどということは稀かもしれないが、昔はよくある話だった。ここはCで、ここはFortranで、ここはjavaで、という適用言語の棲み分けがそのままチーム分けと同一であった。この分割基準は現在ではよほど特化した言語以外では意味を失っている。旧い時代の名残でもあると私は思う。

 

具体例はさらに多くあるが、プロジェクトを分割するにはそれ相当の合理性があるということなのだ。このことが十分に考慮されていなけば、たとえ隣の部屋のプロジェクトとの間でさえうまく連携できない。ところが、こうした法則とは逆に働く”不可解な”引力が世の中にはある。

ポータビリティ誤認の悲劇

オフショア開発で複数のベンダと取引する場合、どこか１社だけに依頼が集中することは当然ありうる。オファーの内容がマッチしているとか、優れたマネージャやエンジニアがいるとか、理由はさまざまだ。しかし、将来的なキャパシティを確保するために、オファーが遠のき気味のベンダにも助けを出さないと、というインセンティブが働く場合がある。これが逆行の引力となるわけだ。何といっても目的が救済とくれば、この引力はプロジェクトの論理的整合を超えた分割を強いることがある。

実際にあるプロジェクトでそのような事態になったのを目のあたりにした。

元々とあるベンダ１社で受注して開発していたプロジェクトのうちの一部が突然キャンセルになった。そのキャンセルになった部分の開発は発注側の企業が資本関係を結ぶ、ある別のオフショアベンダに流れていった。この２社間は地理的にもかなり離れており、しかも互いに交流のない関係だった。現場では反対の声があがったが、発注元が一部引き揚げると決めた以上どうすることもできない。

果たしてどうなったか。

元々の仕様が曖昧で手戻りが多かったのに加えてブリッジ担当者は２社間を行ったり来たりと、コミュニケーションロスが増えた。このような状況からプロジェクトの進捗は思うにまかせず、結果的にそのプロジェクトは炎上した。そのあと、どう収束したかは知らないが、当初発注を受けたベンダはまもなく経営に行き詰まり会社を解散してしまった。利益を生まないデスマーチに企業体力を使い果たしてしまったか、あるいは先行きを悲観した経営者が資本を引き揚げてしまったか、そんなところだろう。ともかく、この出来事に関係者は驚愕した。

この事件の背景には、現地ベンダとの信頼関係の問題があると私はみる。当初からずっと現地ベンダの意向はまったく顧みられていない。プロジェクトの分割による作業効率の低下は黙殺されている。無理矢理にプロジェクトの一部分を切り取っても１００％のポータビリティを可能にできるという誤解がある。実際、こうしたケースでもリソースを追加し人海戦術でなんとかなるだろうと考えられる向きもある。しかし現実、人海戦術で解決できることはそんなに多くはない。火に油を注ぐの例えに近い状況になった事例は数知れない。量ではない。いかに効率的、合理的に仕事を進めるかが重要なのだ。

なにはともあれ、たった一つのプロジェクトの失敗が会社の崩壊につながるとは、プロジェクトを分割した当事者を含め誰しも予想もしなかっただろう。しかし、もしも当初の体制通りに１社で開発をしていたら、大成功とはいかなくても会社は存続できたかもしれない。もし開発途中でこのような事態になると、最終的にはクライアントに提供するサービス品質の低下に帰結する。これが避けられない事態となることも忘れてはいけない。

 

マイクロマネジメントの誤解

ベンダとの信頼関係ということに関しては、製造工程の進捗の把握方法にも様々な影響を及ぼすことがある。毎週はともかく毎日のたとえばプログラム行数など出来高を逐一把握することでプロジェクトの見える化が完璧であると錯覚する人がいる。だが、元々仕様の理解浸透度がプロジェクトの成否の決め手であるとの持論を持つ私にとって、製造工程での出来高を細かにモニタすることに大した意味を感じない。問題を解決する目的に沿って作られないプログラムコードは価値を生まないからだ。そうしたプログラムコードはのちのち破棄するにも手間がかかる状況があることを想定すれば、これは価値としては寧ろマイナスである。それを逐一把握することは場合によっては必要であってもあくまで手段であって目的ではない。

立場を変えてみよう。

毎日毎日書いたプログラム行数を報告させられるプログラマの負担はどうだろう。報告のために使う時間もその日の作業を終えて帰宅する直前の５分１０分と短くとも、数週間・数ヶ月で累積すると延べ数時間と無視できないロスになる。それにテストを書いているとき、リファクタリングでソースコードを整理しているとき、これらの重要な作業にも関わらず出来高は微々たるものに見えてしまう。むしろ無駄に冗長なコードを大量生産するエンジニアの方が高評価になってしまうおそれがあるのだ。

何よりこうした非生産的な作業の強制はエンジニアのモチベーションに影響する。これが一番の問題ではないだろうか。何より実際に手を動かしているのは人間であるということをよく理解しなければいけない。

そのようなことに貴重な時間を使わせるくらいなら仕様に関するコミュニケーションを濃密に行う方がよほど有効だ。その方が確実にプログラムの精度が上る。もしプログラムの出来高がどうしても知りたいという人は、ヴァージョン管理システムの例えばGitやSVNリポジトリから毎日差分を自動検出するなど工夫をすればいいと思う。そういう作業は機械の仕事だ。思考と感情を持つ人間であるエンジニアはそういう束縛から解放しなければいけない。

よくも悪くも、人間と人間の対話を経て人間自身が生み出すものがソフトウェアである。我々はプログラムコードを相手にしているのではない。人間を相手にしているということを常に意識すべきだ。

 

いかなる場合にても、喜び大ければ大なるほど、それに先立つ苦しみもまた大なり。

 アウグスティヌス

 

ヴェトナムオフショア開発のツボ（８）

３．失敗に学ぶ

全体を俯瞰する

何があるるのかわからないまま暗い道を進むようなオフショア開発プロジェクト。道は明るくしていきたいところだが、さて、どうしたら．．．？

アノマロカリスの謎

太古カンブリア紀の昔、この時代では最大の生物となるアノマロカリスは皆さんご存知だろう。アノマロカリスは同時代の生物のどれと比較しても巨大で奇妙な形だが、実は長い間その存在は確認されていなかった。この生物が確認されて現在みられる形になるまでには頭のイカのような部分と後ろのエビの尻尾のような部分は別々の生物と考えられていた時期もあった。

頭と尾の化石が別々に出てくるからである。あるいはあまりに形状が違うので一緒の生物とは考えられなかった。生物が他の生物を捕食中に死に化石になったのだろうと推測されたりもした。

なぜ長年本当の姿に行き着かなかったか。

カンブリア紀が終わって長い年月のあとにこの世に登場した我々はこの生き物の本当の姿を誰も確認することができなかったからだ。

まさかあの２つの化石が同じ生物の体の部分だったなんて。。。と分かってしまえば受け入れ易いことでも知らないうちはまったく考えも及ばなかったということになる。

この話は数人の盲人が象を触りそれぞれの感じたまま象とはどんな動物かを語る故事とも通ずるものがある。

このように、全体を俯瞰することの意味は実に大きい。

ソフトウェア開発での、より規模が大きくなればなるほど、全体の様子は把握しにくくなる。

作業を細分化していくと下流工程ではそれぞれの受け持つコードがいったいソフトウェアの中でどういう位置付けなのか各々はわかっていないという状況になる。この状況の起きる傾向はプロジェクトの規模とほぼ比例するといっていい。

それでもなんとかソフトウェアとして論理的に統合できるのは、やはり全体を見る立場の人間がいて、その知見がプロジェクト内に存在しているからであろう。

全体を見通す知見がなければたちまち論理的整合がとれなくなり、いわば目標を失った航海のようになるであろう。

インタフェースはどこに？

 オフショア開発でいくつかの案件をみていて、この形態での開発のある弱点があることがわかった。すでにシステムの中に既成のサブシステムなどが組み込まれており、この中が完全なるブラックボックスになっている場合などがある。たとえば特定のメーカーのハードウェアなどを使用するときに、そのハードウェアのドライバーおよび関連ツールなどと共にサブシステムが構築されている場合がある。また、古くから使われているコンポーネントであればすでに導入時のことを知る人間もおらず、情報が不十分であることが多い。基本的なインターフェースの情報があれば御の字なんていうこともｌ少なくないのが実情だ。

オフショア開発企業は自分たちがタッチする直接のコンポーネントについては比較的詳細を確認するが、上記のような閉ざされたサブシステムに関しては「これが何をするものかわからない。我々はどうしていいのかわからない。」といった思いのほか強い拒否反応がある。ビジネスの上での「そこを何とか．．．」の通じる世界とそうでない世界の違いなのかもしれない。この拒否反応があまりに強くて、工程自体がストップしたりすることもあるし、テストのためといって多大な工数をかけてでも当該のサブシステムの代用品を自分たちで作ることも辞さない勢いである。

まさに上記のような性格のプロジェクトをオフショア開発で委託して、やり取りに苦心していたプロジェクトを知っている。従来からあるシステムの機能追加であり比較的小規模のエンハンス案件であったが、そこに当初の開発でのみ関わったベンダが作成したサブシステムが存在し、このサブシステムが実にデータの入出力に介在していたのだ。「そういうものだから」とずっと面倒をみてきたが、いざ開発をしようとすると資料もなく当初の担当者もいない。その重要なサブシステムの仕様がよくわからない。それでも、そのサブシステムの中を改造するわけじゃないし．．．とそのままオフショア開発に踏み切った。実際中はさわらなくてもデータの内容は重要で、オフショア開発会社側は何度も情報の公開を依頼したが、「ないものは出せない」とずっと依頼を拒否するしかなかった。結局そういった状況がネックになってQ&Aなどのやり取りに相当時間とパワーを使っていた。これは設計上重要な位置を占めるガシーなサブシステムの情報を開示できずにいたためのコミュニケーションの負荷であり、実装工程から結合試験工程でのバグ潰しにいたるまで大きく影響してしまった。

担当者は「オフショアなんかしなけりゃよかった．．．。」と嘆息したが、その原因はオフショア開発にあるのではないことは明白だろう。

情報は受け取る側の身になって

誰しも不可解なものを使って仕事をするのに結果だけは保証しろといった話には腰がひけるのは仕方ないところかもしれない。ここは作業を請け負っている立場になって考える必要がある。オフショア開発の担当者にもいろんな人がいるので一概にはいえないが、「とにかく黙って言った通りやればいいんだ」という態度でいくと大概うまくいかない。自分がその仕事に携わる側の立場になったつもりで考えてみよう。おそらく情報が少ない、情報が曖昧など様々な問題がみえてくるはずだ。自分の発信している情報がどれだけの精度を持っているかを第三者にチェックしてもらうのもよい。

もし使い古しのサブシステムであろうが何だろうが、システムのコンポーネントである以上、機能やインターフェースは明確なものを提示し、ブラックボックスはブラックボックスなりに全体を把握する妨げにならないだけの情報はそろえる必要がある。情報がなければシステムの概要図に大きな穴があいているのも同然だ。これではうまくいくものもうまくいかなくなることを認識しよう。

全体像を共有する

プロジェクトの全体あるいは規模によってはキーメンバーだけでもいいが、関係者に全体の完成イメージを見せてどう「パズル」が組み合わされるのか認識をまず共有するべきだ。もちろんその場でいろいろ議論してもいい。自分自身が疑問を持っていなくても議論の場にいたという経験は後々知見に大きく貢献する。オフショア開発の場でも、というよりそういう場であるからこそ最終的なターゲットのイメージは共有することに大いに意義がある。アノマロカリスの部分部分をみて「どういう生物だ」とか語るよりはずっと状況は改善している。

全体図を見せようにも、場合によっては完成形が見えないプロジェクトというのも世の中にはあるかもしれない。いかに完成形が定義されていなくとも、目標のないプロジェクトは存在しない。そういう場合も目標と目標に向かうプロセスを共有することで十分なコミュニケーション効果が得られる。

いささか偏った考え方になるが、理論だけで語ると、きちんとした構造化ができていれば全体が見えなくてもきちっと完成物になるはずである。それぞれのコンポーネントを受け持ったベンダがバラバラに仕事をしても問題ないはずだ。しかし現実はどうだろう。それはまさに夢のような話だ。そう理論どおりにならないところが不完全な人間の仕事だし、そもそも完成物に仕立てるための労力がエンジニアの仕事であるといっても過言ではない。