プロジェクトの実質的な地位は自分の努力と実力で得るもの [プログラミング]
上から目線と言われたので僕が底辺プログラマーだった時のことを書いておこう。
もう、10年も前になるがとある生保系システムのバッチ処理を書いてた時があった。
僕は、一番下っ端・・・というか、実質プログラムを書いている唯一の人間で、上ににサブシステム（バッチ関連）のマネージメントをするという人、その上に全体を総括してマネージメントするという人がいるような感じだった。
つまるところ、実際にプログラムを書く/書ける人は全体の一部で、マネージメントするひとばっかりという状態。
プログラムを書いてるのは（自分も含めて）外注、マネージメントしてるのが実際に仕事を請けた会社のプロパー社員という、まさに IT 土方仕事の末端にいた。
他に、VB で作るクライアントアプリのサブシステムがあったが、そっちは５人くらいいた気がする。
（あ、プロパーの人たちがテーブルの設計はしてたかな。全部 CHAR 型で ForeignKey なかったけど。Oracle がかわいそう。）
当然、客先との仕様取りまとめとかやりとりは上の人たちがやって、僕は言われたものを作りますって感じだったので、プログラミング中は客先の人と僕が直接やりとりすることはなかった
・・・が、本番環境を構築して総合テストというときにちょっと状況が変わった。
総合テストを客先常駐で既存のシステムと平行してやるという時に、初めて「バッチ担当してます nakagami です」と一応あいさつするんだけど、お客さんからは当然、サブマネージャーを通して不具合の指摘が入る。一応、サブマネージャーの人は設計するって立場だったんだと思うけど、確か C のソースは読めなかったと思うし、プログラムの中身については（どうせわかんないのでめんどくさいし）とくに説明してなかったので、まぁ僕に丸投げになる。
客先常駐で僕は見えるところにいるわけだし、細かい動作については、担当の人と直接やりとりしないとわからないところもあって、不具合直したら直したで「できましたー」ってお客さんのところに知らせに行ってたりすることもあって、だんだんとお客さんと直接やりとりするようになってくる。
そのうち「nakagami さんに直接頼むとすぐ直る」ってことになってきて・・・
（ごめんねー、僕がそのバグ作ってるわけだからねー）
お客さんと末端のプログラマーごときが直接やりとりするのは問題になることもあると思うけど、サブマネージャーの人も自分通されてもよくわからんし、お客さんもそっちのが喜ぶしっていう雰囲気で全部自分が受け取って直す感じになっていってた。
最後の方になると実質的なポジションっていうか、みんなの見方は変わってきてた気がする。
多重請け負いのツリーの中で、形式的な地位や実際の収入を変えることはできないけど、ちゃんとやってれば実質的な地位っていうのは変わって行くもんだなぁと思ったプロジェクトであった。
もう、10年も前になるがとある生保系システムのバッチ処理を書いてた時があった。
僕は、一番下っ端・・・というか、実質プログラムを書いている唯一の人間で、上ににサブシステム（バッチ関連）のマネージメントをするという人、その上に全体を総括してマネージメントするという人がいるような感じだった。
つまるところ、実際にプログラムを書く/書ける人は全体の一部で、マネージメントするひとばっかりという状態。
プログラムを書いてるのは（自分も含めて）外注、マネージメントしてるのが実際に仕事を請けた会社のプロパー社員という、まさに IT 土方仕事の末端にいた。
他に、VB で作るクライアントアプリのサブシステムがあったが、そっちは５人くらいいた気がする。
（あ、プロパーの人たちがテーブルの設計はしてたかな。全部 CHAR 型で ForeignKey なかったけど。Oracle がかわいそう。）
当然、客先との仕様取りまとめとかやりとりは上の人たちがやって、僕は言われたものを作りますって感じだったので、プログラミング中は客先の人と僕が直接やりとりすることはなかった
・・・が、本番環境を構築して総合テストというときにちょっと状況が変わった。
総合テストを客先常駐で既存のシステムと平行してやるという時に、初めて「バッチ担当してます nakagami です」と一応あいさつするんだけど、お客さんからは当然、サブマネージャーを通して不具合の指摘が入る。一応、サブマネージャーの人は設計するって立場だったんだと思うけど、確か C のソースは読めなかったと思うし、プログラムの中身については（どうせわかんないのでめんどくさいし）とくに説明してなかったので、まぁ僕に丸投げになる。
客先常駐で僕は見えるところにいるわけだし、細かい動作については、担当の人と直接やりとりしないとわからないところもあって、不具合直したら直したで「できましたー」ってお客さんのところに知らせに行ってたりすることもあって、だんだんとお客さんと直接やりとりするようになってくる。
そのうち「nakagami さんに直接頼むとすぐ直る」ってことになってきて・・・
（ごめんねー、僕がそのバグ作ってるわけだからねー）
お客さんと末端のプログラマーごときが直接やりとりするのは問題になることもあると思うけど、サブマネージャーの人も自分通されてもよくわからんし、お客さんもそっちのが喜ぶしっていう雰囲気で全部自分が受け取って直す感じになっていってた。
最後の方になると実質的なポジションっていうか、みんなの見方は変わってきてた気がする。
多重請け負いのツリーの中で、形式的な地位や実際の収入を変えることはできないけど、ちゃんとやってれば実質的な地位っていうのは変わって行くもんだなぁと思ったプロジェクトであった。
私も SIer 時代に似たような状況の末端で開発していた頃があります。違いは、
- 開発部ではなくヘルプデスクのような運用サポートをしていた
- 運用の部署に所属していながらプログラム改修の権限を持っていた
- 自社のエンドユーザを直接サポートしていた
毎日、現場の担当者と電話していたので、ユーザがどう運用しているか、何に困っているかを理解していました。なので、私が改修する方が(要件定義が不要なので)納期が短く品質も高かったりしてました。SI で現場を知らない開発はなかなかに難しいですね。
by t2y (2010-06-20 14:59)
http://d.hatena.ne.jp/t2y-1979/20100619/1276932433
これ↑ですね。イイハナシダナー
僕の見聞きした範囲では、運用は改修しないで Oracle のデータを直接修正してごまかす（←これはこれですごい）。改修はあくまでも開発の部署で・・・というかんじだったので運用が固定費の中で改修するってちょっとすごいなーって思いました。
仕様書もないのに、現状にあわせてヤマカンでプログラム書くって、どっかで問題になんなかったんかなー、と心配になります。
by nakagami (2010-06-20 18:31)
> 僕の見聞きした範囲では、運用は改修しないで Oracle のデータを直接修正してごまかす（←これはこれですごい）。改修はあくまでも開発の部署で・・・というかんじだったので運用が固定費の中で改修するってちょっとすごいなーって思いました。
仰る通り、昔いたその SIer も基本的にはこんな感じでした。公式には認められない。運用の人は、どんな手段を使っても現状のまま運用するという意固地ともプロ意識とも取れる感じでやっていました。私自身が特殊なポジション(運用の部署でありながら開発期間中に開発に参加していた)で関わっていたのと、私がやる事なす事(当然、失敗もしてる)の全責任を取ってくれた上司(PM)がいて成り立ったのでした。
by t2y (2010-06-20 20:33)
イイハナシダナー
by nakagami (2010-06-21 13:15)
Viagra Limbiate <a href=http://apcialisle.com/#>canadian cialis</a> Order Cialis Online India <a href=http://apcialisle.com/#>Cialis</a> Cialis Generika Aus Polen
by JanTrum (2020-03-16 16:29)
Ricrescita Propecia Finasteride <a href=https://buycialisuss.com/#>cialis no prescription</a> Propecia Nizoral Hair Loss Treatments <a href=https://buycialisuss.com/#>Buy Cialis</a> Valtrex Order Online
by JanTrum (2020-04-21 23:57)