タグ

システムに関するMikatsukiのブックマーク (35)

  • 綺麗なだけじゃ意味がない!ディレクターが見落としがちな仕様書作成の4ポイント : LINE Corporation ディレクターブログ

    こんにちは。ウェブサービス部の河野です。 ディレクターの業務の重要なものの一つに、仕様をまとめたりドキュメントを作る業務があります。限られた時間の中でシステムを開発しなければならない際に、どのようなドキュメントをどこまで作成するか悩むことも多いかと思います。 そこで今回はディレクターがドキュメントを作成する際の心がけやポイントについて考えてみたいと思います。 1.ドキュメントを作ることが目的とならないようにする 当たり前のことですが、一番重要なのは進めているシステム開発が納期通りに不具合なくリリースできることです。仕様をメンバーに理解してもらうことが第一で、その手段としてドキュメントがあるという優先度を間違えないようにしましょう。 きちんとしたドキュメントの作成には時間が掛かり、変更時の更新にも同じく時間がかかります。また、更新をせず情報が古いままの場合、開発メンバーがそれを最新バージョ

    綺麗なだけじゃ意味がない!ディレクターが見落としがちな仕様書作成の4ポイント : LINE Corporation ディレクターブログ
  • 信頼性計算で使う指標

    信頼度 不信頼度 故障率 MTBF(平均故障間隔) MTTR(平均修理時間) 修復率 保全度 アベイラビリティ(稼働率) 不稼働率 MTTF FIT MDT この文書の作成にあたって早川じゅん様のご協力を頂きました。 1.信頼度 単位時間内にシステムや機械が動いている確率のこと。とりあえず、問題文中に「0.9」とか「0.8」などのように0~1までの間の数字があったら、それは間違いなく信頼度です。 例 次のシステムの信頼度はいくつですか? 0.9×0.9=0.81 答え0.81 また故障率(件/時間)から信頼度を求める計算もあります(故障の発生件数がポアソン分布に従う(故障の発生が偶発的の)場合)。故障率と信頼度の間には次のような関係があります。 R=e-λt Rは信頼度、λは故障率、tは時間です。 このR=e-λtという式はどっから出てくるの?と疑問な場合は、信頼性計算のための数学のeとボ

    Mikatsuki
    Mikatsuki 2017/01/08
    指標のあれこれ。
  • 「システムエンジニアリングで SysML を使いこなす」第1章 概要編-システムエンジニアリングとしての SysML | オブジェクトの広場

    1.1. 身近なモデルベース開発 1997 年に UML が OMG により認定され 12 年、組込みソフトウェア開発の現場でも UML を活用したモデルベース開発が浸透してきました。 オブジェクト指向という考え方も一般的になってきた一方、モデルベース開発やオブジェクト指向を何やら高級なものに感じ、組込みソフトウェア開発の現場に適用することに否定的な意見もあるようです。 しかし、モデルベース開発やオブジェクト指向は当に小難しい技術なのでしょうか。 ものづくりの現場において、機械/電気/制御などソフトウェア以外の領域では、昔からあたりまえのようにオブジェクト指向でありモデルベース開発を行っているのではないでしょうか。 機械設計では、ドラフターで図面を手書きしていた昔から製図表記法には JIS B 0001 という標準があります。 図で表現される部品は意識せずとも「オブジェクト」と認識せざる

    「システムエンジニアリングで SysML を使いこなす」第1章 概要編-システムエンジニアリングとしての SysML | オブジェクトの広場
  • 「エンジニアリング至上主義」時代の終えんに開発現場で今すぐできることとは

    エンジニアリング至上主義」時代の終えんに開発現場で今すぐできることとは:特集:Biz.REVO~開発現場よ、ビジネス視点を取り戻せ~(2) リーンやアジャイルプロセスは「アプリケーション(ソフトウェア)」を作るためのもの。ビジネスにおけるIT活用が高度化・複雑化する現在、「システム」開発現場には、より大局的なIT観が求められている。 「よりビジネスに貢献できるITを」。もはや言い尽くされた感もあるテーマだが、ITがかつてないほど企業のビジネスに深く組み込まれている今日、ITにいかにビジネス視点を持ち込めるかが、そのままビジネスの成否に直結する時代になった。特に、市場環境の変化スピードが速くなる一方の昨今、ビジネスを裏で支える企業システムの整備には、かつてないほどのスピード感が求められるようになった。 しかし、自社の基幹ビジネスを支えるに足る品質や機能、独自性を備えたシステムを構築するには

    「エンジニアリング至上主義」時代の終えんに開発現場で今すぐできることとは
  • DevOps時代到来!Engine YardのPaaSで変わるシステムの開発と運用のあり方

    2013年5月11日(土) 九州産業大学で行われた「Future Sync vol.3」で登壇した時に用いたスライドです。一部のスライドは公開向けに修正を加えています。 Future Sync vol.3 : http://futuresync.jp セッション情報 : http://futuresync.jp/vol3_session/archives/4 セッションタイトル : DevOps時代到来!Engine YardのPaaSで変わるシステムの開発と運用のあり方Read less

    DevOps時代到来!Engine YardのPaaSで変わるシステムの開発と運用のあり方
  • 【書評】システムインテグレーション崩壊 これからSIerはどう生き残ればいいか? - GoTheDistance

    技術評論社の傳様より献御礼。 システムインテグレーション崩壊 ?これからSIerはどう生き残ればいいか? 作者: 斎藤昌義出版社/メーカー: 技術評論社発売日: 2014/06/05メディア: Kindle版この商品を含むブログを見る 工数積算のビジネスは終わる SIという言葉が指し示す範囲もSESから受託開発まで幅広い中で、著者の斎藤氏は「工数積算を前提としたビジネス全般、請負や準委任などの受託開発やSES技術者派遣ビジネスも同様に崩壊に向かう」という内容の趣旨が、表紙をめくって1ページ目に書いてありました。アクセル全開です。エンジニア人月0円セールと、ござ先輩に見た未来 - 山大@クロノスの日記っていう話もあるぐらいですからね。 崩壊に向かう理由は大きく3つあると書かれてあり、最初に挙げられている理由が「工数積算で成果保証を担保されるSIビジネスは、構造的に不幸にしかならない。」

    【書評】システムインテグレーション崩壊 これからSIerはどう生き残ればいいか? - GoTheDistance
  • EAの詳細(図表類の説明)<法規・基準<Web教材<木暮

    図をクリックすると拡大図が別ウインドウに表示されます。 政策・業務体系(BA) 経営戦略の明確化とかビジネスモデルの策定のプロセスです。対象となる業務・システムの範囲と最適化の方向性を優先順位をつけて明確に示す体系です。この体系で作成されるドキュメントには,業務説明書,機能構成図,機能情報関連図,業務流れ図があります。 業務説明書 業務・システムの管理・運用体制や最適化に向けた責任体制を明確化したものです。一般に簡潔な文章で記述されます。以下の文書は,それを具体的に詳細化したものであると位置づけられます。 機能構成図(DMM:Diamond Mandala Matrix) 業務機能を階層的に3×3のマトリックスで表現します。中央のマスに業務名を書き,その周囲のマスに中央の業務を構成するサブ業務を,左上から時計周りに業務の順序に合わせて記述します。中央のマスを目的だとすれば,周囲のマスはそれ

    EAの詳細(図表類の説明)<法規・基準<Web教材<木暮
    Mikatsuki
    Mikatsuki 2015/05/09
    いろいろあります
  • ベンダーとIT部門がぶち切れた“仕打ち”の理由

    「素晴らしいご提案ですね」と、ある製造業のシステム部長は唸った。その企業はグローバル展開の強化に向けて、SCM(サプライチェーン管理)関連で新たなシステムを導入しようとしていた。この分野でのシステム構築に多くの実績があるSIerに提案を依頼したところ、このSIerはまさに唸るような提案を出してきたのだ・・・。 あらかじめ断っておく、これから始まる“悲劇”は実話ではない。ただし架空の話でもない。複数のITベンダーの営業担当者やユーザー企業のシステム部長らから聞いた話を基に組み立てたストーリーである。だが、ここまで劇的な展開ではないとしても、特に大企業がやってしまう“人でなしの所業”とその結果生じるトラブルには思い当たる読者も多いはずだ。 さて、この製造業のシステム部長がSIerの提案を評価したのは、単にその内容が素晴らしいからだけではなかった。彼らが2カ月かけて経営層や事業部門に対して行った

    ベンダーとIT部門がぶち切れた“仕打ち”の理由
  • 甘やかされて稼げないIT部門と技術者は淘汰される

    パナソニックの2つのシステム子会社、そこで働く技術者の対照的な運命は、ユーザー企業のIT部門だけでなくIT業界でも大きな関心事となった。何度も報道されていることなので、くどくどと説明しないが、要約するとこうだ。かつて松下電器の情報化を担った子会社はITベンダーに売却し、旧・松下電工の子会社を今後、パナソニックグループのIT関連の中核会社と位置付ける――。 以前、松下電工は松下電器の“兄弟会社”として独立色が強かったが、今ではパナソニック電工としてパナソニックの子会社だ。つまり旧・松下電工のシステム子会社は、パナソニックから見ると孫会社にあたる。その孫会社をパナソニックは完全子会社化して、2015年10月にも社のIT部隊を移管する。どうしても旧・松下電器のシステム子会社と比較してしまう“厚遇”である。 かくしてパナソニックグループのIT関連の中核会社となったパナソニック インフォメーション

    甘やかされて稼げないIT部門と技術者は淘汰される
  • 要件定義ツールを使った既存システムの分析

    前回はUMLを使ってシステムの地図をかく方法を説明しました。今回はUMLを使わずにより簡単に分析する方法を説明します。システムの入出力とデータをつなぐ分析手法は、要件定義でも使われる手法なので同じ要領で既存システムを分析することができます。今回ご紹介するのは要件定義ツールを使う方法です。柔軟性には欠けますが、要件定義が初めての方でも簡単に短時間でまとめることができます。 短期間に分析する 今回ご紹介する方法は画面数が100程度の中小規模なシステムを対象としています。システム関係者へのヒアリングが行える環境があり、材料(入出力情報とデータ)が揃っている場合は、手法とツールを使うことで、短時間でシステムの地図を作成できます。 今回は要件定義ツール「要件のツボ」を使った方式を説明します。今回もプログラムそのものを調査するのではなく、システムの入出力を調べ、その使われ方を調べる方法です。「要件のツ

    要件定義ツールを使った既存システムの分析
  • HAクラスタとは 「HAクラスター」 (High availability cluster): - IT用語辞典バイナリ

    HAクラスタ フルスペル: High Availability クラスタ 別名: HAクラスター , ハイアベイラビリティクラスタ 【英】 High availability cluster , HA Cluster HAクラスタとは、コンピュータシステムの可用性(アベイラビリティ)を高めることを目的とした、複数台のコンピュータによる連携構成(クラスタ)のことである。主にサーバーを対象として構築される。 HAクラスタでは、複数台のサーバーが相互接続され、システムの冗長化が図られる。現在稼動している(稼動系)サーバーに障害が発生した場合、待機系として用意されていたサーバーに処理が引き継がれるため、クラスタ全体としては異常なく稼動し続けていることができる。これによってシステムの停止時間を最小限に抑え、可用性の向上を図ることができる。 なお、処理を稼動系サーバーから待機系サーバーへと引き継がせる

  • SQLインジェクション対策もれの責任を開発会社に問う判決

    ポイントは下記の通りです。 X社(原告)はセキュリティ対策について特に指示はしていなかった 損害賠償について個別契約に定める契約金額の範囲内とする損害賠償責任制限があった 当初システムはカード決済を外部委託し直接カード情報を扱っていなかった X社が「カード会社毎の決済金額を知りたい」とY社に依頼をして、その結果カード情報をいったんDBに保存する仕様となった(2010年1月29日) X社からの問い合わせに対してY社は、カード情報を保持しない方式に変更することが可能で、そのほうが安全となり、費用は20万円程度である旨を伝えた(2010年9月27日)が、その後X社は改良の指示をしなかった 以下の脆弱性その他が認められた システム管理機能のIDとパスワードが admin/password であった 個人情報が記載されたお問い合わせログファイルの閲覧が可能(ディレクトリリスティングと意図しないファイ

  • 複合主キーを避けるべき理由 - 虎塚

    データベース設計の話をしていて、「連番の主キーは業務上意味のないデータだから、テーブルに持たせるのはムダだ。複合主キーにするべき」という意見を聞く機会がありました。 脊髄反射で「ないわー」と思ったものの、理由を上手く説明できなかったので、改めて考えてみました。 その結果、次のような結論に至りました。 単一の連番カラムによる主キーと、複合カラムによる主キーとで迷ったら 実装をシンプルにし、業務変更の影響範囲を小さくするために、複合主キーを避ける というわけで、調べたことや考えたことをメモしておきます。# 間違っている部分があれば、教えていただけると嬉しいです。 (2011/07/25 追記)複合主キーとサロゲートキーについては、要件やシステムに依存して多様な判断がありうると思います。にもかかわらず、「避けるべき」というタイトルにしたのは極端でした。申し訳ありません。ご指摘下さった皆さん、あり

    複合主キーを避けるべき理由 - 虎塚
  • 「クラウド化は、コスト削減のためとちゃいます」 東急ハンズ・長谷川秀樹氏がAWSイベントで語る

    東急ハンズにて情報システムと通販事業の責任者を務める長谷川秀樹氏が、AWS Cloud Roadshow 福岡 powered by Intel に登壇。大手小売企業が仮想サーバを導入するにあたって注意した点、また新しく気がついた点を具体的に列挙。後発組へもAWSの採用を勧めました。 東急グループにおける情シスの責任者が登壇 長谷川秀樹氏:東急ハンズ、長谷川でございます。よろしくお願いします。「一体何者やねん?」っちゅうところなんですけども、東急ハンズで情シス(情報システム)と通販事業の責任者をやっています。ハンズラボという会社で、これSI(システムインテグレーション)の会社なんですけど、そこで代表やらさせてもらっています。 あとは東急不動産ホールディングスのほうで、マーケティングIT戦略部長みたいなのもやらさせてもらっています。今日はどっちかと言うと、ユーザー企業の情シス部長みたいな感じ

    「クラウド化は、コスト削減のためとちゃいます」 東急ハンズ・長谷川秀樹氏がAWSイベントで語る
  • 多くのユーザーは一度に1本しかジュースを買わない - @IT

    ユーザビリティのヒント(1) 多くのユーザーは 一度に1しかジュースを買わない 「自動販売機での不要な動作から考える」 ソシオメディア 上野 学 2006/6/2 前項とも関係しますが、一般的に、システムは大多数のユーザーにとっての利便性を優先するようにデザインされるべきです。なぜなら仕事や手続きを簡便化するのがシステムの存在意義だからです。通常の利用範囲を超えた状況を想定してプログラムを作ることは重要ですが、大多数のユーザーに対してそういった「例外的な利用からシステムを守るための」機能や制限を強調してしまうと、かえってタスクが阻害される場合があるので注意が必要です。 プログラミング作業では、主要な使用方法に対する処理の作り込みと同じかそれ以上に、特殊な使い方をされた場合の処理の作り込みに時間をかけますが、ユーザーインターフェイスの設計では、一般的な使用状況に最適化した表現に気を使うべき

  • http://www.csaj.jp/committee/keiyaku/download/070828_data1-3.pdf

  • 「ITプロ必携の超便利システム管理ツール集」関連の最新 ニュース・レビュー・解説 記事 まとめ - ITmedia Keywords

    ITプロ必携の超便利システム管理ツール集(17): 最強のトラブルシューティングツール、それはWindowsの「インストールメディア」 「正常に起動しないPCをどうにかしたい」「壊れかけのPCからデータを救出したい」「ディスク交換してPC環境を丸ごと引っ越したい」、どれもWindowsのインストールメディアがあれば即対応できます。(2014/11/7) ITプロ必携の超便利システム管理ツール集(16): MBSAでWindowsセキュリティチェックと構成の見直しを Windowsを安心、安全に使うには、マルウェア対策やWindows Updateによる更新はもちろんのこと、セキュリティを低下させるような不適切な設定を放置しないことが大事です。「Microsoft Baseline Security Analyzer」(MBSA)でチェックしてみましょう。(2014/11/6) ITプロ必

  • 今さら聞けない RFPによる調達&提案ガイド(11) 機能要件の実現に必要な機能を定義する要件

    RFPに記載すべき最も重要な要素であるシステム要件は機能要件と非機能要件から構成されています。前号と重複するところもありますが、非機能要件を作成する方法を解説するにあたって、機能要件と非機能要件についておさらいしておきましょう。 前号では機能要件について、「システムを利用して何をやりたいか」を説明したもので、「業務上の付加価値に直接的に関係するもの」だと述べました。例えば、「前日の商品別売上実績を翌日の9時までに見られるようにしてほしい」「従業員の残業時間を翌月の第1営業日までに集計してほしい」などが、機能要件に当たります。 対する今号のテーマである非機能要件とは「その機能をどのような品質で利用したいか」を説明したものであり、「想定される環境下でその機能を問題なく利用し続ける」ための要件となります。 各種標準化団体が非機能要件について定義しているので、以下に紹介しましょう。 非機能要件とは

    今さら聞けない RFPによる調達&提案ガイド(11) 機能要件の実現に必要な機能を定義する要件
  • 「なぜ、提案依頼書(RFP)を書くのか? 提案依頼書(RFP)にかかる基本的な考え方について」 | オージス総研

    WEBマガジン 「なぜ、提案依頼書(RFP)を書くのか? 提案依頼書(RFP)にかかる基的な考え方について」 2013.03.11 株式会社オージス総研  島 道夫 【発注者としての対応とは?】一般財団法人 日情報システム・ユーザー協会(以下、JUASと表記)より例年発行される「企業IT動向調査」(2012年度版)は、ユーザー企業からのアンケート調査(有効回答数 1000件以上)とヒアリング調査(40社)を実施してまとめられたものです。 その調査の内容で興味深い兆候が見て取れました。それは、発注者としての対応ができている企業ほど、プロジェクトの工期は規模を問わず、予定通りに完了し、プロジェクトの予算も予定通りに完了し、満足した品質を得ているということです。 では、発注者としての対応とは、どのように定義されているのでしょうか。JUASの調査では、以下の4点を挙げています。 「要求仕様の

  • 分かりやすい提案書はアウトラインが美しい

    分量がある文書を作成する際には、文書全体の「アウトライン(骨格、構成)」をきちんと作り上げてから内容を記述する必要があります。今回は、「読みやすく分かりやすい提案書」にするアウトラインの作成方法について紹介します。 読みやすい文書は「階層構造」をしている 読みやすい、分かりやすい文書は、全体が階層構造になっています。文書は、一般的に下記のような階層で構成されています。 大見出し(章) 中見出し(節) 小見出し(項) 階層構造は、複雑で大量の情報を含んだ文書の内容を、分類・整理するために必要不可欠です。階層化した文書は、各トピックで記述される範囲が決まっているため、焦点を絞って読むことができます。このことは、読者の理解を大いに助けます。 階層構造の方法について、順を追ってみていきましょう。まず「大見出し」の層に分割します。その後に各「大見出し」を「中見出し」の層に、さらに必要であれば「中見出

    分かりやすい提案書はアウトラインが美しい