カテゴリ
以前の記事
2022年 10月 2015年 08月 2015年 05月 2015年 01月 2014年 11月 2014年 10月 2014年 09月 2014年 08月 2014年 07月 2014年 01月 2013年 12月 2013年 09月 2013年 08月 2013年 07月 2013年 05月 2013年 04月 2013年 02月 2013年 01月 2012年 11月 2012年 10月 2012年 09月 2012年 08月 2012年 07月 2012年 05月 2012年 04月 2012年 02月 2012年 01月 2011年 12月 2011年 11月 2011年 10月 2011年 09月 2011年 08月 2011年 07月 2011年 06月 2011年 05月 2011年 04月 2011年 03月 2011年 02月 2011年 01月 2010年 12月 2010年 11月 2010年 10月 2010年 09月 2010年 08月 2010年 07月 2010年 06月 2010年 05月 2010年 04月 2010年 03月 2010年 02月 2010年 01月 2009年 12月 2009年 11月 2009年 10月 2009年 09月 2009年 08月 2009年 07月 2009年 06月 2009年 05月 2009年 04月 2009年 03月 2009年 02月 2009年 01月 2008年 12月 2008年 11月 2008年 10月 2008年 09月 2008年 08月 2008年 07月 2008年 06月 2008年 05月 2008年 04月 2008年 03月 2008年 02月 2008年 01月 2007年 12月 2007年 11月 2007年 10月 2007年 09月 2007年 08月 2007年 07月 2007年 06月 2007年 05月 2007年 04月 2007年 03月 2007年 02月 2007年 01月 2006年 12月 2006年 11月 2006年 10月 2006年 09月 2006年 08月 2006年 07月 2006年 06月 2006年 05月 2006年 04月 2006年 03月 2006年 02月 2006年 01月 2005年 12月 2005年 11月 フォロー中のブログ
エキサイト以外のリンク
シャオがよくお世話になっているリンク。
RYOKAN'S OFFICIAL SITE あまだくと! シャオと連絡が取りたい方はこちら。 shaoz01■yahoo.co.jp (■を@に変えてください) 最新のトラックバック
検索
その他のジャンル
ブログパーツ
ファン
記事ランキング
ブログジャンル
画像一覧
|
2007年 04月 06日
とある事情があり、会社のパソコンの古いデータを見てたら、前の前の仕事の時の引継書が出てきた。数年前のコトでもあり、差しさわりのない部分を抜き出してみる。なお、付記するなら当時シャオは、とある基本システムに関連するインターフェース側システムの開発を「クライアント側」として行っていた。これは業務を引き継ぐ先輩に向かって書いたものと知ってみると、なかなか当時のシャオのキレ具合(どっちの意味かは閲覧者側で判読されたい)が匂ってきて大変香ばしい。 *サノバビッチシステム(仮称)担当者心得* ○ 完全なシステムなどない。マスターシステムとと同じ事をするためにはマスターシステム並みの資源(特に予算・そして人)が必要。 ○ システムは現業の業務に沿うべき(システムを業務にあわせるべき)という考え方と,業務を効率化するためにシステムを利用すべき(システムに合わせて業務を再構築すべき)という考え方が,社内で統一されていない。項目,費用対効果,まわりの情勢等も含め,どちらの考え方で行くのかを考えないと,あとで大やけどする。 ○ 業務主管個所とは密な連携が必要。雑談・毎日5分でもよいので業務主管個所の担当者と接触を。知らないことで泣くのは自分。 ○ SEとプログラミング知識で張り合わない(=かなうわけがない)。仕様書を元に,業務的な知識等を提示し,それに対する見解を聞くのが原則。彼らは技術職であり,職人。言われたことをきっちりやるのが仕事で,それ以上のことはしないし求めてもいけない。SEが「やりすぎた」のならSE側の責任だが,SEが「なにもしていない」のなら,それは指示者たる自分の責任。 ○ 早い時期にテスト系でシステムを一通り当たってみること。「そんなこと知りません」は,現場の人間やSE,応答窓口にとっては関係ない。あなたは担当者なのだから。 ○ 本来,システム担当は使用個所のサーバントであり,彼らの要望を叶えてあげるのが役目。ただし,要望と単なる我侭を同一視しないこと。また,本社の担当者が了承したことは,全て前後の文脈言葉のイメージ関係なく「本社が積極的にそれを認めた」として言い訳にされる傾向があるので,あいまいな言い方は注意。 ○ システム担当だから,主管個所じゃないから,と言っても,サノバビッチシステム(仮称)に関わる以上資材要件・経理要件についてはある程度の知識がないと,防げるものが防げなかったりする。そういう意味で,少しでもおかしいと思ったらキチンと他の部署に聞くこと。「まぁいいや」で進めていって泣くのは自分。 ○ 主管部署とシステム部門は「他会社」。それぞれに守るべき則があり,こだわっている部分がある。「同じ会社なのになんでこんなことを…」と思うかもしれないが,キチンと出向いていってお願いなり根回しなりすること。課長同士の協議は単なるセレモニーか泥沼ガチンコ協議かどっちか。できれば泥沼は避けたいところ。 ○ SEの文書は判らない,と思って機能仕様書等を軽視し,口頭説明に頼りがちになるが,いざ何か起こったときに基準となるのは文書。せめて読み込む努力をすること。できれば自分なりにアルゴリズム(雑誌の占い程度のフローで十分)を作り、SEに提出するのが基本。 ○ プログラミングのことは判らないから,というのは逃げ。判らなければ聞くこと。そのためにSEが存在する。 ○ 係長・課長はシステムや、ましてプログラミングについては素人。従って自分だけの判断でやってしまいがちになるが,係長には詳細に説明を。課長には方針についてきちんと説明を。とりあえず印鑑を押させてしまえばこっちの勝ち。 ○ エラー書類等,使用個所への連絡は,原則として電話連絡で。メールで出しても問合せの電話がどうせ鳴る。やむをえないときは,相手側の書類状態にあった判りやすい周知文を。全社から一斉に電話がかかってくるとパニックになる。 ・・・・・どうでしょうか開発系閲覧者の方々。クライアントなんて、SEを泣かせてナイトガウンに赤ワインと美女を侍らせてるイメージなんだけど、現実はまるで違ったよなあ。 え? 今ですか? ええ、あの頃に戻りたいなあ(遠い目をしながら)。
by shaonanz
| 2007-04-06 23:07
| 日記
|
Comments(0)
|
ファン申請 |
||