機能要件の合意形成ガイド
機能要件の合意形成技法WG の成果として、「発注者ビューガイドライン」 （2008年7月に公開）を改訂し「機能要件の合意形成ガイド」を公開します。 開発者が設計書を記述することのみではなく、発注者と開発者がシステム像をいかに共有し、行き違いなく合意形成を行うかに注目して、有効と思われる事柄を「コツ」としてまとめました。 「発注者ビューガイドライン」では画面、システム振舞い、データモデルの3つの技術領域、187のコツを掲載していましたが、「機能要件の合意形成ガイド」では、外部インタフェース、バッチ、帳票の3つの技術領域を追加するとともに、発注者視点のコツも充実させ、278のコツを掲載しました。 なお、初めて利用される方は、概要編を読んでいただくことをおすすめします。
派生開発を成功させるプロセス改善の技術と極意 - プログラマの思索
清水吉男さんの「「派生開発」を成功させるプロセス改善の技術と極意」を読んだ。 気付いたことをメモ。 【1】是正保守と改良保守の違い ソフトウェア保守 - Wikipediaの定義がJISに公開されている。 是正保守は普通の障害修正に近い。 改良保守は、既存の製品に新機能を追加していくこと。例えば、ケータイにカメラやワンセグ、お財布携帯を追加していくこと。 後者はどう考えても保守ではない。清水さんはこの保守を意識して区別している。 おそらく世の中のSW開発の殆どは派生開発である、という指摘は、組み込み製品だけではなく、大規模な業務システムほど同様だ。 だから、継ぎ接ぎだらけで、たくさんの人のパッチが入った複雑なシステムになりがち。 リファクタリングそのものも危険になるから保守性も下がるし、品質も下がる。 そしてこれら保守の特徴は、開発期間が短く見積もり工数が小さいことだ。 2週間とか1ヶ月で
日経SYSTEMS「設計ミスをなくそう」特集でのインタビューで思ったこと：森崎修司の「どうやってはかるの？」：オルタナティブ・ブログ
日経SYSTEMS 3月号「設計ミスをなくそう」特集でインタビューいただいた。事前に大まかな話題をいただき、「俯瞰的な話」として回答差し上げた。ソフトウェアレビューを研究テーマの1つとして進めているので当然なのだが、普段細かい話や計測結果等を相当に近視眼的にみているので、視点を変えて考えるよい機会をいただけたと思う。 詳細は日経SYSTEMSをご覧いただきたいが、事前の話題をいただいた時点で考えたことは以下のとおり。 ここ10年くらいの文献の変化をみると「網羅的にとにかく全てのエラーを発見する」という考えから規模の増大に伴って「どこ（あるいは何）に注力してエラーを発見するか」という考え方に変わりつつある。（そのようなレビューが適しているソフトウェア、プロジェクトの割合が増えてきていることを反映したものだと思う。これにあてはまらないものもあるだろう） レビューの形骸化の主要な原因には、作業量
サブシステムを「使い捨てる」ためのアーキテクチャ - 設計者の発言
友人から、最近の「薬品卸売業界」の話を聞いた。知られているように、規制緩和によって一部の薬がコンビニや電器量販店でも扱えるようになった。そうすると薬品卸売業としては、多様な販売先に対応したきめ細かい受注・出荷体制や棚割ノウハウの提供が求められるようになる。ところが、規制緩和したからといって国民がいきなり市販薬をより多く買うようになるわけではない。結果的に、新しいタイプの顧客からの売上が増えるいっぽうで、その分だけ既顧客からの売上は減る。 その業界で生き延びてきた企業の多くは、販売管理システムを手作りすることでサービスレベルの向上をはかってきた。この経営方針は「サービスレベルを向上させつつ物流コストを抑えるためには、システムを手作りしたほうがまだトータルのコストを抑えられる」という経済合理性にもとづいている。しかし、この方針は売上高が右肩上がりで増大することを前提としている。より多様な顧客へ
妥当性検査をＤＢ側に集約する - 設計者の発言
テーブルフィールドの妥当性検査をどこに配置するかは、ＤＢシステムの開発において重要な問題である。大別してプログラム側に置く流儀とＤＢ側に置く流儀とがあるが、基本的に後者が正しい。 なぜなら、どのプログラムで実行されるかに関わらず同じ検査がなされるとしたら、その仕様はフィールド固有の属性とみなされるからだ。たとえそのフィールドに対する妥当性検査を実行するプログラムが１個しかないとしても、そのように考えるべきである。フィールド固有の属性については、テーブル側の定義情報を読めばひととおりわかるようでなければいけない。以前にも書いたように「カエサルのものはカエサルへ、ＤＢのものはＤＢへ」の原則で、フィールドの扱われ方に関する仕様はテーブル上に集約したほうがよい。 では次のような妥当性検査があったらどうだろう。「テーブルＡ上の関連レコードのフィールドＢの値がナントカの場合、テーブルＣ上のフィールドＤ
Yahoo!ショッピングにおけるログ設計と監視
ヤフー株式会社は、2023年10月1日にLINEヤフー株式会社になりました。LINEヤフー株式会社の新しいブログはこちらです。LINEヤフー Tech Blog こんにちは、ショッピング事業部開発部の吉野と申します。 今回は「アプリケーションログの設計と監視」について、実際にYahoo!ショッピングで採用している方法を少し交えながらお話しさせていただきます。 1.ログ設計のポイント ログ設計は、以下のポイントに注意して行うとよいでしょう。 ・ログ出力のポイントが押さえられているか ⇒セッションの始まりと終わり、処理の過程、例外処理の中など。 フローチャートのような処理フロー図があれば、そこにログ出力ポイントを書き込むとわかりやすくなります。 ・出力する情報に過不足はないか ⇒「いつ(システム時間)」「だれが(プロセスID・IPアドレスなど)」 「どこで(パスなど)」「なにをした(実行コマン
例外処理とロギングのベストプラクティス
はじめに システム開発において例外処理は重要なポイントですが、あまりに軽視されているのが現状ではないでしょうか。本稿では、これまでの著者の開発経験の中から培った汎用的な手法を説明します。 この記事は「美しい設計」ではなく「現実的な設計」、現場に適用できる「できるだけ手間の少なく、汎用的な設計」を目指しています。 対象読者 J2EE開発者・アーキテクト。特に業務システムの開発現場の方が対象です。 必要な環境 概念の説明が中心ですので、開発環境は必要ありません。 エラーの分類 実装時に考慮すべきエラーは2つに大別できます。 想定内でトランザクションの実行開始前にチェックするエラー。主に入力エラー。 異常な状態としてトランザクションの続行が不可能なエラー（例外）。 前者については、例外を使うべきではありません。入力チェックエラーを表現するには、ステータスコードを使うべきです。理由は次のとおりです
うさぎとSEのブログ: ログに対する認識の甘さ
ソフトウェアを開発する方ならば、多くの方はログをプログラムから出力しているかと思います。 ログは例えばリリースした後に客先で動作しないなどの何らかの不具合が発生した際に、原因等を探るとても重要な情報源です。そのため、ログを適切に出力、保存されなければ、そのログはただ要領が大きいだけのゴミにしかなりません。 ただ、ログを出力するということは、 1. 何を出力するべきなのか？ 2. いつ、だれが、何に利用するのか？ 3. いつ出力するのか？ 4. 何を出力してはいけないのか？ 等を考えながら出力している方は少ないように思います。 ログを出力するときに、ログに対してもみなさんは設計書を作成していますか？ ばかばかしい、ログなんてメインの業務処理から考えればオプションのような位置づけだと思うかもしれません。 ですが、ログ出力を正しく行わないと、私の周りでは、今までこういった問題が発生してきました。
【実録ドキュメント】そのログ本当に必要ですか？
今回の概要 数人で利用しているときは、レスポンスが軽快だったシステムで、ユーザー数が増えてくると急激にレスポンスタイムが悪化する現象が発生した。現場から学ぶWebアプリ開発のトラブルハック 第2回で扱ったFull GCなどいくつか原因が考えられるが、本稿ではログ出力にまつわるトラブルをドキュメンタリー形式で紹介し、まとめとしてログ出力のパフォーマンスに関するTipsを紹介する。 今日もまた、突然電話が鳴り響く ある穏やかな朝、突然電話が鳴る。相手は結合テストの工程からパフォーマンステストで支援に入る予定のプロジェクトの担当者である。用件は「結合テストを20人のテスターで実施しようとしているが、レスポンスタイムが1分を超えていて、テストがままならない。早急になんとかしてほしい」 これだけの情報では、トラブルをハックすることはできないので、Webアプリの問題点を「見える化」する7つ道具をノート
::memolet | development/Documents
ノート RFPなんて書く機会ないだろうけど、RFPから提案書に何を書くかを掴む。 提案書評価のチェックポイントを知る - 上流工程-RFP/提案：ITpro これなんかは、提案書の目次書いてある。 提案の骨子、提案の内容、成果・効果の指標...、スケジュール、スケジュール、価格、体制、役割分担、定例報告および会議の内容、成果物の仕様、窓口 uyabin's workbench: 思いつきとやっつけ: RFPの作成と評価(実績版メモ) 評価方法から提案を書くポイントを掴むのだ。 第１章RFPとは（その３）：スーパーエンジニアへの道：So-net blog 提案書評価のチェックポイントを知る - 上流工程-RFP/提案：ITpro 提案の骨子、提案の内容、成果・効果の評価方法と指標、スケジュール、価格、体制、役割分担、定例報告および会議の内容、成果物の、窓口 提案書作成支援ツール 提案書の書き
データベースもアジャイル開発に対応したい！ （1/3） － ＠IT
Jiemamy作者が考える “データベースの進化的設計” データベースもアジャイル開発に対応したい！ アジャイルの考え方においては、実装前にシステム要件・設計を確定させることはせず、常に変化を受け入れていく体制が必要です。アジャイル開発の考え方にのっとるなら、アプリケーションだけではなくデータベースについても設計の凍結はせず、また、ソースコードに限らずデータベースの構成・設計についてもリファクタリングが適用されるべきです。Jiemamyはこの問題に取り組むプロジェクトとして始められました。本稿ではこのJiemamyの取り組みを紹介します。 ソースやスキーマだけ管理しても意味がない 近年注目を集めている「アジャイル開発」は、リファクタリングが重要な要素の1つであることはご存じのとおりです。アジャイルの考え方においては、実装前にシステム要件・設計を確定させることはせず、常に変化を受け入れていく
JPCERT Coordination Center - グッド・プラクティス・ガイド プロセス・制御と SCADA セキュリティ
こちらはご意見・ご感想用のフォームです。各社製品については、各社へお問い合わせください。 ※本フォームにいただいたコメントへの返信はできません。 返信をご希望の方は「お問合せ」 をご利用ください。
ITエンジニアにも必要な国語力（1）
図解の本質はここにあった ITエンジニアにも必要な国語力 第1回 名前にとことんこだわるべし 開米瑞浩（アイデアクラフト） 2005/8/10 コミュニケーションスキルの土台となる図解言語。だが筆者によると、実はその裏に隠れた読解力、国語力こそがITエンジニアにとって重要なのだという。ITエンジニアに必須の国語力とはどのようなものだろうか。それを身に付けるにはどうしたらいいのか。毎回、ITエンジニアに身近な例を挙げて解説する。 「Can you speak English?」と聞かれてあたふたしてしまう日本人も、「あなたは日本語が話せますか？」と聞かれたら「いいえ」と答えることはないだろう。しかし、「日本語が話せる」といっても、日常会話レベルの日本語力とエンジニアリングに必要な日本語力とでは次元が違う。ITエンジニアに必要な国語力をあらためて見直そう。 ■ITエンジニアにこそ国語の力が必要
ソシオメディア
ソシオメディアは各種ビジネス向けデジタルプロダクトのデザイン支援を行うデザインコンサルティング会社です。業界をリードする OOUI（オブジェクト指向ユーザーインターフェース）設計、独自ガイドラインをもとにしたエクスパートレビュー、クリエイティブ組織を構築するデザインマネジメント支援など、様々な角度から御社のデザイン戦略をサポートし、デジタルトランスフォーメーションを実現します。 もっと読む 多くの方からご要望をいただいておりました OOUI メソッドの解説書『オブジェクト指向UIデザイン ― 使いやすいソフトウェアの原理』が、2020年6月5日、技術評論社より遂に出版されました。 オブジェクト指向ユーザーインターフェース（OOUI）とは、オブジェクト（もの、名詞）を起点としてUIを設計すること。タスク（やること、動詞）を起点としたUIに比べて劇的に使いやすくなり、開発効率も向上します。 ブ
DESIGN IT!
News（一覧） 2010年10月 1日 10/13（水）に東京・麹町でトークセッションイベント「DESIGN IT! Talk 」を開催します。テーマは「UXとは何か ～プロジェクトを通して考えるユーザーエクスペリエンス（UX）」。講演者は株式会社エクサ 安藤氏、産業技術総合研究所 江渡氏。参加申し込み受付中です。 2009年11月17日 DESIGN IT! Conference 2009 いよいよ明日開催、当日受付あり。「皆さんと一緒に考えることができるような、チャレンジングな内容を準備中。日本の方々との刺激的な議論を期待しています」（昨夜来日した海外スピーカー、Donal Mountain氏とBraden Kowitz のコメントより） 2009年10月16日 「DESIGN IT! magazine」vol.3 発売記念イベントを10月19日（月）19時から青山ブックセンター（六
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
http://homepage.mac.com/minahito/japanese/index_files/2d89715a772e44a5ed4310503b7f0921-120.html
http://www.jiemamy.org/
IBM Developer
VerifyDesign Ant Task
http://japan.internet.com/column/developer/20070502/27.html