コーディングもテストも持ち回りな新プログラミング手法「モブプログラミング」とは何か――本場 Hunter社に学ぶ
役割分担ではなく協働作業という考え方 プログラミング、コーディングというと、ともすると優秀なスーパーエンジニアが一人で設計、コーディング、デバッグまで進めるという、属人的な作業というイメージがある。大規模プロジェクトでも、プログラマーやエンジニアにはモジュールごとの開発を担当することが多い。それをグループの協働作業でひとつのプログラムを完成させるというのだが、果たしてうまくいくのだろうか。 実は、クリエイティブの場でもこのような協働作業を取り入れる動きがある。ハリウッド映画だ。映画のストーリーや脚本を決めるのに、脚本家や監督、企画系のスタッフらが集まりミーティングをしながら展開を決定していくスタイルが一部で広がっている。クリエイティブと相反するような取り組みだが、読めない展開、多様な登場人物とそれぞれが持つ設定が重層的にからみあうストーリーが可能になる。 映画におけるこの協働作業が、必ずう
「機能は現状のままで」は危険、システム刷新を失敗に陥れる禁句
基幹システムの刷新でトラブルが起きやすい典型パターンは、旧システムの機能を、現状のまま新システムに載せ替えるケースだ。既存システムには自社業務や業界慣習に基づく機能を組み込んでいる。こうした機能を「現状のまま」新システムに反映させるのは本質的に難しい。 既存のレガシーシステムを新システムにリプレース（置き換え）する。近年の基幹システム刷新プロジェクトの多くはこのパターンだ。 プロジェクトを始めるきっかけは、メインフレーム、オフコン、OS、パッケージ、ミドルウエアなどのサポート切れが多い。まったく新しいシステムを一から開発するよりも、既存システムの機能をそのままに、新システムへと置き換えるほうがリスクは少ないように見える。 ところが、システム開発トラブルの多くはこのパターンのプロジェクトで起きている。 日本の企業は20年から30年くらい前に、販売管理、生産管理、会計管理などの基幹システムを相
外注したシステムが未完成なのに「約5億」支払わされた理由
政府CIO補佐官。ITプロセスコンサルタント。 元・東京地方裁判所民事調停委員・IT専門委員、東京高等裁判所IT専門委員。 立教大学経済学部経済学科卒業後、NECソフト株式会社（現NECソリューションイノベータ株式会社）にて金融機関の勘定系システム開発など多くのITプロジェクトに携わる。その後、日本アイ・ビー・エム株式会社にて、システム開発・運用の品質向上を中心に、多くのITベンダと発注者企業に対するプロセス改善とプロジェクトマネジメントのコンサルティング業務を担当。独立後は、プロセス改善やIT紛争の防止に向けたコンサルティングを行なう一方、ITトラブルが法的紛争となった事件の和解調停や裁判の補助を担当する。これまで関わったプロジェクトは70以上。調停委員時代、トラブルを裁判に発展させず解決に導いた確率は９割を超える。システム開発に潜む地雷を知り尽くした「トラブル解決請負人」。2016年よ
日本郵便の大炎上プロジェクト、火消し人は何をしたか？
民営化に伴う日本郵便の大規模システム開発。ベンダー十数社が参加したプロジェクトでは、多くの現場で火を噴いていた。 無理もない。期間が極端に短い上に、民営化に伴い業務が複雑化、民間の発注スタイルに不慣れなユーザーなど、至るところにリスクがあった。 そんな中、渦中のプロジェクトをリカバリーした人物がいる。日本ユニシスの佐々木 貴司氏（金融システム第三本部長）だ。同社が担当したのは、業務アプリケーションの開発。プロジェクトは先行部分と後続部分から成る。このうち先行部分は納期通りの2013年夏にリリースしたものの、稼働後に後納郵便料金の誤計算や、性能不足といったトラブルに見舞われた。 後続プロジェクトの発注先を変更する案も出たが「金融機関並みの品質を確保してほしい」と日本郵便側が要請。そこで急きょ、日本銀行やメガバンクなど金融系大規模プロジェクトの経験が豊富な佐々木氏が立て直しに入った。 ヒアリン
巨額のシステム開発は、なぜ破綻するのか？
先日、セブン―イレブン・ジャパンが情報システムを刷新するのに520億円の投資を行うと発表がありました。（コンビニ、欠品ゼロへ セブン、10年ぶり新システム 520億円投資） みずほ銀行は4000億円もの巨額のシステム投資をしましたが破綻のうわさも出ているように、システム投資は失敗に終わることが非常に多い。特に巨額になればなるほど、サクラダファミリアのようにいつ完成するか分からない状態になりがちです。 そこで巨額のシステム開発は、なぜ破綻するのか、何度もそのような現場に立ち会ってきた立場から一般の人にも分かるように説明したいと思います。 見積りは勘、終わるかは運次第 システム開発は建築と似ていますので（これがそもそもの間違い）、建築に例えますと……。 お客様からどんな建物が良いかヒアリング お客様の希望を元に設計を行う 基礎（土台）を作る 外形を作る 外装をする 内装をする というような順に
SonarQubeでプログラムの品質管理をはじめる（概要） - Qiita
はじめに SonarQubeは日本語のドキュメントが少なく導入に苦労したので、同じように導入を試みようとする方の手助けになればと思い、使い方などまとめておこうと思います。 （２週に１度程度の頻度です） 記載する予定のもの 概要（今回） インストール方法(CentOS 7にSonarQubeを立ち上げる) Maven、Jenkinsを使用してCIに組み込む SonarQubeで行った品質レポートの見方 SonarQubeのバージョンアップ方法 SonarQubeとは スイスのSonarSource社が主に開発を行っている統合的なプログラム品質管理を行える統合品質管理ツールです。 SonarQubeのHP 何ができるのか 様々な言語で書かれたソースコードに対して、静的解析チェックを実行して、その結果をWebで閲覧できる。 JUnitなどでユニットテストを実行して、テスト成功数、失敗数、カバレッ
数値で測るコード品質 - give IT a try
プロフィールのところにも書いてあるのですが、おいらの目標は「美しく無駄のないシステムアーキテクチャを設計、構築すること」です。 なぜならシステムの保守性や拡張性って、アーキテクチャやコードの品質によって雲泥の差が出ることを、幾度となく痛感してきているからです。 しかし、どんなアーキテクチャやソースコードがキレイなのか、拡張性や保守性が高いのか、っていうのはなかなか客観的に判断しにくいのもたしか。 「俺のコードはあんたのより分かりやすい」 「そうですか？？」 「絶対そうやろ！？なんでわからんのや？？？」 みたいな議論が始まったらたぶん平行線になっちゃいますよね。 そこでツールを使って、コードの品質を定量的に測ってみることにしました。 今回使ったツール 今回使ったツールはこちらです。 SourceMonitor V3.5 http://sourceforge.net/projects/dupl
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
あと10年で、6リットルに73億人の脳が収まる：PEZY Computing齊藤元章が描く「プレ・シンギュラリティ」の衝撃 #wiredai