「技術的負債だらけのチームで技術マネージメントしてみた」資料が素晴らしい - プログラマの思索
「技術的負債だらけのチームで技術マネージメントしてみた」の公開資料が素晴らしいのでリンクしておく。 【参考】 akipiiさんのツイート: "すごく良い資料。RT @yassan168: #kichijojipm 発表資料upしました。誰かの役にたてば良いのだけど。connpassにもUPしています。＞技術的負債だらけのチームで技術マネージメントしてみた https://t.co/3R25aUnI4S" 前任の仕事を引き継ぎしたら、下記の問題があったらしい。 技術的負債込みで引き継いでしまった、という例は、本当によくある。 (引用開始) １年前の状態 ・すべてがメールベース ・ドキュメントはほぼ無い ・最強の属人化。個人のパワーで乗り切る ・技術に関心が無く誰も行動しない ・暫定スクリプトが今も元気に本番稼働中 ・ソースには、ほぼコメント無し ・hoge.pl.(日付) 形式のソース管理
最近感じる日本企業のITの問題と展望~「ソフトを他人に作らせる日本、自分で作る米国」を読んで : プログラマの思索
【公開】第30回IT勉強宴会「最近感じる日本企業のITの問題と展望～「ソフトを他人に作らせる日本、自分で作る米国」を読んで」 【1】「ソフトを他人に作らせる日本、自分で作る米国」の著者である谷島さんが来阪されたのを記念に勉強会が開催されました。 数人が本の感想をメインに発表し、谷島さんに感想を述べてもらうという緩い勉強会でした。 いろんな議論がありましたが、詰まる所、「日本のユーザ企業がシステム開発を内製化するにはどうすればよいのか？」というテーマを巡る話だったと思います。 僕は、SIとユーザ企業の両方を経験した立場から、現状の日本のIT企業(SIとユーザ企業の両方)について、話しました。 【2】「日本企業はロールが多すぎる」という問題 【2-1】SIにしても、ユーザ企業にしても、日本企業は役職が多すぎる。 特に、管理職は部長、課長だけでなく、事業部長、PMO、○管理長、主査など色んな肩書
「電子立国は、なぜ凋落したか」の感想～日本の技術者は減価償却のコスト意識が低い - プログラマの思索
「電子立国は、なぜ凋落したか」の感想をメモ。 理解できた部分だけラフなメモ書き。 あくまでもメモなので、時々論理は飛んでいる。 【元ネタ】 日本の製造業もアジャイルの概念が必要ではないか: プログラマの思索 ユーザの力を利用するアジャイル開発: プログラマの思索 【1】「電子立国は、なぜ凋落したか」では、特に日本における半導体、電子電気の業界の栄枯盛衰を多角的に記載している。 そこで興味深い文言だけ拾っておく。 「日本の技術者は減価償却のコスト意識が低い。なぜなら、技術ではなく経営の問題だから。」 【2】日本の技術者は減価償却のコスト意識が低いのではないか 日本の半導体は世界を席巻していたが、諸外国に負けた時の言い分は「経営、戦略、コスト競争力で負けた」「技術では負けていなかった」とよく言う。 しかし、著者は、製造コストを考える時に、日本の技術者は減価償却のコスト意識が低いのではないか、と
セールスとエンジニアのためのIT提案戦術～SIベンダーの営業方法 - プログラマの思索
「セールスとエンジニアのためのIT提案戦術」を借りて読んだ。 受託開発中心のSIで、顧客折衝が多いSEやシステム提案の機会が多いPMにとっては必須の本だろうと思う。 感想をラフなメモ書き。 【1】システム提案プロセスの問題 普通のシステム提案プロセスでは、発注者がRFIを作ってベンダーに提示し、ベンダーは実現するシステムの内容や見積金額をRFPで発注者に提案する。 日本ならば、ユーザ企業がITを使って経営革新や新しいビジネス戦略を行うための道具としてITを使いたいので、ベンダーにシステム構築だけでなく、ITを使ったソリューション、つまりコンサルティングも求める時は多い。 そして、SIが作ったシステムの運用保守もユーザ企業ではなくSI任せになりやすい。 だから、どうしてもユーザ企業がSIへ丸投げしてしまいがちという日本特有の特徴が出るように思われる。 システム提案プロセスの問題としては、ユー
RedmineのWikiに図面を入れる - プログラマの思索
小川 明彦, 阪井 誠 : チケット駆動開発 日本のソフトウェア開発の現場で生み出された「チケット駆動開発」という概念を、数多くの実例を元にモデル化・体系化を試みた最初の本。 小川 明彦, 阪井 誠 : Redmineによるタスクマネジメント実践技法 Redmineによるチケット駆動開発の実践技法に関する最初の本。アジャイルなソフトウェア開発への適用方法、TestLinkによるテスト管理手法についても言及。 清水 吉男: 「派生開発」を成功させるプロセス改善の技術と極意 組込システム開発をベースとして、ソフトウェア開発特有のスタイルである派生開発、特にXDDPについて解説した世界でも稀な本。既存製品を保守するのではなく継続的に機能追加していく昨今の開発では、派生開発特有の問題を意識しなければならない。XDDPはプロセス論だけでなく、要件定義などの上流工程の品質改善にも役立つので注意。 Le
プログラミングは「ブロックを組み合わせる」感覚に似ている - プログラマの思索
若い開発者に僕が書いた設計書を説明後、プログラムをJSPから書き始めるのか、それともServletから書き始めるのか、聞いてきた。 僕は、まずJSPを動かしてからServletを書いたら、と言ったら、コンパイルエラーばかりで全く進まない。 僕の意図は、JSPやServletを確実に動かしながら、fakeした機能を一つずつ実装していけばいいだろ、ということだった。 結局、若い開発者にValueObjectからボトムアップで書かせたら、コンパイルエラーもなくなり、ようやく書けた。 プログラムを書く時、トップダウンから始めるか、それとも、ボトムアップから始めるか？ ＰＧやＳＥなら一度は、はまった経験があると思う。 【１】プログラミングとは、機能を組み合わせていくこと ＩＴ業界に入った時、先輩から、「プログラマは数学者とは違った能力を要求される。機能を組み立てる感覚が大事だ」と言われた事がある。
複雑度と単体テストケース数の相関関係 - プログラマの思索
garyoさんから、ソースの複雑度と単体テストケース数について有益なアドバイスを示唆してもらったので、メモしておく。 ◆SourceMonitor Version 2.4 SourceMonitorはフリーで、以下の言語のソースのソフトウェア複雑度（McCabeのサイクロマチック数）を測定できる。 例：C++, C, C#, VB.NET, Java, Delphi, Visual Basic (VB6) or HTML ◆McCabe's cyclomatic complexity SourceMonitorで求められる複雑度（McCabeのサイクロマチック数）は、モジュール内の分岐の数（＋ループの数）で計算される。 複雑度の数値は、下記の意味を持つらしい。 10 以下であればよい構造 30 を越える場合，構造に疑問 50 を越える場合，テストが不可能 75 を越える場合，いかなる変更も
Mavenで開発ライフサイクルを制御する - プログラマの思索
Mavenを使う時があり、「Apache Maven 2.0入門 Java・オープンソース・ビルドツール 」を参考にした。 Mavenを実際に使ってみて、概念や経験を整理してみる。 【１】Mavenとはビルドツールの標準テンプレートである MavenはJavaのビルドツールである。 Antも同様だが、Mavenの特徴は汎用ビルドツールのテンプレート版みたいなもの。 Mavenには下記の主要な概念、仕組みがある。 1-1.アーティファクト Mavenによって作られるプロジェクトの成果物を指す。 一般には、JAR、WAR、EARファイルなどのコンポーネント。 他に、JavaDoc、JUnitテストレポート、DJUnitレポート(カバレッジのレポート)も含まれる。 1-2.POM（Project Object Model） ビルドするための情報(メタデータの構造)が定義されたファイルのこと。 普
ITガバメントとは何か？ - プログラマの思索
小川 明彦, 阪井 誠 : チケット駆動開発 日本のソフトウェア開発の現場で生み出された「チケット駆動開発」という概念を、数多くの実例を元にモデル化・体系化を試みた最初の本。 小川 明彦, 阪井 誠 : Redmineによるタスクマネジメント実践技法 Redmineによるチケット駆動開発の実践技法に関する最初の本。アジャイルなソフトウェア開発への適用方法、TestLinkによるテスト管理手法についても言及。 清水 吉男: 「派生開発」を成功させるプロセス改善の技術と極意 組込システム開発をベースとして、ソフトウェア開発特有のスタイルである派生開発、特にXDDPについて解説した世界でも稀な本。既存製品を保守するのではなく継続的に機能追加していく昨今の開発では、派生開発特有の問題を意識しなければならない。XDDPはプロセス論だけでなく、要件定義などの上流工程の品質改善にも役立つので注意。 Le
プログラマの思索: TestlinkがExcelのテスト仕様書よりも素晴らしい点
TestLinkはオープンソースのWebのテスト管理ツール。 TestLinkがExcelのテスト仕様書よりも素晴らしい点を書く。 【0】インストールが超簡単 XAMP＋TestLinkが一体化されたパッケージがある。 解凍して起動するだけ。 USBメモリに入れて持ち歩くことさえできる。 【1】テストケースを再利用しやすい シナリオベースのテストケースは、運用保守や2次開発でも頻繁に使う。 実際は、1次開発で使ったテストケースを複製して、仕様変更や追加機能を反映させる。 この時、Excelのテスト仕様書から該当のテストケースを抽出したり、変更するのに手間がかかる。 また、テストケースは書く人によって、粒度や書式が大きく異なる時が多い。 後の保守で再利用できなかったりする。 TestLinkの場合、テストケースはDBにあるから複製が簡単。 また、TestLinkの入力フォーマットが固定されて
@daipresentsさんのRxtStudyとshinagawa.redmineの講演資料を解読してみる #RxtStudy #47redmine - プログラマの思索
@daipresentsさんのRxtStudyとshinagawa.redmineの講演資料を解読してみる #RxtStudy #47redmine @daipresentsさんのRxtStudyとshinagawa.redmineの講演資料を@sakaba37さんと読みながら、自分が理解してなかった点がたくさんあることが分かった。 気付いたことをメモ書き。 間違っていたら後で直す。 【shinagawa.redmineの講演資料】 【1】SVNリポジトリのスケールアップ チケット駆動開発の特徴は、ITSにSCM連携の機能があることで、トレーサビリティやソース変更履歴を即座に確認できる利点がある。 しかし、5人ぐらいの小規模開発チームから数百人以上の大規模な組織で運用する場合、SVNリポジトリがダウンしてしまうケースが出てくる。 そもそもRedmineのようなOSSのITSでは、大規模な運
ソースインスペクションを真面目にやるGoogle、MS - プログラマの思索
GoogleやMSがソースコードレビューを真面目にやっている下記の記事を何度も読んで、ソースコードレビューシステムを何とか導入できないか模索している。 【元ネタの記事】 Googleのコードレビュー MS内部のソフトウエア開発手法の話 Review Board - コードレビューをオンラインで VMWareの開発でも利用されているソースコードレビュー共有ソフトウェア「Review Board」 ソースコードインスペクションの重要性は、二人の目による品質管理だけでなく、設計思想を共有する重要な手段と捕らえるべきだと思う。 プログラミングは誰でも癖があり、時に品質をすごく落とす。 だから、他の人に手軽に見てもらい、チャットのようにレビューをコメントしてもらうようなスタイルにしたい。 そうすれば、ソースインスペクションという技術者同士で熱くなりがちな議論を会話するような雰囲気に持ち込みやすいから
メール駆動開発は時代遅れではないか - プログラマの思索
マネージャになるほど膨大な量のメールを処理するのが主な仕事になってくる。 また、SEの仕事の殆どは、顧客やメンバーからのメールや添付されたExcelを元に、設計書をどんどんブラッシュアップしていくことだ。 倉貫さんのつぶやきを読んで、同感すると共に、果たしてそれが本当に良いことなのかラフなメモ。 【元ネタ】 Twitter / @kuranuki: メールで5人とかに送って、ひとりtypoとかで届かなかったときの残念さったらない。もう一度5人に送り直すか、その人だけに送り直すか。前者は他の人にはウザいし、後者はこれからの返信に漏れるし。もう複数人でのメールやだ。 Twitter / @kuranuki: メールでは手紙で出来ること以上のことをやっちゃいけないんだよ。 Twitter / @kuranuki: メールのccにいつまで偉い人を入れておくのか判断が難しい。遠慮なく入れた方が良いの
チケット駆動開発の適用範囲 - プログラマの思索
日本のSI企業がチケット駆動開発について記事を書かれていたのでメモ。 以下ラフなメモ書き。 【元ネタ】 「チケット駆動開発」の適用について考える｜コラム「ITよもやま話」｜特集│株式会社JSOL 補完チケット方式はチケット駆動開発の先祖返り: プログラマの思索 [#TiDD] チケット駆動開発によるアダプタブル・ウォータフォール開発 #agileto2011: ソフトウェアさかば ユーザの力を利用するアジャイル開発: プログラマの思索 チケット駆動開発の戦略: プログラマの思索 僕はチケット駆動開発がどこまで知名度が上がっているのか、正直知らない。 でも、チケット駆動開発のアイデアをアジャイル開発だけでなく、従来のWF型開発にも適用すればその恩恵が受けられるのではないか、という意見は、既に@sakaba37さんたちが色々試されている。 チケット駆動開発をWF型開発に適用する場合、「チケット
ビジネス特化SNS「Linkedin」から見えるもの～人脈はデータマイニングで作られる - プログラマの思索
2009年はTwitter、2010年はFacebookが流行して、ビジネスだけでなく政治まで大きな影響を与えている。 ビジネス特化SNS「Linkedin」がこれから流行するかもという記事を見つけたのでメモ。 Linkedinは使ったことが無いので、ラフなメモ書き。 【元ネタ】 [jp]ビジネスSNSのLinkedInが6月ごろに日本語化か――現在日本語の翻訳者を採用中 シリコンバレーでは常識，850万人が使うビジネス特化SNS「Linkedin」 - ニュース：ITpro Linkedinの魅力 | Linkedinの使い方を日本語でわかりやすく解説！ 「LinkedIn」は、次のFacebookになり得るか？ | その他（IT） | 毎日がアップデート | あすなろBLOG Facebookやツイッターなどのソーシャルメディアが通販サイトにお客をどれだけ流しているかを調べてみる(20
エンピリカルソフトウェア工学をチケット駆動開発がサポートする - プログラマの思索
エンピリカルソフトウェア工学(実証的ソフトウェア工学)に関する記事を見つけたのでメモ。 【元ネタ】 「少人数のチームの方がソフトウェアの品質は高い」実証的ソフトウェア工学の研究会が開催 － Publickey 少人数のチームの方がソフトウェアの品質は高い - 思考のスキマ 【参考】 ソフトウェア・リポジトリ・マイニング～Web2.0をソフトウェア工学に応用する: プログラマの思索 BTSをBusiness Intelligenceとして使う: プログラマの思索 Web2.0時代のプロジェクト管理: プログラマの思索 アジャイル開発の弱点をプロジェクト管理サーバーが助ける: プログラマの思索 チケット駆動開発が進むべき道part2～プロジェクト管理サーバーは開発チームの資産: プログラマの思索 エンピリカルソフトウェア工学は、ソフトウェア工学を科学実験のように実証的に確かめていく分野の学問。
プログラマの思索: ツールが開発プロセスを改善する
Redmineでチケット駆動開発(TiDD)を運用して気付いたことは、開発プロセスが大きく改善されただけでなく、従来の開発プロセスの弱点が浮き彫りになったこと。 下記の記事を読んで考えたことを書いてみる。 【元ネタ】 ケント ベック氏のアジャイル開発における開発支援ツールの役割についてのホワイトペーパー 元請SIerがTracのような環境を提供できない３つの理由 - なからなLife 元請け企業が用意すべきもの - T/O 【1】強力な構成管理ツールが無い時代はライブラリアンが独裁者 構成管理の基本は、任意のバージョンのシステムを再現できること。 今時、Subversionのようなバージョン管理ツールの無いSW開発プロジェクトはありえないだろう。 CVSやVSSが無かった頃は、構成管理ツールなど存在せず、構成管理を人手でやるしかなかった。 今でも、Excelなどの設計書はバージョン管理で制
障害記録票と問合せ管理簿の2重管理問題 - プログラマの思索
応用情報技術者試験で、インシデント管理をExcelの障害記録票と障害管理簿で2重管理していた問題が出ていた。 この手の不手際がよくありそうなのでメモ。 以下ラフなメモ書き。 【元ネタ】 平成22年度春期試験 応用情報技術者試験（AP）午後問題 平成22年度春期試験 応用情報技術者試験（AP）午後問題解答 上記の問11にITILのサービスサポートのインシデント管理の問題がある。 問題の詳細は省略。 その事件として、まずかった点は二つある。 問合せ管理簿で、他の問合せの最新状況が反映されていなかったために、過去直近の問合せと原因は同じと判断を誤ったこと。 もう一つは、問合せ管理簿に、プログラム改修の要否や改修予定日などが書かれていなかったために、ユーザに正しい情報を即答できなかったこと。 ITの運用保守業務では、インシデント管理ではまず障害の暫定措置や早期復旧を最優先にして、根本原因の解決は
HTML5のオフライン機能の可能性 - プログラマの思索
HTML5のオフライン機能の可能性についてメモ。 【元ネタ】 HTML5で、オフラインでも使えるiPod/iPhone超簡単アプリっぽいものを作ってみた － Publickey Web利用はオフラインに拡大へ，企業アプリも変わる？ - 最新ブラウザが描く次世代Webの輪郭：ITpro HTML5を使うと、ネットワークに接続しない状態でもオフラインでWeb画面を見ることができる。 仕組みとしては、キャッシュとして残したり、SafariやFirefoxなどのブラウザに搭載されたSQLiteに必要な情報を保存しておく。 この仕組みによって、iPhoneでオフラインでメールを見たり、Webページを見ることができる。 HTML5のオフライン機能はそんなにすごい実装ではないだろうが、Ajaxが出現した頃を思い出させる。 AjaxもHTML5もWebアプリをデスクトップアプリのように、セッション切れや画
バージョンのないRedmineプロジェクト～TiDD初心者が陥りやすい罠 - プログラマの思索
TiDD初心者が陥りやすいアンチパターンを実際に見つけたのでメモ。 【1】チケット駆動開発の概念に慣れておらず、Redmineでタスク管理をまず始めた人に多い特徴がある。 それは、バージョンが設定されておらず、ロードマップが空っぽないし非表示な状態。 話を聞くと、Redmineのバージョンの意味や使い方が理解できないらしい。 だから、彼は、Redmineのチケット一覧画面でタスク管理を実施している。 彼のチケット一覧画面を見ると、スクロールできないくらい、たくさんのチケットが無造作に一覧表示されている。 どうやら、必要なタスクはチケットに登録しているが、彼のチケット管理を見ていると、チケットの納期が意識されていない。 そのチケットはいつリリースするのか？の観点が漏れているみたい。 何故なら、チケットがたくさんありすぎて、どのチケットが必要なのか、チケット一覧画面では分かりにくいからだ。 だ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
