ausearchコマンドの使い方 - QiitaHelp us understand the problem. What are the problem?
今回のシステム業者の新しい担当SEがちょっと変
会社で使ってるシステムで調べてほしいところがあったから、最近かわった新しい担当SEに連絡したら、 「不具合だったら直すけど、不具合じゃなかったら調査費用と出張費で８万請求するけどいい？」みたいな聞かれ方したんだけど、これってIT界の常識的にどうなの？ こっちは不具合かどうかなんかわからないんだからどうしろっつーの？もし不具合だったらオマエの会社に損賠請求してもいいの？(客に喧嘩売ってんのか？)って思ったけど、普通はどうなんでしょう。
人のコードを引き継ぐときに一番困るのは「使われていないコード」 | mah365
プログラミングを生業としていると、人のコードを引き継いで開発するなんてこともままある訳ですが、そういうときに一番困るのは「使われていないコード」だなー、としみじみ感じます。 使われていないコードがもたらす弊害 特に動的言語で書かれたコードというのは前触れ無く呼び出される可能性があるため、本当に利用されていないのかどうなのか、きっちりと調べあげるのは困難なケースがあります。例えばrubyであれば、method_missingでキャッチしてsendで動的に処理先を振り分けるなんてことをしていると、単純にgrepして利用状況を見るだけでは不十分な場合があります。 そういう意味では「使われていないコード」というよりは、「使われているのか使われていないのかはっきり分からないコード」という方が適切な表現かも知れません。 そういった「はっきりと判断のつかないコード」がある状態だと何が問題なのかと言うと、
「何もしてないのに壊れた」撲滅運動
よんてんごP @yontengoP ・「何もしてないと私は思っていますが壊れました」 ・「壊れたのですからきっと私が知らないだけで何かをしたのでしょう」 ・「何かをしましたが何をしたかは分かりません」 ・「そもそも壊れることと何かをしたことの間に因果関係はあるのでしょうか」 同僚「全てムカつくわ」 2014-09-10 15:18:35 よんてんごP @yontengoP 「使い続けていたら壊れました」 同僚「まだ納得がいく」 「何も知らずに使い続けていたら壊れました」 同僚「説明書読んで、どうぞ」 「何かを知ろうとした結果、壊れました」 同僚「何だろう、宗教感ある」 「そもそも壊れるとは何でしょうか」 同僚「壊れてるのはお前の発言だよ」 2014-09-10 15:22:24
壊れてから直そうとする人達へ
壊れてから直そうとしないで下さい。 もう直りませんから。 普段からメンテナンスすることが大事なんです。 恋人と破局寸前までいってから、謝っても遅いです。 反省しても遅いです。 泣きついても意味がありません。 部下が鬱になってから、不満を聞いても遅いです。 改善案を出しても遅いです。 心配しても意味がありません。 日々良い関係を維持すること以上に大切なことはありません。 壊れたものは直らないんで。
インフラ老朽化に「最後の警告」 NHKニュース
橋やトンネルなどの老朽化による事故を防ぐため、専門家による国土交通省の審議会は、「最後の警告」という異例の強いことばを使った提言をまとめました。 国や自治体に、点検や対策を行った結果を公表することや、点検の質を確保するため技術者の資格制度を導入することなど、維持管理を確実に行う仕組みを作るよう求めています。 おととし１２月に発生した中央自動車道の笹子トンネルの事故などを受けて、専門家で作る国土交通省の審議会は、老朽化した橋やトンネルなどの維持管理を確実に行う仕組みを作るための提言をまとめ、太田国土交通大臣に手渡しました。 提言では、冒頭で「最後の警告」と異例の強いことばを使って、「今すぐ本格的なメンテナンスにかじを切らなければ、橋の崩落など、人命や社会システムに関わる致命的な事態を招くであろう」と指摘しました。 そのうえで、国と自治体に対して、点検や診断、それに対策を行った結果を公表するよ
ＷＥＢシステムの不具合修正などの無償保守期間の長さ - システム開発・導入 - 専門家プロファイル
IT化支援ラボ 濱田です。こんにちは。 軸さんの仰るとおり問題になる点は「?不具合対応」「?仕様との違い」 の２点ですね。 ?不具合の対応については、本来は瑕疵対応(無料保守)可能期間を 設定し、双方合意の上で開発契約を結ばなければなりませんがこの点は 如何でしょうか？(一般的に1年が多いですが、2百万円規模ですと 半年も有り得ます) 経緯や現場を見ない限り判断できないのですが、話しが行き詰って しまっているようでしたら、保守対象に優先順位をつけ相談しながら 要求する形が良いかと思います。 要求にメリハリをつけることで合意を頂ける可能性が高くなり ます。その際に優先度の低いものもリストには加えておいて下さい。 ?仕様の認識違いについてはグレーゾーンが多く必ず問題になる ところです。こちらも泥沼化しそうでしたら早めに優先順位を つけ相談する形を取ってみて下さい。 また保守金額についてですが、
基幹システムの改修費用交渉で問題発生？エンジニアのスキルによる費用変動は普通？ - OKWAVE
当社の基幹システムの改修費用交渉で問題が発生しました。開発会社からの見積もりが高額で驚いた私たちは、エンジニアのスキルによって費用が変わるのは普通なのか疑問を抱いています。改修費用の基準について契約書で確認すべきかもしれません。 基幹システムの改修費用交渉で問題発生！開発会社から高額な見積もりが届いた理由は、システムに熟知していたエンジニアが退職し、別のエンジニアが対応することになったためでした。今までと異なるスキルのエンジニアによる改修であり、そのため費用が上がることが分かりました。 基幹システムの改修費用交渉について疑問が生じました。開発会社側によれば、エンジニアのスキルによって費用が変動するのは普通のことだそうです。しかし、当社としては納得がいかないため、再見積もりを依頼しました。契約書には改修費用の基準が記載されているか確認したいと考えています。 恐れ入ります。 当社で利用している
シス蔵 | 情報システム担当者のＱ＆Ａコミュニティ
私の経験ですが、 業種や規模によりますが、総売上高に対して、おおよそ1～3%が総IT費用 というのが感覚値です。（利益ベースではなく） 年間売上120億円であれば、年間1.2億～3.6億がIT費用になります。 月額2000万円であれば、年間2.4億なので、妥当かもしれませんが、 IT費用は、基幹系システム以外のパソコン代、ネットワーク代、通信費などの経費とIT資産の減価償却費なども加味したものだと思いますので、そうなると、ちょっと高いと思われます。 ただし、基幹系システムを日々改修する費用（日々市場は変わりますので）も含まれているのであれば、妥当かもしれません。 保守は、「実際に改修をしてもらう」or「ただの問い合わせ管理」のいずれかで違うと思います。 なお、これも経験ですが、 カスタマイズをしないパッケージの「問い合わせ管理」としての保守で、 「開発費用の10～20%くらいが妥当」だと思
契約ってのは意外と交渉の余地がない - プログラマーの脳みそ
株式会社マジカジャパンの羽生章洋が書いてるブログ:元請けにこだわる理由 - livedoor Blog（ブログ） 「元請けにこだわる理由」の「いいがかり」についてひとこといっておくか - yvsu pron. yas あたりの話。 自分は地方の零細の下請け会社なわけなんだけど、自分の判断で契約を行える自由を持っている。かといって、契約内容については、実はそれほど自由には決められないものだ。 というのは、こっちの話ではなく、相手側の話なのだ。中規模以上の会社と契約しようとすると、おおむね定型の契約方式のいずれかを選択、変更可能なのは一部の数字だけ、ということが多い。 フリーエンジニアになってぶち当たる壁 IT関連と言うのは独立が非常にしやすい。設備投資などがほかの業種に比べ圧倒的に少ないから、自分の技術力を買ってくださいと個別交渉することさえ出来るなら即刻独立することができる。 フリーの身に
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
RHEL, CentOS 7 に移行しよう！ LT
長期間の酷使に耐えるテクノロジー関連製品は何？ | スラド IT