タグ

会社と開発に関するgouei2001のブックマーク (11)

  • システム開発における見積もりって何をチェックすればいい? - システム開発のプロが発注成功を手助けする【発注ラウンジ】

    システム開発の見積を算出する方法は、大きく分けて4通りあります。以下では算出方法ごとの概要や特徴を紹介します。 ●類推見積(トップダウン) 類推見積は、過去にあった類似プロジェクト事例を参考に、具体的な見積を算出する方法です。事例を参考にするため、ほかの方法よりもスピーディーに見積を出しやすくなっています。予想工数や費用に大きなズレが生じにくいため、正確性の高さにも秀でた方法です。ただし、「初めてシステム開発の見積を出す」というケースにおいては、そもそも類似事例を参考にできません。類推見積は、あくまで類似事例があって成り立つ算出方法だという点を覚えておきましょう。 ●係数モデル(パラメトリック見積) 係数モデルとは、特定の数式モデルを使用して、各作業を数値化したうえで見積を算出する方法です。例えば、「製品Aを100個作る見積」を計算するケースの場合、過去のデータを参照に「製品Aを1個作るの

    システム開発における見積もりって何をチェックすればいい? - システム開発のプロが発注成功を手助けする【発注ラウンジ】
  • 20年前の「障害の再発防止策の考え方」は今でも通用する説 - Qiita

    障害の再発防止策は、 1. メカニズム 2. ツール 3. ルール 4. チェックリスト の順番に検討せよ。 上記は、私が20年前に所属していたパッケージソフト開発会社の標語です。 ※転職したので現在の所属会社ではありません。 当時はまだインターネットが今ほど普及しておらず、修正パッチはCD-Rで配布していました。 特に、データ破損系の障害の場合は、 お客様にファックスで障害内容を報告し、 緊急ホットラインを開設し、 データ異常が見られる場合はバックアップを預かって修正後に返却し、 上記と同時並行でバグの原因調査と修正を行い、 パッチをCD-Rに焼いて配布する。 という障害対応を行っていました。 各パッケージの利用社数は数万〜10数万社に上りますので、大変な騒ぎでした。 そして事後に、障害の再発防止策を検討し報告する義務が課されるわけです。 メカニズム 仕組みとして、障害原因を封じ込める対

    20年前の「障害の再発防止策の考え方」は今でも通用する説 - Qiita
  • JTP Technology Port - JTP株式会社

    JTP Technology Portにアクセスいただきましてありがとうございます。 JTP Technology Port は、2021年3月31日ををもちまして閉鎖いたしました。 これまでご利用いただきました皆さまには、心より御礼申し上げます。 トップ に戻る

    JTP Technology Port - JTP株式会社
  • [連載]CakePHP3で開発 – クーディップ株式会社(Coodip, Inc.)

    カテゴリー: [連載]CakePHP3で開発に関する情報が1件見つかりました。 CakePHP3の初期インストールと環境切り分けプラグインを使った番反映 CakePHP3 系で web サイトを開発する場合、ローカルの開発環境でサイトを新規作成し、ステージングサーバや番サーバへ反映するケースがあります。以下では、重要なファイルを git の管理下から除外しつつ、特別なデプロイツールを使わずに簡単に反映する方法を記述します。 ローカルの開発環境の構築 普段開発で使用しているローカル環境の準備を行います。最近は docker で高知sくしておりますが … 続きを読む published 2016年4月19日 updated 2020年2月1日 in CakePHP, [連載]CakePHP3で開発, 開発

  • CakePHP3 の フロント側に Bootstrapを適用する – クーディップ株式会社(Coodip, Inc.)

    フロントの html / CSS をマークアップする際、プリセット済の bootstrap を利用することがあります。そこで、CakePHP3 の bootstrap プラグインを利用して、標準の関数を使用したまま bootstrap ベースの Html を書き出す方法を記述します。 Bootstrap UI のインストール 以下 Url からプラグインをインストールしたいのですが、 Read Me に composer の詳しい情報が書いていないので、直接 Packagist から参照します。 Bootstrap UIプラグイン Packagist の該当ページ 2016年7月28日現在でバージョンが 0.5.0 なので、これ以降のバージョンを利用するように composer.json を修正しました。この時点で記載さている内容は以下の通りです。 "require": { "php":

    CakePHP3 の フロント側に Bootstrapを適用する – クーディップ株式会社(Coodip, Inc.)
  • 【2019年版】おすすめのフリー(無償)CMSを紹介! - innova

    無償プランか有償プランかの選択も重要 同じ製品でも、無償プランと有償プランが用意されている場合があります。フリーのCMSとは、オープンソースか非オープンソースかという違いではなく、各製品ラインナップとして用意されている無償プランを指すと理解いただくほうが良いかと思います。無償プランでは、商用利用制限や、利用可能な機能やサービス内容に大きな制限ががあることも場合が多いです。それぞれの特徴を確認しておきましょう。 無償プラン 必要最低限の機能・サービスが利用できるイメージです。個人向けで小規模なサイトを作ったり、お試しで触ってみたりしたい人におすすめです。無償プラン契約時に構築・設定した内容は、有償プランに変更してもそのまま引き継げることが多いです。 企業での担当者自身がすべてを学び、構築運用を行う場合や、実験的にサイトを作ってみる場合には、無償のCMSは有用な選択肢です。低コストのメリットは

    【2019年版】おすすめのフリー(無償)CMSを紹介! - innova
  • トラブルの収拾つかず、謝り方を知らないITエンジニア

    ITの現場にはトラブルがつきもの。時として「謝る」場面がある。しかし謝り方を間違えると、かえって火に油を注ぎかねない。4日間で、上手な謝り方をマスターしよう。 あるシステム開発のプロジェクトでトラブルが発生。その直後に開かれた打ち合わせの場での話だ。立腹気味のユーザー企業のシステム担当者に会うなり、システム開発会社のITエンジニアが最初にこう言ったという。「今直面しているこの問題、解決させましょう」――。 システム開発会社側の火消し役としてその場に居合わせた、大手SIerのAさんは「謝りもせずにいきなりそう言うとは…」と、ITエンジニアの一方的な態度にあっけに取られた。 「今こそユーザーの協力が必要だというのに」――。Aさんがおそるおそるユーザー企業の担当者の様子をうかがうと「勝手に解決すればいいじゃないか」という表情。Aさんは「とても協力など得られそうにない雰囲気になってしまった」と振り

    トラブルの収拾つかず、謝り方を知らないITエンジニア
  • SQLインジェクション対策もれの責任を開発会社に問う判決

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

  • 工数見積もりのコツ - Qiita

    はじめに 稿では、仕事をする上での作業工数の見積もり方法について説明します。 工数とは何か 工数(こうすう1)というのは、仕事において、あるひとつの作業を完了するまでにかかる総累計時間のことです。情報処理技術者試験に出てくるTAT(ターンアラウンドタイム)とは意味合いが異なります2。 例えば、ある作業に40時間(40H3)かかるとした場合、工数は40時間であるといえます。1日8時間勤務だとした場合、40時間は5人日(にんにち)と表現することができます。さらに、1ヶ月20日勤務だとした場合、0.25人月(にんげつ)と表現することもできます。 一般的に工数の単位は「人日」および「人月」で扱います。 学生時代は工数を気にすることはないですが、ITエンジニアとして会社で働くようになると、かならず工数を意識する必要があります。 なぜ工数を意識する必要があるのか なぜ工数を意識する必要があるのかとい

    工数見積もりのコツ - Qiita
  • 破たんした見積もりはプロジェクト失敗への近道

    建築業界では、ほとんどの工事は見積もり額の-10~+10%に入るといわれており、多少誤差があるが、このPMBOKの定義とほぼ一致している。これに対しシステム開発では、最終的にはどのくらいの見積もり精度なのだろうか。感覚値だが、たぶん、-20~+100%ぐらいになっているのではないだろうか。 それでは、なぜシステム開発においては、見積もり精度が出ないのであろうか。これには、いくつかの理由が考えられる。 (1)機能の洗い出しが不十分 確定見積もりを算出するためには、プロジェクトで開発するシステムの機能とその難易度が分からないといけない。しかし、見積もりを算出する段階で、そもそも機能は明確になっているだろうか。機能が明確でないのに見積もりを提出しているとすれば、その精度はそもそも期待できなくて当然である。 (2)見積もり技術が確立していない システム開発においては、見積もる人によって金額に倍の開

    破たんした見積もりはプロジェクト失敗への近道
  • 営業は利益を、開発は売上を | ベンチャー法務の部屋

    私は、弁護士という職業上、あまりビジネス・コンサルタントっぽい発言は控えてしまう傾向にあります。 ただ、数多くの経営者やコンサルタントの話を耳にさせていただく中で、ある瞬間にいろんなことが結びつき、異なる表現ではあるけれども、同じことを意味しているのではないかと思わさせられることがあります。今回は、その話をさせていただきます。 先日、企業の利益向上のための施策についての議論を耳にしました。話をわかりやすくするために、小売業で考えてください。その議論とは、次の問題に関わるものです。問題とは、「既に市場で売り出されている製品Xについて、さらに利益を上げるためには、どうするか」というものです。もちろん、市場や経済は、様々な要素や人間の気持ちによって左右されますので、画一的な回答があるわけではありません。ただ、一般論として、利益を上げるには、(i)価格を上げる、(ii)販売数量を増やす、(iii)

  • 1