Redmineのチケット駆動開発の面白さは、最初は課題チケットでしかなかったのに、いつの間にか作業チケットに変わった、というように、チケットにストックとフローの二重性を持たせて、チケットに複数の意味を持たせている点にあると思う。 以下、ラフなメモ書き。 【参考】 Redmineによるチケット駆動開発はストック型プロセスとフロー型プロセスの二面性を持つ: プログラマの思索 ストック型チケットは記憶媒体、フロー型チケットは流通媒体: プログラマの思索 チケット管理システムは作業の構成管理と同じ: プログラマの思索 【1】以前、下記のツイートがあった。 最初はRedmineでチケット管理して上手く回っていたのに、ガントチャートで厳しく管理し始めたら、内容が空っぽのチケットが大量発生して、チケット駆動でなくなった、というアンチパターン。 【1-1】 akipiiさんのツイート: "ガントチャートは

2018年4月現在、Redmineの今後の課題について考えてみる。 以下はラフなメモ書き。 【1】Redmine大阪や東京Redmine勉強会にスタッフとして活動してきた中、参加者も大幅に増えて、参加者層も初心者から経験者まで広がり、業種もIT業界だけでなく特に製造業にも広がっている印象を持っている。 たぶん、RedmineはRailsアプリ、そしてチケット管理ツールの中で、日本で最も普及したアプリの一つだろう、と思う。 しかし、技術革新の流れが早い中、Redmineにも課題がチラホラ見えてきたように思う。 僕は、Redmineの直近の課題は、Redmineのシングルページアプリケーション化、Redmineのコンテナ化、Git連携の強化だろうと思う。 【2】1つ目は、RedmineのUIが古臭いと言われる問題意識だ。 たとえば、スマホに慣れていると、Redmineのように画面更新のたびにリ

以前、Excel設計書をテキスト化できないか、考えたことがあった。 ネットしながら、PlantUMLや他ツールを使ってExcel設計書をテキスト化するアイデアをメモ。 以下は、後で自分が参考にしたい記事をリンクしておく。 仕様書にもExcel脱却が求められている: プログラマの思索 【参考1】 PlantUML 埋め込み AsciiDoc の Gradle を用いた HTML 一括変換 ・ Yutaka ?? Kato 【参考2】 AsciiDoc と PlantUML と mermaid.js で素敵なテキストベース仕様書ライフ 【参考3】 PlantUML を導入するのに適したケースとは - kkeisuke blog (引用開始) 以下のいずれかに当てはまる場合、PlantUML はプロジェクトの生産性を向上させます。 一人で利用する場合 少数精鋭、もしくは統制(教育)されたチームで

最近のツイートで、アジャイル開発には要件定義工程はあるのか、というテーマで、DOAモデラーとアジャイル系のアーキテクトの間で議論があった。 内容がとても奥深い。 僕はまだ自分の考えをまとめきれていないので、自分が後で参考にしたいためにリンクしておく。 以下、ロジカルでないラフなメモ書き。 【参考】 @yusuke_arclampさんのまとめ記事が公開されました。 アジャイルにおける事前合意について - arclamp 【1】エンタープライズアジャイル勉強会　2017年12月セミナー開催のお知らせ アジャイルを機能させる外枠について - arclamp (引用開始) アジャイルを機能させる2つの外枠 1つ目の外枠は「何を作るべきか」という観点。 チームが何を作るべきか、という手前には「そのチームが実現すべき価値とは何か」をきちんと考える必要があります。この点はギルドワークスの市谷さん（@pa

「過剰と破壊の経済学-「ムーアの法則」で何が変わるのか」を気軽に読んでいたら、ブルックスの人月の神話の一節が書かれていて、今頃になって、すごく腑に落ちたのでメモ。 ブルックスの人月の神話の文章のうち、自分が理解できたことを、ラフなメモ書き。 以下は書きかけ。 【参考】 第0回：人月の神話とはなんなのか？（解説編）｜本気で読み解く”人月の神話” | GiXo Ltd. 第2回：銀の弾は無いけど、”銃”はあるよね｜本気で読み解く”人月の神話”（第16章） | GiXo Ltd. ソフトウェア開発とは、現実世界の複雑さをプログラムコードの難しさに置き換える作業だ - セカイノカタチ ソフトウェア開発でよく言われる「銀の弾丸など無い」とはどういう意味なのか本を読んでみた。 - 感謝のプログラミング 10000時間 【1】ソフトウェアの複雑性は本質的な性質であって偶有的なものではない。 「過剰と破壊

Redmineのようなチケット管理ツールがとても威力があっても、上司や経営者が見なければExcelがはびこってしまう事例を見かけたのでメモ。 チケット管理ツールに限らず、営業支援システム、日報システム、経営状況の見える化の為の情報系システムでも同様の症状がよく発生する。 【参考】 golangでRedmineの情報をExcelにするコマンドラインクライアントを作った - write ahead log Big Sky :: コマンドラインからredmineを扱える「godmine」作った。 【1】(引用開始) SIerに所属している方ならわかると思いますが(あんまりわかって欲しくもないですが),体質の古い会社だとRedmineを使っていても「Excel表がない」と文句を言われたりします. 面倒なのが「プロジェクト一覧表がない」とか「課題管理表がない」とか「バグ一覧表がない」とか....et

「技術的負債だらけのチームで技術マネージメントしてみた」の公開資料が素晴らしいのでリンクしておく。 【参考】 akipiiさんのツイート: "すごく良い資料。RT @yassan168: #kichijojipm 発表資料upしました。誰かの役にたてば良いのだけど。connpassにもUPしています。＞技術的負債だらけのチームで技術マネージメントしてみた https://t.co/3R25aUnI4S" 前任の仕事を引き継ぎしたら、下記の問題があったらしい。 技術的負債込みで引き継いでしまった、という例は、本当によくある。 (引用開始) １年前の状態 ・すべてがメールベース ・ドキュメントはほぼ無い ・最強の属人化。個人のパワーで乗り切る ・技術に関心が無く誰も行動しない ・暫定スクリプトが今も元気に本番稼働中 ・ソースには、ほぼコメント無し ・hoge.pl.(日付) 形式のソース管理

技術的負い目の記事がすごいのでリンクしておく。 【元ネタ】 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によるタスクマネジメント実践技法 Redmineによるチケット駆動開発の実践技法に関する最初の本。アジャイルなソフトウェア開発への適用方法、TestLinkによるテスト管理手法についても言及。 清水 吉男: 「派生開発」を成功させるプロセス改善の技術と極意 組込システム開発をベースとして、ソフトウェア開発特有のスタイルである派生開発、特にXDDPについて解説した世界でも稀な本。既存製品を保守するのではなく継続的に機能追加していく昨今の開発では、派生開発特有の問題を意識しなければならない。XDDPはプロセス論だけでなく、要件定義などの上流工程の品質改善にも役立つので注意。 Le

「開発組織のマネジメント」のスライド資料が素晴らしいのでメモ。 資料の内容を理解したレベルで書く。 【1】問題意識としては、最近15年でWeb開発は従来よりすごく難しくなり、重要度が増している。 付け焼刃で簡単にプロダクトを作れるレベルではなくなった。 その理由はいくつかある。 一つは、開発基盤やシステムがレガシーであるため、ビジネスの変化に追いつけないこと。 2つ目は、企画チーム・開発チーム・運用チームのそれぞれで異なるやり方が根付いており、押し問答の状態になっていること。 サイロ型組織故に、開発組織の行動が局所最適化されてしまい、全体最適になっていない点に問題がある。 本来解決されるべき姿は、レガシー化を防ぐ作業に継続的に取り組むことと、サイロ型組織から自己組織化されたチーム構造へ組織を変化させること。 チームが都合で解散されるようでは、習熟度はいつまで経っても向上しない。 【2】一番

AgileTourOsaka2014に参加してきた。 テーマは「パタン特集」。 パターン言語とは何か、現場の経験知をパターン言語にするコツが分かった。 とても有意義な勉強会だった。 ラフなメモ書き。 【元ネタ】 10月11日 AgileTourOsaka2014 Agile Tour Osaka 2014でパタン・ランゲージのワークショップを担当しました AgileTourOsaka2014 #agileto2014 のまとめ - Togetterまとめ KenColle/AutomationPatternLanguage パターンを使うもう一つの動機～パターン言語の構築よりも設計・実装・運用のノウハウをカタログ化する: プログラマの思索 パターン言語の構造と事例集: プログラマの思索 「アジャイルに効く アイデアを組織に広めるための48のパターン」の感想～エバンジェリストが自分のアイデア

「APIデザインの極意」の感想Blogがとても素晴らしいのでメモ。 「APIデザインの極意」を買おうと思ったら、台風で警報が出ており、買いに行けないのが残念。 ラフなメモ書き。 【元ネタ】 アジャイルAPI設計時代の到来！？APIデザインの極意を読みました。 - シスアーキ in はてな ソフトウェア再利用の概念: プログラマの思索 ソフトウェア部品化の幻想: プログラマの思索 SIerの俺様フレームワークは最悪に激しく同意: プログラマの思索 【1】ソフトウェア再利用の概念としては、ホワイトボックス再利用、ブラックボックス再利用の2種類の区別がある。 ブラックボックス再利用とは、再利用資産を変更なしでその まま利用する。 よくある例は、GUIコンポーネントや数値演算ライブラリなど。 例えば、DLL、Jar、Exeなどのバイナリの実行ファイルが相当するだろう。 ホワイトボックス再利用とは、

僕が使い始めた2008年頃と違って、現在はかなりRedmineが普及している。 ソフトウェア開発者だけでなく、製造業や製薬業、営業や事務、勉強会のタスク管理に使っている事例も多い。 最近特に目立つのが、初心者がRedmineを使っているものの、Redmineの良さを出し切れていない場面。 上記の資料では、「Redmineは、チームでチケットを消すゲーム」と定義して、わかり易く説明しているのがすごくいい。 アジャイル開発では、XPの計画ゲーム、Scrumのプロダクトバックログのように、ストーリーやタスクをチケット化して、イテレーション(Redmineならバージョン)単位にグループ化して、リリースしていく戦略を取る。 すると、チケット管理とは、チームでチケットを消すゲームなのだ、と感覚で分かるようになる。 この辺りの感覚は、40代以上の中年SEよりも、20代の若手PGの方がすぐに馴染んでくれる

2014年になって、ITの地殻変動がどこに起こっているのか、を考えてみる。 ＃ラフなメモ書き。 【1】最近感じることは、Webアプリをプログラミングするアプリケーションエンジニアよりも、サーバー基盤を構築するインフラエンジニアの方が目立つというか輝いて見える時が多い。 何故なのだろう？ また、先月の日経BP主催のITアーキテクト カンファレンスでは、エンタープライズシステムの構築に携わるITアーキテクトを対象にしているが、その内容はすべて、クラウドがキーワードだった。 DOAやOOAは全く含まれていない点が衝撃だった。 ITアーキテクト カンファレンス 2013 最近の流れを見ると、アーキテクチャ設計の技術では、DOAやOOAは既に古い技術であり、クラウドが席巻しているように見える。 【2】最近のバズワードである「クラウド」には、否定的な意見を持つ人も多い。 ITの歴史の延長線上にあるだけ

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

ChefやPuppetなど、サーバー構築をプログラムで作成する時代になってきた。 しかも、サーバー構築を構成管理とTDDで作業するのが最近の流れのようだ。 クラウドが当たり前の時代になった今、もう一つの技術革新が生まれているように思う。 クラウドについてはまだ理解不十分だけれども、気になる記事をメモ。 【元ネタ】 Chefのテストスイーツを色々試してみた （1） - カイワレの大冒険 Chefのテストスイーツを色々試してみた （2） - カイワレの大冒険 Chefサーバを動かすまでの方法をまとめてみた（自動化のススメ） - カイワレの大冒険 2008年出版された「ThoughtWorksアンソロジー ―アジャイルとオブジェクト指向によるソフトウェアイノベーション」では、ラストマイル問題が提示されていた。 ラストマイル問題とは、いくらソフトウェアを作っても、本番環境へリリース＆稼働確認するの

「44のアンチパターンに学ぶDBシステム」を読んでみて、とても優れたアーキテクチャ設計のアンチパターン集に思えた。 過去の経験上、あるあると思う箇所がたくさんあった。 感想をラフなメモ書き。 【元ネタ】 44のアンチパターンに学ぶDBシステム - give IT a try あなたの現場にも必ずあるDBシステムの"悪い例"が満載！「44のアンチパターンに学ぶ DBシステム」 | oracletech.jp 『44のアンチパターンに学ぶDBシステム』 - 虎塚 44のアンチパターンに学ぶDBシステム : 賢者の図書館 (Under Construction) : livedoor Blog（ブログ） 【本】SQLをしっかり学習したい人におすすめミック本。 | ﾌﾟﾗﾌﾟﾗ式技術系 Access流! 【本まとめ】44のアンチパターンに学ぶシステム構築時の失敗パターン。もっとはやく言ってよーとな

「勝つための論文の書き方」「創造的論文の書き方」「これから論文を書く若者のために」を読んでみて、論文作成の技法をまとめたみた。 但し、僕は優れた学術論文を書いた経験はないので、想像の部分がある。 ラフなメモ書き。 【元ネタ】 われわれはどのように論文を書いているか（1/12）: 主体性確立のための「弁証法・認識論」講義 われわれはどのように論文を書いているか（2/12）: 主体性確立のための「弁証法・認識論」講義 われわれはどのように論文を書いているか（3/12）: 主体性確立のための「弁証法・認識論」講義 われわれはどのように論文を書いているか（4/12）: 主体性確立のための「弁証法・認識論」講義 われわれはどのように論文を書いているか（5/12）: 主体性確立のための「弁証法・認識論」講義 われわれはどのように論文を書いているか（6/12）: 主体性確立のための「弁証法・認識論」講義

エリック・エヴァンスのドメイン駆動設計の本を一通り読んでみて、何かすっきりしない感想を持っていた。 @sakaba37さんや@jp_watanabeさんと議論して、すっきりしない原因がようやく分かったのでメモ。 ラフなメモ書き。 【元ネタ】 ドメイン駆動設計: プログラマの思索 ドメイン駆動設計よりもパターン本が好き: プログラマの思索 ドメイン駆動設計はソフトウェアプロダクトラインとオブジェクト指向分析のミッシングリング: プログラマの思索 DOAとOOAの違い: プログラマの思索 Agile開発に足りないもの～モデリング技術: プログラマの思索 ドメイン駆動設計の本の違和感は二つある。 一つは、分析と設計を区別せず、設計中心の技法ばかり説明していること。 もう一つは、過去のオブジェクト指向設計との違いがはっきり理解できていなかったこと。 前者は、「ドメイン駆動設計」というタイトル通り「