どっちの言い分もわかる気はする。 発注側はどんなものができるか製品がわ..
どっちの言い分もわかる気はする。 発注側はどんなものができるか製品がわからないのに製品代を出したくない。 受注側は製品を設計する事は片手間でなく本業のうちだから設計の代金が欲しい。 すれちがう原因はお互いにあって、 発注側は大量生産品や「設計済み」の受注生産品を買う認識でいること。つまり設計の労力を過小に見積もっている。 受注側は相手がシステム開発の発注について熟知してることを前提にしていること。つまり設計の手間が工業製品とはまるで違い、設計が仕事のメインだと顧客に認識させずに話をすすめている。 これが原因だ。 システム開発の大部分の労力は設計にあるといってもいい。 要望を満たすために「顧客が事細かく話した内容をシステムに落とし込んだらどうなるのか、どんな画面でどんな印刷物がでて、顧客ごとのの入金の流れとか、その他諸々がどんなふうになるのか」を考えることがシステム開発のメインとなる作業だ。
「地方公共団体における情報システムセキュリティ要求仕様モデルプラン（Webアプリケーション）」を一般公開しました - 財団法人 地方自治情報センター（LASDEC）
現在位置： ホーム > 情報セキュリティ 対策支援 > 自治体セキュリティ支援室からのお知らせ > 「地方公共団体における情報システムセキュリティ要求仕様モデルプラン（Webアプリケーション）」を一般公開しました 背景 情報システムは住民向けのサービス基盤として欠かせない存在ですが、情報システムを安全に利用する上で避けては通れない問題があります。それが「脆弱性」に関する問題です。 脆弱性とは情報セキュリティ上の弱点のことであり、脆弱性の問題を放置すると、情報の流出や、ホームページ等コンテンツの改ざん、サービスの停止などの問題を引き起こす可能性があります。一見すると安定して動作しているように見えていても脆弱性が内在することもあり、情報システムの調達・構築・運用にあたってこの対処をあらかじめ決めておくことは安定的な運用に欠かせないことです。 特に近年ではWebアプリケーションの脆弱性
営業に関する質問です。 例として、ぐるなびを挙げてみます。…
営業に関する質問です。 例として、ぐるなびを挙げてみます。 ぐるなびはお店に予約システム、ブログシステムを提供する事で月額料金で利益を得ています。 ぐるなびのようなサイトを運営していると仮定し、初期費用無料、月額3000円と仮定します。 もし、100万円の営業資金があるとしたらどのような営業活動を行いますか？ そして、何件ほどの契約をどれほどの期間で見込みますか？ 必須事項 1.営業資金100万円の使い方 2.期間 3.契約件数 4.1～3の理由をかなり詳しく 例 1.月額25万円で営業派遣を使う。 2.3ヶ月 3.120件 4.理由をかなり詳しく・・・
Rails で、Controller に定義されている action を一度に取得する方法はありますか？ - QA@IT
平素よりQA＠ITをご利用いただき、誠にありがとうございます。 QA＠ITは「質問や回答を『共有』し『編集』していくことでベストなQAを蓄積できる、ITエンジニアのための問題解決コミュニティー」として約7年間運営をしてきました。これまでサービスを続けることができたのは、QA＠ITのコンセプトに共感をいただき、適切な質問や回答をお寄せいただいた皆さまのご支援があったからこそと考えております。重ねて御礼申し上げます。 しかしながら、エンジニアの情報入手方法の多様化やQAサービス市場の状況、＠ITの今後のメディア運営方針などを検討した結果、2020年2月28日（金）15:00をもちましてQA＠ITのサービスを終了することにしました。 これまでご利用をいただきました皆さまには残念なお知らせとなり、誠に心苦しく思っております。何とぞ、ご理解をいただけますと幸いです。 QA＠ITの7年間で皆さまの知識
ウォーターフォールの方が楽ですか？
(顧客) そのシステムを作った結果に対して、顧客自身が結果責任を背負っていない場合は、ウォーターフォールの方が楽。最初に仕様合意して最後に「納品」されれば良い。場合によっては、システムによって得られる価値が目的なのではなく、「システムを作る」こと自体がアリバイ的に目的であるケースすらある。こういう場合は、顧客自体のプロジェクトへの参画が必要なアジャイルは面倒だと思うだろう(顧客) また、顧客が開発部隊に対して政治的に極めて強い力を持っている場合なんかは、基本的に全てのリスクを政治的な力によって移転できるので顧客側が大きくコミットする必要性はなく、ウォーターフォールの方が彼らにとっては楽かもしれない(顧客) その一方で顧客自身が結果責任を背負っている場合やそのシステム自体がビジネスの中心を担っているような場合、肉体的ではなくリスクマネジメントとして楽なのは圧倒的にアジャイルであると言える。市
ソフト開発をステップ数で見積っていることに疑問を持たなくてはならない - レベルエンター山本大のブログ
ステップ数を見積もり根拠にする会社さんは、いまだに多い。嘘じゃない。 お世話になってる会社さんもそういう仕組みをとってるところがあって、いいにくい部分もなきにもあらずだが、お世話になってるからこそいいたい。 そんなことやってちゃだめだと。 １キロステップの生産性指数をだして、今回の開発は10キロだから１０００万円とか。 汎用機時代ならまだ百歩譲ってわからんでもないけど、オープン系という言葉すら死語になりつつあるこのご時世において、ステップ数が１キロ（１０００行）だったら１人月とかどうこうという話は、もはや見積もりでもなんでもなく、こじつけだ。 フレームワークのコアのコードも、 ビジネスロジックの肝のコードも、 ネットワークの通信コードも、 自動生成したコードも同じ１ステップとカウントする。 見積もり時の計画ステップ数と、実際に開発したときの実績ステップ数を比較して 次の開発の値決め（ダンピ
［速報］スルガ銀-IBM裁判、日本IBMに74億円超の賠償命令
勘定系システムの開発失敗を巡り、スルガ銀行が日本IBMに115億8000万円の支払いを求めた裁判で、東京地方裁判所は2012年3月29日、日本IBMに74億1366万6128円の支払いを命じる判決を言い渡した。 スルガ銀行は2000年代初頭に勘定系システムの刷新を計画し、海外製の勘定系パッケージ・ソフト「Corebank」を担いだ日本IBMの提案を採用した。ところが刷新プロジェクトは要件定義から難航。新システムを完成させることができなかった。 結果的にスルガ銀行は日本IBMに新システムの開発中止を通知し、2008年3月に「日本IBMの債務不履行によりシステムの開発を中止せざるを得なくなった」として、日本IBMに損害賠償を求める訴訟を東京地裁に提起していた。 関連記事：“スルガ銀－IBM裁判”を振り返る ■変更履歴 スルガ銀による賠償請求額について、当初の記事では「111億700万円」と書い
特許庁の55億かけて頓挫したプロジェクトの報告書が面白い
http://www.asahi.com/business/update/0124/TKY201201240616.html 24日のニュース http://www.meti.go.jp/press/20100820003/20100820003-2.pdf その発端ともいえる二年前の報告書 始まりは、ありがちな汚職だと思えた･･･その巨大プロジェクトの実体は！ 1部～2部で内容が重複してるから、ストーリーだけ知りたい人は3部から読むのをお勧めする。図表もあるのでわかりやすい。 これについてのブコメやTwitterを見ていると不祥事を叩いたり、やめた事を批判して55億賠償しろって人も結構いるのだけど、なんかもうそういう問題よりも気になる点が山ほどある。自分の感想をまとめておく。不祥事そのものより、その裏にあるプロジェクト全体や日本の開発にありがちな問題にもっと注目されて欲しいのでそういう視
内製について考える － 本業とは？ コア業務とは？ - andalusiaの日記
システムはどこまで内製化できるか - 急がば回れ、選ぶなら近道 今の日本の経営陣の基本的なスタンスは一般化すれば、「ITは経営の背骨である。ITがしっかりしていない企業は早晩衰退する」という考えと「うちの本業はITではない」という考え方のふたつに収斂されるでしょう。 多分、そういう答えが返ってくると思います。そして、後者と答えた経営陣に、なぜそう思うのかと尋ねると、「コアコンピタンスに経営資源を集中して資本効率を高めることがグローバル化した市場からの要請で・・・」などという答えが返ってくると思います。 では、市場主義の本家本元の米国ではどうなのでしょうか？ よく言われているとおり、米国では情報システムについては内製が主です。ところが逆に、例えば製造業でのアウトソーシング、EMS*1やODM*2の活用が進んでいるのは、むしろ米国です。実は、米国では必ずしも「本業に経営資源を集中」はしていない
システムはどこまで内製化できるか - 急がば回れ、選ぶなら近道
どこでも何回も何十回も言われているが、システムを経営の変化に対応させるにはある程度のシステムの開発を内製化すべきである、という論調が強い。この問題は、古くて新しい問題であり、と同時におそらく、いままでとは違うコンテクストで語られることになるような気がしている。ここ１０数年の流れを見れば、内製化の議論はアウトソーシングの流れとそのより戻りの反復運動の繰り返しだといっていても過言ではなかったと思う。近年はむしろ、SI屋さんの全体的な弱体（特に技能として）化とクラウド等によるインフラの導入しやすさと相まって別の背景で語られることが多くなってきている。また、見逃せない背景としては、そもそもの就労可能若年層の減少と、若年層の総体数減少による能力のばらつきの顕在化も強くあげられる。特にシステム開発の供給サイドの問題は、エンドユーザーの内製化の議論においては、今までのコンテクストでは語られることがなかっ
工数見積もりで陥りやすい罠 - プログラマの思索
「ソフトウェア見積り」を読んだ後に「アジャイルな見積りと計画づくり」を読み直したら、とても理解しやすかった。 理解できたことをメモ。 間違っていたら後で直す。 ※追記：一部修正した。 ※追記：Velocityの計算方法を「塹壕よりScrumとXP」から参照するようにした。 【元ネタ】 Twitter / @akipii: 見積について色々考えている。1.0MD(人日)という単位は規模・出来高・工数という複数の意味を持ち混乱しやすいから、ソフトウェア開発の計画づくりに支障をきたしているのではないかという仮説を考えている。その考えを深めるとScrumのストーリーポイントはよく考えられた概念だと思う。 アジャイルサムライで一番難しくて面白い概念～Velocity: プログラマの思索 ソフトウェア開発に特有な技術～ソフトウェア見積り: プログラマの思索 チームは加速するのか～Velocityの使い
SIビジネスの流れ - @ledsun blog
システムインテグレータ（SI）のビジネスは大きく以下のような流れで進みます。 集客 営業 要件定義 製造 検収・請求 フォローアップ 集客 どんなビジネスでも同じですが、まずは見込み客を集めます。システム開発に興味を持ったお客様を探しアポイントを取ります。よく使われる手法に商品・サービスの説明をするテレアポ、割引を謳ったDM、自社の推す技術のセミナー、役員が個人的に懇意にしている既存顧客の紹介があります。会社の規模やブランドにマッチした手法を選ぶ必要がありますが、会社が成長にするにつれ手法を変えていかなければいけないのが難しいところです。 営業 アポイントの取れたお客様に顧客に直接、自社の提供するサービス、商品の説明を行います。また会社の紹介も同時に行います。お客様がある程度の金額を掛けてソフトウェア開発を行いたいと意思表示をされた場合に次の段階に入ります。そこで現状の課題を聞き出します。
offchizというアプリを2週間で作ってみました。
ヤフー株式会社は、2023年10月1日にLINEヤフー株式会社になりました。LINEヤフー株式会社の新しいブログはこちらです。LINEヤフー Tech Blog ヤフー西日本開発部開発チームの近藤です。 LatLongLabでは先日、お出かけや旅行に気軽に持っていける地図帖を作成するサービス「offchiz」（おふちず）を公開しました。 昨年公開したyubichiz（ゆびちず）に続き、今回の新サービス「offchiz」もウェブアプリとなっており、具体的なサービスの企画からおよそ2週間で初回リリースまでこぎ着けました。 このエントリーではoffchizを公開するにあたっての 素早い開発サイクルを回すためのチーム体制 今回採用したHTML5と、その周辺技術 といった点を紹介させていただきます。 素早い開発サイクルを回すためのチーム体制 サービスの企画 最初に、LatLongLabメンバーが集ま
要件定義を得意ワザにしよう
「システム開発で、何が一番難しい？」と尋ねられたら、「要件定義」と答える人が多いのではないか。ユーザーが何を望んでいるのか的確につかみ、ときとして関係者間で対立する要望を整理し、システムの要件にまとめて関係者の合意を得なければならない。技術者からは「いろいろ神経使うし、大変だよね…」という声が聞こえてきそう。 要件定義のスキルを磨くには「知識＋実践」が不可欠だ。ここでは要件定義に関する好評連載・特集をピックアップした。これらの手法やノウハウを使って、より良い要件定義ができるよう、実践に役立てていただければ幸いである。 認識のズレや要件の抜けを防ぐ「詰めの質問術」 システムの出来が見違える コツ1●言葉の定義を聞く コツ2●言い換えて聞く コツ3●タイミングを聞く コツ4●なぜ必要なのかを聞く コツ5●そうではないケースを聞く コツ6●順番が逆のケースを聞く コツ7●状態の変化に注目して聞く
少人数開発に役立つ5つのまとめ
if ( $blog == " Webエンジニアのためのライフハック " ) { print " 1-byte.jp "; } ホーム1-byte.jpとは 書いてるヒトは ここ2ヶ月間で気になる記事がたくさん上がっていました。 特に少人数チームにおける開発に関する記事です。 昨日、書き上げた”1年間の技術的負債を返すために読んだ3冊の本“にある通り、お知らせメールでは1年間の技術的負債を返そうとしています。 そのためには今まで曖昧だった箇所を浮き彫りにし、改善する必要があります。 また、せっかくなので新しいモノも取り入れたい。 こうしたことを考えながらの2ヶ月だったので、自然と目に止まった記事が3つありました。 スタートアップ企業で8年間Webの開発をしてみての反省点いろいろ 複数人(2-3人)でウェブサービスを開発するコツ A successful Git branching m
新しい契約形態での受託開発サービス ｜ 永和システムマネジメント
近年、大変注目を集めているソフトウェア開発手法に「アジャイル」があります。 アジャイルはお客さまの組織やビジネスの変化に素早く対応することが可能な開発手法です。 しかし、ソフトウェア業界での受託型の請負契約は要件定義が完了してから開発見積り・契約するというやり方が当たり前となっており、お客様にアジャイルのメリットを実感頂くのが難しいという課題がありました。 これまでの受託開発における一括請負型の契約では納品時に費用を全額お支払いいただくというビジネスモデルをとってきました。 このサービスではこのビジネスモデルから脱却し、開発したシステムを初期費用0円で提供します。その後、お客さまにはサービス利用料という形で月々お支払いいただきます。 サービスがお客さまに価値を提供するのは納品した瞬間ではなく、お客さまがサービスを利用しているあいだ継続的にです。 このことから、お客さまがサービスを利用してい
「コードの読まれ方が分かった」、工数見積もり精度向上に寄与
「コードの読まれ方が分かった」、工数見積もり精度向上に寄与：奈良先端科学技術大学院大学 森崎修司氏らが発表 「ソースコードの読まれ方の傾向がまた1つ明らかになった。これで派生開発、保守開発の工数見積もりの精度が向上する」――奈良先端科学技術大学院大学 森崎修司助教らの研究グループは、2009年9月～11月にかけて行ったソースコードリーディングのオンライン・ハンズオン、2010年1月、2月に行ったイベント「ソースコードリーディングワークショップ」、ほか3回におけるハンズオンの分析結果を発表した。 総計126人に、保守／派生開発プロジェクトを模した形式で複数のソースコードを読んでもらい、それぞれにかかった時間を計測、分析したところ、「ソースコードの読解時間はソースコードの行数だけで予測することは難しい」「大規模な変更の場合、コードレビューの経験があるとソースコードの読解時間を短縮できる」ことな
スタートアップ企業で8年間Webの開発をしてみての反省点いろいろ - Masatomo Nakano Blog
2002年、当時設立したばかりの会社に入り、何もない状態から、コンテンツとシステムを作り続け8年が経った。日々、試行錯誤しながら、それなりに会社も大きくなり、まだ、大成功とは言えないけど、それなりにうまくやってきたつもりだ。 しかしながら、その8年という短くはない時間の中で、色々な課題や問題が発生し、その時々正しい選択をしてきたつもりだったけど、反省点も多い。もう一度スタートアップに参加するとしたら、やり直したいところや、もっと早くこうしていれば良かったというところがたくさんある。 そんなわけで、次の挑戦のときに忘れないように、また、もしかして誰かの参考くらいになればと思い、メモっておくことにした。1 まず、反省点の前に、何をやっているのかというのを簡単に。 ビジネスとしては、英語e-learningのWebサービス(ネットを使った英語のお勉強)をASPな形で、企業や大学などに提供している
フローチャートの力を思い出そう
一つ，後悔していることがある。 今年の6月29日，「オブジェクト倶楽部 2006夏イベント」に参加した。オブジェクト倶楽部は，永和システムマネジメントの社員有志が中心になり，オブジェクト指向の実践／研究／発表を目的として作ったグループ。夏と冬に定期的にイベントを開催している。2006夏イベントで6回目となる。 このイベントで，スターロジックの羽生章洋社長が講演した「仕事で必要なことはフローチャートで学んだ」というセッションを受講した。同じ時間帯の裏番組でとても魅力的なセッションがあったのだが，あえてこちらを選択した。羽生氏のプレゼンテーションのうまさをよく知っていたからだ。案の定，おもしろかった。羽生氏がタブレットPCを使ってその場でどんどんフローチャートを書いていく。講演の資料はこちらで公開されているが，これだけではとても伝わらないライブ感があった。 講演の内容はノートにメモしたし，講演
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
