少人数開発に役立つ5つのまとめ
if ( $blog == " Webエンジニアのためのライフハック " ) { print " 1-byte.jp "; } ホーム1-byte.jpとは 書いてるヒトは ここ2ヶ月間で気になる記事がたくさん上がっていました。 特に少人数チームにおける開発に関する記事です。 昨日、書き上げた”1年間の技術的負債を返すために読んだ3冊の本“にある通り、お知らせメールでは1年間の技術的負債を返そうとしています。 そのためには今まで曖昧だった箇所を浮き彫りにし、改善する必要があります。 また、せっかくなので新しいモノも取り入れたい。 こうしたことを考えながらの2ヶ月だったので、自然と目に止まった記事が3つありました。 スタートアップ企業で8年間Webの開発をしてみての反省点いろいろ 複数人(2-3人)でウェブサービスを開発するコツ A successful Git branching m
オープンソースによる新しい受託スタイルの提案
前々回のエントリ「受託開発とGPL」では、受託開発においてGPLのソフトウェアを用いる際に注意すべき点やライセンスの扱いについて書いた。ただし、その視点はあくまでも「GPLはSIerにとって注意すべき≒厄介なシロモノであり、如何に地雷を踏まないようにするか」というものであったように思う。だが、「厄介である」という性質は、裏を返せば「味方につけると頼もしい」ということだ。つまり、GPLは、味方になれば強力で頼もしい存在なのである！今日は、SIerが今の開発スタイルから脱却し、如何にしてGPLを味方につけて戦っていくかということについて語ろうと思う。ちょっとひどい妄想夢物語的な記述も入っているのだが、「何言ってんだコイツ？！」とツッコミたいところをぐっとこらえて最後までお付き合い頂ければ幸いである。 システム全体を再構築するのは大変SIと一口で言ってもその規模は大小様々であるが、業務（基幹系）
アジャイルと受託開発
先日、永和システムマネジメント社がアジャイルによる受託開発サービスを発表し、話題になっている。多くの人の関心を引いているのは、アジャイル開発手法を取り入れるということだけでなく、その価格の安さだ。一ヶ月あたりの料金は、もっとも安いものでは月々15万円から、もっとも高額なプランでも月々150万円からとなっている。果たしてそんなので儲かるの！？というのが多くの人がいだいている疑問であろう。自分なりに「アジャイルによる受託開発サービス」について分析してみたので語ってみようと思う。なお、本エントリは永和システムマネジメント社が公開されている資料と筆者の推測に基づくものであるので、より詳細で正確な内容は永和システムマネジメント社さんへ問い合せて頂くよう悪しからず了承いただきたい。 採算割れしないのか？筆者の見解では、たぶんしない。何故か？それは一旦開発が終わったらそうそう頻繁にシステムの仕様を変更し
知るだけで天地の差が出る、テスト仕様書の必須項目＆表現方法
テスト仕様書で絶対に必要な項目リスト テスト仕様書に記述すべきものとして、以下の事項があります。 テストを実施した環境 実施するテストの内容 テストを実施するためのシステムの操作手順 テストの実行結果 個々のテスト項目を識別するための番号や記号（通し番号など） テストを実施した年月日 テストを実行した担当者 障害報告票番号（発生した障害の詳細を開発グループに報告する帳票の識別番号） まずはテスト環境について明記する テスト仕様書の先頭には、「テストを実施した環境」を記述します。ここでは、ハードウェア環境やソフトウェア環境、ネットワーク環境など、「どのような環境でテストを行ったか」を説明します。 ただし、テストを実施した環境を記述するだけでは十分ではありません。「顧客にとって必要な情報は何か」を考えるのです。ここで必要なのは、「要件定義書で規定した環境」との関係が分かることです。 なぜなら、
UML アクティビティ図: ガイドライン
Live dependency validation Removing unwanted dependencies is an important part of managing your technical debt. Visual Studio provides live validation of dependencies, including precise information about issues, such as where they are located. Live dependency validation takes full advantages of new features in the Error List and the editor. The authoring experience has changed to make dependency v
Linuxクラスタリング多様化するクラスタ方式
現在では、コンピュータを導入していない企業はないといえるほど、私たちの業務はコンピュータに依存しています。また、インターネット利用による新しいビジネスは、コンピュータがあればよいというものではなく、いかにサービスを提供し続けるかが成功のための重要なカギとなります。例えば、1台のマシンが故障や過負荷によりダウンしただけで、顧客へのサービスが全面的にストップしてしまうことがあります。そうなると、莫大な損害を引き起こすだけではなく、顧客からの信用を失いかねません。 このような事態に備えるのがクラスタシステムです。クラスタシステムを導入することにより、万一のときのシステム稼働停止時間（ダウンタイム）を最小限に食い止めたり、負荷を分散させることでシステムダウンを回避することが可能になります。 「群れ」「房」の言葉どおり、クラスタシステムとは「複数のコンピュータを一群（または複数群）にまとめて、信頼性
シーケンス図で処理の流れを整理！
シーケンス図の概要 本連載では、Google Android（以下、Android）を使った携帯アプリ作成を例に、マインドマップやUMLによる設計について学んでいきます。前回はクラス図を使ってプログラムを整理する方法を紹介しました。今回はシーケンス図を使ってプログラムの処理の流れを整理する方法を紹介します。 クラス図はプログラムの構造が複雑になった時に非常に役に立ちます。ただしプログラムの構造が複雑になった時は、たいてい処理も複雑になっているものです。クラス図はプログラムの構造を整理するのには向いていますが、処理の流れを表現することができません。こういった時に役に立つのがシーケンス図です。 シーケンス図はオブジェクト同士の動的側面をとらえるための図です。描き方はまずオブジェクトを四角で囲み、左から右に順番に配置していきます。次にそれぞれのオブジェクトに生存線を引いていきます。生存線が引けた
スクラム組んで開発しよう！ | オブジェクトの広場
今回の記事では, プロジェクト管理に特化したアジャイル開発手法であるスクラムの概要を説明します. また, スクラムによる開発が成功する理由を説明するための理論的なバックボーンとして引用されている知識創造プロセスやコンテキストの概要を紹介します. さらに, 20 名程度の中規模開発チームにおいてスクラムを適用し, 開発に成功した事例を紹介し, その中で知識創造プロセスやコンテキストが生まれたのか否かについて考察します. 1. スクラムとは 1.1 スクラムの価値と理論的な基盤 スクラム [1] は, Ken Schwaber と Mike Beedle によって考案されたアジャイル開発手法です. スクラムという開発方法論の名称は, ラグビーのスクラムにちなんで名づけられたそうです. スクラムは、Schwaber らがいくつかの失敗プロジェクトを立て直す経験を通じて生み出されたとされています.
内製開発を考えているSI技術者が知っておくべき内製アンチパターン - aike’s blog
数年前から、ゼネコン的なSIerの業態に構造的な限界を感じ社内のエンジニアによる自社開発（内製）を見直す動きが見られます。自分の場合も少し前にSI企業を辞めて今は内製をしていますし、知り合いの技術者にも何人かそのような転職をした人がいます。しかし、彼らの話を聞くと良いことばかりではないようです。 そんなわけで、今回は内製に潜むアンチパターンをまとめてみました。なお、ここでは一般向けプロダクト開発ではなく、社内向け業務システムの開発を想定しています。 ■そこは異業種ですよ 内製ということは、ほとんどの場合その会社はシステム開発会社ではなく、異業種に転職することになります。そのため想像以上に開発の常識が通じないことにとまどう技術者も多いようです。SIのとき、システム開発に理解がないゆえに無茶を言う顧客にあたった経験があるかと思いますが、自分以外の社員が全員そのような人であるおそれもあります。
日本のソフトウェア産業は「製造業」 - My Life After MIT Sloan
これは、MIT SloanのCusumano先生が本でも授業でもよく言ってる話。 面白いから忘れないうちに書き記しておく。 Cusumano先生は、Microsoft SecretやPlatform Leadershipで有名なソフトウェアビジネスの研究者。 日本の企業研究も色々されているし、一橋大学のビジネススクールで何年か教えてらしたりした日本通でもある。 そのCusumano先生が、ソフトウェア産業への取り組み方を比較して、こんなことを言っていた。 Europe: Software as a science －ヨーロッパにとってソフトウェアは「科学」 Japan: Software as production －日本のソフトウェアは「製造業」 India: Software as a service －インドのソフトウェア産業は「（プロフェッショナル）サービス」 U.S.: Soft
Webアプリの問題点を「見える化」する7つ道具 (1/3) - ＠IT
今回の概要 システムが応答しない、パフォーマンスが劣化したなどのトラブルが発生したときに、原因がなかなか掴めず、あたふたすることはないだろうか？ 本稿では、Java EEトラブルシューティングの現場で役立つ7つ道具を紹介する ある日、突然電話が鳴る 用件は、「システムが不定期に停止する。よく分からないけど、どうやらJava EE部分がおかしい」とのこと。このような事態が発生したとき、やみくもに原因を調べ、いつまでたっても問題が解決できず、原因の一片も発見できないことが多々ある。 トラブルが発生した場合、ツールが充実していない昔は、開発者の経験と勘に頼るところが非常に大きかった。Webシステムが普及するいま、昔とは比べ物にならないほど、システムの数が増え、開発者数が増える一方、システム障害を切り分けられる職人的なエンジニアの人数はシステム数に比例して増えているわけではない。そのため、すべての
クックパッドのデータ処理、たった5万円：日経ビジネスオンライン
気になる記事をスクラップできます。保存した記事は、マイページでスマホ、タブレットからでもご確認頂けます。※会員限定 無料会員登録 詳細 ｜ ログイン 月間ユニークユーザー数、884万人、月間ページビュー数、4億6000万（2010年3月）を誇る国内ナンバーワンの料理レシピの投稿・検索サイト「クックパッド」。 日常的に料理をする人はもちろんのこと、たまにしか包丁を握らない人でもクックパッドのウェブサイトを一度は訪れたことがあるのではないか。 2ちゃんねるやTwitterを凌駕する それくらい、クックパッドはレシピの投稿・検索サイトとして不動の地位を築いているように思える。なにしろ、母の日とカミサンの誕生日くらいしか、料理をしない筆者でさえも、クックパッドは何度かのぞき、お世話になったことがあるくらいだ。 ページビュー数の比較でいえば、この4億6000万という数字は、2ちゃんねるや今流行りのT
開発プロセスの最適化手法 | オブジェクトの広場
※本稿は、株式会社アイ・ディー・ジー・ジャパン発行の 『ITアーキテクト vol.1』に掲載された「開発プロセスの最適化手法」の元原稿をITアーキテクト編集部の許諾を得て公開したものです。 ※一切の転載をお断りします。 はじめに 筆者らが、オージス総研で「オージステーラリングサービス」という開発プロセスのコンサルティングサービスを行う中で、ユーザー企業の情報システム部門のお客様からは「開発委託先が何をやっているのかわからない」という相談をよく受ける。一方、SIerやソフトハウスのお客様からは「Javaにも慣れたがソフトウェアの品質が一向によくならない」といった相談もよく受ける。どちらも開発組織に明文化された開発プロセスが無いことが原因で、プロジェクトの利害関係者から開発側の活動が見えなくなったり、開発側の品質の改善が進まなくなったりしていることが多い。また「以前、市販の開発プロセスを導入し
セールスフォースが「Force.com vs Windows Azure」ビデオを公開。クラウド開発環境の明日はどっちだ？
セールスフォースが「Force.com vs Windows Azure」ビデオを公開。クラウド開発環境の明日はどっちだ？ 米セールスフォース・ドットコムが、自社で提供しているクラウドでのアプリケーション開発環境であるForce.comの優位性を示すために「Force.com vs Windows Azure」という動画をYouTubeに先週投稿しました。 その動画では、Windows Azureは申し込みからアプリケーションのデプロイが終わるまで、1時間以上かかる12ステップ以上もの作業を行わなければならないのに対し、Force.comならばわずか数ステップのみの2分程度でまで済んでしまう、という点を主に訴えています。 まずは動画から、Windows Azureのステップを見ていきましょう。 Windows Azureでアプリケーションをデプロイするには、申し込みのあとSilverlig
第2回 プロジェクト計画――システム開発プロジェクトの「計画」を作成する：ITpro
プロジェクトマネジメントで最初に行うべきことは，プロジェクト計画の策定だ。品質，コスト，納期，さらには顧客満足度の観点から，プロジェクト全体の範囲やスケジュール，コスト，組織・要員を明確化する。この計画をどれだけしっかり練り上げるかが，プロジェクトの成否を左右する。 布川 薫／日本IBM 前回はPM（プロジェクトマネジメント）の概要を述べた。今回からは，いよいよ日本IBMの方法を基に，情報システム開発プロジェクトに特化したPM技法の詳細な解説に入る。 日本IBMにおけるPM実践体系では，PMで行うべきプロセスを「プロジェクトの計画」，「トラッキングとコントロール」，「リスク管理」，「契約管理」の4つに分類していることは前回に述べた。今回は，PMのプロセスで最初に実施する「プロジェクトの計画」について概要を解説するとともに，情報システム開発プロジェクトでは特に重要な作業である「開発工程の定義
完了報告書の作り方
誰が誰に何のために報告するのか。これを意識することが報告書の内容を考えるうえで重要である。 完了報告書を作成する役割は，プロジェクト・マネージャが担うケースが一般的である。システム開発プロジェクトでは発注側であるユーザー企業と受託側であるベンダーの双方にプロジェクト・マネージャが存在するが，どちらのプロジェクト・マネージャが誰に対して報告するのかによって完了報告書を書く目的は少々異なってくる。その報告者と報告先は下記の三つのパターンに分けることができる（図1）。 A.ユーザー企業のプロジェクト・マネージャが経営者や上長に報告する B.ベンダーのプロジェクト・マネージャがユーザー企業に報告する C.ベンダーのプロジェクト・マネージャが自社の経営者や上長に報告する Aの場合の完了報告書の主な目的は，経営者や上長が決断したシステム投資に対して，担当者として説明責任を果たすということである。システ
COBOLこそスピード経営に必要
家電通販最大手のジャパネットたかた。同社における開発言語のメインはCOBOLだ。通信販売で取り扱う商品は日々追加され、客先でのセッティングといった付帯サービスも多様化している。情報システムを統括する星井龍也専務執行役員は、「こうした状況変化に迅速に対応するためには、COBOLの高い生産性が必要だ」と語る。（聞き手は井上英明＝日経コンピュータ、写真は林田大輔） メインの開発言語にCOBOLを据えていると聞く。 2008年1月、基幹システムをメインフレームからUNIXサーバーにオープン化するプロジェクトを開始する際に、「当社はメインの開発言語をCOBOLとする」と宣言しました。26人いる情報システム部員の全員が、COBOLを読み書きできるようにしています。それまでは、COBOLを読み書きできる部員は3人だけでした。 当社のシステムにおいて基幹となるのは、販売管理システムです。お客様からの注文や
知っておきたいテストの“イロハ”（1）：ITpro
テストの基本的な知識は、あまねくITエンジニアが持つべきだ。しかし実際には、本当に基本的な知識でさえ浸透していないのが現状である。そこでこの記事では、ITエンジニアが最低限知っておくべきテストの基本知識と、その活用方法を解説する。 社会的なインフラとして構築された大規模システムで，大きな障害が多発している。こうした問題を防ぐためにも，高品質なシステムを開発する必要性がますます高まっていることは言うまでもないだろう。 システムの品質を向上させるためには，しっかりと設計を行い，それに基づいて正しく実装する必要があるのはもちろんだが，最終的にはシステムを動作させてテストするしかない。 テストで品質を検証するためには，周到なテスト計画やソフトウエアの特性に合わせたテスト設計，効率的なテスト管理が必須となる。そのためには，品質管理の担当者だけではなく，プロジェクト・マネジャーやリーダー，SEにも，テ
第1回 複雑さを捨てて使いやすさに徹したEJB 3.0
今，Enterprise JavaBeans（EJB）の新しいバージョンであるEJB 3.0が技術者の注目を集めています。これまで複雑で扱いにくいと批判されてきたEJBが，今回のバージョンアップでその批判に応えて大きく変わろうとしているからです。 EJB 3.0の仕様の最終リリースは2006年第1四半期に予定されています。本稿執筆時点（2005年12月11日現在）では最終リリースはまだ行われていません（6月現在Final Releaseあり）。しかし，現時点でドラフト段階の仕様に対応したEJB3.0の実装がいくつか公開されています。 この連載では，米JBossが開発した「Embeddable EJB 3.0」という実行環境を使い，EJB 3.0の新しいプログラミング・モデルを紹介します。EJBを使ったことがある方もない方も，ぜひEJB 3.0の新しいプログラミング・モデルを体験してください
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
CoolCoding.com is for sale | HugeDomains
