データベースとSQLの業務スキルレベル 判別表 （５段階） - 主に言語とシステム開発に関して
スキルチェックの目次へ リレーショナル・データベースを利用したシステム開発の，簡易スキルチェックのための調査表。印刷用。 データベース・エンジニアのレベルを測定する。 レベルは，０から４までの５段階。 （０） 非エンジニア （１） 初学者（入門書を学習してゆく段階） （２） ノーマル（基礎的な知識があり，ある程度の動くものを作れるようになった段階） （３） 中級者（開発プロジェクトで１人月としてカウントできる水準） （４） 上級者（メインPG/メンターとして，主設計を任せられる水準） Webアプリのプロジェクト開始時に作業振り分けをするにあたって，新規メンバ全員にこれを渡して回答してもらうという用途を想定。 なお，開発上のスキルをチェックする事が主眼なので，DBAとしての技量はあまり考慮しない。 下記で「自分に当てはまる項目が最も多いレベルが，自分の属するレベルである」とする。 ※ただし，
高速開発を支えるDMMプラットフォームの作り方 ～DMM.makeの場合～
Datapaloozaで発表した資料です。 http://www-01.ibm.com/software/jp/events/analytics2/ 現在、DMM.com ラボでは、1日あたり1億レコード以上の行動ログを中心に、各サービスのコンテンツ情報や、地域情報のようなオープンデータを収集し、データドリブンマーケティングやマーケティングオートメーションに活用しています。本発表では、DMM.comのビッグデータ基盤について紹介し、ビッグデータを処理するためのSQLの活用について発表します。特に、代表的なSQL on HadoopのプロダクトであるHiveやSparkSQL, Prestoの活用事例や、Sqoopを用いたRDBとの連携について、具体的な事例や導入時の注意点を解説し、現状の課題と今後の方針についても紹介します。
リモート勤務に使えそうなツール10選（2014/11更新）
2016年版はこちら↓ リモート勤務に使えそうなツール10選（2016年版） – K blog 今年はリモートワークが来る、はず プログラマーなら誰もが一度は 「自宅ならもっと集中して作業できるのに」 と考えた事があるはず。今までは願望に過ぎなかったのが、最近では、結構実現している会社が増えているし、「強いチームはオフィスを捨てる: 37シグナルズが考える「働き方革命」」なんて本も出たし、安倍政権もテレワーク推進を謳っていて、個人的には 「今年はリモートワーク（テレワーク、遠隔勤務）が本格的に来る！」 って気がしている。 自分自身、最近は自宅で仕事をさせてもらうことも増えてきてるんだけど、インフラ・ツールの発達により、それほど不便も感じていない。 今回は、そんなリモートワークをするのに必要、あるいはあると便利なツールを10個紹介する。実際の所、10個のうちの大半はリモートワークじゃなくても
Sqwiggle が良いという話、またはリモートでアジャイル開発をどう進めるか - naoyaのはてなダイアリー
KAIZEN platform Inc. は、新しい働き方をいろいろ試してみようという会社でそのひとつにリモートワークがある。リモートワークの良さあるいは良くないところについては、以前に Rebuild.fm の ep.32 でも話した。 ちかごろは、オンラインミーティングのための道具、情報共有のための道具もクラウドサービスがたくさんあるので、その辺を使って工夫すれば一昔前に比べてだいぶリモートワークも現実的になってきている。実際、KAIZEN には大阪からリモートワークしている人とか、最近リモートワークを前提に都内から鎌倉に引っ越したメンバーなんかもいる。 リモートワークとアジャイル開発 HipChat、Google Hangout や Qiita Team なんかを使うことで、日常の会話、ミーティングや情報共有についてはもともと特に困ったこともあまりなかった。特に Qiita Team
自動改札機の運賃計算プログラムはいかにデバッグされているのか？ 10の40乗という運賃パターンのテスト方法を開発者が解説（中編） － Publickey
自動改札機の運賃計算プログラムはいかにデバッグされているのか？ 10の40乗という運賃パターンのテスト方法を開発者が解説（中編） 9月12日から14日のあいだ、東洋大学 白山キャンパスで開催された日本科学技術連盟主催の「ソフトウェア品質シンポジウム 2012」。オムロンソーシアルソリューションズ 幡山五郎氏の講演「自動改札機ソフトウェアの品質向上の取り組み 厳密な仕様、もらさないテストを目指して」。この記事では、そのダイジェストを紹介しています。 本記事は、前編、中編、後編の3部構成です。いまお読みのページは中編です。 自動改札機の制御は1000件くらいのテスト さて、次は間違えない自動改札機の話です。ここからソフトウェアの話になります。 1つは運賃計算。この切符はこの駅で降りられるのか、というもの。そしてもう1つは自動改札の制御。ランプを光らせるとか、切符を回収するとかです。 まずはその
GitHub時代の開発委託とは？ デブサミでQA@ITの事例の話をします - QA@IT公式ブログ
2013年2月14日と15日の2日間にわたって東京・目黒で開催されるDevelopers Summit 2013（デブサミ2013）の1セッションで、QA@ITの委託開発の話をさせて頂くことになりました。 ソーシャルコーディング革命後の開発委託の世界〜QA@ITの事例（仮） 私はこれまでいつも、デブサミは取材記者という立場で見て来ました。記者として取材して、例えば以下の様な記事を書いて来ました。聴衆に混じって講演を聞く側だった私が、まさか話す側に回ることになるとはと、今からドキドキしています。 デベロッパーズ・サミット2008：すばらしいソフトを作るには、カリスマが講演 未来の言語は「APL」？ Rubyのまつもと氏が講演 IIJのRuby対応PaaS「MOGOK」は、どんなサービスか？ さて、デブサミは開発者のイベントですが、私は委託側、つまり受託開発における「お客の声」ということでお話
著作権／アジャイル開発契約のウソ・ホント
システム開発をめぐる契約は、年々複雑さを増している。クラウドを使ったシステム開発やアジャイル開発のプロジェクトなど、開発手法や技術の変化で契約の仕方が分かりにくい場面が増えている。開発契約に携わる法務担当者や現場担当者、弁護士などへの取材を基に、今現場が知っておくべき開発契約の知識を、「ウソ」と「ホント」で解説する。 今回は、共同開発したSaaSの著作権と、アジャイル開発の契約における「ウソ」と「ホント」を取り上げる。 共同開発したSaaSの著作権は発注者が持つ 著作権は発注者と受注者が協議して、どちらかあるいは両者が持つことを決める。SaaSの場合は受注者が持つことが多い。 複数のユーザー企業が共同利用するSaaS（Software as a Service）の開発を委託する事例が出てきた。このような場合、発注者と受注者が協議して、成果物の著作権をどちらかあるいは両者が所有するかを決める
SI屋さんとSIと、直近の課題について。 - 急がば回れ、選ぶなら近道
某セッションでちょっとしゃべったことをつらつらと。SIの現状と近い将来について思うところをまとめておきます。自分自身の立ち位置も確認していくという意味で。 結論的にいうと、SI自体は必要とされていますが、SI屋さんのビジネスモデルは成立しないという状況になるので、旧来の「SI屋さんの方法」ではうまくいきません。なので、別のやり方でSIをどうやっていくか？という議論が必要になりますね、という話です。 まずSI事業は人月稼働で商売をしています。スタート地点はそうではなかったのですが、一旦大きな人数を抱えると、食わせる必要があるため、より大きな仕事を取る羽目になります。要は稼働させる事、それ自体が目的になります。稼働を維持させる事で、収入を確保する事ができ、確保された収入で稼働のための人員を維持できる。そもそもそういう循環をベースに組織の目的が、「結果として」形成されてしまっています。 副作用と
WEBシステム開発の値段
1 名前:以下、はてなにかわりまして元増田がお送りします。 投稿日:2012/02/23 11:49:47うちの団体で、インターネットで講習会を申し込めるようなシステムを作ることになって、ネットで調べた何社かに見積りを頼んだら、出てきた金額が業者によって２５万～４００万で出てきた。 見積りの項目も各社バラバラだしそれぞれの意味も、なにがなんだか素人の俺にはさっぱりわからない。 年間に１万人ぐらいが100会場でやる研修の申込みを受付けられるようにするってだけの機能なのになんで各社こんなにもバラバラなのかが理解不能。 若いってだけでITに詳しいと思われて、担当にあてがわれて、２５万～４００万の間で業者決める手掛かりが全くない状態でどうすればいいんだ？（それでもし業者選びに失敗したらやっぱり俺のせいなのかな。。） 続きを読む
開発時に。送信内容が確認できるダミーのSMTPサーバ·smtp4dev MOONGIFT
smtp4devはWindowsローカル上に立てるダミーのSMTPサーバです。 システム開発においてメール送信を行う時はよくあります。SMTPサーバを立てたとして、間違って送信してしまうと大変な事態につながるかも知れません。そこで使ってみたいのがローカルで使えるダミーのSMTPサーバ、smtp4devです。 起動しました。まずはセキュリティ警告が出ます。 メイン画面です。この時点でポートは開いています。 オプションです。UIに関する設定です。 サーバ設定です。ポート番号はデフォルトで25です。 アップデートチェッカーもあります。 こんな感じで常駐します。 こんな感じでPHPからメールを送ってみます。 送信しました。すぐに反映されます。 さらに日本語件名のメールを送ってみました。文字化けせずに送信されています。 メーラーでメールの内容を確認できます。 さらに詳細を確認できます。 メッセージソ
ソフトウェア技術者軽視のシステム開発を続けるのはもう限界かもしれない - 達人プログラマーを目指して
つい先日、富士通がグループで抱える3万人ものSEを再教育して、職務転換を行う計画であるというニュースを知りました。 富士通の3万人SE職務転換大作戦は成功するのか？ - GoTheDistance 一つのシステムを複数の企業などが利用するクラウドサービスがこのまま普及すれば、顧客の要望を聞いて個別システムを作り込むＳＥは仕事がなくなり、余剰人員問題が顕在化するからだ。 クラウドの普及により、オーダーメイドでシステムをゼロから構築する必要がなくなり、そもそも顧客からの要件をまとめてシステムを設計するSEの仕事が不要になったり、基盤を構築、運用するエンジニアが不要になるということは、最近になってよく言われることであり、特に新しいことではありません。もちろん、クラウドの普及によって、これらの伝統的なSEの仕事が少なくなり、人員が余るという議論は間違いではないと思います。 ただし、一方でより本質的
「規模見積もり」が消えてしまう？
システム開発プロジェクトでは通常、事前に「何を作るか」を検討する。この作業を一般に「規模見積もり（Sizing）」と呼び、その結果が成果物スコープとなる。規模の単位はファンクションポイント（FP）やステップ数（LOC：Line of Code）、ユースケースポイントなどだ。しかし最近、この「規模見積もり」が消えてしまうのではないかと、危機感を募らせている。 なぜこんなことを思うようになったのか。それは、クラウドサービスを使った開発や、アジャイル開発が広がりを見せているからだ。これらはスピード重視の開発だけに、作りながら実装すべき機能を詰めていくことが多い。つまり、何を作るかという規模見積もりに相当する作業を、工程の中に組み込んでいるとも言える。 「それならそれでいいではないか」と思う人がいるかもしれない。実際あるベテランのプロジェクトマネジャーは「何を作るかを考えるのが上流工程の役割。要求
アジャイルの人たちは自分の優秀さに気づいていない - 設計者の発言
アジャイル手法を実践できるプロジェクトは恵まれている。それは、「理解ある管理者」がアジャイル手法を了承してくれたからではない。管理者がそう判断できるほどに参加メンバーが優秀だからだ。 アジャイルの特徴のひとつが「少数精鋭」である。いっぽう、アジャイルの対立手法として理解されているウォーターフォール型手法では「人海戦術」で進められる点が対照的だ。じつは「少数精鋭」というのはアジャイルの特徴であるだけでなく、あまり触れられたくない弱点でもある。なにしろ「精鋭」しか関われない。 しかしアジャイル手法の推進者は、自分が優秀であることをそれほど意識していない。それどころか彼らは「いえいえ精鋭である必要はありません。じっさい私はアジャイルが大好きですが、凡庸な技術者ですよ」と自嘲的に語るだろう。そしてそれは本心でもあるだろう。なぜなら、彼らは「超」がつくほど優秀な技術者たちがいることをアジャイルコミュ
キャプション直すだけで数万円？システム開発の値段が高くなる３つの理由とは | Social Change!
今のシステム開発の業界における価格は、実はその提供している価値に対して、コストが高すぎるのではないか、と以前から考えていました。IT投資に対するパフォーマンスの比率が著しく悪い、摩擦係数が異常に高い気がします。それが何故なのかを考えてみました。（今回は問題提起だけなので悲観的なようですが、別途私の提案編を書く予定です） 色々なお客様とお話しさせて頂くと、かなりの予算投資をしてシステムを構築した後に、実際に使い始めると修正したい箇所が出てくるもので、その改修をベンダに依頼すると想像以上の金額の見積りが返ってきて驚いた、という話をよく聞きます。 実際に、画面の一部のキャプションを少し直すだけでも、数万円とかの見積が出てきた、というのも大袈裟な話ではないのでしょう。そんな経験をしてしまうと、より一層に構築時に確実に作って、改修しなくて済むように、と考えてしまっても仕方ありません。 また、システム
人月計算とExcelとスーツの世界より
俺の住む世界はアイティーとやらに支えられているらしい。 アイティーに関われば、俺の住む世界をさらに素敵なものにしていけるに違いない。していきたい。 そう願って、何も知らなかった文系新卒の俺が金融系のシステム会社に入って、もう一年以上が経つのだ。 昔、お遊びでゲームを作ったことはあった。RPGツクールなんかが好きだった。 だから自分はシステム会社に向いていると思った。 実際、資格取得を勧められて始めた勉強は楽しかった。 浮動小数点数、オートマトン、SQL、スタック、木、論理式。 パズルみたいで楽しかった。コンピュータの中身が理解できて、わくわくした。 楽々と基本情報技術者の資格を手にし、半年後にはほとんど勉強もせずにソフ開も取得した。 研修の課題では同期の誰よりも速く、短く効率のいいソースを仕上げた。 現場に出て、本番機に触った。 ３０年間親会社を支え続ける偉大なシステムの中身を、わくわくし
まとめ：なぜ人月見積がダメか - Zerobase Journal
社団法人日本情報システム・ユーザー協会(JUAS)発行の『ソフトウェアメトリックス調査2007』を取り寄せて読んでみましたよ。SI関係の人は必読ですよね。私はいままで知らずに損していました。 そんなこともあり、年の瀬でもあり、今回の記事では表題の件「なぜ人月見積がダメか」について、現時点での総括をします。 人月見積方式の弊害に対する言論 「ユーザー企業は出席をとるな」，日本IBMの大歳社長が提言：ITpro (2001/08/31) 「日本の商慣習でぜひとも変えて欲しいのは，ユーザー企業が我々の技術者の出席をとることだ。出席をとられると我々は開発の生産性を挙げようとする努力をしなくなる。1000人でできる仕事を500人でやってのけると，売り上げが半分になってしまうからだ。技術者の頭数ではなく，成果物について対価を払っていただける商慣習に変えていくよう，広く呼びかけたい」。日本IBMの大歳卓
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
ふつうの受託開発チームのつくりかた