【常駐編】「上流工程」とは、生粋のプログラマが望まない仕事である
お疲れさまです。４月から新しい現場で働き始めて、最近になってようやく今の作業環境に「慣れ」を感じるようになってきました。常駐して働くのは、今回が７社目になります。
エンジニアの仕事を始めたころは、会社をいくつも転々としていると、いつかは「どこの会社も同じだなぁ」と思うようになるんじゃないかと想像していたのですが、意外なことにこれまでのところ、１つとして似た会社と出くわすことがなく、どこも違った風土、違った習慣、違った空気を持っていると感じました。
お陰で何年も続けているのにこの仕事に対して「飽き」を感じることはありません。
#エンジニアあるある 実録IT用語辞典【常駐編】INDEX
「上流工程／下流工程」とは
システム開発をする際の工程をジャンル分け（？）する時に使うことがある言葉。
上流工程は要求分析や設計など、システムを作る初期の段階。お客さまとの折衝や資料作成、開発メンバーの管理が主な作業になる重要なポジションだが、実際にコードを組むことはほとんどないため、プログラムを組んでいる時が一番楽しいと思っている生粋のプログラマが望まない仕事になることもあるもの。
下流工程は、上流で決められた設計を元に詳細設計（もしくはプログラム設計）や、実際のコードの作成、そしてプログラムの検証などをするのが主な作業になる。
プロジェクトを円滑に進めるには、上流と下流の双方がかみ合って作業をしていかないといけない。双方の意識にズレがあったり、どちらか片方でも能力に欠如があると、そのプロジェクトは必ずヤバイことになるあたりが、システム開発は難しいと思わせてくれる。
一般的には上流で働いている人のほうが給料が良く立場も上であることが多い。ただし、プロジェクトの進行が「ヤバイこと」になった場合は、上流下流関係なく、みんなの労働時間が等しくヤバイことになるあたりは平等であるような気がするもの。
「ストイックな現場」とは
決められた工程、決められた期間、決められた体制で、バグなく仕上げることに対して強い意識を持っている現場。銀行や証券などのミスが許されないシステムを作っているところに多い。
ストイック度が高い現場では、ハードカバー数冊分の厚さがある仕様書をきっちり管理しながら開発するような、確かに間違いを防ぐ確率は上がるだろうけど、工数は膨れ上がるし、エンジニア的にはあまり楽しくない作業が発生したりする。
また、1カ所ソースを修正しただけで障害管理表への記載と大量のテストが必要になったりすることもある。
ストイックな現場のほうが確かにバグが発生する確率は少ないが、だからといってバグが完全になくせるわけではないことは、日々のニュースを見ていれば分かるような気がするもの。
「フリーダムな現場」とは
規約等があまり決まっておらず、エンジニアの裁量やその場の雰囲気で開発が進んでいく現場。良い言い方をすると「自由」。悪い言い方をすると「適当」な現場である。
このタイプの現場では決められたルールがない分、まとめ役になる人間は周囲がバラバラなことをしないように統制を取っていかなければならない。そうしないと、似ているけど仕様が微妙に違う機能や、微妙にレイアウトや配色が違う統一感のない画面などが出来上がってしまったりする。
全体を見てちゃんと統率できるリーダーがいるのであれば、フリーダムな現場のほうがストイックな現場よりも効率良く作業ができる場合が多い。ただし、プロジェクトの成功がエンジニアの能力によって大きく左右されるため、失敗する時の被害も大きくなりやすい。
「アドベンチャーな現場」とは
フリーダムを通り越した先に位置するような現場。
どの仕様が真実なのか、誰が何を担当しているのか、自分は何をすればいいのか。そういった根本的なことさえ分からないような、一寸先は闇な現場である。
そんな現場に入ってしまったエンジニアは、情報や体制の整備に奔走して開発が正しく進められるように尽力するか、最低限の仕事だけをしてできるだけ現場と距離を置くことで後に問題が発生しても責任を負わなくて済むよう気を付けるか、どちらかを選ぶことになったりするもの。
「守秘義務」とは
職務上で知った情報を「他者には漏らしません」という内容の約束ごと。
派遣などで働いていると、どこかの案件にアサインされる前に必ずと言っていいほどこの条項が入った契約書にサインさせられることになるもの。
「今、C社に派遣されていて、来春発売される予定のこんな製品作っています」とかいう話をプレスリリースより前にブログに書かれるなんてことになったら、企業的には大ダメージだったりするので、結んでおく必要があるもの。
「この前までH社にいたんだけど、開発中にマスタDBの顧客情報全部見れちゃってさ」とか言って顧客情報を漏らされたらわりとシャレにならない。
また、たまに自分自身が通勤している会社の名前すら、喋らないほうが良かったりすることもある。派遣された先の会社の指揮で、元請に常駐する時とか。
その場合、たとえ肉親でも喋らないほうが良いと思われるので、親や配偶者から「今、どこで働いているの？」と聞かれた場合には、「それは守秘義務なので」という、「あんた、リストラされた……？」という誤解などを生みそうな怪しい返答をしなければいけないかもしれないもの。
「情報漏えい」とは
漏らしてはいけない会社の情報を、うっかり、もしくは故意に外部に流してしまうこと。
顧客情報の扱いが法律的に厳しくなったころから、開発現場でも気を付けるようにと頻繁に言われるようになったもの。
「もう分かったので、勘弁してください」という気持ちが浮かんでくるくらい頻繁に、企業さまから注意とか指導とかがあったりするもの。
代表的な情報漏えいの例として、うっかり会社のノートパソコンを電車の網棚に置きっぱなしにしてしまったとか、飲み屋で同僚と仕事の話をしていたら、知らぬ間に盗み聞きされていた、といったケースがある。
ノートパソコンについては、「暗号化しておく」とか「USBキーを使う」（大抵USBキーも一緒に忘れるような気もしますが）とか、「怖いから、会社から持ち出さない」といった対応策が考えられる。
恐らく、「持ち出さない」ことができるなら、それが一番良いと思われるもの。特に自宅に仕事を持ち帰るとか殊勝なことはしてはいけないと思われるもの。いろんな意味で。
飲み屋での情報漏えいは、気を付ければ回避できるような気もするけど、仕事関係のそれほど親しくない人と飲みに行った時には、普通は仕事の話になるし、「仕事の話厳禁」なんてことになると「仕事以外って言われても、何喋ればいいんだろう……」という状態に陥ってしまうこともあるもの。
うっかり情報漏えいすると、それが個人の過失だった場合はクビとか、会社がダメと言ってることを破って漏えいした（持ち出し禁止の資料を持ち帰って途中で落としたとか）場合は損害賠償とかもありうるので注意が必要なもの。
#エンジニアあるある 実録IT用語辞典 【注目のキーワード】
あわせて読みたい
注意!!
この連載記事には必ずしも正しいとは限らない内容が含まれています。この記事を信じたことによって発生した障害に対して、筆者及び株式会社マイナビは一切の責任を負いません。ご容赦ください。
※この記事は2007／11／23〜2009／08／28に連載された内容を再構成しています
著者プロフィール：ＭＷ（えむだぶりゅー）
Java、PHP、C、C++、Perl、Python、Ruby、Oracle、MySQL、PostgreSQL関連の業務経験がある、典型的な広く浅い役に立たない系のウェブ（時々クライアント）アプリのエンジニア。 週に1日休みがあれば、ほか6日間は終電帰りでも全然へーきな体力と、バグが出ても笑って誤魔化す責任感の無さを武器に、今日も修羅場った開発現場の風景を横目で見ながら、適当に仕事をこなす日々を送る。
著書「それほど間違ってないプログラマ用語辞典」（発行：毎日コミュニケーションズ）
