「簡単ですよね？」を「挑発」とは受け取らないようにしてます - @katzchang.contexts
SIに限らず、「技術的な客商売」をやっていると、時として打合せの時に「簡単ですよね」という「挑発」を受けることがある。 「簡単ですよね」という挑発 | おごちゃんの雑文 あるあるw 自分が仕事してる中でよく言われるのが「できますよね？」っていう言葉で、それに対して安易に『できます』と答えるな！っていうのはSE稼業の基本中の基本中の基本。新入社員研修で、名刺交換のお作法の次くらいに叩き込まれるはずです。いわゆる「持ち帰り検討します！」。コレばっかりじゃ、打ち合わせなんて一つも進まないんだけどねー。 で、個人的に便利でよく使ってるのが、「技術的にはできます」。技術的には問題ない。論理的には可能です。でも実装やらなんやらは必要です。時間はかかります。工数はかかります。さて、どうします？どこまでやります？…などと、メニューを提示するわけです。 ただし、これは自分で本当に実現可能だと思わないと使っち
受託案件と企画案件の違いを感じる - GeekFactory
受託開発の最たる問題は受け身であること。例えば、試験項目書は必ずWordで書かなきゃいけないとか、証跡はPowerPointにまとめて表紙を付けなきゃいけないとか、誰が決めたか不明なルールがたくさんあると思います。ルールがガチガチに決まった開発現場にずっといると、非効率なルールが当たり前に染みついてしまい、思考停止に陥る危険性があります。 お客様が作れといったから作りました。 という思考停止は危ない。 企画案件は自分らが意志決定していく必要があります。自分らが投資をするので、どこまで設計書を作るとか、リファクタリングをするかといったことも経営判断の1つになります。文字色を少し変えるだけで売上が変わる可能性もあるのです。 日本のSI業界が受け身の姿勢に染まっているのは問題ではないでしょうか。
株式会社マジカジャパンの羽生章洋が書いてるブログ:key-valueはデータディクショナリの夢を見るか - livedoor Blog（ブログ）
今日はCouchDBの話というよりも、key-valueという形に基づいてのデータ構造設計を考えてみたときの与太話です。 DOA自体の説明はここでは端折ります（ERDレッスンをお読みくださいm(__)m）が、その考え方の中で非常に重要でありながらも実現に際して途轍もなく困難なものがあります。それがデータディクショナリです。 データディクショナリ（以下DD）とは、乱暴に要約するとシステム内で登場する全てのデータ項目に対して意味合い・意図をしっかりと定義して辞書のように統合し、利用者の間でぶれのない状態にしましょうというものです。そしてDDの作成においては、エリアス・ホモニム・シノニムの除去が重要になります。ホモニム・シノニムについてはhttp://www.atmarkit.co.jp/fbiz/cinvest/opinion/qa/qa13_2.htmlをご覧ください。ちなみにエリアスは別名
第11回 多忙と徹夜を「喜ぶ」 最悪の“システム屋”
経営者にとって、情報システムは頭痛の種になりがちだ。業務に必須だが投資に見合った効果が出るとは限らない。ほかの設備投資に比べて専門的で難解でもある。 野村総合研究所で約20年間勤務した後に、人材派遣大手スタッフサービスのCIO（最高情報責任者）を務め急成長を支えた著者が、ベンダーとユーザー両方の視点から、“システム屋”の思考回路と、上手な付き合い方を説く。 前回（第10回）では、「それは『IT（情報技術）以前』の問題ですから、ITでは解決できません」と、やたらと課題の整理を要求する“システム屋”が多いことを説明しました。 こうした“システム屋”は主に、2つのタイプに分類されます。「ガミガミ屋」と「マゾヒスト」です。こうした“システム屋”たちがユーザー企業の情報システム部門にいる場合、元々ある課題がより複雑化してしまいます。 ユーザー企業の情報システム部門にいる「ガミガミ屋」は、課題の検討が
言い訳はうまい - masayang's diary
忙しかった頃 「Agileしましょうよ〜」 「忙しくて人を出せない」 暇になってきた今 「Agileしましょうよ〜」 「予算がないので手を出せない」
そろそろ携帯電話のデザインについて言っておこうか - （旧姓）タケルンバ卿日記避難所
不満点はただひとつ。これ以外はどうでもいいんだ。これだけは許せないんだ。 3の上に電源ボタンを置くのはやめろおおおおおおっっ！！！ 女子高生なみの両手光速タイピングを旨とするワタクシ、タケルンバにとって、この配列はメチャメチャ困るんだよ。 この配列は困るんだ。 3を押して「さしすせそ」を変換してるつもりで、電源ボタンを連打することがよくあるんだよ。 問答無用で「YES」。待ち受け画面、こんにちは。つくった文章、さようなら。 これを数字ボタンから遠いところに置いてくれないかねえ。それだけでかなりリスクが減るんだが。みんなやっちまったこと、あるっしょ。 おねげーしますだ、メーカー様。 追記（2009/01/29 16:45） 奇跡のタイミングでネタがかぶった。 携帯電話の機種選択で絶対にゆずれないただ1つのポイント 負けまいとする心でしょう！ 同じこと考えてたのか。
女性に「何度も同じことを言わせるな」と怒ってはいけない - ひがやすを技術ブログ
女性に「何度も同じことを言わせるなよ」と怒った経験のある男性は、きっと多いよね。俺もそうだし。でも、そんなことで怒っても、余り意味がない。女性はそういうもんだとあきらめて、何度も同じことを言ってあげたほうが、腹が立たない分、実は得なのです。 例えば、うちのかみさんが、ダイエットのためにコアリズムをはじめたとします。コアリズムって何?ってかたは、こちらを見てください。 http://www.exabody.jp/disp/CSfLastGenGoodsPage_001.jsp?GOODS_NO=69590&af_id=17&banner_id=kaiadw クワバタくびれ大作戦でやっていたあれです。 かみさん:ウェスト2cm細くなった!!! 俺:おめでとう ほめることは、何度繰り返しても違和感はないよね。 かみさん:体重が変わらない(あるいはちょっと増えた)。 俺:ある程度の筋肉もつくだろう
となりの技術者をイラッとさせる10の方法 - ぼくはまちちゃん！(Hatena)
人の画面をじっと見る あるいは人の後ろにずっと立つ。 人の画面を指で触る せめて爪側、できればペン等で…！ 作業中に話しかけて、そのまま長話 質問や要点をまとめておいてから→いまいい？って確認するとか。 急ぎでなければ、たとえ隣の席でもメールかメッセンジャー的なもので…！ 自分じゃなくても答えられる質問 その技術者が「誰でも知ってて当然だろ」と思っているようなことを質問しちゃうのはだめ。 逆に技術者が「これは俺の得意分野」って思っていることを質問すると機嫌が良くなる場合も。 知ったかぶりによる言語批判 「****(言語)って汚い or 気持ち悪い」 これを言うのはほとんどその言語をちゃんと使ったことない人ばかりでは…！ バグの犯人捜し・犯人叩き 開き直っちゃうけどバグが出るのは仕方がないよ…！ 日経新聞から得たような(あるいは広告業界特有の)IT(?)用語 「WEB2.0のインフルエンサー
SEとPG、どっちが頭がいい？（2）：下流から見たIT業界：エンジニアライフ
刺戟的な題名で続けます。 前回は日本独特のSE／PGの分業体制がどのようにして発生したのか、ということを説明しました。それは日本にソフトウェア開発が産業として根付いたときに、PGが単純作業労働者と位置付けられてしまったため、上級技術者を区別する言葉が必要とされた、それがSE（システムエンジニア）だというものでした。 ●C言語＠UNIXでは COBOLの開発ではSE作業とPG作業がきちんと分けられていると思われがちですが、これも前回述べたとおり実際には形式だけのものになっていました。これはタイムシェアリング端末の普及によってプログラミング作業が格段に効率化されたからでした。プログラミングに残っていた煩雑な手作業の部分が省力化されたのです。 この事情はBasicやC言語でも同じことです。1980年代後半、わたしは最初の会社を辞め、パソコンの開発をするようになりました。現場では、技術者はそれぞれ
オタクなスイーツになりたい。
私は半端である。確かにアニメや漫画は面白いと思うが、自分の興味があるものにしか興味がない。声優はすげーと思うが自分の好きな声優くらいしか覚えられず、そしてそれさえも聞いて当てることはできない。パソコン知識はHTML程度である。 スラムダンクは読んだことはあるが、りょーなんの誰誰、といわれても覚えていない。 でもネタとして「バスケがしたいです…」がみっちゃんってくらいなら解る。 一般人として皮を被るにはオタク側に足を突っ込んでしまっている。 しかし全てにおいて半端なため、オタクの友人たちの話にはついてゆけず、ガンダムの種類の話をされても全く解らないし、声優は自分の好きな人しか判らない。 そして、一般人の友人達の話にもついてゆけない。 ＤＭＣ見た。でももう女優の顔思い出せない。バナナマン。面白かったような。でもネタは思い出せない。エルレガーデン。…聞いたことはある。そんな感じ。 確かにオタクな
なんでデスマーチが発生しちゃうのか…伝言ゲームの恐怖 : らばQ
なんでデスマーチが発生しちゃうのか…伝言ゲームの恐怖 「伝言ゲーム」、誰でも一度はしたことありますよね。 やってみると、人の記憶のあいまいさ、コミュニケーションの難しさ、人がいかに話を聞いていないかなどの事実を学ぶことができます。会社勤めをしていると毎日のように伝言ゲームのような場面に出くわすものです。 そしてIT業界には「デスマーチ」という恐怖の言葉があります。 とても間に合わない期日、人員不足、無茶なクライアントの要求などにより、過酷労働のもと開発者たちが死の行進をする状況を言います。 なぜデスマーチが発生してしまうのか…。仕事が現場から上に伝えられていく伝言ゲームのような過程をご紹介します。 〜全国で苦しむプログラマーのみなさんに捧ぐ〜 1. プログラマーからシステム・エンジニアへ 「このプロジェクトは無理です。大きなデザイン変更を強いられる上、うちのチームにはこのシステムのデザイン
Doblog - Joe's Labo - “ホウレンソウ”は第二の“カロウシ”になるか
■ 『クロワッサン』10月号 映画『トウキョウソナタ』レビュー寄稿(14) →永遠の30歳 [10/05 01:29] →とおりすがり [10/04 14:36] →みに [10/03 19:30] ■ 格差問題の本質とは何か(10) →とおりすがり２号 [10/04 21:54] →M.T.かーにー [09/28 16:56] →yasu [09/27 19:55] ■ シンポジウム「考えよう、若者の雇用と未来」(2) →とおりすがり [10/04 14:38] →みに [10/03 19:36] ■ 貰いすぎの人がいない会社(6) →y [09/28 19:37] ■ “ホウレンソウ”は第二の“カロウシ”になるか(28) →野田一丁目。 [09/27 08:31] →通りすがり氷河期 [09/25 12:31] →NEET☆ [09/25 09:43]
見積もりには「初乗り料金」が必要なんです。:しっぽのブログ
見積もりが高いといわれたら。Noという交渉術 | Web担当者Forum ここで紹介されていた以下の事例は、案件見積もりの全てを工数計算で行っていると発生するトラブルです 今度もタダでの変更依頼です。そこで当初の契約にない旨を伝えると「じゃあ見積もりを出せ」と命じられました。 （中略） ファクシミリで見積もりを送ると折り返し電話があり「高すぎる」と語気を荒げます。 まあこんな喧嘩腰は流石に無いのですが、話自体は結構身の回りにもあります。 うっかりすると営業さんが「はい、ちょこっとなんで無料でやっちゃいます」と、引き受けてきてしまいます。 １度なら良いのですが、それがかさんで思わぬ赤字が出ることも稀ではありません。（というか、結構多い） 上記サイトの方は皮肉で返すそうですが、毎回皮肉を言うのも疲れるでしょうし、人間関係にも良くありません。 それに、あなたが製作者なら、まず社内の営業やディレク
浜口さんに贈るSI業界を良くする方法 - ひがやすを技術ブログ
浜口さんの言葉には、ブクマや突っ込みを生み出す何かがありますね。 したがってシステムの大規模化は、必然的に想像以上のコストアップと信頼性リスクの増大を招くものであるとの認識が必要になる。 きました。想像以上のコストアップだそうです。 そんな浜口さんに贈ります。今よりコストダウンさせて、SI業界を良くする方法。 例えば、誰が書いても同じコードにするために、プログラム設計書(内部設計書)を今、書かせているとしたら、そんな無駄なものはやめたほうがいいと思う。 プログラム設計書は、自然言語で書きます。プログラムは、プログラミング言語で書きます。どっちの言語が、プログラムを書くのに適しているかといえば、誰が考えても、プログラミング言語ですよね。 いきなりプログラミングはできない人もいるから、プログラム設計書が必要だという人もいるかもしれませんが、それは、間違っていると断言しましょう。 いきなりプログ
ウォーターフォール式「アジャイルのやりかた」 (プログラミング C# - 翔ソフトウェア (Sho's))
ウォーターフォール式にアジャイルを導入する手順。 社内で「うちでもそろそろアジャイル開発を導入しませんか」と根回しをします。 「アジャイル開発プロセスに関する調査を行うための準備委員会」の提案書を作成し、上に提出します。 提案書が、課長→部長→本部長と段階的に上にあがっていき、承認されて段階的に戻ってくるのを待ちます。 「アジャイル開発プロセスに関する調査を行うための準備委員会」の責任者となって、委員会を設立します。 会議を繰り返し、その結果を元に「アジャイル開発プロセスに関する調査書」案を作成し、委員会を召集してレビューします。 反対意見をまとめあげて、「アジャイル開発プロセスに関する調査書」を完成させます。 もう何もかもがいやになり、全てを窓から投げ捨てます。
SI業界を目指す君達へ贈る「何故システム開発はテンパるのか」 - novtan別館
先日学生に聞かれたんですよ。 「下流工程は大変って聞きますが、上流は楽なんですよね？」 よろしい、君はよく勉強している。でも根本的に間違っている。下流工程が辛いのは、上流工程でちゃんと仕事ができなかったからだ*1。 というわけで、主に学生向きに話を単純化して語ってみます。これが普通だとか、一般的だとか言うつもりはなく、違う視点もあるかと思いますが、一つの考え方として。 SIでのシステム開発は、建設業にたとえられます。が。 顧客の希望を聞き、設計し、施工し、引き渡す。こういった工程を踏む仕事ということで、システム開発はよく建設業にたとえられます。実際に工程管理の手法なども似通っています。ところが、大抵の場合、耐震偽造をした建築物よりもシステムのほうが脆弱に仕上がります。何故でしょうか。 一つには、建物の図面を引くには建築士の資格が必要ですが、システムの設計に資格は必要ありません。 もう一つ、
自分にとって当たり前になっていることを説明するのはむずかしい - essence-s
相手との「あたりまえ」の差がどこにあるのかを測るのがとても難しい。 なぜなら、自分にとっての当たり前が相手にとっても当たり前のことのはずだと見てしまうからだ。 相手との当たり前の差が見えたときに自分にとっての当たり前がなんなのかが見えることがある。
机の上に紙とペンを広げられるかで勝負が決まる - ひげぽん OSとか作っちゃうかMona-
そういえば昨日の飲み会で誰かが言っていて同意したのがプログラマの机の話。 机の上に紙とペンをどれだけ広げられるかで勝負が決まる。 せまい机に押し込まれて隣の人と触れ合うほど、近かったりするともうだめ。 デュアルディスプレイで得られる効率はコーディングの効率なのだけど、机に広げたノートで得られるのは考えをまとめる効率。 脳の中に展開できない何かをノートに展開ですよ。 紙とペンとか言うと、うげー古いぜとか思うかもしれないですが僕より若い優秀なエンジニアは良く紙に何か描いているなあ。（上の世代は言うまでもない）。 今使っているノートとペンを教えてくれたのは僕よりずっと若い id:kambara氏 だし。
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
http://twitter.com/takesako/statuses/800365932
顧客から要求を迫られた時に知っておくべき対応の掟
