技術的負い目の記事がすごいのでリンクしておく。 【元ネタ】 16年間うごいているWebアプリケーションが抱えていた技術的負い目を考察する | GMOメディア エンジニアブログ たくさんの負のレガシーがあり、しかも本番稼動中であり、バックアップ容量も多い。 そう簡単にリファクタリングしにくい。 そんな中で色んな対応をされている。 以下、自分が今後参考にしたいためにメモ。 【1】JDKが古い。 古いJDKはセキュリティホールもあるだろうから危険。 性能要件も低いだろう。 →JDK6からJDK8へバージョンアップ。 Gradleでビルド環境を作る。 ライブラリの依存関係はMavenリポジトリから探し、Gradleで依存関係管理させる、と。 【2】コード重複率も多く、デッドプログラムも多い。 長年運用したシステムは、デッドプログラムが多い。 でも、リスクがあるから、デッドプログラムをうかつに消去で

JAXAにおけるスーパーコンピュータ活用課でのチケット管理ステムの経験論文がPDFで公開されていたのでメモ。 【参考】 ※参照リンクを修正しました。 JAXA Repository / AIREX: CODA: JSS2の運用・ユーザ支援を支えるチケット管理システム: Redmineの事例と利用のヒント akipiiさんはTwitterを使っています: "気になる。RT @g_maeda: なんだこれ ? CODA: JSS2の運用・ユーザ支援を支えるチケット管理システム : Redmineの事例と利用のヒント https://t.co/9QlySYSzZk" MAEDA, GoさんはTwitterを使っています: "@akipii @y503unavailable @takenory JAXAの資料のPDF見つけました https://t.co/msKI89zsCh" akipiiさんは

最近、Redmineの運用事例をSlideshareでたくさん見かける。 その中でも、参考になった資料をリンクしておく。 【1】 チーム力向上のために、取り組んだ活動は3つ。 ①チーム力向上活動 ②Redmineの活用 ③信頼貯金の蓄積 そのうち、Redmineの活用では、次の3つを実施。 a)Wikiでノウハウ蓄積 b)チケットでコミュニケーション c)フォーラムで見積り根拠 参考になったのは、フォーラム機能を使って、顧客とのやり取りや仕様変更のやり取りを記録するだけでなく、見積り根拠も残すようにした運用だ。 SIならば、顧客からの要望に対して、必ず見積もりし、その見積り工数と金額で同意を取ってから、作業を開始する。 しかし、顧客から、過去に同じような仕様変更を頼んだのに、なぜ今回はこんなにお金がかかるのか、とよく質問される場合が多い。 その時、過去の案件の見積もり根拠は普通は記録されて

【公開】第30回IT勉強宴会「最近感じる日本企業のITの問題と展望～「ソフトを他人に作らせる日本、自分で作る米国」を読んで」 【1】「ソフトを他人に作らせる日本、自分で作る米国」の著者である谷島さんが来阪されたのを記念に勉強会が開催されました。 数人が本の感想をメインに発表し、谷島さんに感想を述べてもらうという緩い勉強会でした。 いろんな議論がありましたが、詰まる所、「日本のユーザ企業がシステム開発を内製化するにはどうすればよいのか？」というテーマを巡る話だったと思います。 僕は、SIとユーザ企業の両方を経験した立場から、現状の日本のIT企業(SIとユーザ企業の両方)について、話しました。 【2】「日本企業はロールが多すぎる」という問題 【2-1】SIにしても、ユーザ企業にしても、日本企業は役職が多すぎる。 特に、管理職は部長、課長だけでなく、事業部長、PMO、○管理長、主査など色んな肩書

アジャイル開発を日本風にアレンジしたプロセスをマネジメント・デザインパターンとして説明した記事があったのでメモ。 【参考】 ウォーターフォール開発とアジャイルの本質 - プロマネブログ サルでも分かるアジャイルとウォーターフォールをハイブリッドしたマネジメント・デザインパターン - プロマネブログ 炎上プロジェクトの責任はプロマネが９割 - プロマネブログ 【1】WF型開発とアジャイル開発には、それぞれの特徴があり、適用の問題点がある。 WF型開発は、仕様変更に弱く、無駄なドキュメントが多い。 アジャイル開発は、変化に強く、スピード重視で開発できるが、従来のプロセス手法と発想を変えないといけないので、実現しづらい。 上記の記事によれば、各プロセスの特徴は、「WFが形式知の作成を行うことで、開発体制と開発工程を管理する手法」「(アジャイル開発は)フォーカス管理の最適化」。 つまり、WF型開発

「テスト駆動開発による組み込みプログラミング」を頂きました。 ありがとうございます。 既に色んな方が感想を書かれています。 【元ネタ】 「テスト駆動開発による組み込みプログラミング」 - Yasuo's Notebook [書評]テスト駆動開発による組み込みプログラミング | Ryuzee.com O'Reilly Japan - テスト駆動開発による組み込みプログラミング 書籍『テスト駆動開発による組み込みプログラミング』：柴田 芳樹 (Yoshiki Shibata)：So-netブログ "これこそ私の探していたものだった" - テスト駆動開発による組み込みプログラミング: 菊と書評 テスト駆動開発は設計技法である～組み込みアジャイルコーチ James Grenning さんインタビュー: プログラマの思索 C言語でTDDをやる場合、JavaやRubyに比べると、リフレクションやモック

ソフトウェアテストで著名な秋山さんがSQIP分科会で細谷さんの講演をTwitterでログ公開されていたのでリンクしておく。 内容がとても為になると思う。 【元ネタ】 日科技連 ソフトウェア品質 第6回特別講義 「アジャイル開発での品質向上への取り組み」 - Togetter 【1】ここでのアジャイル開発は、Scrumをベースとした開発のようだ。 つまり、要求をプロダクトバックログに一覧化するプロダクトオーナー、プロダクトバックログを元にスプリント単位で開発していくチーム、プロダクトオーナーとチームを側面支援するスクラムマスターの3つの役割がある。 「品質の問題が発生する要因として、『階層構造＋オーバーコミット』がある。オーバーコミットはスコープとコストに矛盾がある状態です。上の階層から実行部隊に矛盾が落ちてくる。この矛盾を上に上げて解消するためのロスがある。」という細谷さんの指摘は鋭い。

Jenkinsでプロジェクトの状況をウォッチするRedmineMetricsPluginが公開されていたのでメモ。 【元ネタ】 Jenkinsでプロジェクトの状況をウォッチする - mitoma_ryoの日記 mitoma/redmine-metrics-plugin RedmineMetricsPluginはJenkinsのプラグインで、Redmineのチケット情報を元にバージョン単位にステータスごとのチケット推移を表示してくれるらしい。 このプラグインを有効活用するには、バージョンをフィーチャないしビジネス要求単位に作る方がグラフが意味あるものになるだろう。 似たようなメトリクスとしてパーキングロットチャートがある。 パーキングロットチャートはバージョンをビジネス要求に対応付けて、バージョン単位にざっくり集計したメトリクスを出してくれる。 それに対して、RedmineMetricsPl

2012/8/24に@sakaba37さんと「チケット駆動開発～プロジェクトを成功に導くための「現場からの改善」提案を完全網羅」を出版します。 前作「Redmineによるタスクマネジメント実践技法」に続くチケット駆動開発の解説本になります。 過去5年間、チケット駆動開発とは如何なるもので、一体何ができるのか、という根本的な問題をずっと考えてきた結果を全て書きました。 元々は@machuさんがTracのチケット管理から提唱したアイデアを参考にして、故意にそのアイデアを拡張して、Redmine上でアジャイル開発を実践できるように、自分なりのノウハウを詰め込みました。 その後、チケット駆動開発について講演したり、コミュニティで議論しながら、アジャイル開発だけでなく、技術や開発プロセス全般、ソフトウェア工学など色んな観点で分析するように努めてきました。 そして、チケット駆動開発に関する技法や適用方

日本のSI企業がチケット駆動開発について記事を書かれていたのでメモ。 以下ラフなメモ書き。 【元ネタ】 「チケット駆動開発」の適用について考える｜コラム「ITよもやま話」｜特集│株式会社JSOL 補完チケット方式はチケット駆動開発の先祖返り: プログラマの思索 [#TiDD] チケット駆動開発によるアダプタブル・ウォータフォール開発 #agileto2011: ソフトウェアさかば ユーザの力を利用するアジャイル開発: プログラマの思索 チケット駆動開発の戦略: プログラマの思索 僕はチケット駆動開発がどこまで知名度が上がっているのか、正直知らない。 でも、チケット駆動開発のアイデアをアジャイル開発だけでなく、従来のWF型開発にも適用すればその恩恵が受けられるのではないか、という意見は、既に@sakaba37さんたちが色々試されている。 チケット駆動開発をWF型開発に適用する場合、「チケット

小川 明彦, 阪井 誠 : チケット駆動開発 日本のソフトウェア開発の現場で生み出された「チケット駆動開発」という概念を、数多くの実例を元にモデル化・体系化を試みた最初の本。 小川 明彦, 阪井 誠 : Redmineによるタスクマネジメント実践技法 Redmineによるチケット駆動開発の実践技法に関する最初の本。アジャイルなソフトウェア開発への適用方法、TestLinkによるテスト管理手法についても言及。 清水 吉男: 「派生開発」を成功させるプロセス改善の技術と極意 組込システム開発をベースとして、ソフトウェア開発特有のスタイルである派生開発、特にXDDPについて解説した世界でも稀な本。既存製品を保守するのではなく継続的に機能追加していく昨今の開発では、派生開発特有の問題を意識しなければならない。XDDPはプロセス論だけでなく、要件定義などの上流工程の品質改善にも役立つので注意。 Le

「ソフトウェア見積り」を読んだ後に「アジャイルな見積りと計画づくり」を読み直したら、とても理解しやすかった。 理解できたことをメモ。 間違っていたら後で直す。 ※追記：一部修正した。 ※追記：Velocityの計算方法を「塹壕よりScrumとXP」から参照するようにした。 【元ネタ】 Twitter / @akipii: 見積について色々考えている。1.0MD(人日)という単位は規模・出来高・工数という複数の意味を持ち混乱しやすいから、ソフトウェア開発の計画づくりに支障をきたしているのではないかという仮説を考えている。その考えを深めるとScrumのストーリーポイントはよく考えられた概念だと思う。 アジャイルサムライで一番難しくて面白い概念～Velocity: プログラマの思索 ソフトウェア開発に特有な技術～ソフトウェア見積り: プログラマの思索 チームは加速するのか～Velocityの使い

本日、Redmineでのタスク管理を考える勉強会＠大阪第1回が開かれました。 スタッフの皆さん、ありがとうございました。 今日の発表資料をCC Attribution ライセンスで公開します。 Redmineを初めて導入した時によく聞かれる質問や、よくはまるアンチパターンについて発表しました。 多分、どれか一つぐらいは経験があるだろうと思います。 「放置されたチケット」は原因が根深いアンチパターンです。実際、他のアンチパターンと同様に発生してます。 「空っぽのロードマップ」はバージョンやロードマップの機能が分かっていないチームに多い。 特に、MantisやTracでは、バージョン(マイルストーン)やロードマップをまともに使っていないチームはRedmineよりも多いでしょう。 Twitter / @akipii: まさにその通りですね。redmineを使う以前の問題なのかも。　RT @agi

@daipresentsさんのRedmineの記事が素晴らしいのでメモ。 【元ネタ】 3年使ったRedmineの使い方について共有したい10のこと | 世界 - daipresents!! Twitter / @あきこ: 題名、説明はプログラムする気持ちで記述する、は心がけています。/ 3年使ったRedmineの使い方について共有したい10のこと | 世界 - daipresents!! http://t.co/rOcsJkL via @daipresents http://twitter.com/#!/akiko_pusu/status/55514322046169088 InfoQ: かんばんボードによるプロジェクトの見える化 Redmineでアジャイルチームのスピードやパワーを見える化する Redmineが1000人のエンジニアに使われるまでのこと 受託開発でTracを導入してよかっ

ドメイン駆動設計に関する良い資料があったのでメモ。 InfoQにログインすれば、概要をダウンロードできる。 【元ネタ】 InfoQ: Domain Driven Design（ドメイン駆動設計） Quickly 日本語版 無料で読めるDomain Driven Designの概要 上記は「Domain-Driven Design: Tackling Complexity in the Heart of Software」に関する概要資料。 「はじめに: なぜドメイン駆動設計なのか」の節でなるほど、と思った。 マーチン・ファウラー の「エンタープライズ アプリケーションアーキテクチャパターン (Object Oriented Selection)」によれば、オブジェクト指向による実装は本来、テーブルモジュールでもなく、トランザクションスクリプトでもなく、ドメインモデルにある。 つまり、OOA

チケット駆動開発についてのFAQをまとめてみた。 他に聞きたい質問があれば、コメントして下さい。 チケット駆動開発のFAQを集めれば、チケット駆動開発を普及させるのに役立つと思うから。 【元ネタ】 チケット駆動開発 … ITpro Challenge のライトニングトーク (4) - まちゅダイアリー(2007-09-07) TiDD：チケット駆動開発: ソフトウェアさかば RedmineとTracの機能比較: プログラマの思索 脱Excel！ Redmineでアジャイル開発を楽々管理 － ＠IT自分戦略研究所 Tracのワークフロー: プログラマの思索 ワークフロー機能のカスタマイズ方法 - かおるんダイアリー そろそろTracのワークフローについて語っておくか - almost nearly dead チケット駆動開発は進捗報告作りをどのように解決しようとするか？: プログラマの思索

garyoさんに教えてもらった「Google 工藤拓さん講演「大規模ソフトウェア開発を支えるGoogleのテクノロジー」」の感想を書く。 【1】コードレビューができないプロジェクトの問題点 コードレビュー以前に、レビューというプロセスが存在しないプロジェクトは数多い。 相次ぐバグ修正や仕様変更にひっきりなしに対応するのに追われて、設計書やコードを書いただけになってしまいがち。 特にデスマーチプロジェクトでは、雑な作業の結果である雑な成果物ばかり作られる。 読んでも誰も分からない、とか、誤植が多い、などの症状が頻発するだろう。 レビューのない開発チームでは、設計思想や運用ルールの情報共有ができていない。 どんな開発でも、フレームワークやハードを含めたアーキテクチャの上で設計してプログラミングする。 その思想を理解するには、最初は時間がかかる。 特に昨今のWebシステム開発では、3カ月おきに開

TestLinkはオープンソースのWebのテスト管理ツール。 TestLinkがExcelのテスト仕様書よりも素晴らしい点を書く。 【0】インストールが超簡単 XAMP＋TestLinkが一体化されたパッケージがある。 解凍して起動するだけ。 USBメモリに入れて持ち歩くことさえできる。 【1】テストケースを再利用しやすい シナリオベースのテストケースは、運用保守や2次開発でも頻繁に使う。 実際は、1次開発で使ったテストケースを複製して、仕様変更や追加機能を反映させる。 この時、Excelのテスト仕様書から該当のテストケースを抽出したり、変更するのに手間がかかる。 また、テストケースは書く人によって、粒度や書式が大きく異なる時が多い。 後の保守で再利用できなかったりする。 TestLinkの場合、テストケースはDBにあるから複製が簡単。 また、TestLinkの入力フォーマットが固定されて

今日の昼に50代のマネージャと昼食しながら、プロジェクトリーダーの仕事に関して考えることがあった。 【１】プロジェクトリーダーの特徴 5人ほどのチームで開発する時、プロジェクトリーダーの能力には特徴がある。 一つは、システムの設計や技術を細部まで知り尽くして技術者としては殆ど完璧なタイプ。この場合、基本設計や仕様確認ではお客さんよりも詳しいので信用できるが、プロセス管理や交渉にあまり長けていない。2次請け以下の会社に多い。 他方は、仕様や技術は詳しくないが、お客さんとの交渉やプロセス管理に長けているタイプ。この場合、サブリーダーが技術統括者の役割を担う。1次請けの会社に多い。この人達は基本的に手配師。 プロジェクトリーダーは現場監督そのもの。ソフト会社で最も戦力となる人達だ。 手配師はプロジェクトリーダーと言うよりも、もう一段格上のマネージャに近いように思う。 【２】技術者と管理者の役割を