システム開発工程における詳細設計は、どんな作業をすればいいのか、どんなアウトプットを出せばいいのか疑問を持つことも多いと思う。 そこで今回は詳細設計のサンプルを紹介しつつ書き方も簡単に説明していく。 なお、詳細設計は内部...
新着記事 あなどれない「ネットワークの落とし穴」 登場から約10年、インターネットは企業のビジネスを進化させた。だが適用分野が広がる反面、セキュリティ対策が企業の命運を握るようになっている。この連載では、システムを設計・変更する際に、企業内ネットワーク管理者やSEが知っておくべきセキュリティ対策について検討する。 (2006/6/5) ネットワーク自体をセキュリティソリューションに 新人技術者は「資格」にいかに臨むべきか 本当に資格って役に立つの? 数あるIT系資格のどれを取得すればいいの? 技術者にとって、新人のころがもっとも「資格のための勉強」がしやすい時期だ。さて、資格をとれば一人前の技術者として認められるのだろうか。 (2006/5/31) コンビニでの買物指南 SEはとにかく激務だと聞きます。「3日間寝てない」なんてこともあるとか。これでは体も悲鳴を上げるというもの。せめて食
テーマが決まったあとは、書き始める前の準備と構成が大事 文章は、まず書き出しの第1行目の文から始まり、文が一つ一つ、つながって最初の段落が形成され、いくつかの段落を経て収束します。 エッセイだろうと小論文や解説文、はたまた広告コピーだろうと、文章は全体で作者の思想(感情)を表しており、書き出しで読者を惹きつけた後は、流れるように結びの言葉へと向かっていかなければなりません。 文章を書く作業の中で初心者が陥りやすいのは、文章を書き始めるまでに十分に時間をかけていないということです。言い換えれば、テーマを十分に吟味していない、必要にして十分な文章素材を用意していない、構想を練ったり文章構成を考えたりしない、ということです。 イメージがぱっと湧いてきたので、すぐに書き始める。そういう人が実に多いのです。文章の超達人ともなれば、「一行目が浮かんだらもう書き終わったも同然だ」と豪語することもできまし
誰でも犯しがちな《6つの悪文》をご存知ですか? ここを直すと、読みやすくて魅力的な文章になります ●小論文●レポート●企画書●提案書●就職作文●社内報 ●投稿●寄稿●ウェブ…etc ⇒文章力で損をしないために…
うまく書こうとすればするほど、わかりづらい文章になる? うまい文章が書きたいとは、誰もが思うもの…。では、「うまい文章」とはどんな文章でしょうか? エッセイなら「味のある文章」、小論文や広告コピーなら「説得力のある文章」ということになるのでしょか。 でも、どちらも大前提として「わかりやすい文章」であることが求められます。わかりやすい文章とは、読みやすい、つまり「1回読んだだけで、内容がしっかりと頭に入る文章」と置き換えてもよいでしょう。 文章を書き慣れていない初心者の場合は、皮肉なことに、うまく書こうとすればするほどわかりづらい文章になってしまいます。また、かなり書き慣れた方の文章でも、「ここを直せばわかりやすくなるのに…」と思われる箇所がたくさん見つかります。 一見、達者な文章のように見えても、わかりづらくては読者はよほどの義理がない限り読んではくれません。また、何とか読んでくれたとして
はじめに 時の経つのは早いもので、私がIT業界に身を置いて四半世紀になってしまいました。 その間、膨大な数の「設計書(仕様書)」を書いて来ましたが、未だに悩み・迷いは尽きません。 それでも、亀の甲より年の劫とも申しますので、私なりの経験則を「個人」と「チーム」の両観点でまとめてみました。 本稿のテーマは、「主に設計書を想定した、開発ドキュメントの書き方」です。 本稿で前提とする設計書は、ExcelやWordで書かれた、フォーマルな(≒納品物になりえる)設計文書、です。 したがって、自社サービス開発よりも受託開発、アジャイルよりもウォーターフォール、を前提として読んでいただいた方が、しっくりくると思われます。 <ご注意> 本稿の内容は執筆者独自の見解であり、所属企業における立場、戦略、意見を代表するものではありません。 個人的に心がけていること 当該文書の作成目的や位置付けを冒頭に記載する
弊社では開発工程の上流である「要件定義、基本設計、詳細設計」において必要となるドキュメント標準が定義されております。本稿では「ドキュメント標準」の一部をご紹介しますので、是非ご参考にしてください。 各工程で必要なドキュメントを定義しましょう 下記のように工程ごとにドキュメント成果物、内容を定めております。 どの企業でも必要なドキュメント成果物になりますが、必要に応じて追加・削除頂ければと思います。 ※業務系のシステム開発に照準を当てております。 要求分析(要件定義) システム開発は要求分析(要件定義)というプロセスから始まります。要求分析(要件定義)は、顧客の要求を把握してシステム要件を確定することです。主に以下のような事項をまとめます。 要求概要 システムの目的 現状の課題と改善案 基本要件と優先順位 到達目標 システムの実現手段 システム化の範囲 概略費用 効果(定性/定量) 体制図
この記事は「本番環境でやらかしちゃった人 Advent Calendar 2019」の1日目です。 https://qiita.com/advent-calendar/2019/yarakashi-production なかなか濃いラインナップが期待されますが、まずはさらっといきたいと思います。 具体性が乏しい部分もあると思いますが、そこはお察しください。。。 やらかし 背景(前提条件) いっていに昔の話です ETL(データ加工)サーバ 数十を超えるシステムからデータを集める BIツールなどで活用できるように各種加工処理を行い、DBなどにロードする 繁忙の違いはあれど、24/365で常時一定量の処理は稼働している 複数のチームが共存しているサーバ アプリ面では比較的疎 ETL処理のリリース前に本番サーバ上で試験をする取り決めになっていた 性能や本番相当データのテストが安全に行えるような環境
社内のファイルサーバーの全てのデータを消し飛ばしてしまうという、人生史上最大のミスを犯してしまいました。二度とこのような失敗をすることがないよう強く反省し、記録を書き残すことにします。 きっかけ 環境 やっちゃったこと どのように乗り切ったのか そのとき何を考えていたか 惨劇はなぜおこってしまったのか 二度と惨劇を起こさないためにどうしたらよいか やっててよかったこと 補足 終わりに きっかけ まず、なぜこのような物をここに書いているのかと言えば、社内にはここまで精密な記録を残す予定が無いからである。 社内には、私の書いた技術的な記録を読める人は居らず、今度も採用されることはないだろう。 そして業務時間中に、このような丁寧な記録を残している時間など存在しない。 IT素人でも分かるような報告書をサラっと書いて、これでもかと言うくらいデフォルメした説明をして終わりである。 まあ実害がなければだ
黒顔羊のデジタルフォトギャラリー#1です。光蜥蜴(ヒカリトカゲ=光と影)や錆びたもの・滅びゆくものが大好きです。 自分の魂の目に感光したものは何でも撮ります。 by blackfacesheep ここのところ愛用しているキーボード、IBMのKB-8920です。 IBMのキーボードと言えば、シュアな打鍵フィーリングのメカニカル・キーボードが有名ですが、これはごく普通のメンブレン・キーボードです。 それでも名品といわれたIBM5576系キーボードの末裔ですから、しっかりと鉄板で補強された重量級ですし、キーの強度もたっぷりあってタイピングをしたときにもブレは少なく、きょうびのやわなキーボードとは一線を画する打鍵フィーリングです。 某巨大オークションで手に入れましたが、落札価格は500円と新品のキーボードを買うよりはるかに安く、運賃のほうが高いぐらいでした。^^; キーボードの打鍵フィーリングにこ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く