20141108 俺のエンジニアリング #devlove1. E N G I N E E R I N G 俺のエンジニアリング - エンジニアリングにチームビルディングは必要なのか - 及部敬雄 @TAKAKING22 2014.11.8 プレイバックDevLOVE現場甲子園 2. 及部 敬雄 @TAKAKING22 ● WEBサービス開発 ● 唄って踊れるエンジニア ● 野生のアジャイラー ● 邪道スクラムマスター ● チェンジエージェント ● チームファシリテーター
あなたは熱中症になっていないか？：Crazy for life（セイカツ イチバン、IT ニバン）：エンジニアライフ
「生活イチバン、ITニバン」という視点で、自分なりのITを追及するフリーエンジニアです。ストレスを減らすIT、心身ともにラクチンにしてくれるITとはどんなものかを考えていきます。 なんという暑さだろう！ 少し前に高知県四万十市では、国内過去最高気温である41度を記録したという。首都圏でも、ここのところ殺人的な暑さが続いていて、熱中症のニュースばかりが目につく。 しかし今日ここで注意を呼びかけたいのは、猛暑による熱中症ではない。プロジェクトの円滑な進行を阻害する要因のひとつとしての熱中症だ。 ■プロジェクトの進行を阻む熱中症とは その熱中症とは、自分のタスクに没入して周囲の状況がまったく見えなくなる、というものだ。クーラーのガンガン効いたオフィスで一日中机に向かっていることの多いシステム開発プロジェクトのメンバーにとっては、こちらの熱中症にかかる可能性の方が圧倒的に高いのではないだろうか。
知らないと現場で困るバージョン管理システムの基礎知識
知らないと現場で困るバージョン管理システムの基礎知識：DevOps時代の開発者のための構成管理入門（3）（1/3 ページ） 「DevOps」という言葉にもあるように、ソフトウェア構成管理は、インフラ運用に取り入れられるなど、変わりつつある時代だ。本連載では、そのトレンドにフォーカスして、現在のソフトウェア開発に有効な構成管理のノウハウをお伝えする。今回は構成管理に不可欠ともいえるバージョン管理について、ブランチ機能を中心に紹介。SubversionからGitへの移行事例も。 いまさら聞けない「バージョン管理」とは 第3回目となる今回では、構成管理において「過去のある時点の状態をどのように復元するか」を実現するために不可欠ともいえるバージョン管理とバージョン管理システムについて紹介します。 「集中管理方式」と「分散管理方式」 バージョン管理システムとは、ファイルに対して「誰が」「いつ」「何を
山本一郎氏が語る、プロジェクト炎上のメカニズムと鎮火法
4月15日、Unity主催の公式カンファレンス「Unite 2013」が東京で開催された。ゲーム開発エンジン「Unity」は、インタラクティブな3Dコンテンツを作成するための直感的なツールとして近年急激な盛り上がりをみせており、カナダ・バンクーバーのほかアジア各国でもイベントが開催されている。今回は、東京で開催された「Unite 2013」から、山本一郎氏の「プロジェクト炎上のメカニズムと早期発見、行うべき処理の概論」をレポートする。 「炎上」とは何か？ 山本氏は、炎上を「現状のままでは時間、人員、予算を突っ込んでも求めるべき完成度が上がらないという状態」と定義する。つまり、デスマーチどころかそれ以前の状態を指す。デスマーチは皆で頑張れば何とか納品には漕ぎ着けられるが、炎上はモノが完成しない。やればやるほどチームはダメになっていき、やればやっただけ進捗がマイナスになる状態――それが、炎上で
国内におけるアジャイル開発、どのプラクティスがいちばん使われている？ IPAが調査報告書を公開
国内でアジャイル開発を普及させることを目指し、IPAはアジャイル開発の国内での活用事例をまとめた｢アジャイル型開発におけるプラクティス活用事例調査｣として、調査報告書、およびプラクティス活用のためのリファレンスガイドなどを公開しました。 IPAがこのような調査報告書を公開する背景として、「国際競争力強化のため、世界的に主流になっているソフトウェア開発手法であるアジャイル型開発に日本でも取り組む必要がある。しかし、現状、日本では「普及が遅れており、ようやく認知され始めた」段階であるとされている」と調査報告書に記述されています。 報告書では、国内の26のアジャイル開発事例についてその状況をまとめることでナレッジの集積をはかるとともに、今後の普及に向けた提言を記しています。 日次ミーティング、ふりかえり、イテレーションが国内3大プラクティス 国内でアジャイル開発の普及が阻害されている要因として、
第2回 なぜ、「技術力のないシステムエンジニア」が通用するのか？
（前回はこちら） 情報システムの構築には、多くの人手がかかります。「最大瞬間要員数100人」のプロジェクトがあったとして、100人のうち何人が顧客やエンドユーザーの顔を見ながら仕事をすることができるのでしょうか。 100名のうち半数近く、あるいは半数以上が、プロジェクトの「山場」に召集される、いわゆる「下流工程」を担当する要員です。彼ら彼女らは詳細設計書などのドキュメントが正確、かつ変更されないという前提で、その設計を実現するソフトウエア・プログラムの開発を担います。 設計書が間違っていたり、設計内容が変更されることは当然あり得ます。設計ミスを発見できる実力や、変更に迅速かつ柔軟に対応できる実力があれば、「人月単価」のアップにつながります。 ところが、設計を実現するという役割自体は固定化されています。顧客企業やエンドユーザーの顔が見える「上流工程」に関われる機会はなかなかないのが現実です。
システム開発プロジェクトはなぜ“カオス化”するのか
システム開発の多くは“カオス化”します。ぼくも年を取ったもので、システム開発でいろいろな死屍累々（ししるいるい）の修羅場を見てきた気がします。数年もかかったプロジェクトがいきなり中止になっても、もう驚かないようになりました。例えばこんなダメプロジェクト、皆さんも身に覚えはないでしょうか。 マジで10人に1人しか稼働してない 「働きアリの法則」によると、多くの労働環境では、20％のアリが働いて、80％はまじめに働きません。しかし、ひどいソフトウェア開発の現場ではもっとひどくて、だいたい10人に1人のプログラマーがバーサーカーのように働いて、それでなんとか持っているという状況も多いです。残りの人は、仕事をしてなかったり余計にバグをまき散らすだけだったりします。 RPGのパーティーに例えると、こんな感じですね。 「Lv99-せんし Lv1-あそびにん Lv1-あそびにん Lv1-あそびにん Lv
ソフトウェア開発プロジェクトの利益率とかリスク率とかのお話 | ぽんぽんぺいんなう＼(^O^)／
最近、来季（４月〜）のお仕事のお見積りの嵐。そこで気になっている話をしてみる。 ソフトウェア開発の依頼を受けた場合のお見積りの流れはこんな感じ。（数字は究極の社外秘なのでてきとーです。） １）まずは純粋に工数見積り 依頼された工程（設計・開発・単体試験・結合試験とか）について、機能毎の難易度などを考慮しながら工数を出す。 今回は１００人月（例えば１０人で１０ヶ月）だったとする。 ２）コストを試算 予定メンバーのコスト（その人の給料や手当や共通配賦（事務所の家賃や間接部門の人達のお給料をみんなで負担する分）などの合計）からプロジェクト全体のコストを試算する。 例えば、全メンバーの平均コストが５０万円／月だったとすると、コストは５０万円×１００ヶ月＝５０００万円。（そのほかの経費などもあるが省略。） ３）リスク率 今回は１００人月と見積もったけど、始めてみたら話が違ったりトラブルがあったりで１
下から目線のコードレビュー - steps to phantasien
WEB+DB の新しいやつがちょっと前にでてます. コードレビュー特集だそうな. 時が経つのは早い. まだ次の原稿書いてないのに… そういえば前にコードレビューの話を書いた気がして, 見なおしたところ かきかけ だった. せっかくなので続きを書いてみることにします. といっても何書くつもりだったか覚えてないのでだらだらと. WEB+DB PRESS の特集は, 主にこれからコードレビューを導入したい人に向けて書かれている. 幸か不幸か私はコードレビューを義務付けれたプロジェクトで働いているため, 導入には苦労していない. かわりにレビューをちょろまかせない面倒はある. ある意味でコードレビューを <やらされている>. もちろんこの言い分は大げさだ. 必要性に異議を唱える気はない. ただ異議はさておき自分の意向とは無関係にコードレビューに参加している気分を書いた話は あまり目にしないので,
アジャイル開発に踏みとどまっている人へ～段階的なアジャイルの導入とALMinium～
スクラムをテーマに、段階的導入という形で、いきなりの導入が難しいプロジェクトを徐々にアジャイル化する方法とツールALMiniumを紹介。講演は＠ITの大人気連載「ユカイ、ツーカイ、カイハツ環境！」「かんばん！～もし女子高生がRedmineで『スクラム』開発をしたら」の岡本隆史氏 スクラム、リーン開発をはじめとするアジャイル開発の広がりは止まるところを知りません。また、近年エンタープライズ分野でもアジャイル開発を本格的に導入する企業が再び増えつつあります。最近の開発手法の変化に伴い、そこで利用される開発ツール（プロジェクト管理ツール、バージョン管理ツール）などもExcelやSubversionに代わりRedmineやGitと言ったツールが注目を浴びています。 一方、アジャイルを導入しているプロジェクトと、さまざまな理由でいまだに導入できていないプロジェクト、あるいはアジャイルに挑戦したはいい
みずほ銀行のマルチベンダー化について解説する - novtan別館
はてブではすでにボロクソ言われてますね。フラグ立ちまくりと。ちょっとこれは解説せねばなるまいか… 以下はすべてとある人からの伝聞です。伝聞なんだってば。 みずほ銀行が次期システムの開発をマルチベンダー体制で進めることが日経コンピュータの取材で判明した。富士通、日立製作所、日本IBM、NTTデータの4社に分割発注する。 ［スクープ］みずほの次期システムはマルチベンダー、4社に分割発注 | 日経 xTECH（クロステック） 周知の話だけすると、現行システムにおいては 勘定系（ホスト）…富士通 営業店端末システム…富士通 インターネットチャネル（ダイレクトバンキング）…IBM 情報系システム…IBM 周辺系（中継系）…IBM 外部接続系…日立 コーポレート銀行勘定系…日立 等々、すでにここに出てきているベンダーがマルチベンダーの状態で仕事をしている。また、ここ重要なところだと思うけれども、ベンダ
［スクープ］みずほの次期システムはマルチベンダー、4社に分割発注
みずほ銀行が次期システムの開発をマルチベンダー体制で進めることが日経コンピュータの取材で判明した。富士通、日立製作所、日本IBM、NTTデータの4社に分割発注する。ハードウエアの調達とアプリケーションの開発を分離し、さらに預金や融資といった機能ごとに開発委託先を変える。大手4社に発注を分散させることで、総額4000億円を超えるとみられる大規模プロジェクトにおける技術者確保などに万全を期す。 委託内容と発注先との関係は次のとおりだ（図）。勘定系システムの中核をなす「流動性預金」のアプリケーション開発は、富士通に委託する。富士通はみずほ銀が現在使っている勘定系システム「STEPS」の開発元である。 流動性預金のアプリケーションの動作プラットフォームには、日本IBM製メインフレームを使う。みずほ銀は「CIF（カスタマー・インフォメーション・ファイル）」や「処理フロー制御」など、各アプリケーション
フレームワークの選定の仕方 - がるの健忘録
いやまぁいろいろあちこちで議論が出てきたので、まとめて。 もちろん当然ながら、以下は「おいちゃんの見解」であって、それ以上でもそれ以下でもありませんので、その辺は踏まえたうえでご覧くださいませ。 端的に「おいちゃんが個人で自分用の物を作る」んなら議論の余地もなくMagicWeapon一択で終わるのですが(笑 つまりは「おいちゃんでない人」や「個人じゃないところで」とか「他人用のものを作る」場合、それ以外の選択肢の可能性も、十分にあるわけです。 ただンじゃ「選択基準」ってのもいろいろとあろうかと思うので、その辺の指針を考える上での、考察状のポイントを少しまとめたいなぁ、と。 とりあえず「一番多くて」「一番痛い目にあう」のが「＊＊ってフレームワークは有名だしよく目にするから」。 類似品として「＊＊さんがいいって言ってたから」。「＊＊のイベントで」とかそーゆーのも同根。 なんで駄目な論拠なのかは
つっちー師に学ぶスルガ銀・日本ＩＢＭ事件
(๑╹◡╹๑) @tsuchie88 判決速報「コンピューター・システムの開発において、ベンダーのユーザーに対するプロジェクト・マネジメント義務の違反が認められた事例」東京地裁、平24.3.29民事第14部判決請求一部容認[控訴]」(金融法務事情第1952号111頁)を読み終えました #dokusho 面白かった (๑╹◡╹๑) @tsuchie88 本件は、静岡県の有力地方銀行(以下面倒なのでスルガ銀行、駿河責めの駿河ではない)と、世界的なシステム大手SI企業の日本法人(以下面倒なので日本IBM。架空戦記に出てくる国家名ではない)の間で基幹系システム開発プロジェクトの失敗をめぐって争われた訴訟である
［CEDEC 2012］「ドラゴンクエストX」における開発進捗管理法とは？ セッション「大規模開発のプロジェクト管理 〜ドラゴンクエストXにおけるマネージメント事例〜」レポート - 4Gamer.net
［CEDEC 2012］「ドラゴンクエストX」における開発進捗管理法とは？ セッション「大規模開発のプロジェクト管理 〜ドラゴンクエストXにおけるマネージメント事例〜」レポート ライター：大陸新秩序 2012年8月20日から22日にかけて，神奈川県内のパシフィコ横浜にてCEDEC 2012が開催されている。本稿では，開催初日に行われたセッションから「大規模開発のプロジェクト管理 〜ドラゴンクエストXにおけるマネージメント事例〜」の模様をレポートしよう。 「ドラゴンクエストX 目覚めし五つの種族 オンライン」公式サイト スクウェア・エニックス 開発部 ドラゴンクエストＸ デザインセクションマネージャー 荒木竜馬氏 本セッションの講師を務めたのは，スクウェア・エニックス 開発部 ドラゴンクエストX デザインセクションマネージャー 荒木竜馬氏だ。荒木氏は，「ドラゴンクエスト」シリーズや「FINA
「ソフトウェア開発プロジェクトをとりまく６つの誤解」は真実でもある - arclamp
「ソフトウェア開発プロジェクトをとりまく６つの誤解〜プログラミングを経験しないとわからないこと」に釣られてみます。 6つの誤解は次の通り。 既にあるソフトウェアを流用した方が速く作れる ソフトウェアはハードと違って後から容易に直せる 誰が作っても中身は同じ品質になる 共通部品から先に作ることが出来る 人を増やせば一度に沢山の機能が作れる 正確な見積もりを出すことが出来る 記事の前提は"お客さんはITにそれなりに詳しい（けどプログラミングはしたことがない）情報システム部門の人"ということだと思います。 この6つは誤解しやすいし、僕もお客さんと会話する内容です。でもね、お客さんがそう感じていることも事実です。なるべく安く早く、そして変更に強いシステムを作りたいと願うことは当然のことです（もちろん予算どおりに）。 ソフトウェア開発に職人的（あるいは芸術的）要素があることは間違いありませんが、それ
Scrumのプラクティスっぽくサッカーを説明する
自分、アジャイルは理論派な方です！ (実践がほとんど伴っていないの意) 昨日、Scrumのセミナーを受講したので何か書こうと思ったのだけど、五輪も始まるし、Scrumのプラクティスっぽくサッカーを説明するという思考実験をしてみることにした。自分の中では両者はかなり類似していると思うので。 サッカーというのは、足という比較的ニブイ部位でイレギュラーバウンドしうるグラウンド上のボールをコントロールするという、不確実性てんこ盛りの競技である。しかも自分たちを打ち負かそうとする相手もいて、常に自分たちの裏をかこうと我々が予測もしないようなプレーをしかけてくる。ソフトウェアの開発と同様に、予測不可能な状況の変化の頻繁な発生に対して、チーム全員で対処する。時にはリスク覚悟でのチャレンジも勝利のためには必要な場合もあるという、ソフトウェア開発を90分に凝縮したようなスポーツだと思う。(ソフトウェア開発で
終わるSIerの底辺を見てきた - ミッションたぶんPossible
ご挨拶 今月の第二日曜日は3月11日でした。言わずと知れた、あの「3.11 東日本大震災」から丸一年が経過した日です。改めまして、当時亡くなられた方々のご冥福をお祈り申し上げます。また、被災され現在も不便な暮らしを強いられている大勢の方々にお見舞い申し上げます。一日も早く元通りの日常が送れるようになることを願って止みません。 3.11の14:46、オレは代休で自宅にいるところにあの大地震がやってきました。自身が立つこともままならないような衝撃の中、不安定なテレビ台とPC棚をなんとか抑えて揺れが収まるのを必死で耐えたのは、今でも鮮明に思い出すことができます。それもあって我が家の被害は全くなく、妹も職場の方の好意で車で送って貰え、日付が変わった頃に無事帰宅できました。都内では翌日昼を過ぎても帰宅できなかった人が多かった中、我々は非常に運が良かったと思います。 はじめに さて、オレにとって、この
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
ふつうの受託開発チームのつくりかた
IDE4Laszlo