Location via proxy:   [ UP ]  
[Report a bug]   [Manage cookies]                

タグ

開発とSIに関するtakigawa401のブックマーク (44)

  • 顧客「長年1人で社内システムを開発していた社員が退職し、新規のシステムに刷新したいので見積りを。予算は5千万」→その結果こうなった

    ビビ@Τwitter @strategic_vivi お客様「長年一人で社内システム開発していた社員が辞める事に」 「ほう」 お客様「社内システムメンテ出来なくなるのでスクラッチで刷新したい。ついては見積もりを。予算感は五千万くらい」 「分かりました」 …(翌日) 「概算見積もり出来ました」 お客様「いくらくらい?」 ビビ@Τwitter @strategic_vivi 「15億円です」 お客様「…は?」 「統計ベースで判断して15億円規模のシステムです」 お客様「…」 「弊社に言える事は一つです。その社員だった方を、年収1億円提示して今すぐ呼び戻して下さい」 世の中には、単に社内SEと呼ばれるハイパーエンジニアがいる。 それ評価出来なきゃ辞めるだろ。

    顧客「長年1人で社内システムを開発していた社員が退職し、新規のシステムに刷新したいので見積りを。予算は5千万」→その結果こうなった
  • 「超高速開発コミュニティ」は何を目指すのか - ジャスミンソフト日記

    超高速開発ツール(または手法)の普及活動を行う「超高速開発コミュニティ」がいよいよ立ち上がりました。 http://www.x-rad.jp/ 記者会見の様子がさまざまなメディアに掲載されています。記事には触れられていませんが会場では記者との間に活発な議論があり、大いに盛り上がりました。厳しい質問を経て、次のような記事でまとめられています。記者の皆様、ありがとうございました。 「超高速開発コミュニティ」を設立――日が19位で黙っているわけにはいかない http://www.atmarkit.co.jp/ait/articles/1308/06/news121.html 開発ツールベンダー13社が集結し、「超高速開発コミュニティ」を設立 http://itpro.nikkeibp.co.jp/article/NEWS/20130806/496983/ 業務システムの開発ツール・ベンダー13

    「超高速開発コミュニティ」は何を目指すのか - ジャスミンソフト日記
    takigawa401
    takigawa401 2013/08/07
    外野から偉そうに否定的な意見ばかり言ってる連中に読んでほしい。
  • 超高速開発はスクラッチ開発の3倍から10倍の開発効率が条件、競合するベンダ13社が利害を超えて「超高速開発コミュニティ」を設立

    ソースコードの自動生成やカスタマイズ、ビジュアルプログラミングなど、スクラッチからプログラミングにより開発するよりも短期間で容易にシステム開発を実現するツールや開発手法を持つベンダが13社集まり、「超高速開発コミュニティ」を結成しました。 コミュニティが目指すのは、ユーザーに対してこれら「超高速開発」を名乗るツールの浸透をはかり、使ってもらうこと。「ユーザー企業がITをベンダに丸投げするシステム開発から脱却する道筋が描けるのではないかと期待している」(コミュニティ会長の関隆明氏)。また、これまでシステム開発に参入していなかった上流プロセスのコンサルタントがシステム開発に参入することなども期待しているとのこと。 コミュニティはこれからユーザー企業の参加を積極的に呼びかけ、当面200社の参加が目標。超高速開発を自社の強みにしたいと考えるSIerなどの参加も想定しています。 活動として予定されて

    超高速開発はスクラッチ開発の3倍から10倍の開発効率が条件、競合するベンダ13社が利害を超えて「超高速開発コミュニティ」を設立
    takigawa401
    takigawa401 2013/08/07
    「終わるSIer」を終わらせない為の面白い試みだと思う。ここに富士通やNTTら大手SIerが入るとパワーバランスが一気に崩れるのか、それとも更に発展するのかは見てみたい気がする。個人的には応援したい。
  • SIerを退職し、Web系に転職しました - arveltのソフトウェア技術メモ

    銀行系列の中規模SIer退職し、 受託と自社サービスの開発を行っている小規模Web系に転職することになりました。 7/30が最終出社日でした。8/1からは新しい勤め先へ向かいます。 1.これまでやったこと 2.これからやりたいこと 3.なぜ転職しようと思ったのか なお、3はいわいる自分語りを含む上に長いのでご注意ください。 読ませる知り合いもいないのに何故書いた。 1.これまでにやってきたこと。 オープン系の基幹システムの保守開発に携わり4年ほど。 JavaCOBOLExcelVBAをメインにやっていました。 もちろんSQLも普通に書いたりしつつ、触ったことのあるDBOracle、PostgresSQLSQLServer。 業務知識は主に流通系。Web開発とかもやりました。Javaでstruts1.Xとか、ASP.NETとC#とVBとか。 それと個人的欲求に基づき、Android

    SIerを退職し、Web系に転職しました - arveltのソフトウェア技術メモ
    takigawa401
    takigawa401 2013/08/06
    凄く共感した。でもオレ自身SIもWebもさほど変わらないことを経験したばかりなので、せめて彼の今後が幸多いことを祈りたい。
  • 2012/10/09 SIエンジニアの自分戦略 -急がば回れ、選ぶなら近道 - DevLOVE #devlove

    ござパイセン @gothedistance ちょっと気になったんだけど、打ち合わせが入ってもうた>SIエンジニアの自分戦略 -急がば回れ、選ぶなら近道- #devlove http://t.co/perVypp7 2012-10-09 16:21:10

    2012/10/09 SIエンジニアの自分戦略 -急がば回れ、選ぶなら近道 - DevLOVE #devlove
    takigawa401
    takigawa401 2012/10/09
    行けなかったのが非常に残念。 #devlove
  • 失敗しない!ラーメン屋と開発会社選びの5つのポイント! | DevelopersIO

    こんにちは!おおはしりきたけです。ここ最近すっかり涼しくなり秋らしくなってきましたね。秋と言えば欲の秋。と言えばやっぱりラーメンですよね。今回はタイトルの通り、失敗しないラーメン屋と開発会社の選び方5つのポイントということで、書かせていただきます。 1.インターネットでしっかり調べる ”知る人ぞ知る名店”なんてのは、昔の話です。今は、ラーメンデータベースやべログなどで、いくらでもラーメン屋を見つける事ができます。とにかく今は情報が多いので、べログの点数などはあまりあてにせず、メニューの写真などでていたりもするので自分が好みのラーメンなのかをしっかり吟味する必要があります。開発会社も同様で、大手の有名どころや、知っている会社だけでは良い開発会社を選定しているとは言えません。どんなシステムを作りたいのか?そのためにはどのようなキーワードで会社を選べばよいか?この会社は何をやっている会社

    takigawa401
    takigawa401 2012/09/25
    不覚にも納得してしまったじゃないかwww。
  • 実録!SIerがネットゲーム事業に参入できない理由

    SIerにおける某ネットゲームシステム(以下「NGS」)開発プロジェクトの発言録です。内容はもちろんフィクションですが、SI業界の実情を踏まえて構成してみました。SIerが内部に抱えるネットゲーム事業への参入障壁、さらにはSIerの将来の姿が垣間見えるかも知れません。 プロジェクト計画レビュー部長「NGSは、今年度の重点目標『高利益率ビジネスへの参入』を達成するために立ち上げる非常に重要なプロジェクトです。部長から直々のご指示を頂き、開発チームのメンバーを集めました。」 PMO事務局「PMOとしてもプロジェクトの成功に向けて最大限貢献したいと考えています。」 部長「それは心強い。ありがとうございます。」 課長「それでは、早速ですが、NGS開発プロジェクトプロジェクト計画レビューをお願いします。」 PMO事務局「プロジェクトのマスタスケジュールに計画が不明確な箇所が散見されます。βテスト

    takigawa401
    takigawa401 2012/09/20
    あー、これ今まさに味わってるわ。無駄な作業が多いこと多いこと…。品質の名の下にどれだけお客さんの金をドブに捨てる気なんだろ、って思ってる。
  • iOS Developer Enterpriseで社内向けiPhoneアプリを作る方法 [完全版] » SHINGOLOG

    iOS Developer Enterpriseで社内向けiPhoneアプリを作る方法 [完全版] 2012年3月13日 in iPhone 前回の記事で「iPadiPhoneで社内向け業務アプリを作る方法」として全体の流れを説明しましたが、今回は具体的な実装方法をまとめていきます。ネットで探しても企業用アプリの例は公開されているものが少なくて苦労したんですが、分かってみればかんたんです。アップまで詳しくまとめてますので、この記事だけでEnterpriseでの配布までは完璧なハズ! iOS Developer Enterpriseを使うメリット おさらいですがiOS Developer Enterpriseは、社内用のアプリを作る場合に使うライセンスです。 ・AppStoreに公開せずデバイスにアプリをインストール出来る ・しかも台数制限なし ・インターネット経由でアプリをダウン

  • 大きなリリースの際にチェックすべき34のこと

    アジャイル開発に取り組むチーム向けのコーチングや、技術顧問、認定スクラムマスター研修などの各種トレーニングを提供しています。ぜひお気軽にご相談ください(初回相談無料) 以前に作っておいた大きめなリリースをする際にチェックしておくべきことのリストが役に立ちそうなので公開しておきます。 僕の場合は普段はワンクリックデプロイが多いんだけど、かなり大掛かりな変更をするケースが年に数回あったりするので、その際にこういうリストを使ってリリース計画をチェックしています。(もちろん大掛かりなリリースでもワンクリックでできるのに越したことはないし、そもそもビッグバンリリースにならないようにできるだけ小さい単位で頻繁にリリースできるに越したこともない) 体制当日の体制は決まっているか夜間立会いの場合、日中の営業時間の対応体制は決まっているか翌営業日以降の体制は決まっているか連絡担当と作業担当は分離されているか

    大きなリリースの際にチェックすべき34のこと
  • テクノロジー : 日経電子版

    駅や野球場、高速で移動する新幹線の車内――。人が集まり、動くところに高速通信のビジネスチャンスがある。通信大手は鉄道会社などと需要喚起に挑む。 ■時速100キロの電車に8K映像 「デ…続き 時速500キロで途切れない 光ファイバー無線の仕組み [有料会員限定] 災害に強い通信へ 途切れぬスマホが命綱 [有料会員限定]

    テクノロジー : 日経電子版
    takigawa401
    takigawa401 2011/10/19
    現実なんてクソゲーだ → だったら現実をゲームにしちゃえばいいじゃん = ゲーミフィケーション
  • アジャイルで限定版を開発、公開版は手法を変えて作り直し

    マネックス証券は、約130万ある口座の保有者に長期分散投資の視点から資産設計をアドバイスするシステム「MONEX VISION β」を1年弱で構築、2010年10月1日にリリースした。クライアントにWebブラウザーとFlashプレーヤーを用いる、RIA(Rich Internet Application)型のWebアプリケーションである(図1)。 このプロジェクトには、課題が二つあった(図2)。 一つは、機能要件がすぐには決まらないにもかかわらず、短期間で構築すること。開発メンバーは作業を進めるうちに、その課題にはアジャイル風の手法が有効なことが分かり、限定版の開発に適用した。限定版で機能要件が確定したので、公開版はウォーターフォール型で開発を進めた。こうすることで「要件を誤って認識したまま開発を進め、終盤で大幅な手戻りが発生するということは皆無だった。不安を持たずに作業に集中できたことが

    アジャイルで限定版を開発、公開版は手法を変えて作り直し
    takigawa401
    takigawa401 2011/08/09
    個人投資家向けの分析ツールを、プロトはアジャイルで、本番はウォーターフォールで開発。プロトではコードを2回破棄している。
  • 日本のアジャイルムーブメントに、何が起きていたのか、何が起きているのか

    記事は、InfoQに掲載された平鍋健児氏の記事「What has happened and is happening in Japan’s Agile movement」を、InfoQ Japanの許可を得て翻訳、転載したものです) この10年の私のアジャイル人生でもっとも誇らしい出来事と言えば、Agile2008で「Gordon Pask Award」を受賞したことでした。振り返れば、私が初めて参加したアジャイル関連のイベントは、ソルトレークシティで行われた「Agile Development Conference 2003」で、そこで私は賞をもらったことを思い出します。それは「Thank-you-very-much-for-coming-all-the-way-from-Japan Award」(わざわざ遠い日からようこそいらっしゃいましたで賞)でした。 この記事では、私は「Go

    日本のアジャイルムーブメントに、何が起きていたのか、何が起きているのか
    takigawa401
    takigawa401 2011/08/01
    アジャイルが採用されない日本の特異性と徐々に採用されつつある日本のシステム開発の変化について。
  • 「要件定義書のアウトライン作成」完全マニュアル

    他の文書と同様、要件定義書はまず文書全体のアウトライン(骨格、構成)をしっかり作り上げてから内容を記述します。今回は、読みやすく分かりやすい要件定義書にするためのアウトライン作成方法を紹介します。 階層構造で読みやすい文書にする 要件定義書を作るためには、全体を大見出し=中見出し=小見出し(章=節=項)の階層構造にします。 「大見出し」「中見出し」「小見出し」の数を、それぞれ5から10程度にするのは、前回(第3回「分かりやすい提案書はアウトラインが美しい」)紹介した提案書と同様です。見出しの数が多すぎると、読み手が文書の全体像を把握できなくなります。また、1つの項目の記述量を1ページ内に収めるようにします。 要件定義書を構成する項目 要件定義書に必要な大見出しの項目としては、次のようなものが挙げられます。 システムの概要/システムの構想 機能要求 入力要求と出力要求 システム導入後の業務フ

    「要件定義書のアウトライン作成」完全マニュアル
  • 「アジャイル開発」って何がいいの?--アジャイル開発を実案件に生かすための基礎知識

    柏木雅之、山下博之 (IPA SEC エンタプライズ系プロジェクト) 2011-05-25 12:00 皆さんは「アジャイル開発」と聞くとどんなイメージを思い浮かべるでしょうか。語源となっている英語の“agile”を辞書で引くと「俊敏な、迅速な」という意味が載っています。そのとおり、刻々と変化する市場の要求、顧客の要求に迅速に対応していくというのが基的なアジャイル開発のあり方です。 連載では3回に渡り、アジャイル開発の採用を検討している方々に対して、その基的な事項を解説していきたいと思っています。連載によってアジャイル開発への理解を深めていただくきっかけになれば幸いです。 「ウォーターフォール型」の限界 アジャイル開発の説明に入る前に、「ウォーターフォール型開発」について見ていきましょう。 システム開発には納期が伴います。開発サイドは決められた期間内に要求通りの機能を実現し、顧客に

    「アジャイル開発」って何がいいの?--アジャイル開発を実案件に生かすための基礎知識
  • アジャイルソフトウェア開発宣言

    私たちはソフトウェア開発を実践あるいは実践の手助けをする ことによって、よりよい開発方法を見つけだそうとしている。 この活動を通して、私たちは以下の価値に至った。 プロセスとツールよりも個人と対話に。 包括的なドキュメントよりも動くソフトウェアに。 契約交渉よりも顧客との協調に。 計画に従うことよりも変化への対応に。 すなわち、左側に書かれたことがらに価値をおきながらも、 私たちは右側に書かれたことがらにより価値をおく。 Kent Beck Mike Beedle Arie van Bennekum Alistair Cockburn Ward Cunningham Martin Fowler

  • [ThinkIT] 第1回:開発ドキュメント体系と業務フロー (1/4)

    ソフトウェア業界の仕事は、下請け・孫請けのピラミッド構成となることが多く、常駐・派遣型のビジネスがかなりのパーセンテージを占めています。そんな中、他の業界と同じように、下請け脱却を目指して"一括請負"で仕事を引き受けたいとする会社もあります。 その志は善しとしましょう。しかし、肝心の"実力"が伴っていないと発注者も受託者もお互いに手痛い目に遭います。ここで言う"実力"とは、単なる技術力のことではありません。スケジュール管理や品質管理、コスト管理などのプロジェクト管理の技術・体制を社内で持っているかどうかが成否の鍵となるのです。 筆者の会社は創立11年目なのですが、創業以来「常駐・派遣の仕事はやらない!」という起業時のポリシーを貫いて来ました。C/SやWebのシステム開発を主体としているのですが、10年間の中では当然(?)、いくつかの失敗プロジェクトもありました。その苦い経験の中で「成功率と

  • プログラマーの成長を考えないSIerの仮説は間違っている - 達人プログラマーを目指して

    Java EEや.NETCOBOLやVB6よりも当に生産性が高いか? - 達人プログラマーを目指してのコメントで 熟練者も居ることは理解しているが、開発をする上で熟練者ばかりを集めることはできない。このため初心者側にレベルを合わせざるを得ない。 というコメントをいただきましたけれど、これは実に典型的なSIer(の上司)の考え方ですね。SIerの仮説と呼んでもよいくらいですね。とにかく、この仮説の前提となっているのは プログラマーのスキルレベルは一定で成長しない プログラマーは容易に交換可能なリソースである プログラマーは単純労働者である というモデルです。とにかく、この仮説がはびこっているから、いまだにSIerのフレームワークは「初心者側にレベルを合わせざるを得ない」という思い込みで作られていることが多いのでしょう。 COBOL(の初期の)時代ならまだしも、少なくとも現在の開発環境にお

    プログラマーの成長を考えないSIerの仮説は間違っている - 達人プログラマーを目指して
    takigawa401
    takigawa401 2010/12/08
    上に立つヤツがビジョンを正しく描けてないから明後日の方へ迷走するだけで、きちんと手順を踏めばハイレベルな技術を全体で共有できる。
  • UXとは何ぞや? UXを高める武器を手に入れよう! ― 開発者は、いかにユーザー・エクスペリエンス(UX)と付き合うべきか ―

    連載目次 ◇連載の趣旨 ユーザー・エクスペリエンス(以下、UX)とは、大ざっぱにいうと、ある製品(アプリケーション)をエンド・ユーザーが使った際に経験する「楽しさ・心地よさといったプラスの感情」を、(エンド・ユーザーに提供する)価値として重視するコンセプトだ。具体的には、見た目のみではなく、使い勝手や信頼性などの側面を重視した設計を行い価値を実現する。(UXの詳細な定義については後述)。そのUXが注目されるようになって久しい。が、UXの定義や意味するところ、もたらされる恩恵は、一般の開発者レベルまで伝わっているだろうか。 開発者にUXについて尋ねると「UXはデザイナーの仕事(なので、自分には関係がない)」というような意見を持っている方に出会う。当にUXに関係のない開発者がいるのだろうか。 アプリケーションに対するエンド・ユーザーの不満を例に、不満の原因が誰の責任か見てみよう。 これら、

    UXとは何ぞや? UXを高める武器を手に入れよう! ― 開発者は、いかにユーザー・エクスペリエンス(UX)と付き合うべきか ―
    takigawa401
    takigawa401 2010/09/06
    ユーザーエクスペリエンスについて。末尾のWindows / Google / AppleそれぞれのUIガイドラインのリンクと和訳が有難い。
  • 【中級】無駄なく確実にテストする III システム・テスト:ITpro

    システム・テストの対象は,結合テストを終了した機能やサブシステムをまとめた「システム」となる。Vモデルによればシステム・テストは要求分析工程に対応している。テストの目的は,要求分析で定義された,負荷限界や必要なリソースなどの要件を,「システム」が正しく実現しているかどうかを確認することだ。 また要求分析には,開発/運用/利用部門の共通の認識として,システムのコンセプトや目的,達成すべき目標などが記述されている。テスト実施者は,開発者としての視点だけではなく,利用者や運用担当者の視点も含めたテスト・ケースを設定して,テストを実施すべきである。 III-(1):負荷テスト システムが,どこまでの負荷に耐えられるかを実測確認する。後述の「パフォーマンス・テスト」とは,正確には別のものである。代表的な負荷テストには以下のものがある。 ●ロングラン・テスト ある一定時間システムを連続稼働させて,一定

    【中級】無駄なく確実にテストする III システム・テスト:ITpro
    takigawa401
    takigawa401 2010/08/25
    負荷テスト、パフォーマンステストあれこれ。
  • 社員2人が2カ月で完成、自前開発の喜びを取り戻す

    IT研修サービス大手の富士通ラーニングメディアが2009年7月、研修受講者が利用する「新受講管理サービス」を、セールスフォース・ドットコムのPaaS(プラットフォーム・アズ・ア・サービス)「Force.com」上に構築して運用を開始した。全国6カ所の拠点で同時に1000人が利用するシステムを、2人の社員がわずか2カ月で作り上げた。<日経コンピュータ2009年8月5日号掲載> 「コーディングを一切外注しない開発がこんなに楽だということを、久しく忘れていた。テスト運用中に生じた利用者の不満も、その日の内に解決できた。外注したコードを自分で修正できないことに今までどれだけストレスを感じていたか、改めて気付かされた」。富士通ラーニングメディア システム推進部で「新受講管理サービス」の開発を担当した若松英寿氏(写真)は、Force.comを使った「クラウド開発」の感想をこう述べる。 富士通ラーニング

    社員2人が2カ月で完成、自前開発の喜びを取り戻す
    takigawa401
    takigawa401 2010/07/20
    SIの終わりの始まり。Force.comを開発・利用する事で開発費・運用費ともに大幅にダウンできた事例。クラウドが内製化を加速させる。