[IPA] デスマらないために「超上流から攻める IT 化の原理原則17ヶ条」が思った以上に使える件 [要件定義] | oshiire*BLOG
「超上流」という言葉自体はとても気に入らないけれども、IPA 独立行政法人 情報処理推進機構 が作って公開している「超上流から攻める IT 化の原理原則17ヶ条」が、当たり前のことを当たり前に並べてあってとても役に立つ。 原理原則 17箇条 ユーザとベンダの想いは相反する 取り決めは合意と承認によって成り立つ プロジェクトの成否を左右する要件確定の先送りは厳禁である ステークホルダ間の合意を得ないまま、次工程に入らない 多段階の見積りは双方のリスクを低減する システム化実現の費用はソフトウェア開発だけではない ライフサイクルコストを重視する システム化方針・狙いの周知徹底が成功の鍵となる 要件定義は発注者の責任である 要件定義書はバイブルであり、事あらばここへ立ち返るもの 優れた要件定義書とはシステム開発を精緻にあらわしたもの 表現されない要件はシステムとして実現されない 数値化されない要
![[IPA] デスマらないために「超上流から攻める IT 化の原理原則17ヶ条」が思った以上に使える件 [要件定義] | oshiire*BLOG](https://cdn-ak-scissors.b.st-hatena.com/image/square/bfb41ba2bfefb166491d5d3e83380136f2017ab2/height=288;version=1;width=512/http%3A%2F%2Foshiire.to%2Fwp-content%2Fuploads%2F2015%2F01%2F17principles-300x212.png)
「挫折しないRedmine」の資料が分かりやすい - プログラマの思索
僕が使い始めた2008年頃と違って、現在はかなりRedmineが普及している。 ソフトウェア開発者だけでなく、製造業や製薬業、営業や事務、勉強会のタスク管理に使っている事例も多い。 最近特に目立つのが、初心者がRedmineを使っているものの、Redmineの良さを出し切れていない場面。 上記の資料では、「Redmineは、チームでチケットを消すゲーム」と定義して、わかり易く説明しているのがすごくいい。 アジャイル開発では、XPの計画ゲーム、Scrumのプロダクトバックログのように、ストーリーやタスクをチケット化して、イテレーション(Redmineならバージョン)単位にグループ化して、リリースしていく戦略を取る。 すると、チケット管理とは、チームでチケットを消すゲームなのだ、と感覚で分かるようになる。 この辺りの感覚は、40代以上の中年SEよりも、20代の若手PGの方がすぐに馴染んでくれる
渡辺幸三の開発支援サイト「システム設計のこと、もっと知りたい」 - HOME
現在進行中のプロジェクトで、設計の品質や生産性を高めたい．．． 業務知識や上流工程のスキルを身につけてキャリアアップしたい．．． ――そのためのお役立ち情報を揃えています。実務家から高い評価を得ている設計手法、専用の支援ツール、洗練されたモデルライブラリー。これらを駆使して、効率的にシステム設計のレベルアップをはかりましょう。 ニュース 「ＣＯＮＣＥＰＷＡＲＥ／自治体」の開発が始まりました(080420) 「ＣＯＮＣＥＰＷＡＲＥ／販売管理」をバージョンアップしました(080404) 「ＣＯＮＣＥＰＷＡＲＥ／生産管理」をバージョンアップしました(080404) ＸＥＡＤで入出力パネルの画像ファイルを扱えるようになりました(071004) 管理人のブログ「設計者の発言」
SIビジネスの流れ - @ledsun blog
システムインテグレータ（SI）のビジネスは大きく以下のような流れで進みます。 集客 営業 要件定義 製造 検収・請求 フォローアップ 集客 どんなビジネスでも同じですが、まずは見込み客を集めます。システム開発に興味を持ったお客様を探しアポイントを取ります。よく使われる手法に商品・サービスの説明をするテレアポ、割引を謳ったDM、自社の推す技術のセミナー、役員が個人的に懇意にしている既存顧客の紹介があります。会社の規模やブランドにマッチした手法を選ぶ必要がありますが、会社が成長にするにつれ手法を変えていかなければいけないのが難しいところです。 営業 アポイントの取れたお客様に顧客に直接、自社の提供するサービス、商品の説明を行います。また会社の紹介も同時に行います。お客様がある程度の金額を掛けてソフトウェア開発を行いたいと意思表示をされた場合に次の段階に入ります。そこで現状の課題を聞き出します。
テストコードを書く文化を根付かせたい─和田卓人｜【Tech総研】
日本におけるテスト駆動開発（TDD）のスペシャリストとして知られる和田卓人氏。講演活動やハンズオンイベントを通してテストの重要性を語り続けている。その深奥にあるプログラムの哲学とは── 父親がデータベース設計を得意にするソフトウェア・エンジニアで、受託開発の会社を経営していました。私は大学在学中からその仕事を手伝っていて、その延長で大学を出るとその会社の一員になりました。 そのころのことで一番印象に残っているのは、電子政府関連の公共システム開発に関わる大規模プロジェクトへの参加です。複数のSIerやソフトハウスが関わり、要件定義に時間をかけ、膨大な設計文書をつくっては、何千人というエンジニアを投入する、典型的な大規模システム開発です。私はそこにSEの一員として参加することになりました。 ただ、私は初日から生意気にも「Excelで設計書を書き続けるために来たのではありません」と嘆願して、基盤
［1］ベンダー任せの契約は危険がいっぱい！
ユーザー企業のみなさんは、システムの開発・運用をITベンダーに委託する際、どれくらい契約や法律について意識しているだろうか。「契約に時間をかけるより、システムを計画通りに完成させることが重要」と、契約にかかわる合意形成を後回しにしてプロジェクトを進めた結果、あとあと、トラブルが泥沼化するケースは少なくない。 そうならないために、ユーザー企業はどう対応すればよいか。その答えが、システム開発・運用にかかわる契約・法律（以下、IT法務）のスキルを高めることだ。システム部門や業務部門の担当者がIT法務スキルを高め、契約交渉の段階でお互いの役割や責任範囲を明確にすることで、早い段階でトラブルの芽を摘み取ったり、トラブルが起きても契約内容に基づいて円滑に収束させることができるようになる。 「そういうことは、法務部門や弁護士に任せればいい」という指摘もあるだろう。だが、実態は違う。経済産業省の「平成22
外注さんに失敗なく仕事をお願いする単純で画期的な方法を考えたった
株式会社プラムザ 代表取締役社長。システムコンサルタント。1998年に28歳で起業し、現在も現役のシステムエンジニア、コンサルトとして、ものづくりの第一線で活躍しつつ、開発現場のチームとそのリーダーのあり方を研究し続けている。 基本的にほぼ100％、社内のプログラマだけで開発を行っている弊社ではありますが、時折どうしてもリソース不足を起こすことがあります。 特にここ1年ほどは、消費税増税に伴ってシステムをフルリニューアルしようというようなお話が多く慢性的な製造力不足に悩まされております。 そんな時は外注の開発会社さんにお仕事をお願いするのですが、これがまあなかなか難しく、これまで結構失敗を重ねてきました。 今回、不肖わたくしめが「たぶんこれが正解じゃないか？？」という案を考えましたので、ここにご提案します。同業者の方々にとりまして何かヒントになれば幸いにございます。 □外注さんとうまくやる
ソースコード20万行の大規模サイトのPHPを5.1から5.4に上げるためにやったことまとめ · DQNEO日記
所要期間 着手しはじめたのが2010年12月ごろ、完了したのが2013年9月だったので何と３年近くかかったことになります。 長引いた原因は、日々の機能追加や運用をしながら孤独に片手間で細々とやってたからです。(単純に人手不足とも言う) また、PHPバージョンアップと同時にCentOSサーバを5から6にあげることにしたのでサーバ再構築のための工数も含まれています。 後半は仕事仲間が増えてその人が専業でバージョンアップ作業をやってくれたのでだいぶ楽できました。 それと専任のテスターさんたちにも参加していただいたので本番で大きなトラブルなく完了することができました。 感謝感謝です。 サーバ入れ替え作業が終わってPHP5.1の入った古いサーバを削除したときの、まさに「技術的負債」を返済し終わった瞬間の、あのスッキリ感、もう言葉にはできません。 終わってみてこの件に関するRedmineのチケットを数
ウェブエンジニアの生存戦略 - mizchi's blog
最近、この話題について経営者目線の話が多かったので、エンジニアのスキル獲得戦略とその最大化という観点から話をする。 まず目下のウェブエンジニアとして一番の課題は、「35歳定年説をどう乗り切るか」、ということだろう。もちろん、みんな35歳定年説なんてのが、まやかしであるとはわかっている。若い業界だったウェブ業界も成立してからだいぶ経ち、結果として平均年齢が押し上げられ、自然と35歳以上のエンジニアも増えてきた。 問題は、人月という概念によって、できる人間とそうでない人間の区別がされていないことだ。ウェブエンジニアとしての悲哀や業界の歪みはここにあると思う。下手に謙遜したりして話をややこしくする前に言ってしまうと、自分をできる側の人間として話をする。 生産性を測る確固としたメトリクスがないのも事実だと思うが、すくなくとも熟達した人間と未経験者がおなじ1人月というのは、到底ありえない話だと思う。
“素人集団”が強みに 基幹システムを自社開発するハンズラボ
東急ハンズのIT子会社であるハンズラボが、基幹系など自社開発したシステムをクラウドサービスに移行する作業に取り掛かっている。年内に作業を完了するとともに、自社開発の経験を生かして外販に乗り出す。最大の売りは、オーダーメイド型システムを早く、安く作り上げること。得意とする小売業にアプローチする。 業務に精通するITメンバーたち 2013年4月に設立したばかりのハンズラボには、約30人のエンジニアらがいる。多くは、東急ハンズ社内の公募によって、前身のIT部門に異動してきた20代から60代の社員。彼ら、彼女らは業務に精通するが、ITの専門家ではない。そんなITの素人集団で、2008年からシステムの自社開発を始めた。（関連記事：東急ハンズ、ITソリューション会社「ハンズラボ」設立 クラウド事業にも参入) 東急ハンズ執行役員・ITコマース部長を兼務する長谷川秀樹社長は「システムの構築方法を教えて、『
システム開発に欠かせない契約の基礎知識まとめ - GoTheDistance
先日識者の方に色々教わったのでメモっておきます。知ってそうで知らない、元々よくわからない、そういう方に向けてまとめてみました。 僕がSIにいた頃は大抵｢基本契約｣と｢個別覚書｣ってのがありました。納期とかお金とかそういうのは個別覚書に書かれたりしていました。 開発の契約体系 ｢仕様策定〜開発まで｣と｢保守運用｣で別契約にすることが多い。 ｢仕様策定フェーズ｣で1つの契約にして、別に新しく契約を締結しなおせるほうが望ましい。リスクが低減できる。 仕様策定までは準委任、開発は請負、保守運用は準委任という契約が多い。 ちなみに準委任は｢事務作業の代行｣という意味合い。委任は｢法的効力がある作業｣の代行。サムライビジネスは後者が多い。 別に運用が事務作業とイコールじゃないけど、成果を問わないタイプの契約の場合は役務提供という位置づけになる。 かといって契約で｢僕らのコンサル案を僕らが実施し成果が出
システム開発を適正な価格で発注し，プロジェクトを成功させる方法(その1：見積編)｜TechRacho by BPS株式会社
2013.04.20 システム開発を適正な価格で発注し，プロジェクトを成功させる方法(その1：見積編) こんにちは．morimorihogeです． 僕は普段受託開発の案件を中心に，要件定義から設計，実装，サーバ構築してリリースし，運用に乗るまで一通り携わる仕事をしています． Web開発自体はかれこれ学生時代からやっていて（当時は今の会社ではないですが），最初は純粋なプログラマとして入り，その後順当にやれる幅を広げていった形になります．もうそろそろ10年目みたいです．時が経つのは早いです． 昔に比べて最近は，お客様と開発の間の調整をしたり，案件の見積をしたりすることが多くなりました． そんな中，うまくいったプロジェクトもあり，こちらの力が至らずうまくできなかったプロジェクトもあります．いくつものプロジェクトを経験していく中で，最近はそうしたプロジェクトの差が見える様になってきた気がするので，
機能要件の合意形成ガイド
機能要件の合意形成技法WG の成果として、「発注者ビューガイドライン」 （2008年7月に公開）を改訂し「機能要件の合意形成ガイド」を公開します。 開発者が設計書を記述することのみではなく、発注者と開発者がシステム像をいかに共有し、行き違いなく合意形成を行うかに注目して、有効と思われる事柄を「コツ」としてまとめました。 「発注者ビューガイドライン」では画面、システム振舞い、データモデルの3つの技術領域、187のコツを掲載していましたが、「機能要件の合意形成ガイド」では、外部インタフェース、バッチ、帳票の3つの技術領域を追加するとともに、発注者視点のコツも充実させ、278のコツを掲載しました。 なお、初めて利用される方は、概要編を読んでいただくことをおすすめします。
ドキュメントを作成しないユーザーは、失敗する − ＠IT情報マネジメント
ドキュメントを作成しないユーザーは、失敗する：ユーザーサイド・プロジェクト推進ガイド（15）（1/2 ページ） システム開発にドキュメントはつきものだ。しかし、しばしばドキュメントが作られないプロジェクトが見られる。ドキュメントがないとどのような事態が発生するのだろうか？ コンピュータ・システム開発プロジェクトにおいて、ユーザーサイドではどのようなドキュメントが作成、準備されているのでしょうか？ 対象業務の概要を個条書きしたもの、現状使われている伝票や帳票類、現行システムのソフトやハードの構成図、それに画面のハードコピー、もしくは完成図書一式を資料として用意すれば十分でしょうか？ あとは打ち合わせの中でベンダへ口頭で伝えればよい──といえるでしょうか？ 関係部署が1つか2つ程度で限られた業務だけを対象とする小規模なシステム、あるいは現行システムの単純な更新であれば、この程度の資料だけで間に
ERPの落とし穴part1～SW開発ではない。要求開発だ！ - プログラマの思索
今まで数々のERP開発に携わってきたけれど、正直楽しかったと言う印象はあまりない。 開発者が想像するソフトウェア開発とは何か違う。 そんな時に梅田弘之さんの「グラス片手にデータベース設計~販売管理システム編 (DBMagazine SELECTION)」を再読して、ERPについて色々と感じるものがあった。 ERPの落とし穴やポイントについて考えたことをメモ。 【1】ERP開発はソフトウェア開発ではない。要求開発だ！ ERPは基幹系業務システムのためにある。 その開発スタイルは正直ソフトウェア開発ではないと直感している。 開発者がイメージするソフトウェア開発は、問題やタスクをプログラミングやサーバー構築などの技術で解決していくこと。 その作業は大変だが、やりがいはある。 しかし、ERP開発では、顧客から要求を収集し、要件として定義して後続の設計作業に落とし込む作業期間が非常に長い。 開発でき
あるＳＥのつぶやき: フリーで使えるプロジェクト管理ツールまとめ
フリーで使えるプロジェクト管理ツールをまとめておきます。 ■ガントチャート 開発マイルストーン ガントチャートでプロジェクト管理できるExcelツール フリーとは思えないほど高機能 ガントチャートforExcel・・・シェアウェアになりました こちらもガントチャートでプロジェクト管理できるExcelツール スケジュールの表示期間を切り替えられるのが便利 OpenProj Java ベースでガントチャートでプロジェクト管理ができるツール Microsoft Project のフリーのビューワーとしても利用可能 フリーの高機能プロジェクト管理ソフト「OpenProj」を試してみました TaskLine Excelのアドインとして動作するプロジェクト管理ツール（saramiさん情報） Microsoft Projectのファイル(XML形式)をExcelで表示するProjectViewerもある
ニッポンIT業界絶望論:江島健太郎 / Kenn's Clairvoyance - CNET Japan
日本のIT業界は救いようがない。絶望的としか言いようがない。 IT業界不人気なんて、この業界に重くのしかかる決して晴れることのない暗雲の氷山の一角に過ぎない。はてなの匿名ダイアリーにもどうせ理系出身者なんていらねえんだよ。なんて書かれていたけど、これが現実なのだよ、学生諸君。 ちょっと補足しておくけど、ここでIT業界っていうのは、SIerのことだ。お客さんの要件をヒアリングして、その要求に沿ったシステムを受託開発するっていうビジネスのことを指している。 ぼくもその昔、その世界のループに組み込まれていた。そして華麗なるコミュニケーション能力とやらをいかんなく発揮し、場の空気を読み、生意気なぐらいのチャレンジ精神で、それなりに仕事のできるよい子だったようだ。 いや、正直に言うよ。正直に言うとだね、結構楽しかった。 だって、考えてみてごらん。お客さんのところに出向いて行って、その業界のことをじっ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
モダンな現場にするために実践したこと
Full-[Watch]! Power Season 6 Episode 12 Online Free 123Movies![Full-[Watch]! Power Season 6 Episode 12 Online Free 123Movies](https://cdn-ak-scissors.b.st-hatena.com/image/square/1f4c5e88a0f20510caffcbe04a2c82643c871c41/height=288;version=1;width=512/https%3A%2F%2Fwww.digitalocean.com%2F_next%2Fstatic%2Fmedia%2Fsocial-share-default.e8530e9e.jpeg)
[ThinkIT] 第3回：基本設計書 (1/3)