「コミット/プッシュに上司の承認印が必要なんです」 - @katzchang.contextsなら上司がやれよ。
「簡単ですよね？」を「挑発」とは受け取らないようにしてます - @katzchang.contexts
SIに限らず、「技術的な客商売」をやっていると、時として打合せの時に「簡単ですよね」という「挑発」を受けることがある。 「簡単ですよね」という挑発 | おごちゃんの雑文 あるあるw 自分が仕事してる中でよく言われるのが「できますよね？」っていう言葉で、それに対して安易に『できます』と答えるな！っていうのはSE稼業の基本中の基本中の基本。新入社員研修で、名刺交換のお作法の次くらいに叩き込まれるはずです。いわゆる「持ち帰り検討します！」。コレばっかりじゃ、打ち合わせなんて一つも進まないんだけどねー。 で、個人的に便利でよく使ってるのが、「技術的にはできます」。技術的には問題ない。論理的には可能です。でも実装やらなんやらは必要です。時間はかかります。工数はかかります。さて、どうします？どこまでやります？…などと、メニューを提示するわけです。 ただし、これは自分で本当に実現可能だと思わないと使っち
下限に合わせたプログラム設計はシステム開発を停滞させる - @katzchang.contexts
FxUG@北陸の懇親会で出た話題。 中規模以上のプロジェクトになれば、悲しいかな、テンプレにそったプログラムしか書けない人や、そもそもプログラムを書いたことすらない人が結構いたりします。10人もかき集めれば2〜3人、いや半分はそういう人だったり。リーダーさんは仕様検討とかで忙しいから、そういう初級者さんにプログラムの作成を頼らざるを得ないってのが現実です。 で、初心者さんにもわかりやすい設計のプログラムを量産していきましょう、となる現場はよくあります。なに、うちのところもそんなもんですよ。 でもそれで良いの？と、個人的には疑問を持っています。 初心者でも書けるように、テンプレートをコピーして使う。 コピペ駆動開発の副作用は周知の通り。 テンプレートが役立つのは限定的な場合。仕様が想定の範囲を超えればテンプレートを捨てなきゃならないけど、その判断を誰が下す？ 後々の保守しやすいよう、初心者で
本質的には福利厚生の範囲の問題であって - @katzchang.contexts
そこで解決策として用意されるのが「分煙」だ。喫煙者と非喫煙者を分断すれば（実は分断されるのは『喫煙者と嫌煙者』なのだが）、少なくとも嫌煙家が不快に感じる要素はなくなる。本質的にはエロ系コンテンツのゾーニングと同じ論理である。 http://d.hatena.ne.jp/y_arim/20090417/1239925575 エロ系コンテンツのゾーニングと同じ論理だと言い切れるならば、庁舎内に個室ビデオルームとティッシュを用意すべきという意見に反論できなくなっちゃいますよ。（これは、用意すべきではないという部分は合意できますよね？） ブクマにも書いたけど、要するに福利厚生をどの程度まで認めるべきかの話であって、一般の企業なら「経費としてどこまでお金を出せるか」の判断になるし、公共施設なら「法的/社会的にどこまで予算を使えるか」の判断になるわけで。 私企業はとりあえず勝手にすればいい。事務所の喫
プログラマが作ったスケジュールはいつも壊される - @katzchang.contexts
スケジュールを作るプログラマが一番効率が良い。 - レベルエンター山本大のブログより。内容については同意します…というか、ほんとうにその通りだと思うけど、現状そんなに上手くいかない理由について列挙してみる。 いつも急かされる。 2週間かかりそうなものを、マネージャから「1週間で仕上げてほしい」と言われる。2週間かかる根拠を求められ、FP等の数字を算出しても「1週間で仕上げてほしい」と繰り返される。 単純に説得に時間がかかる。場合によっては1週間以上使ったり！ 時間をかけて説得できたらまだマシ。メンバーが"ハイ"と言えば万事おｋ、と思ってるPMはたまにいる。 顧客もまた然り。 こんな調子で「1週間あれば大丈夫でしょ」と言われ続けると、その内「1週間あれば大丈夫かも」と何となくそう思ってしまうパターンはマジでよくある話。 「あの機能が1週間の見積もりなら、この機能も同程度だろう」で、ズレが拡大
みんな自分を卵だと思い込んで、衝突に備えて殻を厚くする - @katzchang.contexts
で、いつの間にか厚い壁が出来上がるわけだ。 「negative_dialektik はてな村出張所」を読んで、なんとなくそう思った。
もう、何度でも言ってやる！ - @katzchang.contexts
誰でも実装できるレベルまで落とした仕様書書く暇あったら、プログラム書けるっつーの！ 誰でも実装できるレベルまで書き込んだ仕様書書いてプログラムを外の人に任せるくらいなら、自分でやった方が早いっつーの！ 誰でも出来るなんて、一番おいしいところ持ってかれてるんじゃねーの。
公共系SIerにトップページを頼んでみた - T/O
仮見積もり 1ページ：320万円 工期：4ヶ月 内訳 要件定義：85万円 要件定義書（打ち合わせ3回程度を想定） 設計：80万円 画面設計書（画面レイアウト定義、画面項目仕様、画面遷移図）、DB設計書 製造・試験：80万円 プログラム、単体試験仕様および結果、結合試験仕様および結果 総合試験：40万円 総合試験仕様および結果 導入サポート：35万円 運用手順書、セットアップ手順書 備考 内部統制に対応しております。 システム構築 要件定義 ログイン制御が必要。 部署・役職に応じた権限ごとにメニュー表示を管理。 ログイン情報およびメニュー選択情報のログを管理。 設計（下請け） 部署・役職と利用者マスタの関係確認に工数の半分をかける。 メニュー終了時のログを要件から落とすよう交渉すべく、資料作成と打ち合わせに残りの半分をかける。 製造・試験（孫請け） 当初1画面のみと想定していたが、ログイン画
「バックアップすればよかった」という指摘に「だろバカ」は余計 - @katzchang.contexts
上から目線の人達は失敗を隠蔽する社会を作っている - 未来のいつか/hyoshiokの日記のコメント欄より。ブコメにも書いたけど、大切なことなので何回でも書きます。 id:otsune だからなんで「svn repoのバックアップをとって無くて破損した失敗」を「バカだなぁ。まともな技術者はやらないだろ」と正しく正確に評価することが「切り捨てる」になるのでしょうか？ それっと「正しい事をいわれると萎縮するから言うな」ってことですよね。どこの昭和の風習ですか 上から目線の人達は失敗を隠蔽する社会を作っている - 未来のいつか/hyoshiokの日記 「バックアップをとるべき」という指摘に「だろバカ」は余計という意味において、id:hyoshiokの主張は全く正しい。 指摘する側は指摘される側の感情を特別にケアしろとは言わないけど、他人を馬鹿呼ばわりしないように気を付けるのは、なにも「特別なケア
SI業界の未来 - @katzchang.contexts
「SI屋の経営陣が技術の空洞化に気づかない理由 - プログラマーの脳みそ」のブクマから、ネタを拝借。 id:xaucia909 ｢IT傭兵｣と戦力分析／TODO→俺「孫子・マキャベリは傭兵についてなにか言っていないか」 はてなブックマーク - SI屋の経営陣が技術の空洞化に気づかない理由 - Nagise’s blog おぉ、面白そう。ということで検索されたのが、下記。 常備のプロ化した軍隊は政策や皇帝の継承に関与し大きな災いを為したと書かれています．．． マキャベリがプロの軍隊を嫌ったのは 当時のイタリアの軍の主力だった傭兵隊のひどさからなのですが （中略） 当時の傭兵隊に中には．．． 最後は雇い主を追い払って領土を占拠してしまう者まで現れています．．． 常備のプロ化した軍隊は悪であるという考え方はヨーロッパに広く行き渡ったらしく 第二次大戦直前のフランスでドイツの機甲部隊に対抗してフラ
「『変数のスコープは狭いほど良い』という迷信」という迷信 - @katzchang.contexts
「変数のスコープは狭いほど良い」という迷信 変数でもメソッド名でもクラス名でも言えることだが、単純に「スコープは狭いほどよい」という方針でプログラムすると、逆に保守性も可読性も悪いプログラムができあがることがけっこうある。 中途半端に優秀なプログラマが「正しいプログラミングテクニック」だと妄信しがちな３つポイント - 分裂勘違い君劇場 by ふろむだ 変数とオブジェクトが持つ属性やメソッドを混同してません？ いわゆる「変数」のスコープが問題になるのは、一言では「依存性が複雑になるため」。 そのオブジェクトだったりメモリ領域だったりの内容は、その変数を使う時点でどのような状態を持つかっていうのは、その処理の前に実行されたどれかの処理結果に依存する。が、実際にその変数の内容を定義したり更新したりしたのはどの処理かは、もう闇の中。だから、グローバル領域の変数に対して、使う直前にわざわざ初期化して
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
マウスパッドに布を使う - @katzchang.contexts