ウォーターフォール型開発のおさらい ウォーターフォール型開発とは はじめに、ウォーターフォール型開発のおさらいをしておきましょう。ウォーターフォール型開発は、「要求定義→設計→プログラミング→テスト→リリース→運用・保守」という流れで開発を進めていきます。工程がすべて完了してから次の工程に進み、後戻りがないことを前提としています。しかし実際には、ほとんどの場合で手戻りが発生し、それにより納期が遅れたり、最悪の場合プロジェクトが頓挫してしまったりします。 開発期間中に要求が変化することを考慮していない 大抵の顧客は、最初から自分の欲しいソフトウェアをはっきりと説明できません。そのため、出来上がったソフトウェアを見てから、自分の欲しいものではなかったと気づきます。また、近年のビジネスは変化が非常に早く、外部環境の変化から要求が変更されることもあります。結果的に、無駄な作業が発生し、追加の作業に
(画像:wikimedia commons) こんな記事を見かけました。 記者の眼 – 「アジャイル嫌い」はもうやめよう:ITpro http://itpro.nikkeibp.co.jp/atcl/watcher/14/334361/082400357/?ST=system&P=1 開発の経験が長い人からすると、「あーはいはい」と昏い目をしてしまうような記事なのですが、実際のところアジャイルを宣伝する本やブログなどは多く、「プロジェクトを始めよう!」となったときに、候補に上がることが多い開発手法ではあります。 しかし、現場の現実から言うと、安易にアジャイルを導入して失敗するケースは非常に多いです。 私は20件以上のアジャイルプロジェクトを見てきましたが、そのうちちゃんと成功していたプロジェクトはたったの3件だけです(ウォーターフォールは100件以上見ていますが、成功率はそんなに低くはあり
若手が知らないメインフレームと銀行系システムの歴史&基礎知識:FinTech時代、銀行系システムはどうあるべきか(1)(1/2 ページ) 本連載では、銀行系システムについて、その要件や歴史を整理しつつ、スマートフォンを使う銀行取引やブロックチェーンなど、新しい技術が及ぼす影響を考察していきます。初回は、メインフレームと銀行系システムの歴史と基礎知識についてです。 「Finance(金融)」と「Technology(技術)」を足した造語である「FinTech」。その旗印の下、IT技術によって金融に関わるさまざまな業務や処理を利便化し、ビジネスの拡大を図る動きが国内金融業界から大きな注目を浴びています。特に金融業界の中心である“銀行”が運用するシステムについては話題に事欠きません。 例えば、ブロックチェーンによって銀行の勘定系システムが変わるという話があれば、2016年10月から日本でも利用可
ここにクソコードがある。 誰が作ったかはわからぬ。それが、どのような経緯でクソコードとなったのか、 あるいは、最初からクソコードであったのか、それらは全てクソコード自身が知るのみである。 ファーストコンタクト ある日、営業からシステム案件を打診されたので見積もりして欲しい。というメールが来る。 とある企業の既存システムに機能を追加する簡単な案件ですが、なななんとソースや仕様書をご支給いただけます! と、それはサンタにプレゼントが貰えると信じて疑わぬ子供のような真っ直ぐなメールである。 ソースコードが入った圧縮ファイルを受け取ったプログラマは、早速、コードを読んでみる。 そのシステムが本当にいいコードで書かれているかを判断するには時間がかかるが、 クソコードであるかはおおよそ30分でわかる。 インデントがタブとスペースどちらかに統一されていないとか、フレームワークの誤用があるとか、またはフレ
みずほフィナンシャルグループの佐藤康博社長は15日の決算発表会見で、傘下銀行のシステムを統合した新システムの完成時期について「もう少しで開発が完了する」との見通しを示した。今夏ごろとみられる。本格運用の開始時期は「移行の完了時期は特定できていない」と述べるにとどめた。みずほはかつての度重なるトラブルを受け、傘下銀行で三つあるシステムの統合を進めている。昨年12月末としていた完成時期は数カ月遅れるとしていた。延期によって、開発投資額は当初予定していた3千億円台後半から、4千億円台半ばに増えた。 佐藤社長は、新システムの運用開始後、ITの活用で店舗を減らす方針も示した。グループで約800ある店舗を1~2割程度削減する計画という。
内容がネガティブに取られそうで、公式なところに書くべきではないので個人ブログで書きます。 この記事は、公式なブログで僕が書いた「社内横断の技術組織をはじめました」という記事へのアンサーブログになります。 ※元の記事は探せば出てきそうだし、個人的なブログと紐付けるべきではないのであえて出しません。 特定の誰かを陥れる目的ではなく、完全に個人の責任として、始めたものを終わらせてしまったことへの事の顛末を記録する目的で書きます。 はじめに 始めた理由 CTOの不在 品質面に対するレビュー不足 技術広報の不足 それぞれの施策の結果 時間がかかってみんなストレスが溜まる新規レビュー 当たり障りの無いことしか表現できない運用レビュー 兼任状態が続き、進まない新規技術検証 やる必要の薄い「全社」広報 終わった理由 成果が出せなくて、そもそも証明出来ないかもしれない 問題解決は組織じゃなくても出来ると気が
2018年4月25日をもちまして、 『CodeIQ』のプログラミング腕試しサービス、年収確約スカウトサービスは、 ITエンジニアのための年収確約スカウトサービス『moffers by CodeIQ』https://moffers.jp/ へ一本化いたしました。 これまで多くのITエンジニアの方に『CodeIQ』をご利用いただきまして、 改めて心より深く御礼申し上げます。 また、エンジニアのためのWebマガジン「CodeIQ MAGAZINE」は、 リクナビNEXTジャーナル( https://next.rikunabi.com/journal/ )に一部の記事の移行を予定しております。 今後は『moffers by CodeIQ』にて、 ITエンジニアの皆様のより良い転職をサポートするために、より一層努めてまいりますので、 引き続きご愛顧のほど何卒よろしくお願い申し上げます。 また、Cod
みずほフィナンシャルグループ(FG)が開発中の次期システムが今夏に完成する見通しとなったことが2日、分かった。第一勧業、富士、日本興業の3銀行が2000年に経営統合して発足したみずほグループのシステムは、2度の大規模障害を経て、初めて統一される。運用開始は来年度以降になるとみられる。 次期システムの開発は、02年と11年に大規模なシステム障害を起こし、11年は当時の銀行トップが引責辞任する事態に発展した、みずほグループにとって最大の経営課題だ。だが、2度にわたる開発の延期で当初の想定以上の資金と人員を投入しており、収益を圧迫していた。
朝も早くから目が覚めたので、出社前に愚痴っとく。 当方のスペックは ・30代、化学系メーカに勤務。 ・大学での専攻は情報系ではない。パソコンは趣味でいじってきた。 1. SIerへの思い ・毎回、見積もりの度に「何人月ですか?」と聞くが、聞いてる私だって無意味な質問だと思ってるよ。 すまん、私の説明が悪すぎるのか、こっちの決裁権者は上から下まで人月でしか理解できないんだよ。 妥当かどうかはわからんけど、例えばソースの行数単価とか、プログラムの容量単価とかで説明したこともある。「訳がわからないから、やっぱり人月で表現してくれ」と言われたがな。 ・要求する機能に対して短い納期を設定しているが、「なんとかします」って言ってくれてありがとう。無理をねじ込んでごめん。 私にはお金関係を決裁する権限もなければ給料も安いから、ありがとう、ごめんと言うしかできない。 ・毎年「保守費、下がりませんか?」とお
半年ほどかけてWebサービスのプロトタイプを公開するところにこぎつけたのでその記録をしておこうと思います。 作ったもの 一言で言うと「Webブラウザで閲覧したページの履歴を共有するSNS」です。 History(履歴)を流す(stream)ということでHistreamと名付けました。 Chrome拡張をインストールして、ウィンドウを選択し、オンにするとそのウィンドウで見たページ履歴を自動でアップロードします。 そしてWebサービスでアップロードされた履歴を整理された状態で確認したり、友達の履歴を読めたりします。 Chrome拡張: Histream-Extension - Chrome Web Store Webサービス: https://histream.io 作ろうと思ったきっかけ 今から一年前、大学2年の冬にワンタップダイエットというアプリを作っていました。プログラミングするのはほと
10年ほど前のことになるが、プロジェクトマネジメント学会に呼ばれて「トワイライト・サロン」で講演を行ったことがある。テーマは「海外プロジェクトの共同遂行におけるリスク要因」で、海外の企業と組んで共同でプロジェクトを進める際に、どんなリスクが考えうるかと言う話だった。共同で組む場合、ジョイント・ベンチャーや、コンソーシアムなどいくつかの契約上のパターンがある。また、スコープをどう分担するかも問題だ。これらを考えた上で、最適なフォーメーションをデザインする必要がある。わたしは同僚のAさんと一緒に、来場者の前でこうした問題についての考え方をお話しした。 講演の後質疑応答の時間になって、幾人かの方が質問に立った。ところで、PM学会の参加者は昔も今も、ほとんどがIT業界の人たちである。話題も、IT開発系プロジェクトがなぜかデフォルトになってしまう。その中の1つは、プロジェクトがスタートしたしばらく後
ネット上ではSIer批判=技術のことをわかっておらずプログラムも書けずPMも出来ない非効率でダメダメな上流工程と、 人月単位での労働力提供という業界の慣習に縛られ、持ち前の優秀な技術力・知識を生かせず非効率な作業を強いられているかわいそうな下請け開発者、という構図が確立されているように思います。 自分が関わるまでは、まあそうなんだろうなと思っていましたが、しかし実際にそういう立場のひとと関わりをもつにつれて、どうもそうではないのではないかと思うようになりました。このあたりの実情を書いていこうと思います。 なお、先に言っておきますが本記事で書くことは、上流工程がどうのとか、業界の多重請け負い構造がどうのとか、給料が安くてとか労働条件が過酷でとか、そういう話とは全く関係がなく、純粋にプログラミングのスキルの話だけです。 対象はおもに詳細設計、実装UTだと思ってもらえれば。外部仕様が決まった状態
Featured Evernote 사업 거점을 유럽으로 이전하였습니다 2023년 6월 23일, 저희는 Evernote 직원들에게 업무 대부분을 모회사인 Bending Spoons의 본거지 유럽으로 이전할 것을 발표했습니다. 업무의 효율성을 높이고 유럽에서 매우 강력한 Bending Spoons이라는 고용주 브랜드를 최대한 활용하기 위해 이러한 결정을 내리게 됐습니다.… 자세히 알아보기 Featured Evernote 가격 변경과 예정된 개선 사항에 관한 최신 정보 예정된 가격 변경, 성능과 안정성 개선, 흥미로운 새 기능에 관해 소개하는 제품 책임자Federico Simionato의 요약 보고서 자세히 알아보기
これは未来からの投稿です。現在、信頼のおけるスケーラブルなプロダクションシステムの構築は、言ってみれば、その他のソフトウェアを書くのと同じくらい容易になっています。未来にはどのような風景が広がっているのか、お伝えしましょう。 2016年当時は、誰も彼もが「マイクロサービス」を取り上げていました。例えば、1996年に「情報スーパーハイウェイ構想」の記事ばかりが出回った頃に似ています。「情報スーパーハイウェイ構想」というフレーズがやがて消滅し、人々はインターネットの構築に戻っていったのと同様に、サービスが、スケーラブルなソフトウェアシステム構築の標準になるにつれ、マイクロサービスの「マイクロ」の部分もまた、削り落とされて行きました。私たちが使ってきた(そして捨て去った)名称であるにもかかわらず、どちらの用語も、当時のテクノロジーに対する考え方とその使い方に起こった転換を示しています。サービスベ
ん~、ことコンピュータに関して、“押下”はおかしいよなぁ?。 普通、ボタンは「押し込む」ことによって機能します。券売機のボタンにしても、自動販売機のボタンにしても、押し込んだら機能します。ところが、コンピュータ…というか、ソフトウェア上の話だな。ソフトウェアでは、ボタンは押し込んでも機能しません。押し込んで、放したときに機能します。 例えば、あなたが見ているブラウザの(Windows なら)右上にある「×」ボタン。ここへマウスポインタを移動させ、マウスのボタンを押し込みます。しかし、ブラウザは終了しません。ボタンを押し込んだまま、マウスポインタを「×」ボタンの外に移動させ、マウスのボタンを放します。やはり、ブラウザは終了しません。終了させるためには、マウスポインタが、マウスボタンを押し込んだのと同じコントロールの上にある間に、マウスボタンを放さなければなりません。つまり、“クリック”です。
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く