技術系メーリングリストで質問するときのパターン・ランゲージ
目次 はじめに メーリングリスト —— サポートセンターではなく互助会です 表題 —— あいさつではなく用件を書きましょう 自己紹介 —— 自分の知識・技能・経験を簡潔に書きましょう 書き出し —— 最初に問題の要旨を書きましょう 肩書き —— 会社の名前を背負っていることを忘れないように 実行手順 —— 手順は箇条書きで書きましょう 結果の予想 —— 期待した結果を書きましょう 実際の結果 —— 実際に起きたことを書きましょう ステップ明記 —— どこからうまく行かなくなったかを書きましょう 実際の値 —— 条件を具体的に書きましょう エラーメッセージ —— 必ずコピー＆ペーストしましょう 判断理由 —— そのように考えた理由を書きましょう 文献の引用 —— 読者の手間を省くように書きましょう ソース —— 関連する部分を抽出して示しましょう スレッド —— 関連する話題なら「返信」しま
「SIをダメにする負のスパイラル」
きしだൠ(K1S) @kis SIの、元請はユーザー企業の業務をよりよくするために、プロダクトを作るんじゃなくて契約書をつくる。で、元請はそれを下請けにつくらせるんだけど、そのときはユーザー企業の業務をよりよくするためではなく契約を満たすためにプロダクトを作らせる。これが負のスパイラルの発端。 2013-11-15 08:17:14 きしだൠ(K1S) @kis 契約を満たすことが目的でプロダクトを作ってるから、実装段階で気づいたアイデアや欠陥は報告されない。納期や金額なんかの契約は満たさないといけないのに追加仕様や変更が発生してやぶへびだもん。品質は悪くなる。 2013-11-15 08:23:58 きしだൠ(K1S) @kis 品質が悪くなってとられる対策は、技術向上ではなく契約の厳密化。設計書を「きっちり」つくるとか、テストのエビデンス(画面キャプチャのかっこいい言い方)をとるとか、
スルガ銀行とIBM訴訟判決から学べること | IT Leaders
かつてのようにITベンダが赤字覚悟で開発を請け負い、保守で赤字を取り返すという商習慣はなくなり、プロジェクト単体で採算性を求めるようになった。そうである以上、発注者側も受注者側も厳格な要求定義や工程管理、品質管理等のプロジェクト管理が求められるようになっている。決して目立たないが、ITに関わる訴訟は増え続けている。その原因はどこにあるのか、防止のためには何を行うべきか、また実際にトラブルになりそうな場合、なった場合には何をすればいいのか。シリーズ企画として、その対策を検討していく。第1回は、スルガ銀行と日本IBMの訴訟判決を取り上げる。 昨年、スルガ銀行とIBM訴訟判決（東京地判平24･3･29金法1952号111頁）がIT業界で話題になった。判決は日本IBMがスルガ銀行に対して74億円あまりの支払義務があることを認める、ほぼスルガ銀行の要求通りの内容。しかし、これは金銭面の話で、システム
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
一斉休校で児童と先生をICTが結んだ、学びのライフライン――千葉大学教育学部附属小学校の臨時休校対策緊急レポート
「システム構築に潜むヒヤリハット事例」なる教育ビデオ