「ソフトウェア開発データが語るメッセージ2017」を公開～ソフトウェアの信頼性は向上するも生産性は低下傾向～：IPA 独立行政法人 情報処理推進機構
概要 独立行政法人情報処理推進機構ソフトウェア高信頼化センター（以下、IPA/SEC）は2018年3月6日、「ソフトウェア開発データが語るメッセージ2017」（以下、本書）を公開しました。 本書は、「ソフトウェア開発データ白書2018-2019」（2018年10月発行予定）作成用に収集した最新のプロジェクトデータに基づいて、ソフトウェア開発の傾向を分析したものです。 分析の結果、ソフトウェア開発の信頼性は向上しているものの、ソフトウェアの品質に対する要求の高まりにより、生産性は低下傾向にあることが分かりました。また、生産性・信頼性の向上には定量的管理を推進し、品質要求レベルに見合った生産性目標を設定すべきこと、さらに、要員の人材育成が重要であることが分かりました。 背景と目的 近年、ソフトウェアの大規模化／複雑化が進む一方、信頼性向上、生産性向上、開発期間短縮等の要求は高まっています。この
AgileとCMMIの融合:SEPG Conferenceより - masayang's diary
CMMIにAgileの思想とプラクティスを取り込む動きは2006年あたりから始まっていたが、今回開催されたSEPG Conferenceにおいて以下のような議論が進行した。 従来のウォーターフォール思想を基盤としたCMMIは今後メンテされない。つまり進化しない。(お猿さん向けに残るには残る。) AgileはCMMIに正式に取り込まれる。 ただし、CMMIが重視する「成熟度」「再現性」などはAgileであっても尊重されなければならない。 成熟度や再現性が問われる以上、プロジェクトは一定以上の「見通し」が確保されるべきである。 すなわち、イタレーションやスプリントという言葉に代表される「やってみて、できるところまで作業する」という姿勢は正されるべきである。 このような考えのもと、Agile+CMMIはRUP(Rational Unified Process)を踏襲した工程名を採用することになっ
こんなPMはダメだ！プロジェクトをいつも炎上させているPMに多い4つの特徴 - paiza times
Photo by Rich Bowen こんにちは。谷口です。 皆さんの職場では開発プロジェクトの炎上は起きていませんか？ エンジニア、特に受託開発企業にお勤めの方の転職理由を伺っていると、「自分のスキルをいかせる仕事がしたい」などの前向きな理由がある一方で、「炎上プロジェクトばかりが続いていて大変」「勤務時間が長く、休日出勤も多い」という、職場環境の問題も少なくありません。 最近は労働基準法改正案で残業時間の上限が「100時間未満」と規定されたり、厚労省が労働基準関係法令違反企業のリストを公開したりしたことで、労働環境改善の課題が、社会的に注目されています。IT企業も例外ではありません。炎上プロジェクトはできる限り減らしていかなければなりません。 では、なぜプロジェクトの炎上が起こるのでしょうか。 受託開発企業では、開発メンバーの残業時間や仕事のしやすさを左右するのは、多くの場合PMの手
リポジトリ - Strategic Choice
リポジトリ＠オブジェクトリレーショナルメタデータマッピングパターン「仕様」を満たすデータ取得レイヤ。どういうこと？リポジトリは、ドメイン層とデータマッピング層を仲介し、ドメインオブジェクトに対してコレクションのようにアクセスできるインターフェースを提供します。リポジトリにより、クライアントは、「仕様」を満たすコレクションを、クエリオブジェクトやクライテリアを使用することなく、宣言的に取得することができます。どうすれば？リポジトリは、ドメインオブジェクトに対して、データマッパーの検索を隠蔽します。リポジトリは、内部的に『クエリーオブジェクト』を生成して検索を実行し、クライアントには単純な検索インターフェイスだけを公開します。どうして？データマッパーは、ドメインオブジェクトをデータベースアクセスコードから分離する「レイヤ」です。このよう構成の中で、クエリ部分を別途「レイヤ」化することには価値が
単一責任の原則(SRP)についての見解と方法論 - FLINTERS Engineer's Blog
こんにちは@kimutyamです。 今週末はいよいよScalaMatsuri2017ですね。 弊社は、今年も将軍スポンサーとして参加させていただきます。 そして今年も同人誌を配布させていただきます。 同人誌については去年配布した話を杉谷がブログで紹介しております。 labs.septeni.co.jp 今年の同人誌目次は以下となります。 ScalaでAndroidアプリ開発 単一責任の原則(SRP)についての見解と方法論 末尾再帰の呼び出し最適化の有無によるScalaコンパイラの挙動について Akka HTTP で LINE bot を作ってみました 新卒scalaエンジニアが書くISUCONの歩き方 去年に比べて記事数は少なめですが、内容は濃くなっております。 ちなみに私は弊社の今泉と一緒に『単一責任の原則(SRP)についての見解と方法論』を執筆しました。 (Scala関係ないw) 代わ
Webブラウザ「Vivaldi」が超絶便利すぎてChromeユーザーはさっさと乗り換えたほうがいい - Brian'z Imagination
ブログにしろダイアリーにしろブックマークにしろ、はてなにお住いの皆さんが1日にブラウザと過ごす時間は、他のかたよりそれなりに多いことと思う。 そんなブラウザ使いの貴公子たちよ、こんな経験をしたことはないだろうか。 折角書いたブログ記事が誤操作で消えてしまった。 タブを開きすぎたことにより、メモリを食い過ぎてブラウザが落ちた。 ブラウザなんて要らない、俺は念力で十分だ。 そんな迷える子羊たちにオススメなのが、今回紹介するWebブラウザ「Vivaldi」だ。 コイツは使い始めは他のブラウザと変わらない「何の変哲もないただのブラウザ」だが、カスタマイズ次第で子羊たちを弄もてあそぶ「モンスターブラウザ」と化す。 特にChromeユーザーのあなたに、声を大にして伝えたい。 今のところChromeを使い続ける理由はなさそうなので、今日から乗り換えてしまおう！ Vivaldi？そいつは食えるのか？ Vi
アジャイルな開発には安全性が不可欠 : 現実世界の安全機構との3つのアナロジー | POSTD
(2016/7/15、著者プロフィールを修正いたしました。) 仮に、高速道路の自動車をより速く走らせることがあなたの務めだとします。もしあなたが、ドライバー全員にただ「アクセルを思いきり踏むように」と言ったら、一体どうなるでしょうか？ 結果は明らかに、大惨事となるでしょう。それなのに、ソフトウェアの構築を速めようとする時に、多くの開発者がまさにそんな態度を取っているのです。その理由として持ち出されるのは、以下のようなことです。 「本当にアジャイルに進めたいので、デザインやドキュメントには時間をかけられない」 「これは本番環境にすぐ反映しなきゃいけないから、テストを書く時間はない」 「何もかも自動化する時間はなかったので、コードのデプロイは手作業でやる」 自動車が高速道路を高速で走るには、安全性が欠かせません。より速く走るためには、ブレーキやシートベルト、エアバッグといった、いざという時にド
SonarQubeでプログラムの品質管理をはじめる（概要） - Qiita
はじめに SonarQubeは日本語のドキュメントが少なく導入に苦労したので、同じように導入を試みようとする方の手助けになればと思い、使い方などまとめておこうと思います。 （２週に１度程度の頻度です） 記載する予定のもの 概要（今回） インストール方法(CentOS 7にSonarQubeを立ち上げる) Maven、Jenkinsを使用してCIに組み込む SonarQubeで行った品質レポートの見方 SonarQubeのバージョンアップ方法 SonarQubeとは スイスのSonarSource社が主に開発を行っている統合的なプログラム品質管理を行える統合品質管理ツールです。 SonarQubeのHP 何ができるのか 様々な言語で書かれたソースコードに対して、静的解析チェックを実行して、その結果をWebで閲覧できる。 JUnitなどでユニットテストを実行して、テスト成功数、失敗数、カバレッ
ニトリが新ECサイト開設、MAMS導入で配送日時の提示へ
家具メーカーの（株）ニトリは9日、グループの物流を担う（株）ホームロジスティクスが伊藤忠テクノソリューションズ（株）の配送計画を自動化するクラウドサービス「Mobile Asset Management Service」（MAMS）を宅配サービスの基盤として導入したと発表した。17日に立ち上げる新ECサイトと店舗で宅配サービスの本格的な運用を開始し、店舗とECサイトで詳細な配送日時を提示する。 ニトリとホームロジスティクスは、状況にあわせた配送ルートの変更、配送日時の詳細指定などの配送面の課題があった。グループ全社の基幹システム刷新にあわせ、課題を解決するために宅配サービス基盤を変更し、2014年11月に全国のニトリ店舗にMAMSを導入。MAMSは、配送計画を注文時に自動作成し、配送予定時間・配送状況などをPCやスマホで追跡・確認できる。日程変更などの顧客の要望にも、状況に応じて対応する。
「挫折しないRedmine」の資料が分かりやすい - プログラマの思索
僕が使い始めた2008年頃と違って、現在はかなりRedmineが普及している。 ソフトウェア開発者だけでなく、製造業や製薬業、営業や事務、勉強会のタスク管理に使っている事例も多い。 最近特に目立つのが、初心者がRedmineを使っているものの、Redmineの良さを出し切れていない場面。 上記の資料では、「Redmineは、チームでチケットを消すゲーム」と定義して、わかり易く説明しているのがすごくいい。 アジャイル開発では、XPの計画ゲーム、Scrumのプロダクトバックログのように、ストーリーやタスクをチケット化して、イテレーション(Redmineならバージョン)単位にグループ化して、リリースしていく戦略を取る。 すると、チケット管理とは、チームでチケットを消すゲームなのだ、と感覚で分かるようになる。 この辺りの感覚は、40代以上の中年SEよりも、20代の若手PGの方がすぐに馴染んでくれる
The Twelve-Factor App
Introduction In the modern era, software is commonly delivered as a service: called web apps, or software-as-a-service. The twelve-factor app is a methodology for building software-as-a-service apps that: Use declarative formats for setup automation, to minimize time and cost for new developers joining the project; Have a clean contract with the underlying operating system, offering maximum portab
開発環境と本番環境の違いを埋めるHeroku、Engine Yardの新機能：Rails Hub情報局：エンジニアライフ
「でも、ステージング環境ではちゃんと動いています！」 こう言われてブチ切れた経験があります。業務アプリのバギーな動作を社内のエンジニアに指摘したところ、テスト用の環境では動いているというのです。「いや、ぼくら本番環境のアプリを使っていて現に困っているので、それを直してほしいだけなんですけど」というと、「でも、ちゃんとステージング環境では動いています。お使いになっているのがChromeのようですが、Chromeでの動作検証はしていません（キリッ」というようなやり取りに絶望しました。原因はブラウザではなく、バージョンアップしたアプリ自体にあったのですが、ステージング環境では問題が発現しなかったんですね。 というように、開発環境、ステージング環境、プロダクション環境（本番環境）の3つは、大小いろいろな違いがあって、完全に一致させることは難しいものです。手元の環境で動いているアプリが、プロダクショ
[テスト編]本番環境でいきなりテストしてはいけない
「テスト環境を用意する費用がなかった」「緊急性が高いので開発者に本番環境のプログラムを直接変更させた方が早いと思った」「本番環境のデータと同等のデータを用意するのが難しかった」「ベンダーがテスト済みというので信頼した」――。 これらはすべて，本番環境でいきなりテストすることを“必要悪”として認めた担当者の言葉だ。だが，どのケースも結果的に障害に至った。 開発したばかりのプログラムは，誤作動する危険がある。ほかのプログラムに悪影響を及ぼしたり，データやファイルを破壊したりすることもある。OSやミドルウエアのベンダーが提供するセキュリティ・パッチのように，ベンダーがテストしてリリースしている場合でも，個別の環境では動作しなかったり，思わぬ悪影響が出たりする。事故を防ぐためにも，稼働中の本番環境でいきなり未検証のプログラムをテストしてはいけない。 システムを停止していればいいわけでもない。計画停
![[テスト編]本番環境でいきなりテストしてはいけない](https://cdn-ak-scissors.b.st-hatena.com/image/square/bed39b5962a5d552c95b6d796db8f55e72d32943/height=288;version=1;width=512/https%3A%2F%2Fxtech.nikkei.com%2Fimages%2Fn%2Fxtech%2F2020%2Fogp_nikkeixtech_hexagon.jpg%3F20220512)
システムを育てるカイゼン型開発のススメ〜SonicGardenでカイゼン型開発を行う理由 | Social Change!
日経SYSTEMS 2012年4月号の特集１が「システムを育てるカイゼン型開発のススメ」ということで、Part4に私も寄稿させて頂きました。ソニックガーデンが今のビジネスモデルを採用した理由について書きました。 「カイゼン型開発」という言葉は、2006年に私がブログで書いたのですが、ようやく時代が追いついてきたのかと感慨深いものがあります。そして、2012年の私たちは既にそこからさらに先に進んでいて、その答えとなる「納品のない受託開発」というビジネスモデルに辿り着いています。 実際に掲載された寄稿記事の方では割とコンパクトにまとめてもらいましたが、こちらではディレクターズカットということで元々に書いた原稿の方を公開します。もし、このブログよりもさっと読みたい場合は日経SYSTEMSを読んで頂くのが良いかと思います。 ソニックガーデンでは「納品のない受託開発」という少し変わったスタイルでの受
「ユーザーが決めた」は言い訳にならない
「そんな当てずっぽうで決めていいのですか？」。ある会社のシステム基盤の設計に関する打ち合わせをしている際、メンバーから言われたことがある。全体コンセプトを決めて積み上げたものなので、当てずっぽうなわけではないのだが、ユーザーニーズを聞いていない状態で決めるのは納得できない、というのである。 ユーザーからニーズを聞けない状況でも、そこにこだわるエンジニアが意外に多いと感じている。エンジニアには二つのタイプがある。一つはユーザーニーズがまずあって、それをどう実現するかという順序で考えるタイプ。もう一つは、新しいアイデアに沿ってシステムを構想し、ユーザーのニーズに後から合わせようとするタイプだ。前者はSI会社、後者はパッケージ会社や研究所の出身者に多い。 どちらが良いかは場合によるが、筆者の会社のように基幹業務システムの構築に関わる場合、ユーザーニーズを起点にするのが基本だ。ただ、基盤やフレーム
特許庁の基幹システムはなぜ失敗したのか。元内閣官房GPMO補佐官、萩本順三氏の述懐
特許庁が進めてきた基幹系システムの刷新プロジェクトが失敗に終わり、開発に投じた約55億円が無駄になってしまったことが、先週相次いで報じられました。 ［スクープ］特許庁、難航していた基幹系刷新を中止へ - ニュース：ITpro 朝日新聞デジタル：費やした５５億円、水の泡に 特許庁がシステム開発中断 - ビジネス・経済 このプロジェクトに「内閣官房GPMO（ガバメントプログラムマネジメントオフィス）補佐官」の肩書きで2009年まで民間から参加した萩本順三氏（現 匠BusinessPlace 代表取締役社長）がFacebook上で当時を述懐しつつ、失敗の要因を分析していました。今後、失敗プロジェクトを繰り返さないためにも、重要な発言として本人の許可をいただいてまとめました。 特許庁の情報部門に幾度も中止を迫った 萩本順三氏の発言の主要な部分を引用します。 内閣官房GPMO（ガバメントプログラムマ
ソフトウェア開発が好きでないサラリーマンエンジニア：柴田 芳樹 (Yoshiki Shibata)：So-netブログ
ソフトウェア開発は、自分で考えて手を動かしてプログラミングして動くものを作ることを繰り返す訳ですが、そもそもソフトウェア開発という「物作り」を好きではないサラリーマンエンジニアが日本には多いのではないかと思います。 その理由は単純で、新卒新人でも中途入社であっても、自分で分析・設計から実装・デバッグまでするのが好きな人を採用していないからだと思います。たとえば、メーカーでソフトウェア開発部門に配属されるような新卒新人でも、大学ではほとんどプログラミングしたことがない人をメーカーは採用します。中途採用であっても、採用面接でプログラミングを伴う技術的な質問をほとんどしません。 その結果、企業の中には、本当にソフトウェア開発が好きなソフトウェアエンジニアと仕事だからというサラリーマンエンジニアがいることになります。そして、サラリーマンエンジニアは、そもそも好きではないので、業務がこなせるようにな
staticおじさん達に伝えたい、手続き指向とオブジェクト指向の再利用の考え方の違いについて - 達人プログラマーを目指して
何が良いプログラムかという点はもちろん人やコンテキストによって異なりますが、少なくともプログラマーとしての私の信念としては、 機能拡張や変更が容易なプログラム 単体試験によって正しく動作することの検証が容易なプログラム どういった内容が記述されているか理解しやすいプログラム といったものこそ、「品質の高い」プログラムが持つべき性質として、まず真っ先に挙げるべき事項であると考えています。もちろん、前提として顧客の要件に従うということは大切なことです。しかし、一般に要件は長期にわたって変更されるものですし、使い捨てのプログラムを除けば、プログラムを長期にわたって保守するコストという点も見過ごすべきではありません。したがって、ユーザーの目には触れない上記の性質をもっと重視すべきだと思うのです。 DRYの原理 上記のような性質を満たすプログラムを作る上で大切になってくる原理として、DRYの原理とい
DDDの読書記録（第2章、コミュニケーションと言語の使い方） - 達人プログラマーを目指して
アジャイルプロセスのXPでもコミュニケーションに重点が置かれますが、その考え方に影響を受けているDDDでも業務担当者とプログラマーとの間のコミュニケーションを重視しているようです。しかし、これは「報連相」「根回し」「場の空気を読む」といった、いわゆる業界の新人研修やOJTで先輩社員から叩き込まれるような人間的なコミュニケーションのことよりは、むしろ、共通の言語やモデルによる科学的なコミュニケーションという点に重点を置いています。もちろん、最終的にコミュニケーションは人間同士で行うものなので、ヒューマンスキルが重要なのは言うまでもないことですが、日本の場合伝統的にチームの和を乱さないとか事なかれ主義のようなところもあり、事実に基づく正直なコミュニケーションが良くないとされるケースが多いようです。つまり、エンジニアとしてよりもむしろ、サラリーマンとしてのコミュニケーション能力が重視されるという
数値で測るコード品質 - give IT a try
プロフィールのところにも書いてあるのですが、おいらの目標は「美しく無駄のないシステムアーキテクチャを設計、構築すること」です。 なぜならシステムの保守性や拡張性って、アーキテクチャやコードの品質によって雲泥の差が出ることを、幾度となく痛感してきているからです。 しかし、どんなアーキテクチャやソースコードがキレイなのか、拡張性や保守性が高いのか、っていうのはなかなか客観的に判断しにくいのもたしか。 「俺のコードはあんたのより分かりやすい」 「そうですか？？」 「絶対そうやろ！？なんでわからんのや？？？」 みたいな議論が始まったらたぶん平行線になっちゃいますよね。 そこでツールを使って、コードの品質を定量的に測ってみることにしました。 今回使ったツール 今回使ったツールはこちらです。 SourceMonitor V3.5 http://sourceforge.net/projects/dupl
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
