SE徒然日誌

[仕事：徒然日記] カテゴリの記事

全38件 (38件中 1-38件目)

1

• 人員配置

  ２つのプロジェクトに２人の人間を兼任させるのなら、それぞれ１つのプロジェクトに専任させれば能率上がるのに。。。

  2007/11/26

  コメント(0)

• 何のための打合せ？

  仕様を詰める打ち合わせなのに、詳細を確認すると「詳細は後で考えよう」。で、打ち合わせ終了後に残るのが漠然とした不安だけ。ゴールが何かが分かってないから、何をしなきゃいけないのかが分からない。何が問題なのかを明確にしないから、どうすればよいか分からない。なのに、そこをはっきりとさせよとすると「まずは話合うことが必要なんじゃない？」って、何を話し合うというのだ！？　締切りはあるんだぞ！！　今のペースで行ったら確実に間に合わないことをカレンダーを使って説明し始めたら「ちょっと休憩しよう」だとぉ！！！　どうやら、救世主が現れて要件を満たしたプログラム一覧を作ってくれるのを夢見ているようだ。 …ぶっちゃけ、それでも構わないけど、「どうする？」だけで答えを出そうとしない打合せを毎日10時までやるのは勘弁して欲しい。

  2007/11/02

  コメント(0)

• ネットワークの用語

  ネットワークの勉強してたら出てきた用語たち。ベストエフォード：努力はするけど保証はしない。コネクションレス：相手の都合を考えずに一方的に話す。ブロードキャスト：とりあえず皆に喚き散らす。ダメダメ社員じゃん。。。

  2007/07/12

  コメント(0)

• いじったら必ずテスト。

  テストを端折った時に限って問題が発生します。少しでもいじったら必ずテストしましょう。テストした後に修正したら当然テストし直しです。↑しっかりテストした後のちょっとした修正した時、テストを省略しがちです。今回「Ａ＋Ｂ＝１」となるところが「Ａ＋Ｂ＝０」になってた。ＡもＢも０が入ってて「Ａ＝１」じゃんって直したわけですよ。報告書作ってる最後の最後で「Ｂ＝１」にしないといけないことに気付いて慌てて直す。よくよく考えれば「Ｂ＝１」にする前に結果「Ａ＋Ｂ＝１」になったわけだから、「Ｂ＝１」の修正すれば、結果がおかしくなるのは当然です。えぇ、お客さんから「なんか１になるはずが２になってるんですけど。。。」ってダメだしきました。これは、もうベタ謝りしかないっす。

  2007/07/11

  コメント(0)

• 携帯メールを仕事で使う

  生保の担当の方が新しくなり、毎度のことながら見直しをお願いされました。中身については別にどうこう言う気はありません。２、３日放っておいた私も悪いのは確かです。ただ、携帯メールから「見ていただけました？」ってメールをしてくるのは如何なものかと思います。急ぎの要件や催促ならともかく、お伺いを立てるのであれば、PCからしっかりとしたメールを書くのが礼儀だと思います。メールがこの世に存在しなくて、「先日遅らして頂いた見積についてのご感想は如何でしょうか？」とお伺いを本気でするなら、ハガキと封書のどちらを使いますか？携帯からのメール。しかも受信日時が昼休みの終わり頃。片手間に送ったように感じられてなりません。そう感じるのはオレだけ？まぁ、額が低いくせに更新しようとすると渋る大した客じゃぁないんだけどさ。そのかわり、契約中の保険に対して、あーだーこーだ、うるさいこと一言も言ってないぞ。メディアが発達して用件だけなら簡単に伝えられます。相手の顔も見る必要ありません。声すら聞く必要もないです。用件を伝えるだけなら。仕事に限ったことじゃないけど、人と人のつながり。コミュニケーションの在り方を見直すよいきっかけでした。

  2007/07/09

  コメント(0)

• どうでもよいことにこだわるのかな？

  論理だってない愚痴ほど見苦しいものはないけど、力が足りずにメンバーを嘘つき呼ばわりされて言い返せなかった自分にかなりムカついているので、意味もなく長文になってます。●ある案件の見積で。開発工数：50人日（リスク込み）← 当然数字は例えです。社内レビュー時に・実工数が分からない。（リスクに対する保険が見えない）・利益が出ないから客先向けに工数上乗せしろ。とのこと。開発部隊としては、50人日ならオーバーしない自信があるって言ってるのにしつこく実工数って聞くからメンバーが-5日と答えたそうです。ちなみに私は参加せず。毎度のことです。私を無駄な会議に出すと会議そのものをぶっ壊そうとするのが原因だと思います。はい。●レビュー後の作り直し。以下のように作り直しました。・実工数　：40人日・開発工数：51人日・提示工数：60人日●何故か、営業部長が突っかかる。「レビューで実工数45人日って話だったのに、40人日ってどういうことだ。嘘をついたのか！」「嘘じゃなくて、大よそ-5日だと思ったんです。」「数字が違うのを嘘を言ったというんだ！」↓私が首を突っ込んで「-5日は忘れてください。最後に出したのが決定工数です。」「最終結果は関係ない。なぜ、レビューで言った数と違うかを聞いてるんだ！忘れろということは嘘を言ったことを認めるのか！」（5日のズレにひたすらこだわり、話がすすまない…）●断っておきますがまず、実工数自体が意味を成してません。客先提示も開発工数＋αで換算しています。(開発工数に対して○%の利益を出すように辻褄合わせてるので)そもそも「実工数＋リスク＋利益」か「開発工数＋利益」かどちらかで見積もればよいので２つも内部工数を出す自体無意味です。もちろん「妥当なリスクかの精査のため」とか「本音と建前の工数管理」といった意味では必要ですが。●私の突っ込みちゅーことで、開発部隊の隊長も了承のもと、辻褄あわせで適当に実工数を作ってます。（ていうのは、無駄だけどそれらしく見せるための暗黙の了解なんだけどな～）…そこに突っ込みを入れるか！しかも、最終工数はどうでもよいの！？「最終結果は関係ない」ってここが一番重要なんでしょ？更に、実工数の内訳はどうでもよいって！？そのくせ、見積根拠＆管理工数になる開発工数のズレは気にならないのはなぜだ？そもそも、文句をいってくる奴が営業部長。わけ分からん。実工数は関係ないだろ？社内は開発工数で動くわけだから、原価の基準値は「開発工数」。実工数が増えようが減ろうが関係ないだろ。しかも実工数減ってるじゃん！原価が減る可能性増えたんですよ。(実際は開発工数が増えてるので原価は増えてるのだが。)実工数部分については、開発部隊の隊長が文句を言うなら分かります。実工数が正確なほどリスクは減るので。営業には関係のない話です。(知ってたって構わないけど)●お約束散々ブー垂れた挙句、最終レビューには参加しませんでした。本題に入ったら議論に参加できないからでしょう、きっと。「おぉ～い。文句言うなら出るとこ出て話せや。おら！」●結論私に突っかかってきたら、話は早かったんですが、他のメンバーに矛先が向いてたので、説得を試みたのが失敗でした。そもそも難癖つけてきてるだけなんで。「そこが大事なんじゃないでしょ」「最終工数が妥当か見ようよ」ってズレてる論点の修正を修正しようとしても無駄ですよね。揚げ足とろうとしているだけなんだから。さっさと「後でオレが勝手に工数圧縮しちゃいました」って私のせいにしちゃえばよかったんです。自分に矛先が向いてたら「えぇ、嘘つきましたよ。それが何か？」って終わらしちゃったんだけなぁ～。●結論の結論どーでもよいことに難癖つけてきた相手は、説得しようとすること自体無駄。相手が望む回答以外は聞く耳ゼロ。「はいはい」って言ってあげるのが一番。どうせコアな部分には参加しないのだから。後は結果さえ出せば文句言えないんだから。(その代わり、結果が出なかった時は、猛烈に喧しいがそれは結果を出せなかったのでしょうがない。)もし、こんな奴相手に誰か庇うなら、説き伏せようとせずに自分が悪者になっちゃうのが手っ取り早い。↑これが出来なかったためにメンバーが嘘つき呼ばわりされたのを庇いきれなかった。。。

  2007/07/02

  コメント(0)

• 茹で蛙と常識的感覚

  いきなりお湯に放り込まれた蛙は熱くてお湯から飛び出すが、水が入った鍋に蛙を入れて沸かしていくと蛙は茹で上がって死んでしまうという寓話。１つのことに関わり続けると、少しずつ世間と感覚がズレていき、何時の間にか普通じゃありえない状態になっていることがあります。けれども当事者は全くそれに気付いてない。何か決定するときは、「そもそも何だったんだっけ？」って、いったん頭をまっさらにして顧みることが必要です。一番最初に感じた感覚と今が大きくズレてるときは要注意です。ある追加機能の案件。１機能の追加＋付随マスタ＆項目の追加。最初に話を聞いたときの感覚が「リスク込みで２～３人月」。何度か突っ返されて出来た最終工数が「４人月」。自分でも多少多いけどこんなものかな？って気でいました。けど、普通に考えたら、リスクを乗せたって、これは膨らましすぎです。お客の予想はよくて２人月。提示工数はその倍です。このまま見積を出せば、まずはお客があきれ、次には怒り出すでしょう。それでも「４人月」でいくのかな～。ただ、お客怒らす以上に何が怖いって、社内で一度も「見積高すぎ！」って突っ込みがなかったんです。本当に妥当な工数だと思ってるのかな？自分で開発するなら多めに工数言いますよ。リスクを背負うわけないじゃないですか。計画通りに開発進まなかったら評価下がるかも知んないけど、案件とれなくたっても下っ端の私は給料変わんないもん。メインでやる(であろう)私が案件いっぱい抱えてるならいざ知らず、５月からこれといった仕事をしてないんです。まずは仕事をもらうことを前提で考えるのが普通だと思うんだけど、私の方がズレてんのかな？≪追伸≫決して法外な値段を吹っかけてるわけじゃありません。リスクをしっかり乗っけて、その上、十分な利益もとれるようにしたらこの見積になります。上で言っているのは理想と現実、あるいは建前と本音の話。

  2007/06/26

  コメント(0)

• やることない

  仕事が暇。先のことを考えりゃ準備した方がよいのはあるけど、正式な指令は当分なさそうです。あっ、そもそも「部の方針に基づいて人員を決めるんじゃなくて、　組織が決まってから方針考えてる部」もしくは「やること決まってないけど、今後柱とするERPを　選定しようとしてる部」だった。当分は、仕事なさそうだ。

  2007/05/02

  コメント(0)

• 戻ってまいりました

  ようやく客先常駐が終了。自分の会社に戻ってまいりました。今日は撤収したパソコンの片付け＆自社に環境の構築。客先常駐開始がこのブログを始めた次の日。ブログ開始が2005.07.05。…てことは、約1年と10ヶ月。長かった～。

  2007/05/01

  コメント(0)

• ファイルを増やすな！

  プロジェクトのファイルの整理をしています。思いつきで作ってあるファイルが散乱しています。一箇所にしか書かれていなければ、その内容があっているか確認してメンテナンスすればすみます。複数のファイルに同じことに対して微妙に違った内容が書いてあって、よく分かんないから新しくまとめたファイルをまた作る。。。本人は、整理しているつもりなんだろうけど、傷が悪化していく前兆です。「よく分かんないけど、消すと何かあった時困るから。。。」「何かあった時は、よく分かんないファイルなんて当てにできるかぁーーー！」

  2007/04/17

  コメント(0)

• 新しい名詞

  ＥＲＰ事業部だそうです。何のＥＲＰをやるかは検討中だそうです。検討中のまま、翌年を迎えないことを祈ります。

  2007/04/04

  コメント(0)

• 新年度に入ってジリ貧に

  新年度になりました。配置替えの季節です。主力の方が会社を去りました。現場の方が転属になりました。遂に我が部隊で保守で扱ってるERPの開発ができるのが私だけになりました。最短でも４月までは客先常駐です。保守要員を育てる気配は今のところゼロです。しかも既存のお客の新規対応まで駆り出す気です。「こっちをやったら、あっちはできませんよ。」「そうは言っても、できる人間がいないんだよ。」「じゃあ、今やってるのは納期間に合いませんね。」「それじゃあ、困るよ。」「なら、これからやるのに参加できませんね。」「分かる人、確保できないしな～。」で、ぐずぐずしている間に新規の方のお客さんから「もういいです。」と言われて、儲けを逃すのがいつものことです。ただ、今回の新規案件は、お客さんにとっても必須みたいなんで、どう対処するんのでしょう？(↑これだって、最初に話が出たのが１年以上も前なんだけど。。。)

  2007/04/02

  コメント(0)

• ズルズル長引く

  ４月の定期申請をお客さんの所まででするようにとのお達しがありました。あれっ？３月で撤退するんじゃなかったっけ？４月に居残る理由が分からん。そりゃ、お客にしてみれば、住処に引っ込んで打合せで決まったことしか、してもらえなくなるより、なんでも屋を自分の手の届くところに置きたいだろうに。理由がないのにお客の言いなりで撤退できないんじゃ、何時になっても撤退できないな、こりゃ。客先で時間給で働くより、自分とこで成果物に対してお金貰った方が、よっぽど金になるのに。後者で赤出す部隊が多いから最低限の時間給を確保できる前者を選ぶ上の意向がよく分からん。せっかく、１人月分の工数を短縮できてんのに、その分お金もらえず、追加要望を追加費用をもらわずに(時給だからもらえずに)やることになるであろう状況っていったい。。。。不毛だーーーーー

  2007/03/01

  コメント(0)

• 人には言っておきながら！

  お客さんのところで常駐です。人月計算でなく時間計算で行ってます。今月は年始休みもあり時間がピンチです。年前から有休をとる予定を言ってましたが、今月に入って「時間足りないから来月にして」と言われました。何を今更とは思いましたが、ＰＭが更に上からネチネチ言われるのも可哀想なので来月に延期しました。頼んだＰＭ本人が明日休みます。急な話ではなく計画的な犯行のようです。「言ってなかったっけ」とすっ呆けてます。しかも現場には時間がギリギリなので自分が休む日にも残業を強いておきながら。所詮、「やったもん勝ち」のようです。頑張ろうとする行為にどうして絶妙に水を差して周るんだろ～って感じです。こういう人って、「今さえよければよい」んです。「自分に火の粉が降りかからなければよい」んです。筋や仁義はありません。理屈で話をすると結局は、こっちで背負わないとならなくなります。なので、なんとかしようと思うより、適当に受け流すのが一番だとつくづく感じます。「どうすんだ？」→「どうしましょう？」「頑張れ！」→「頑張りま～す」「なぜ終わらないんだ！」→「頑張ったんですけどね～」初めの段階での次善策を講じようとすると不毛な努力に気持ちが萎えるから。「おかしんじゃない」って筋を通そうとすると「お前は直ぐ噛み付く」から始まり「だから何が言いたいんですか？」って話を延々としだすから。へこむなぁ～～

  2007/01/30

  コメント(0)

• 責任とりたくなければ、はっきりさせろ

  既存システムのカスタマイズ案件がありました。対応範囲に、あった方がよいかも程度の機能がありました。本格的に作りこむと費用がかさむので「おまけ程度の機能で作りましょう」という話になりました。後日、見積の対応範囲に、この機能がなかったので、PMに確認しました。「おまけ機能を使ってトラブルが発生したときの責任が持てない。サービス品として提供することにしたので、対応範囲に明記すると責任の範囲が不明確になる。」だそうです。…逆だろ。ものを提供する以上は、サービス品だろうが何だろうが不具合が発生したら、「おたくに作ってもらったもんだけど、不具合が出てるぞ！」になるでしょう。責任の範囲外にしたいのならば、「責任を取れないから提供しない」か「提供するけどサービス品なので如何なる損害も保証しない」のどちらかをはっきりと明記すべきでしょう。打合せで「作ります」って言っときながら、何かあったら「見積書にそんなもん作るって書かれてないでしょう。うちは知らないよ。」って本気で答える気なんでしょうかね？(うちの上なら真顔で言いそうだけど)結局、こうした「ウヤムヤ、もみ消し、その場が乗り越えらればよい」が、ことがあった時に「勝てない、信頼崩壊、次に続かない」原因を作ってるのが分かんないのかな？

  2007/01/25

  コメント(0)

• いるところにはいるんですね

  お客さんのサーバーがダウンするという緊急事態が発生しました。開発したアプリでの障害なら幾らでも対応できるんですが、ハードになると知識が皆無なので、同部署の中堅どころの方にお客さん所についてきてもらって対応しました。物腰は柔らかい方なんですが、１つずつ原因をつぶしてき、最短の方法で復旧させていく様は「おぉ～！」って傍で見てて非常に頼もしかったです。うちの会社の人間にはそっけないお客さん担当者ですが、お客さんから名刺交換の話が切り出され、「おせわになりました」メールがその方も含めて来ました。私が３年間で勝ち得た信頼関係を３０分で獲得してしまいました。「大変だ！大変だ！」っで騒いでるだけで何もしない方々が周りに多いだけに、「うちの会社も居るところにはちゃんといるんだ」って妙に感動してしたのでありました。

  2007/01/18

  コメント(0)

• 必要ファイル一覧

  恥ずかしいことながら、うちの部署にはプロジェクトで必要となる標準ファイル一覧がありません。なので、ＤＢは何を使ってる？サーバーは？みたいなことが担当者に聞かないと分かりません。必要となるファイルの一覧が明確でないから、・必要な資料がない。・不要な資料がいっぱいできる。整理整頓されている部屋はなかなかよごれないけど、散らかっている部屋は直ぐに壊滅的に汚れるのと一緒です。まずは必要最低限のファイルしか作らない。必要なファイルがないことが明確になれば作ればよいだけです。中身が古ければ気付いた時点で修正すればよいだけです。何が必要なファイルなのかが分からないことが問題なんです。だからファイルを削除できないし、全く見ない資料しか残らないんです。

  2007/01/16

  コメント(0)

• 忙しいっていってる奴ほど忙しくなかったりする

  あれもやんなきゃ、これもやんなきゃって忙しそうに騒いでる奴が本当に忙しいことは稀だったりする。本当にやんなきゃいけないことと、どうでもよいことをごっちゃにしとる。騒いでいるだけで作業に取り掛からない。自分で何やるべきかわかっちゃいないので作業に取り掛かれない。自分の作業をやらずに他人の作業に首を突っ込む。そのくせ、定時になったらさっさと帰る。よーするに「今、何をすべきか」が分かってないんでしょうね。具体的に「○○を△△までに××してください。」と頼むとテキパキとこなしてくれちゃったりします。但しその人の裁量に任せて具体性に欠ける指示をすると見当違いや何時までたっても終わらないことが多々あります。

  2007/01/11

  コメント(0)

• 医者の不養生

  今月は年始の休みや成人の日があって、いつもの月より勤務日数が少なくなります。客先常駐をしていますが、当然、お客さんのところでの作業日数も減ります。一般的にはどうだが知りませんが、基本時間＋オーバー分は時給換算で毎月お客さんに請求しているそうです。基本時間にこのままでは到達しません。で、「悪いけど今月、残業して」特に近々にやらなあかんタスクもないし、追加対応はスケジュール通り進んでいるので、残業する理由が見当たりません。昨年はごたごたあって、予算オーバーでお金頂いているので(その分仕事もしましたが)、時給換算で仕事してんなら仕事した分だけ貰えばよいじゃん。損するわけじゃないんだし。と、いっても目標予算もあることだし、ベースの額に満たなきゃ利益も出なかろう。何よりお偉いさんにネチネチ言われる上は辛いだろう。なので、休みの分の時間を残業で地道にカバーしています。なのに、言った張本人が2時から客先のはずが来たのが4時。人には遅刻がうんたらかんたら言っときながら(はい、遅刻そのものはいけないものなのは重々承知です)、自分はそれかい。口でえらそうなこと言っても行動で示さない奴は信用できません。ＰＳ今回のプロジェクトのＰＬは立派なことをいっぱい仰っておりましたが、自分に割り振られたタスクも終えぬまま、会社を卒業なさりました。

  2007/01/10

  コメント(0)

• ソースの修正とリファクタリング

  私がソースの修正を行う場合、かなりの確率でソースの整理が入ります。定義のみの変数の削除。もはや元に戻せない修正前のソースのコメントの削除。仕様変更等で絶対に入らなくなっている分岐等の不要な処理の削除。同一処理の関数化。変数名の統一化。関数名を分かりやすくする。･･･今回、上よりストップが入りました。「お客さんに納品したソースはお客さんのものだから勝手に直しちゃいけない。」確かに一理あるでしょう。じゃぁ、バグ修正やパフォーマンス改善で一々お客さんに断りいれてるかっていうと「いれてない」です。(お客さんところで運用支援＋要望による仕様変更を行っているという環境なので)もちろん画面のデザインを変える等のインターフェース部分を初めとする「使った上での変化」は仮にバグであっても断りを入れてます。どう考えたって直した方がよいなぁと思う箇所であっても了解を得なければ絶対に直しません。「リファクタリング」の場合はどうでしょう？動作は全く変わりません。むしろ今後の仕様変化に対しても柔軟に対応できるようになります。唯一の欠点はデグレが発生するリスクを伴うところです。ソースをコアで見いて初期導入の今だからこそできるのであって、このタイミングを逃したらアンタッチャブル領域に突入です。「今直さないと今後ソースいじれない」っておどしたら簡単に折れました。･･･要するに、デグレがやなんだって。ここの所、修正リリース後にちょくちょく動作不備があって、お客さんに文句言われたからが本音の気がします。ぶっちゃけ、リファクタリングするしないに関わらず、リリース直後に若干の動作不備は覚悟してもらわないと。(もちろん、これは、こっちの都合であって、不具合が発生したらお客さんには謝ります)その代わり常駐してるんだから障害をすぐに直せる大勢をとってるんだよ。システムがストップするようなでかい不具合なら問題だけど、ちっちゃな不具合で上がおたおたされちゃーやりにくいっすよ。「ちゃんとテストしろ」って言われたって、私が要件聞いて提案して直してテストしてリリースしてんだから、発想漏れがあったらそもそもテストパターンが想定されてないんだから無理だろ。ちゃんと他の人にもテストしてもらってって言ったって私が想定されるパターンも説明するんだから抜けはあるって。人任せにしないで取り仕切ってるあなたが本当に取り仕切って個人プレーから団体プレーに変えていってくれなきゃ。(と、言いつつも、SEはチームプレー(野球？)じゃなくてスタンドプレーの集合体(サッカー？)だと思っています。)確かに見た目変わらなくても改造していることには変わりないので、お客さんに了解とって勝手に今後もいじり倒します。どーせ、保守も私がやるんだし。自分のいじったソースについては妥協したくないから。

  2006/12/08

  コメント(0)

• Yes No が聞きたいんじゃない

  お客さんから「○○計上で既存の伝票を修正した場合、△△の項目は最新の情報に書き換わりますよね？」と質問がありました。お客さんが聞きたい応えは「書き換わる。もしくは書き換わらないなら困るから書き換えるようにして。」です。仕様を分かっていないプログラマに調査を依頼したのならば、「書き換わらないですよ。」という調査結果で回答は十分です。「じゃ、どうするかな。」の部分はお客さんと私が詰めます。けど、他のお客さんのところに出てて、主担当者に頼んだ結果、「書き換わんないみたいだよ。」の一言とソースをそのまま添付で送ってくるとは如何なものよ？「自分がお客との窓口になって話をつけるんだったら、その回答をそのまま話せますか？」そういう根性が「仕様だから」の一言で使い物にならないプログラムを平気で納品するような事態を起こすんだ。「誰に対してもの作ってるのか？ 自分の仕事にプライドはないのか？」別に会社人間になる必要はないけど、余計なことして話をややこしくして他人の仕事を増やすような人間だけにはなりたくないですね。

  2006/10/02

  コメント(0)

• 目標や課題、計画を立てて満足してません？

  目標や課題、計画は何のために立てるのでしょう？管理のための管理をしたって作業は終わりません。大抵の仕事には期限があるわけで、期限に間に合わすのであれば、ある段階からタスクを「立て直す」のではなく「切り捨てる」のも必要ではないでしょうか？私は、多くのタスクを抱えた場合、それらを４つに分けます。１．重要で緊急度の高いもの２．重要で緊急度の低いもの３．重要でなく緊急度の高いもの４．重要でなく緊急度の低いもの着手は、１→２→３の順で、４は切り捨てます。ここで重要なのは「２→３」の順で作業することです。２と３の順番を誤ると日々の作業に追われてスケジュールが大抵ずれ込みます。３で実は重要だったものであれば当然１になります。けれども大抵は４(やらなくてもよいもの)に変わります。

  2006/09/26

  コメント(0)

• 辞めちゃった上司が言ったことば

  お前が車を買ったとする。予算は150万納車日が近づくと販売店員がこんなことを言う。「ちょっと不具合が見つかって納車日が遅れそうです。」そりゃー、事故にでもなったら困るので待つことにする。３ヵ月後に販売店員がこんなことを言い出す。「ごめんなさい、一部のオプションがまだ乗っけられてないんです。」高い金払っちゃったし、ちゃんとした車に乗りたいんでしぶしぶならも待つことにする。更に３ヶ月、まだ納車されない。「いい加減にしろや！」もう１ヶ月待って、ようやく納車。届いた車の車種が違う。ギアが入らない。途方にくれるお前に販売店員のとどめの一言。「もう200万かかっちゃったんですけど」システム業界だけだよ。こんなのが許されてるの。世間一般から言っておかしいと思わない？…う～ん。※だいぶ昔の話なんで、都合のよい解釈が入ってると思う。

  2006/07/01

  コメント(0)

• 納得いかない

  今週頭から一部の機能を使うとフリーズしてしまう障害が発生しました。強制終了するしか手がないため、お客さんと相談した上で、その機能を一時的に使えなくしました。パートナー企業が開発した部分のため、私が原因を追うのにも限界があり、そのことをお客さんにもちゃんと説明しました。原因が全く不明のため、根本的な原因追求も大事だけど、当座を乗り切れる次善策についても開発元と話し合いました。運がよく、たまたまサーバー再起動をしたら、とりあえずは動くようになりました。今日、上の人間が打合せをした後で開発部隊のところに来て「どうして再起動するまでに一週間もかかったんだ！」以下のことを説明しました。（「プッチ」と切れたので喧嘩腰だったけど）たまたま再起動して現象が消えただけで、普通に考えれば再起動すれば消える障害とは想像できない。（ソース内で固まるがSQLを投げている箇所ではない）　↑　コールしているDLL内でサーバー内のDLLを使って　いたようです。（推測ですが）自分の部隊が作った部分ならまだしも、他の会社が作った専門外の部分まではどう動いているか分からない。と、いってもそれはこちらの都合なんで、お客さんには十分に説明し、逐次、状況を報告した。これらのことを開発元とメール＋電話で密に連絡取り合った。・本稼働中にもかかわらず機能が使えない。・ユーザレベルでクレームが発生している。・システム担当者で押さえてもらうのにも限界が近い。・とにかく、固まらないようにするための暫定対応でも　よいから緊急対応が必要。で、それ以上どうしろというですか？最終的には「そういったレベルのことは上にちゃんと報告しろ」とのこと。PLには報告してるんで私がすべきことじゃないような気がすけど、それはごもっとも。その後、今回の打ち合わせ資料にしっかりとうちの会社が把握している懸念事項に明記されていることが発覚。「しっかり報告してるじゃん！」（日々緊急対応なので報告していたか否かを覚えていなかった　PLについては、責められないと思う。ちゃんと報告してたし。）PLと再度、切れました。結局は、打合せの席でこちらの現状をしっかりと確認せずに不用意に上が言ったことがお客さんの偉い人の逆鱗に触れたようでした。その腹いせに過ぎなかったような感じです。（この辺からはPLと上との電話でのバトルなので詳細は不明。）お客さんと密に連絡を取りながら、可能な最善の策をとり、上にもちゃんと報告しているのに責められる理由が分からん。（お客さんから今回の対応そのものに対してのクレームは何も聞いてないこと。）こちらで障害に対してハンドリンクして重要度を決定すると今回みたいに(実際は報告してたけど)報告した/しないになるので、障害一覧に対してをそちらでも重要度を精査して。と言ったら。「現場のことは分からん。」これ以上どうしたいと言うんじゃ！要するに、・打合せに言って文句は言われたくない。・責任は取りたくないので、お前ら何とかしろ。・けど、何か言われたときにズバって答えられるように　言い訳のネタだけ教えろ。ということですか。GW明けに別件で爆弾を抱えてます。こいつに対する上の対応によっては大人気ないけど全面戦争します。

  2006/04/28

  コメント(0)

• 最終手段の再起動

  サーバーの調子が悪い。かなり確率で処理が途中で中断されてしまう。原因が全くもって不明。そんな時は、とりあえず再起動。無事、復旧！原因がなんだか分からないからちょっと怖いが、まぁー、とりあえずよしとしましょう。定期的に再起動させていないサーバーの再起動は恐怖以外何ものでもありません。買換えまで再起動させる気ないならよいですが、そうじゃなければ定期的に再起動かけといた方がよいと思います。

  2006/04/27

  コメント(0)

• 分からないならそう言えよ

  プログラムに不具合がありました。マズイことは確かなんだけど、あるべき姿の仕様が分からない。当然、仕様書には書かれていない。正しい姿が分からなけりゃ、修正もできない。PLに現象・原因を説明して確認しました。「○○の区分が××の時は、△△になるべきだよ。」　その通りに直してもあるべき姿になりゃしない。「ひょっとして、××じゃなくて、□□なんじゃない？」「うん。ごめん。説明が足りなかった。」・・・記憶が曖昧なら、そう言え！完全に区分の値を間違えてるんだから説明が足りなかったじゃなくて、勘違いしてただろ。「俺は悪くないよ。そんくらい理解してくれると思った。」って言ってるように聞こえます。（本人にそういう気がないかもしれないが）指示する側は、実際の姿やあるべき姿と本人の思いを明確に区別して話しましょう。・「こうなるべき」と「こうなるはず」・「こうなっている」と「こうなっているはず」どこまでが確かで、どこからは不確かかをはっきりさせてくれれば、こっちだって不確かな部分は調査＋確認しながら進めます。新規追加なら、自分でも確認してから作業するけど、不具合で一刻を争う時に「こうなんだ」って言われた仕様まで本当に合っているの調査確認はできません。自信を持って間違われるとお手上げです。おかげで、確認した仕様が根本的に嘘だったので修正部分を全部作り直しです。

  2006/04/19

  コメント(0)

• 自分で使ってみた？

  開発メンバー間で使い方を聞かないと操作が分からないシステムを、お客さんが使いこなせると思いますか？「動く」のと「使える」のは別物ですよ。他人の説明を聞かないと操作が分からないようなデザインなら再考が必要です。（時間がないから「動く」だけでもよしとするか。。。）

  2006/04/03

  コメント(0)

• 過程より結果

  どんなに一生懸命作ったって動かなければ100円ショップの電卓の方がよっぽど実用的。何とかなるのは、事前に何とかしてるから。何もしなけりゃなるようにしかならない。えぇ、「作ってみたけど上手くいかない」とかサラッと言ってのけたあなた。尻拭いは誰がすると思ってるんですか。

  2006/03/30

  コメント(0)

• してはいけないことはさせない

  システムの内部項目の設定登録機能をお客さんにリリースしているプロジェクトがありました。なぜリリースするの！？伝票番号は内部的に自動採番にも関わらず、伝票番号管理テーブル変更画面なんかがその典型です。お客さんが勝手に番号を変えたら間違いなくシステムは崩壊します。画面が１個でも増えれば、その分、お金が貰えるとでも思ったのでしょうか？メンテナンス画面を提供した以上、勝手にいじられても文句を言えません。当然、お客さん自身で勝手にいじってはいけない項目のメンテナンス画面はリリースすべきではありません。と、思うのは私だけなのかな？「触ってはいけないと言ってもあれば絶対に触る。」ので、「使わない(使ってはいけない)ものは組み込まない。」が鉄則です。

  2006/03/09

  コメント(0)

• 不正なデータはそもそも作らせない

  お客さんから、「エラーで登録できない」との問合せがありました。原因は、マスタに不正データが存在したため、データチェックでエラーとなっていました。（本来、そのマスタのレコードでは値が入っていてはいけない項目に値が設定されていた。）で、説明した時のお客さんの一言「だったら、マスタ登録画面で登録できないようにして下さい。」もっともな話です。《システムの大原則》・してはいけないことはできないようにする。・不正なデータは作らない。作らせない。PKとして扱われる項目が異なるデータを1つのマスタ内で区分で管理しているDB設計にも問題あるんですけどね～

  2006/03/08

  コメント(0)

• VSOP

  日経ソフトウェア（2006年1月号 P140）の著書紹介の欄で、平鍋建治氏がこんなことをおっしゃっていました。　エンジニアのキャリアはVSOP」ってご存知ですか？　エンジニアとして、20代から50代をどのように過ごすか、　という一つの指針です。　20代…Vitality 元気一番！　30代…Specialty 得意を一点深く　40代…Originarity 自分しかできないことを　50代…Personality 信頼される人格を「おかし」や「ほうれんそう」じゃないけど、言いえて妙ですね。

  2006/03/07

  コメント(0)

• 棚卸しと医者の不養生

  先週棚卸しがありました。部署の半分ぐらいの人間が資産(主にPC)の一覧を持って、３日間あっちこっち行ったり来たり。…思いっきり「ムダ」ですね。開発工数１日多く見積もるのに文句言うくせに、毎年やってるムダな作業にお咎めないのも如何なものか。（少なく見ても１人月以上の原価が。。。）１．資産をシステムで管理する。　（２と絡んで履歴も管理しようと思うとEXCELじゃ辛い）２．管理者を明確にする。・自分のPCは自分で管理する。・プロジェクトで使ってるサーバー等はPLが管理する。・協力会社さんが使ってるPCは、協力会社さんをアサインできる人間　が管理する。・使ってないPCは、持ち出す権限を持っている人間が管理する。・自分管理のPCを他人が使う場合は、両者の合意の下、　管理者を委譲できる。・管理しているPCがなくなってたら管理者の責任。・管理者の許可なく勝手に持って行った奴は死刑。・当然、システム屋なんだから、これらをシステムで管理する。３．管理者に申告させる。…棚卸しなんて10分で済むじゃん。＜うちの部署＞１．社内LANに資産管理システムがある。（OK）２．管理できない人間を管理者する。（NG）３．申告してこない。（NG）１について・過去、私と同じことを思った人(今はいない)が音頭をとって　作ってくれました。（それまで、経理から自分の部署の資産表をもらうまで全く　把握できないというひどい状態でした。）・但し、２と絡みますが、管理者が明確でない為、年を追うごとに　システムに登録されていないPCが増えてきています。２の問題・配属が代わった人間のPCが本人が知らないところで管理者に　させられている。・部長以上は自分のPCすら管理者になっていない。・そういったPCの管理を年齢が低い人間に押し付ける。・管理者が管理する権限を持っていないから、知らないところで　勝手にPCが持ち出される。→責任を負わなきゃいけない人間が管理すべきだし、責任を　負わすなら権限も与えるべき。３の問題・資産管理が、申告してこなくて(PCが見つからかなくても)問題ない　程度のものならやる必要ない。・問題あるんだから申告しない奴の査定を落とすぐらいのことを　部長が言えば一発で済むでしょ。　（自分のPCすら管理してないから強く言えないのかな？）＜反論に対する反論＞「こんなことしたら日々の管理者の負担が大変になる」とかいう人（特に他人任せにしていたえらい人）が大抵でます。「本当に大変か？」自分のプロジェクトや個人割当のPCを各々が管理するだけだし、空きPCは勝手に持ち出されるのがそもそも問題。後は、アサインのタイミングで人と一緒にPCの管理もPLに委譲すればよいだけだし、PLも自分のプロジェクトから外れた協力会社さんとPCを外した人間に返せばよいだけでしょ？以前、資産管理メンバーだった際に、「勝手に持ち出されるから行方不明になる。　資産管理メンバーが空きPCの電源コードを全部確保して　勝手に持ち出せないようにしたい。」と言ったら、何故だか大反対をくらいました。＜結論＞「システムを使って効率化しましょう」って言ってる人間が自分の会社のムダを気付かない、改善しないようじゃ、本当によいシステムを提供できるでしょうか？

  2006/02/27

  コメント(0)

• 詳細設計、開発、単体テストの工数

  仕事：詳細設計、開発、単体テストの工数既存システムに対して大幅カスタマイズの見積の話が来て、開発者の意見として工数算出を求められました。私のおおよその算出の際の割合は・詳細設計、開発、単体テスト（自社同一人物）　４：３：２・詳細設計（自社）と開発＋単体テスト（自社他の人間）　５：３：３（単体テスト２＋受入１）・詳細設計（自社）と開発＋単体テスト（他社）　６：３：４（単体テスト２＋受入２）です。上の人に言われたのが「テスト工数が多すぎ」です。一般的には「開発×0.25」だそうです。…納得いかない。私が単独開発する場合は、詳細設計＝テスト仕様書とほぼ同義になります。基本設計書で記述されている要求仕様をプログラムで実現する際の制約事項や基本的な考え方を詳細設計書の起こし、更に個々の動作（体裁よく残すかどうかは別として）を考えます。で、それを実際のソースに落としていくのが開発。作っていく際に各動作を確認していくわけだから単体テストは同時進行で行います。で、開発終了時に単体テストの８割が終了し、後は、最終的な見直しと再テストをして終わりになります。なので、厳密に開発と単体テストを分けろと言われても困るのですが、極論で言えば、開発とテストは１：１、もしくはテストの方が工数が多くなります。詳細設計で考える個々の動作（＝テスト仕様書につながる部分）が、詳細設計者と開発者とのコミュニケーションが疎になればなるほど、厳密に記述しておかなければならないので、大量に増加します。開発は「詳細設計をソースに落とす」のであって、「要件を実現する場」ではないと考えています。記述の仕方を開発者に委ねることはあっても要件の実現方法（処理内容）は、詳細設計者の担当だと思います。開発者との作業場所が同一フロアであったり密にコミュニケーションがとれて、開発者のレベル＋作業内容を把握できる時のみ開発者に実現方法をある程度は委譲出来るのだと思っています。じゃないから、言った言わない、書かれてなかった、そんな仕様知らない常識だろそんなの、どうして他と同じ動きしてないのっていう話になるし、「受入れって結局、単体テストと同じことするんだよね。」とかいうふざけた会話が成り立つんじゃないでしょうか？私の受入れは、やったテストを全て具体的に１つずつ明記してもらい、テスト結果に書かれていないことは「テストしていない」と見なします。なので、大抵、あまりにテスト項目が少ない為、やり直ししてもらいます。（「正しく値を取得する。（○）」みたいな項目があれば論外。）また、テスト結果で「○」があるものは、開発者が動作を保障しているものなので、１つでも「○」になっているのにその通りに動かないものがあれば、全テストやり直ししてもらいます。なので、受入れは、原則、詳細設計者側から見て伝わりにくい部分と致命的な部分のみテストになります。ただ、こうした理由で、開発者のテスト結果が使用できるレベルになるまで、相当の時間がかかり、２度手間に近い状態になります。そう考えると、開発と同等かそれ以上テストでかかるのは当然のような気がするんですが。。。

  2006/02/24

  コメント(0)

• できること、できないこと、してはいけないこと

  販売管理システムでは、締め処理を行った場合、その月以前の売上計上はできなくなります。そうしないと、過去の売上金額がころころ変わってしまいます。締め処理を行った後に、売上計上の忘れがあった場合は、・いったん締め解除処理をして、売上計上をする。・翌月の売上にする。のどちらかになります。例えば、お客さんからこんな依頼があったとします。・先月の売上で金額の入力間違いがあった。・先月は月次更新済み。・当月売上で差額を調整計上すると、先月分は、間違った金額で　請求書が出力される。・締め解除処理はない。→データの修正をして欲しい。対応しようと思えばできます。けど、この場合は「できません」と回答すべきだと思います。お客さんの要望通りにデータを直接修正するのは、論外です。データ改ざんの手助けをしているようなものです。締めた状態を一時的に解除するのも可能ですが、対応していない（締め解除プログラムが存在しない）のであれば、やってはいけません。同じようなことがあれば、次回からも対応しないとならなくなります。もし、対応するのであれば、「締め解除」プログラムの開発を注文してもらい、ちゃんとお客さん自身で対応できるようにすべきです。バグはさておき、通常の運用での問い合わせについては、システムでできる次善策を回答すべきです。極論、システムなんてもんはデータの塊なんで、直接データをいじれば、大抵のことはできてしまいます。けれども、お客さんがプログラムからできない処理は、やってはいけないと思います。プログラムのバグによって不正データが発生した場合、止むを得ずデータを直接修正することはあります。但し、この場合であっても締めた月のデータに対しては修正は原則してはいけません。

  2006/02/24

  コメント(0)

• 餅は餅屋

  世の中には市販製品に引けをとらないフリーのソフトが多々あります。それにも関わらず、高い金を払って製品を購入するのは何故でしょうか？その大部分は「安心」（保障）を買っているのだと思います。動いているうちは、問題ないです。けど、何かあった時にフリーと購入製品では大きな差がでます。システム屋をやってれば、ちょっと調べりゃ、大抵のものは自分達だけで何とかできます。けど、やっぱり餅は餅屋です。専門外の部分も自分達でやろうとするなら、それなりのリスクを背負い込むことを覚悟すべきです。そして、大抵の場合、それによって生じるリスクとコストは、専門業者に金を払うことより大きくなることを肝に銘じるべきでしょう。--------------------今回発生した障害は、初期導入時に他部署へ委託した部分を自部署で見よう見真似でカスタマイズした結果、一部の処理パターンに対応仕切れていなかったことが原因でした。目先の利益や他部署との連携時のコストを省く前にそれに伴うリスクを考えなかいのかな～。そういうことする人に限って、「○○部が関わったんだからそっちに調査してもらうように言って」とか平気で言うんですよね。（注）・目先の利益：　私の勤めている会社は、部門採算性の為、他部署への委託はその分、　利益を持ってかれる。・他部署との連携時のコスト：　よそが絡むと仕様説明・受入れ等、当然、工数は増大する。[余談]もともと担当した部署に「ごめんなさい」して調査してもらいました。「うちで手を入れてたら、こんな設定しないんだけどね」なんて言いながらも、無茶苦茶になっている設定を読み解き、無償で対応して頂きました。本当に感謝です。お金うんぬん以上に、「分かってない奴がいじったことにでグチャグチャになっている　ものを他に影響がないように修正してもらう」ことについて、申し訳ない気持ちでいっぱいでした。

  2006/02/13

  コメント(0)

• プログラムの俗称

  「○○の処理でおかしな動きしてるんですけど」って問合せが来たんですが、プログラム一覧に「○○」がない！（諸事情により「○○」の具体名は出せません。）過去にも聞いたことある名前だったし、絶対どっかにあるはず。うちが作ったシステムのくせして、「○○ってどんなプログラムでしたっけ？」って聞くのもなんだし。で、結局「○○」って俗称だったんです。例えば、「得意先別納品先別受注一覧」を「納品先別受注」みたいに略された場合は、まだプログラム一覧を「受注」で検索すれば引っかかります。ただ、今回のは「納品先別伝票一覧」を「支払伝票」みたいに言われたため、プログラム一覧からプログラムを探せませんでした。問合せは正式プログラム名を書いてもらうのも一つの手ですが、お客さんの中で通常やりとりされている別名があるんだったら、プログラム一覧に併せて書いとくのもスムーズに会話できるための手かなと思いました。そもそも、こっちの都合で現状業務を無視した分かりにくいプログラム名がついているのがそもそもの問題なんですけどね。

  2006/01/16

  コメント(2)

• お客さんは何に対して怒るのか？

  私が担当しているお客さんが理解のある方ということもあるのですが、障害に対して怒られることはまずありません。本気でお客さんが怒ってくるのは、障害に対してではなく、障害に対するうちの対応がずさんな場合です。（※私じゃないですよ。）お客さんが一番困るのは「障害が発生している」ことではなく、「業務がまわらなくなる」ことです。（私の周りではこの状態を「トラブル」と呼んでいます。）今日中に出荷しなければならないのに出荷できない。何とかして欲しいのにメールをしたのに返事が返ってこない。ギリギリやばくなったので電話をしたら「担当者不在なんで明日まで待ってもらえますか？」怒るのも当然ですよね。お客さんは業務のプロです。大抵のことなら、早めに状況が分かれば善後策がたてれます。特にメールでの障害報告は、送信した段階でこちらが認識していると思っているので注意が必要です。個人的には・メールを受信したら状況を認識した旨を即メール。・対応が何時頃までかかるかをその日のうちにメール。・原因報告と対応予定をメール。・完了報告をメール。＋必要に応じて電話で連絡をしています。ちょっと前まで、記事やトラックバック・コメントがなかなか更新されない現象が楽天で起こっていました。気付いた方も多いかと思いますが、管理トップに『記事、コメント、トラックバック等の反映の遅れについて』が掲示されています。みなさんも、反映が遅れることより、これが掲示されるまでの何か分かんないけど反映がうまくいかない状態の方が不快感が大きいんじゃないでしょうか？もちろん、障害は早めに解決しておくに越したことはありません。う～ん、楽天を褒めたのは良いが、プレビューがまた「undefined」だ…

  2006/01/12

  コメント(2)

• 保守対応ソフトの作成中

  本格的なソフトをこしらえてみようかなと。「自分の作りたいように作らしてっ！」と「勉強＋今後のストック」が主な目的なんですが、自分があれば便利だなと思うものしか作らないんで、今回もそれなりのものができるかと思います。乞うご期待。■追伸(2007/05/22)VB.NETのソースのストックはできましたが、ソフト自体は挫折です。

  2005/09/17

  コメント(0)

全38件 (38件中 1-38件目)

1