フロントエンドのパラダイムを参考にバックエンド開発を再考する / TypeScript による GraphQL バックエンド開発
開発組織のマネジメント
フロントエンドのパラダイムを参考にバックエンド開発を再考する / TypeScript による GraphQL バックエンド開発
ソフトウェア開発プロセス残酷物語 - give IT a try
昔々、あるところにジェイソンという、大変真面目な開発者がおりました。 彼がとある会社の情報システム部にやってきたとき、彼は社内システムのクオリティのひどさに衝撃を受けました。 情報システム部といっても、その会社では外注はせず、社内の開発メンバーがシステムを作っていました。 ジェイソンがそこで最初に担当したシステムは、見事なまでのスパゲッティコードでバグだらけ、データ設計も素人レベルでパフォーマンスも最悪、エラー処理もずさん、おまけにまともなドキュメントもなく、ちょっとした障害を調査したり、小さな改造を実施したりするのにも、大変な苦痛を伴うという、それはそれは大変なシロモノでした。 このシステムは元々エセーグルという、ちょっと変わった名前の開発者によって作られていました。 しかし彼はすでに別の開発チームに異動していて、こちらの質問には答えてくれますが、もはや本人が直接手を動かすことはありませ
技術/組織としてどうスケールするか at GitHub - yaotti's diary
会社をスケールさせていくために組織面，技術面で何を行ってきたか．以下簡単なまとめ 組織面 従業員をよりhappyにするために，面白い仕組みを導入している．ミーティングがない，オフィスに来なくても良い．やりとりはpull requestとcampfire． 他にも組織として強くなるために，個人に依存しすぎない(知識共有を促進する)，internal talk(tech talkみたいなのかな?それとも普通の会話?)は将来の従業員のために全て記録する*1，など． 技術面 自動化可能なことを手作業でやり続けることによるコストは，手間だけではない．新規メンバーに学習コストが発生することになる． masterブランチは常にデプロイ可能な状態に保ち，1日に5~30回デプロイを行なっている． 意味のあるメトリクスをグラフ化しよう．全体でのレスポンスタイム平均がXXXms，というのは意味がない． リリース
11の「やめたこと」で実現した1000万ダウンロード突破【スマホ2011冬】 - 日経トレンディネット
NHN Japan スマートフォンゲーム制作室 室長の馬場一明氏。「自分はいつも焼肉屋に行くと食べ過ぎてしまう。自分の食べる量も分からないのに、他人の作業量が分かるわけがないので、作業量の見積もりは不要」とのユーモアあふれる例えに会場は笑いにつつまれるシーンも 12月14日、スマホ関連総合カンファレンス「スマートフォン＆タブレット2011 冬」（ベルサール八重洲）の「ゲーム開発」セッションでは、NHN Japan スマートフォンゲーム制作室 室長の馬場一明氏が登壇した。『ダーツ』や『フォトジグソー』など、直感的に遊べるアプリ「TEIBAN GAME」をいかにクオリティーを維持しながら、短期間で多数開発し、ヒットに結び付けたか。その舞台裏と独自の組織論を披露した。 これまでPCオンラインゲームを手がけてきた馬場氏が、スマホゲームアプリの開発を命じられたのは、東日本大震災直後の今年3月。出され
オフェンシブな開発〜「納品しない受託開発」にみるソフトウェア受託開発の未来 | Social Change!
定期的にSI業界が終わったという話が出ますが、本当にそうでしょうか。終わるべきは一括発注・請負のディフェンシブなビジネスモデルです。受託はなくなることはありません。ソフトウェアの開発を、他の業界のアナロジーで考えるのではなく、正面から取り組んだビジネスモデルについて語っています。 ディフェンシブな開発 今から5年前に、SI業界における多くの問題の原因がそのビジネスモデルにあるという「ディフェンシブな開発〜SIビジネスの致命的欠陥」という記事を書きました。SIにおけるビジネスモデルは、発注者とベンダーはあらかじめ決めた金額と要件の中で納品と検収を目指すため、利益を出すためには双方がリスクを取らずに「守り」に入る必要があります。その結果、顧客にとって価値を産むかどうかよりも決められた要件通りに作られることを重視することになってしまいます。人月という単位であらかじめ決めるとなれば、単価の安い下請
開発者にやさしい環境
ikeike443と申します。このブログの言いだしっぺです。 シャノンに転職してきてちょうど1年になります。前職は業務パッケージソフトの会社に所属していました。 転職してきた経緯などについては、下記のインタビュー記事で話したので、よかったら読んでください。 SaaSの可能性を信じて、新たな道を踏み出したエンジニアの「視点」 で、今回はとりあえず、シャノンに入社してこれは”いいね”と思ったポイントをつらつらと挙げてみます！ アジャイル開発やってるよ 開発方法論としてはアジャイル開発手法の一つ、Scrumを採用しています。 約一ヶ月をひとつのスプリントとみなして、毎月頭にスプリントの計画と見積りをして開発／テストに入ります。 毎朝のミーティングでバーンダウンチャートを確認し、文字通りみんなでスクラムを組んで開発しています。 バーンダウンチャートの作成、プロダクトバックログの管理には、ヌーラボさ
開発と運用の新しい関係、「DevOps」とは何か？ － Publickey
このところ海外のIT系の記事で「DevOps」という言葉を見る機会が増えてきました。スペルからすると、開発＝Developmentと、運用＝Operationを組み合わせた言葉らしい、という程度の認識でしたが、どうやらアジャイル開発やソフトウェアの品質にかかわる新たなムーブメントとして認識しなければならないかも、と感じはじめています。 そこで「DevOps」とは何か？ について調べてみました。 DevOpsとは開発と運用が協力し、ビジネスリスクを軽減する まずはWikipediaの「DevOps」の項目から冒頭の部分を読んでみましょう（2011年3月8日現在の記述）。 DevOps is a set of processes, methods and systems for communication, collaboration and integration between depar
開発とテストの融合こそゴール。続、グーグルはあれほど多くのソフトウェアのテストをどのように行っているのか？
開発とテストの融合こそゴール。続、グーグルはあれほど多くのソフトウェアのテストをどのように行っているのか？ グーグルでTest Engineering Directorを務めるJames A Whittaker氏が書いたエントリを紹介した先日の記事「グーグルはあれほど多くのソフトウェアのテストをどのように行っているのか？」が非常に好評で、「続きがあれば読みたい」というコメントをいただいていました。 Whittaker氏がそのエントリの続き「How Google Tests Software - Part Threeを公開していますので、ご要望に応えて紹介することにしましょう。 品質は開発の問題であってテストの問題ではない 品質とはどのように実現するものなのか？ という問いに対して、Whittaker氏は次のように書いています。 The simple solution to this con
「少人数のチームの方がソフトウェアの品質は高い」実証的ソフトウェア工学の研究会が開催
統計や実証を通してソフトウェア工学を研究していく、それが「エンピリカルソフトウェア工学」（Empirical Software Engineering、実証的ソフトウェア工学）です。「第一回エンピリカルソフトウェア工学研究会」が、12月10日に都内で開催されました。 基調講演では、マイクロソフトリサーチで研究をしているDr. Thomas Zimmermann氏が登壇。開発組織の構造がソフトウェアにどう影響するのか、バグ報告書やバグ報告者と修正されるバグの優先順位の関係、そしてエンピリカルソフトウェア工学という「データ指向のソフトウェア工学」を、どのようにソフトウェア開発における意志決定に役立ていくのか、といった内容の講演でした。 開発組織の構造がソフトウェア品質に及ぼす影響は？ マイクロソフトリサーチのDr. Thomas Zimmermann氏。 今日はいくつかのテーマについて紹介した
基礎教育: 柴田 芳樹 (Yoshiki Shibata)
新任管理職向けの教育の中で、高橋俊介氏の講演がありました。高橋氏の講演を聴くのは初めてでしたが、いろいろと考え直す良い機会でした。高橋氏の話の中で、日本企業は、新卒新人に対して必要な教育を行うことなく、高度な仕事をさせて、本人はメンタル的にだめになっていくという話がありました。 ソフトウェア開発に関して言えば、本来なら大学で基礎的な事柄を学んでいてもらいたいですが、実際には、コンピュータに関する基礎知識もなく、プログラミング経験も乏しい学生を採用したりしています。そして、技術教育担当グループが最初に集合新人教育を行うのですが、これが役に立たないことが多いです。 なぜ、役に立たないかというと、ある期待レベルに達するのに要する時間は、個人差があるにもかかわらず、教育スケジュール通り教育が終わってしまう。さらに、システム研修と称してチームを編成してソフトウェアを開発させても、大学時代からプログラ
プログラミングと設計は本来切り離せないものなのでは - 達人プログラマーを目指して
最近はアーキテクトという役割で客先に常駐し、フレームワークの選定をしたり、事前に共通部品を設計したりする役割を担う仕事を引き受けることが結構あります。そこで運よくお客様のマネージャーがオブジェクト指向開発の経験が十分にある方だと、IDEなどの開発環境やインターネット接続環境を当然のように用意してくれるので最初から仕事がスムーズにできるのですが、そうでないとMS Officeしか入っていないロースペックのノートPCを渡されて、要件定義フェーズの期間中、フレームワークの設計をお願いしますとか、私としてはちょっと首をかしげてしまうような困ったことを言われてしまう場合があります。開発フェーズが始まる半年後まではコーディングは基本的に不要という考え方です。アプリケーションのアーキテクトという役割では少なくともコーディング規約を考えたり、ツールやフレームワークの選定をしたりする必要がありますし、プロジ
ビルドシステム構築スキルの重要性 - 達人プログラマーを目指して
忙しいプロジェクトだとどうしてもおろそかにされがちなところですが、maven2やant+ivyを使ってビルドやリリースの自動化を行い、Hudsonなどの継続的結合環境上で動作させることは、開発生産性向上のために欠かせないことです。ビルド自動化はアジャイル開発なら当然必須ですが、そうでないウォーターフォールのプロジェクトであっても、是非取り入れたいことです。 そこで、意外な盲点となるのが、正しくビルドスクリプトを作成して、メンテナンスするプログラマーのスキルが非常に重要であるという点です。こういったビルドスクリプトはあくまでも最終納品物ではなく、生産性向上のためのツールという位置づけのためか、多くのプロジェクトではきちんとした工数や担当者がアサインされることなく、仕事の合間に知識のあるプログラマーがボランティアで開発するというケースも多いのではないでしょうか。しかし、最近の複雑なアプリケーシ
codic - デベロッパーのためのネーミング辞書
codicは、プログラマーのためのネーミング辞書です。新しいcodicでは、翻訳エンジンを搭載しネーミングをジェネレートできるようになりました。
「ソフトウェアレビュー入門」関連の最新 ニュース・レビュー・解説 記事 まとめ - ITmedia Keywords
ソフトウェアレビュー入門（5）： レビューを「数」だけで管理しているからコストが膨らむ 「ソフトウェアレビューが適切に行われているかどうか」を測る代表的な指標として、「指摘件数」を「対象規模」で割った「指摘密度」がある。しかし、「指摘密度」だけでレビューの質を管理することは難しい。レビューを行う際には、「そもそも何のためにレビューを行うのか」を常に意識することが大切だ。（2010/8/19） ソフトウェアレビュー入門（4）： ソフトウェアレビューが成功する進行役の6条件 ともすると漫然と取り組んでしまいがちなソフトウェアレビューだが、メンバー1人1人の役割を明確化すれば、非常に効率的に行うことができる。中でも司会進行役は、レビューの結果を左右する大きなカギを握ることになる。（2010/4/14） ソフトウェアレビュー入門（3）： “読み方”を知って、レビューをもっと効果的に ソフトウェアレ
日本のアジャイルは海外と比べると周回遅れか、アジャイル開発が国内で普及するには？ IPAの報告書から
海外ではアジャイル型開発の採用は開発企業のステータスとしての側面があり、現在のアジャイルの次にくるものの議論が始まっている。我が国の状況は周回遅れとも表現されることが少なからずあった。 日本のエンジニアが生き生きと働くためにどうすればよいのか？ その一環として独立行政法人情報処理推進機構（IPA）が発表した「非ウォーターフォール型開発に関する調査」では、まとめとしてこのような説明が掲載されています。 アジャイル開発普及のための3つのポイント こうした状況を脱し、国内でアジャイル開発を普及するためにどうすればいいのでしょうか？ 発表されたIPAの報告書では次の3つの指摘がありました。 (1) ビジネス等のコンテキストに応じた開発方法の選択 開発するソフトウェアの特性やプロジェクトに与えられる制約などを踏まえ、妥当な開発手法を定めた結果として、ウォーターフォール型開発色が強い場合もあれば、その
情報処理推進機構：ソフトウェアエンジニアリング：非ウォーターフォール型開発に関する調査結果公開
SECは、短サイクルで設計からシステム稼動までを"機敏"に繰り返し、ニーズへ迅速へ対応するといわれる非ウォーターフォール型開発について、事例を含む適用分野や規模などの調査を行いました。あわせて、有識者に参画していただいて研究会を実施し、現状・動向の把握と課題の整理を行いました。その資料を公開します。 ・非ウォーターフォール型開発に関する調査 調査報告書 ・非ウォーターフォール型開発に関する調査 研究会報告書 ・非ウォーターフォール型開発に関する調査 エグゼクティブサマリー
近代化すべきレガシーアプリケーションを判定する--そのための4つのステップ - builder by ZDNet Japan
ビジネスの推進には必須！ ZDNet×マイクロソフトが贈る特別企画 今、必要な戦略的セキュリティとガバナンス 非構造化データのデジタル活用へ 社内の文書コンテンツを一元管理 デジタル変革と内部統制の二兎を得るECM 身近な改善の第一歩！ ニューノーマルな働き方を前提にした これからの時代のWi-Fi環境構築のポイント 激変するビジネス環境の中でのDX モダンアプリケーション戦略への取り組みが 市場の競争力の源泉となる 高まるゼロトラストの気運 妥協のない安全のために適材適所で組合せ トップ4社によるゼロトラストセキュリティ IT部門のDXはこれだ！ IT運用管理新時代における最適な運用管理 の現場作り ともにDXを推進する コンテナ化されたワークロードを管理 継続的な価値を生みだす「協創」への挑戦 今を知り、未来を見据える 培ってきたノウハウを最新技術へ対応させる レガシーシステムのモダン
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
http://japan.internet.com/webtech/20111214/7.html
開発者たちがアジャイル開発に抵抗感を示すワケ
dfltweb1.onamae.com – このドメインはお名前.comで取得されています。