下流工程の軽視を憂う

仕事では英語のやり取りが必要なので、時々メールや資料の翻訳を頼まれることがある。もちろん、ネットでは無料の翻訳サービスが有るので、和訳の方は利用する人が多いようけれど、さすがに英訳の方は機械翻訳そのままの文章を送付することにためらいを感じる人が多いらしく、結果的にこちらへ依頼されてくる案件は英訳の方がずっと多い。

面白いのは翻訳する和文の記載が、そのまま依頼主の英語のレベルを反映している点だ。例えば、ある程度の英語力を持つ人の和文は、そのまま英語へ機械的に訳しても十分意味を持つ論理構成になっているので翻訳は簡単に済むのに対し、英語は全然ダメという人が書いた和文は、日本語としての論理も不充分なのでそのまま英訳しては全く理解不能(!)なので、まず英訳に適した和文に書き直すところから始める必要が有ったりする。翻訳作業という後工程のために、分かりやすく訳しやすい文章を書ける人というのは、実はかなりの実力の持ち主ではないかと思う。

ソフトウェア開発の現場で必要となる仕様書や設計書の類も全く同じで、実際のコードやテスト項目に容易に落とし込めるようなレベルの記載を明確に書ける人というのは、実は自分自身で良い品質のコードやテスト項目を作れることが多い。おそらく何の情報がどのレベルまで必要なのか分かっているから、逆算的に仕様書に書くべき内容が推測出来るのだろう。このような仕様書は読んでいて不明な点が少ないし、意味不明な箇所も皆無なので信頼性が高かったりする。

逆に最悪なのは、ソースコードを全く書かず、またテストでの検証作業も全く行わない開発者の書いた仕様書で、必要な情報が書かれていないことはもちろんのこと、そもそも技術的に不可能なことを平気で仕様として列挙したりする。後工程での作業が円滑に進まないどころか、前工程への差し戻しが発生している時点で、その仕様書の評価は決まってしまう。お粗末な記載への問い合わせに対して満足な回答も出来ない作成者の様子をみる度に、上流工程としての経験だけでソフトウェアの開発は不可能だと実感する。

アウトプットのレベルを厳しく評価しているのは、後工程の人なのだ。自分が良ければそれで良しと思い込んでいる時点で、それはもう開発のプロとしては失格だろうと思う。開発コスト云々の問題により、実装やテストといった作業工程はますます分断され、「他社に負けない単価だけが自慢」の協力会社に流れがちだが、そのように下流工程を軽視する開発組織の将来は暗いと思っている。

この流れの中で、「下流工程の経験を積むことなく、上流工程専門の要員を育成できないか」という相談を受けることがある。筆者としては、工程間の不整合のリスクを高めるので賛成できないと答えている。

「次工程はお客様」を業界の合言葉に | 日経 xTECH(クロステック)

こうしたコンサルタントの仕事は、エンジニアからは「やり逃げ」などと言われるが、彼らなりに全力で顧客満足を追求した成果物であり自信も誇りも持っている。そもそも設計・実装を経験していなければ、要件定義書に何を残せば十分か的確に判断できるはずがなく、責めるのも気の毒だ。

「次工程はお客様」を業界の合言葉に | 日経 xTECH(クロステック)