« 2014年10月 | トップページ | 2014年12月 »

2014年11月

2014/11/30

Redmineはプロジェクトを横断して使うべきか否かという議論の感想

Redmineはプロジェクトを横断して使うべきか否かという議論をTogetterにまとめた。
過去の僕の経験を踏まえながら、Redmineの運用スコープはどこまでなのか、を振り返ってみる。
ラフなメモ書き。

【元ネタ】
Redmineはプロジェクトを横断して使うべきか否か - Togetterまとめ

【1】当初は、メンバー3人で、短期間の受託開発案件をこなしていた。
その時、Redmineを導入して、Redmineの機能を一つずつ試しながら、アジャイル開発の実現方法を習得していった。
少人数のメンバーで1個のチームだけだから、イテレーションごとにRedmineの運用ルールを軌道修正して、アジャイル開発のプラクティスを1個ずつ試していけた。

一番の発見は「イテレーション・リリースバージョン・マイルストーン一致の原則」と「プロジェクトとブランチ一致の原則」だった。
「イテレーション・リリースバージョン・マイルストーン一致の原則」を実装したプラクティスが「小規模リリース」であり、「プロジェクトとブランチ一致の原則」から「プロジェクトのライフサイクル」「ブランチのライフサイクル」という概念の意味を体で体験できた。

TiDD初心者が陥りやすい罠~マイルストーンの役割を誰も理解していない: プログラマの思索

でも、試行錯誤は結構あった。
僕が良かれと思ったトラッカーではステータスが足りなくて、実は、テスターが作業中であるステータスを作る必要があるとか、似たようなトラッカーをたくさん乱発して逆に混乱した時もあった。
前者は「足りないステータス」、後者は「乱発されたトラッカー」というアンチパターン。

とはいえ、1チームだけのRedmineは運用しやすかった。
アジャイル開発を自由に試すには都合が良かった。
運用ルール変更の影響範囲は、1チームだけだったから。

【2】Redmineの運用を大規模化したい、という意図はずっとあった。

Redmineの大規模化の壁: プログラマの思索

Redmineの複数プロジェクト機能を使えば、複数チームや複数案件のプロジェクト管理は可能だから。
でも単純に、大規模受託案件をそのままRedmineに適用するのは、しっくりこないだろう、というのは感じていた。

以前、Mantisを使った経験があり、Mantisには親子プロジェクトの機能があったから、工程単位にMantisプロジェクトを作って運用していた。
しかし、その運用は「工程単位のプロジェクト」というアンチパターンにはまっており、本番リリース前は良くても、その後の運用保守では、しっくりこなかった。

他にも、Redmineのチケット管理にWF型開発をそのまま適用して、Redmineバージョンを工程に割り当てる「工程単位のバージョン」のアンチパターンにはまった事例もみてきた。

WF型開発にとらわれすぎたTiDDのアンチパターン #tidd: プログラマの思索

WF型開発の工程をそのままRedmineに適用すると、チケット管理の効果が得られない、という経験があったから、僕なりに色々工夫した。
例えば、大規模案件では、各チームのタスク管理プロジェクトとは別に、CCB(変更管理委員会)が使う課題管理プロジェクトをもうけて、週1回は各チームリーダーが出席して棚卸する場を作ってみた。

あるいは、Rootとなる第1階層に事業部プロジェクトを作り、第2階層以下に各チームまたは各案件を配置し、親プロジェクトから複数プロジェクトを横断して進捗管理できるようにしてみた。

個人的には、約100人で約50案件のプロジェクトでうまく回せたから、たぶん、それ以上の規模でも運用可能だろうと思う。

【3】SIでは、大規模受託開発案件だけでなく、小規模な保守案件を1個のチームが担当してやり繰りする場合もある。

こういうチームでは、バージョンやロードマップを全く使わない「空っぽのロードマップ」アンチパターンをよく見かける。
彼らは、イテレーションまたはマイルストーンという区切りを実感しない場合が多いみたいだ。

バージョンのないRedmineプロジェクト~TiDD初心者が陥りやすい罠: プログラマの思索

だから、僕は、毎月の作業報告のタイミングでRedmineバージョンを設定するように運用した。
保守案件だから、月末にアクセスログやSLAの報告が必ずあるから、それらの目標に向けた作業を登録するとか、当月中にやるべきタスクを登録するように、メンバーに声掛けした。

その結果、イテレーションごとにVelocityを自然に集計できるようになり、毎月の作業予定量を把握しやすくなったから、イテレーションの意味が分かるようになったみたい。

TiDD初心者が陥りやすい罠~バージョンをCloseしないRedmineはVelocityが分からない: プログラマの思索

また、小規模な保守案件をRedmineプロジェクトに割り当てるのは良いが、Redmineプロジェクトを階層化しない「サイロ型プロジェクト」アンチパターンもよく見かける。
だから、複数の保守案件をまたがった進捗管理がやりにくく、担当者の作業負荷や開発予定表を把握しにくいみたいだ。

だから、全ての保守案件のRedmineプロジェクトは、チームの親プロジェクトの配下に階層化させるようにした。
そして、Redmineプロジェクトに入れるほどではない中規模ないし小規模なタスクは、親子チケットでWBS化する方法や、Redmineバージョンにリリース対象機能を割り当てるパーキングロットチャートの方法を採用した。

個人的には、小規模な保守案件を抱えるインフラチームやソフトウェア保守チームこそ、Redmineによるチケット駆動開発は有効だと思っている。

【4】とはいえ、Redmineの運用が最初からうまくいったわけではない。
部署や会社を変わるたびにRedmineを入れて、チケット管理の運用ルールをWikiに書いて、運用を普及させようとしたが、どのRedmineでも、トラッカーやカスタムフィールドは全く違う。

Redmineのトラッカーやカスタムフィールドを一度作って運用した後、削除するのは非常に危険だ。
なぜなら、チケットの履歴が表示されなくなる可能性があるからだ。
だから、トラッカーやカスタムフィールドは野放図に増えてしまいがちだ。

特に、Redmine運用に慣れていない部署の場合、試行錯誤の段階で、あのトラッカーやカスタムフィールドは間違っていたね、と気づく時もあるが、その時はもう遅い。

でも、僕はそれでいいと思っている。
チケット管理の運用で試行錯誤するのは当たり前だし、試さなければ分からないことが多いから。

もし、Redmineを綺麗にしたかったら、新しいRedmineのインスタンスを作って、データ移行して作り直せばいい。
また、プログラマ上がりのプロジェクトリーダーが多く、マネジメントに詳しくなければ、チケット管理でたくさん実験してみたらいい。

Redmineによるチケット管理でプロジェクト管理を実験してみたら、アジャイル開発のプラクティス、PMBOKの9つのプロセスエリアの概念、ITILに書かれている運用保守プロセスの概念が自然に分かってくるはずだ。
Redmineで運用するのが目的ではなく、Redmineによるチケット駆動開発を通じて、それぞれのプロジェクトリーダーがマネジメントスキルを身につければいいのだから。

| | コメント (0)

2014/11/29

「フレームワークで人は動く」の感想~論理フレームワークだけではく人を動かすフレームワークも大事

フレームワークで人は動く」の感想をメモ。
「論理フレームワークだけではく人を動かすフレームワークも大事」というメッセージが印象に残った。
ラフなメモ書きなので、論理は飛んでいる。

【元ネタ】
【新刊のお知らせ】 『フレームワークで人は動く』 : タフ&エレガントな日々Ⅱ

人を動かすのにも「フレームワーク」がある?コンサルタント直伝のノウハウとは。 (ビジネスブックマラソン) - Yahoo!ニュース BUSINESS

読んだら書く! フレームワークで人は動く

akipiiさんはTwitterを使っています: "夏目漱石の『草枕』の冒頭。智に働けば角が立つ。情に棹させば流される。意地を通せば窮屈だ。兎角に人の世は住みにくい。そこで智(コト系)と情(ヒト系)で使い分けか。【新刊のお知らせ】『フレームワークで人は動く』: タフ&エレガントな日々Ⅱ http://t.co/2o2VJIGLGZ"

【1】ビジネスで用いるフレームワークには2種類ある。

それは、コト系フレームワークとヒト系フレームワーク。
コト系フレームワークは、物事を整理して分析するのに役立つ。
ヒト系フレームワークは、ヒトを巻き込んでチームを運営するのに役立つ。

【2】既存のビジネスで使われるフレームワークは、普通は、コト系フレームワークを指す。
例えば、ロジカルシンキング、SWOT分析、3C、ファイブフォース、BSC、マインドマップ、など、概念や問題を整理して深掘りしたり、アイデアを創出する。

しかし、実際の現場では、「組織が感情を持っている」。
いくら論理的に主張を構築しても、周囲の人が理解して納得して、行動してもらえなければ、いくら変革のメッセージを言っても、何も変わらない。

ヒト系フレームワークはそんな時に役立つ。
例えば、タックマンモデル、ハーマンモデル、ジョハリの窓、経験学習モデルなどがある。
それらフレームワークを使って、寄せ集めのメンバーから成るチームを有機的にさせて、チームの能力を飛躍的に向上させる。
あるいは、懐疑的な利害関係者を説得し、納得してもらい、逆に、変革の行動を起こしてもらうようにする。

僕のイメージでは、ヒト系フレームワークは、プロジェクトファシリテーションの一種に含まれるかなと思う。

この辺りのビジネスフレームワークの一覧をざっくり見たい時は、「ビジネス・フレームワーク (日経文庫ビジュアル)」がお勧め。
戦略立案、マーケティング、問題解決、マネジメント、組織開発のフレームワークが一通り紹介されている。
例えば、コト系フレームワークは、戦略立案、マーケティング、問題解決、ヒト系フレームワークは、マネジメント、組織開発に相当するだろう。

【3】新しいことを実行しようとすると、たくさんの利害関係者のベクトルを合わせるという「調整」が必要になってくる。
フレームワークで人は動く」には、ステークホルダータイプとして、「アイコン」「インフルエンサー」「ネットワーカー」の3種類を上げている。

アイコンとは、その組織や仕事の価値観を体現している人。
例えば、カリスマと呼ばれる人、高度な技術を持つエンジニアなどが相当するだろう。
アイコンのような象徴的な人物が変革に同意するかどうか、という言動や意見を見て、周囲の人も追随してしまいがちだから。
だから、アイコンを巻き込んで味方に引き寄せる時もあれば、アイコンを引き寄せられなければ更迭して周囲に変革のメッセージを伝える場合もある。

インフルエンサーとは、組織や集団の熱気ややる気を変えられる人。
例えば、ムードメーカーやチームリーダーが相当するだろう。
変革プロジェクトでは、インフルエンサーにエバンジェリスト(伝道師)になってもらい、組織に変革のメッセージを伝達する役割を担わせることが大切。
プロセス改善なら、プロセスチャンピオンかな。

ネットワーカーとは、組織や集団内で事情通で、皆がどう考えているかを把握できる人。
例えば、お局様、事務の女性、事務局の人が相当するだろう。
変革者は、ネットワーカーに変革の評判や評価を随時ヒヤリングして、ステークホルダーの動向や周囲の評判を収集する。

【4】「フレームワークで人は動く」は物語風に変革プロジェクトでコト系・ヒト系フレームワークを使ったストーリーがはさまれていて、読みやすい。

システム開発の案件では、システムの導入の目的の一つが業務の変革だったりする。
ERP導入による業務の効率化、ERP導入によるBPRは、単なるシステム導入ではなく、ユーザ企業の現場の人たちも巻き込んで、業務そのものを変えてしまう威力がある。
だから、プロジェクトリーダーは、技術だけでなく、利害関係者を巻き込んで、彼らを説得し、納得してもらい、システムが長く使われるように調整しなければならない。

その時に、単に技術だけでなく、ヒト系フレームワークやプロジェクトファシリテーションのスキルがあれば、無駄な政治闘争に注力することも減り、プロジェクトをコントロールできるようになるだろう。

この辺りの内容も、自分の経験も含めて整理してみたい。

| | コメント (0)

2014/11/27

astah SysMLのROS連携プラグイン

astah SysMLのROS連携プラグインの記事があったのでメモ。
ROS(an open-source Robot Operating System)のモデルをastah SysMLでリバースしたりエクスポートできるらしい。

【参考】
astah* Users Community Site - フォーラム SysML - Ros連携プラグイン

[Project] ROS + SysML (astah-plugin) ≪ Sugar Sweet Robotics

自律ロボット開発にROSを使うべきいくつかの理由 - MY ENIGMA

ソフトとハードの交差点:ROSとRTミドルウェアの比較 - livedoor Blog(ブログ)

(引用開始)
ROS (Robot Operating System) は,ロボットシステムをプロトタイピングするのにはとっても便利なんですが,システムデザインを行う工程との親和性に関してはあんまり論じられてない感じがします.
この辺はRTミドルウエアがよく出来てる.
んで,文句ばかり言っても仕方ないので,SysML with ROSということで,作ってみました.
(引用終了)

最近のプログラミング技術の傾向として、Webサービス、クラウドなどのインフラ周り、ビッグデータと統計解析を含めたデータマイニングだけでなく、組み込みプログラミングも盛り上がっているように見える。
例えば、Kinectとか、iOSのヘルスケア・アプリとか、ウェアラブルデバイスと組み合わせたアプリが面白そうだろう。

だが、上記の記事では、自律ロボットのオープンソースのプログラミング環境としてROSというものがあるらしく、フリーの割にかなりのことができるみたい。
SysMLと組合せて、ロボットの動きをモデル化するのは面白そう。

この辺りは僕は全く知識がないけれど、お金の計算やくだらない業務のアプリを作っているよりも、ロボットを動かすためのプログラミングの方がはるかに楽しそうな気はする。
特に、家電メーカーとプログラマが手を組めば、面白い組込製品やデバイス、サービスを生み出すことができるかもしれない。

色々調べてみる。

| | コメント (0)

2014/11/24

書籍「実践反復型ソフトウェア開発」へのフィードバック資料のリンク

実践反復型ソフトウェア開発」の著者の方がフィードバックの資料をまとめていたのでメモ。

【1】「実践反復型ソフトウェア開発」は、アジャイルな開発環境作りに興味のある開発者にお勧めだと思う。
理由は、構成管理・チケット管理・ビルド管理・テスト管理に必要な概念が整理されてまとまっているからだ。

SIの現場では、「実践反復型ソフトウェア開発」に書かれているような概念が暗黙知になっており、本来はベストプラクティスないし守るべき規律としてチームが実践すべきルールが徹底されていない場合が多い。
あるいは、10年以上も以前の古い技術に固執しすぎて、アジャイルな開発を阻害している原因になっている時も多い。

だから、そんな現場には、構成管理・チケット管理・ビルド管理・テスト管理に必要な概念や、ベストプラクティスから得られた形式知をチームで共有して実践すべきだと思う。

僕の感想は以前書いた。

実践反復型ソフトウェア開発を読む part1~ブランチの戦略: プログラマの思索

実践反復型ソフトウェア開発を読む part2~マージの戦略: プログラマの思索

実践反復型ソフトウェア開発の読書会ログ: プログラマの思索

実践反復型ソフトウェア開発を読む part3~再現可能なビルド管理: プログラマの思索

「反復型ソフトウェア開発」はソフトウェア工学の良書: プログラマの思索

【1】「実践反復型ソフトウェア開発」の良い所の一つは、ブランチ管理のポリシーやメインラインモデル、マージ手法について一通りの説明がされていることだ。
構成管理はソフトウェア開発者なら誰もが必要とするお作法なのに、構成管理に関する本は「実践反復型ソフトウェア開発」以外には「パターンによるソフトウェア構成管理」ぐらいしかまともな本がない。

【2】また、「実践反復型ソフトウェア開発」では、チケット駆動開発という言葉は明示していないが、チケット駆動開発に必要な概念やプラクティスが暗黙的に紹介されている点も良い。

例えば、障害管理の下記の運用ルールは、チケット駆動開発のプラクティスにそれぞれ対応している。

・バグを発見したらすぐに起票する→バグをタスク全般に拡張すれば、「Ticket First」
・一件一葉の原則(バグ1件に対し1枚のバグ票を起票する)→「One Matter, One Ticket」
・バグ報告票というボールでキャッチボール→「ペア作業」
・コミットして完了にするタスクは、そのチェンジ番号をタスク票に記入して閉じる→「No Ticket, No Commit」
・バグ報告票がなければ作業を開始しない→「No Ticket, No Work」

【3】個人的には、バグ追跡システム(BTS)が仕掛けかんばんの構造に似ている(P.204)という指摘が一番役立った。
「かんばんがなければ部品の製造を開始しない」「かんばんを通じて、部品や工程の作業実績と追跡する」という仕組みは、まさにチケット駆動開発そのものだ。

とはいえ、仕掛けかんばんがBTSと全く似ているわけではない。
TPSの仕掛けかんばんが、かんばんの流通量で在庫を制御するのに対し、BTSでは、障害票はふやしたくもないのに、いくらでも後から湧き出てくるから、障害の件数を人為的に制御することはできない。

だから、障害票の優先順位付けやチケットのトリアージ、担当者のアサインポリシーで制御する必要がある、という指摘は全く同意する。

トヨタのかんばん方式とバグ追跡システムの密接な関係: プログラマの思索


| | コメント (0)

Redmine 2.0対応のニコカレプラグインのリンク

Redmine 2.0対応のニコカレプラグインが公開されていたのでメモ。

【元ネタ】
メンバーのコメントへレスポンスを返せるRedmine 2.0対応のニコカレプラグインを作ってみた - .logbook

yuuu/redmine_nikoca_re(Redmine2.x)

YukiKita/redmine_niko_cale(Redmine1.x)

ニコニコカレンダー

ニコニコカレンダー - Wikipedia

ニコカレはプロジェクトファシリテーションの一技法として知られている。
Redmine1.xのプラグインは非常に使い勝手が良かったが、Redmine2.xになってから、よいプラグインが見つからず、残念に思っていた。
しかし、Redmine2.xに対応したニコカレが作られたという記事を見つけて、嬉しくなった。

僕も、Redmineにニコカレを導入した時がある。
僕の経験では、ニコカレは、特に女性がよく使ってくれる。
毎日の気分を思いつくままに記録し、コメントを書いておくと、同僚の女性や先輩の女性から声をかけられるのが嬉しい感じみたいだ。

Redmineは単に、進捗管理や情報共有だけのツールだけではない。
Redmineは、メンバーやチームのタイムログ、タイムラインを記録した基盤であり、思い出でもある。
チームの各メンバーは単なる作業者ではなく、役割を期待され、その成果を期待され、実際にチームにとって必要な人だ。
Redmineに残されたログを見れば、その結果が分かるはずだ。

AppStoreでもニコカレのアプリが出ているので、スマフォとRedmineのニコカレを連動できたらおもしろだろうなあ、と思ったりする。

iTunes の App Store で配信中の iPhone、iPod touch、iPad 用 ニコニコカレンダー

| | コメント (2)

2014/11/23

「電子立国は、なぜ凋落したか」の感想~日本の技術者は減価償却のコスト意識が低い


電子立国は、なぜ凋落したか」の感想をメモ。
理解できた部分だけラフなメモ書き。
あくまでもメモなので、時々論理は飛んでいる。

【元ネタ】

日本の製造業もアジャイルの概念が必要ではないか: プログラマの思索

ユーザの力を利用するアジャイル開発: プログラマの思索

【1】「電子立国は、なぜ凋落したか」では、特に日本における半導体、電子電気の業界の栄枯盛衰を多角的に記載している。
そこで興味深い文言だけ拾っておく。

「日本の技術者は減価償却のコスト意識が低い。なぜなら、技術ではなく経営の問題だから。」

【2】日本の技術者は減価償却のコスト意識が低いのではないか

日本の半導体は世界を席巻していたが、諸外国に負けた時の言い分は「経営、戦略、コスト競争力で負けた」「技術では負けていなかった」とよく言う。
しかし、著者は、製造コストを考える時に、日本の技術者は減価償却のコスト意識が低いのではないか、という鋭い指摘をしている。

著者いわく。
日本人技術者は、ランニングコスト(変動費)は強く意識している。
ランニングコストは歩溜まり向上のように、品質管理を強化すれば、技術力でカバーできる。

しかし、資本コスト(固定費)は技術の問題ではない。
どこに設備投資すべきか、という判断は、経営の問題だ。
選択の問題であり、技術の問題ではない。

著者いわく。
日本の半導体技術者は歩溜まり向上に熱心だ。
しかし、減価償却コストを勘定に入れると、歩溜まりを下げてでもスループット(単位時間当たりの処理量)を上げた方がトータルコストが安くなる場合もある。
そういう方向へ技術を用いることなく、やみくもに歩溜まりを上げようとする。
「コストを無視して高い品質を追求する姿勢が日本に醸成されている」。

例えば、韓国メーカーは、新しく半導体工場を立ち上げる時、建屋ができると掃除もろくにせず、すぐに装置の搬入を始めて、すぐにクリーンルームをフル稼働し、高価なフィルターを使い捨てにしながら、一刻も早く製品を出荷しようとする。
投下資本が寝ている時間を短くするためだ。
つまり、サンクコストをできるだけ最小化しようとする。

逆に、日本メーカーは、綺麗に清掃した工場に、装置をしずしずと搬入し、ゆっくりと慣らし運転しながら、テストウェハーを流し始める、と言う。
韓国や台湾のメーカは、装置のスループットと稼働率を何よりも重視しているというのに。

「5年以上も壊れない機器は遅れた技術思想の産物ではないか」と。
「ムーアの法則がニヒリズムをもたらしている」と。

つまり、減価償却を軽視し、ランニングコスト重視の開発スタイルは、過剰品質を生み出す。
一方、減価償却を重視する開発スタイルは、品質よりもスループットを重視する。

【2-1】この話は、日本の製造業に限らず、日本人ではよくありがちだ。
現場の人は変動費しか制御できないから、固定費のことまで考慮してない。
だから、いかにランニングコストを下げるために品質強化するか、という局所最適化された行動しか考えてない。

一方、TOCなら、スループットやボトルネックという考え方で、遊休資産を遊ばせないようにスループット向上が重要と言っている。
アジャイル開発なら、1回しかリリースしないWF型開発とは違って、小規模リリースという考え方で、短期間に小刻みにリリースして、製品という価値を提供していく。

これらの概念が欠けているのではないか?
そして、これらの概念を実現するには、技術ではなく経営や選択の問題である、と認識する必要があるからではないか。

【2-2】僕は製造業は知らないが、ユーザ企業が業務システムを導入する場合、ROIを費用対効果の計画から計算して、固定費とランニングコストが将来的にどうなるか、をすごくうるさく言ってくるのは知っている。
少なくとも、彼らは、ソフトウェアライセンスや初期構築費用、オンプレミスのサーバー構築費という固定費はすごく気にしている。
また、その後の運用保守やサービス利用料、ライセンス保守がどれくらいかかるのか、をすごく気にしている。

だから、日本のユーザ企業は、業務システムの減価償却のコスト意識が低いとはあまり思っていない。

でも、違和感があるのは、業務システムは最低10年使うと仮定して費用対効果の計画を作っている部分だ。
10年も経てば、サーバーのOSもVerUpやセキュリティパッチが提供されなくなるだろう。
すると、WindowsXP廃棄対応の特需のように、OSの入れ替えという不毛なリプレース作業が必ず発生し、多大なコストと工数が浪費される。
また、10年も経てば、肝心のフレームワークも古くなっており、保守性も移植性も、使い勝手も時代遅れになっているだろう。

つまり、業務システムを10年以上使い続けるという仮定が間違っているのではないか。
そうなると、減価償却はできるだけ早く終わらせた方がいい。
つまり、早くリリースして、いち早く使って、減価償却のコストを落とした方がいい。

最近のクラウドの技術発展は、減価償却を不要にし、全てを変動費化するという一面も持っている。
だから、TOCやアジャイル開発とクラウドは相性がいいのではないか。

【3】ファブレスとファウンドリの分業体制

半導体工場を持たないファブレスの設計会社、半導体製造サービスに特化したファウンドリによる分業体制が最近の傾向らしい。

ファブレスとは 【 fabless 】 - 意味/解説/説明/定義 : IT用語辞典

ファウンドリとは 【 foundry 】 〔 ファウンドリー 〕 - 意味/解説/説明/定義 : IT用語辞典

著者いわく。
日本の半導体業界だけでなく、製造業もファブレス化している。
例えば、NEC、ルネサス、富士通、パナソニック、ソニーなど。

いずれも、2005年頃から半導体製造部門を縮小売却し、ファウンドリへの依存を進めた。
しかし、設計と製造の統合にこだわり業績を悪化させ、経営が傾き、設計部門も縮小せざるを得なくなっている。
2013年には、大量の半導体技術者が転職を余儀なくされているらしい。

しかし、日本の製造業は製造というものづくりに強いはずだ。
なぜ、製造に強いのに、半導体製造のファウンドリになろうとしないのか?

分業を嫌った理由に減価償却コストへの意識の低さがあるのではないか、と。
日本企業は設計と製造の垂直統合に固執していたからではないか、と。
実際は、設備投資の減価償却が半導体製造の最大のコストになっている、にもかかわらず。

電子立国は、なぜ凋落したか」では、日本の半導体業界で、ファウンドリになろうとしなかった理由がはっきり書かれていない。
でも、勝手に推測すると、ファウンドリは下請けに過ぎない、という発想があったのだろうと思う。
ファブレスなら、発注者だから偉そうにできる、という発想があったのではないか。

【3-1】日本に半導体製造のファウンドリがないために、日本の半導体業界には大きな欠点ができた、と著者は言う。

身近な場所に、手頃なファウンドリがあれば、安心して半導体のファブレス・ベンチャーを起業できる。
ファウンドリは、半導体ベンチャーにとって、大切なインフラストラクチャなのだ。
しかし、日本にはこのインフラストラクチャすら作れなかった。

日本企業は、半導体の設計と製造の垂直統合に固執して、ファウンドリを作れず、半導体ベンチャーの育成の場もなくしてしまった、と。

【3-2】ファウンドリは半導体製造装置会社との連携で、製造技術でも最先端になった、と著者は言う。
製造装置は高価であり、償却サイクルも速い。
すると、ファウンドリは、最新鋭の製造装置を仕入れて、装置の稼働率を高めて、減価償却を早く進める。
償却が速い分、新装置も先に買えるメリットも出る。

そして、ファウンドリは製造装置会社とノウハウを共有して、どんどん技術改良していく。
つまり、半導体製造の技術開発の場が、統合メーカーからファウンドリと装置メーカーに移ることを意味する。
製造技術の技術革新の覇権が、統合メーカーからファウンドリと装置メーカーに移ったわけだ。

設計と製造の統合を重視する日本メーカーは、ファウンドリを見下す姿勢を続けているうちに、ファウンドリに製造技術で追い越され、自らファウンドリになることもできなくなった、と。

さらに、大手ファウンドリは、設計と製造のインターフェイスも公開している。
インターフェイスを公開することで、なるべく多くの設計会社から製造を受注したい意図があるからだ。
すると、たくさんのファブレス会社が特定ファウンドリのインターフェイスに従って設計するようになり、そのインターフェイスが事実上の業界標準になる。

提案したインターフェイスがデファクトスタンダードになったファウンドリには、顧客が集中し、装置の稼働率が上がり、装置の減価償却も進む。
そうなれば最新の製造装置も買えるようになり、ファウンドリの製造技術はどんどん進歩していく。

したがって、ファウンドリにはネットワーク外部性による独占の可能性がある。
つまり、昔のインテル+Windowsのようなデファクトスタンダードができあがるわけだ。

逆に、半導体の設計と製造の垂直統合を目指した日本企業の技術は、他のファブレスやファウンドリでは使えない。
特定の会社の技術に過ぎず、ガラパゴス化してしまい、デファクトスタンダードから追いやられてしまっている現実がある。

【4】「電子立国は、なぜ凋落したか」で興味深いのは「日本の技術者は減価償却のコスト意識が低いのではないか」という指摘だ。
現代は、半導体だけでなく、家という資産、車という資産、オンプレミスの業務システムという資産、のように、何かを資産として保持するリスクの方が高い。

モノという資産はすぐに陳腐化する。
買った瞬間に資産の価値は基本は半減する。

例えば、ソフトウェア開発で使われるPCは、昔は資産として計上していたが、最近はリース資産か消耗品という費用で計上する所が多いはずだ。
なぜなら、5年も経てば、そのPCのスペックもOSも使い物にならなくなるからだ。
さらに、資産として持つと、機密データの抹消、PCというハードを捨てる費用など無駄な作業やコストまで発生してしまう。

しかし、古いSIでは、PCを未だに資産として持っている所もある。
部課長が一番最新のノートPCを持っていて、実際にプログラミングをしている協力会社の社員がお古のデスクトップPCを使って、重たい開発環境でデバッグに難儀している場面を見る時がある。
彼らには、そんな環境がソフトウェア開発者の生産性をいかに落としているか、という観点が欠けている。

だから、減価償却というコスト意識をもっと持った方がいい。
減価償却しながら利益を出すには、資産として購入した直後から、アウトプットを出して売上を上げることを考えるべきだ。
たぶん、TOCのスループット会計の考え方が、この部分にはとてもよく適用できるだろうと思っている。

| | コメント (0)

2014/11/19

チケット駆動開発の感想のリンク

Redmineでチケット駆動開発を実践した人の感想の記事をリンクしておく。
以下メモ書き。メッセージは特に無し。

【元ネタ】
技術見聞録 - Redmineについて思うところ

kakakikikekeのブログ: チケット駆動開発について今更考えてみた

前者の記事では、
「親チケットは要求定義を除き、機能で分かれているべきである」
「進捗率を見る場所は「ロードマップ」!(ガントチャートじゃない)」
「本来「バージョン」は工程を書くだけの場所ではない」
という指摘は同感。

後者の記事では、「メリットとかイケてるところ」として、こんな感想が書かれていて同感。

(引用開始)
・マネージメントが簡単

日本の会社のようにヒエラルキー型の会社にはがっつりハマると思います
上の人がチケット切って「はい、これやって、これやって」とホイホイ下の人に割り当てればいいだけなのでマネージメントはめちゃくちゃ簡単

アサインしている人ごとにチケットも見れるのでリソースの空き状況もすぐに把握できる
チケットさえちゃんと作成できていればという点はあるが

・ルールが勝手に出来上がる(出来上がった)

これはいい事象かなと思ってます
例えば、文書管理のフォルダ名とかwikiのタイトルとかは全くルールがない状態で初めたんですが、初めに誰かが作成した命名規則的なものを次の人がそれに沿って「いい感じ」に作ってくれるようになりました

例えば、wikiページは必ずYYYYMMDD_で始まるように記載していたら、他の人もそれに合わせて書いてくれるようになったりとか、文書管理のフォルダ名もはじめに00_hogehogeとか数字をつけるようにしていたら次のフォルダ名が01_barbarとかになって自然にルールができていたのはいいなと感じました
(引用終了)

「デメリットとイケてないところ」として、
・クローズされない亡霊のようなゾンビチケットができあがってしまう
・チケットの粒度
・検索機能が弱い
があげられている。

| | コメント (0)

yaml_dbを使ってRedmineのDB移行を行う方法

yaml_dbを使ってRedmineのDB移行を行う方法をメモ。

【参考】
Redmineで使うデータベースを変更する | Redmine.JP Blog

RedmineのDBをyml化してバックアップ - Qiita

yaml_dbでMySQLからPostgreSQLに移行した - @znz blog

akipiiさんはTwitterを使っています: "#redmineT redmine にはmantis やtracのチケットをrakeコマンドでインポートできるインターフェースがある。流用できないか?"

nobu_toyofukuさんはTwitterを使っています: "@akipii #redmineT yaml_db を参考に指定したプロジェクトを YAML形式で dump/load(整合性も考慮。添付ファイルも考慮)するプラグインを作っていたことがあります。バグを取りきれずに公開にいたりませんせんでしたが orz。"

RedmineのDBをsqliteからMySQLへ移行 - メモ(仮)

【1】そもそも、yaml_dbとは何なのか?

(引用開始)
Redmineで使用するデータベースはMySQL, SQLite, PostgreSQLから選択可能です。このうちSQLiteは導入が簡単で手軽に使い始めることができますが、本格的な運用を始めるとパフォーマンスが問題になってきて、MySQL等に移行したくなる場合があります。

このようなときに利用できるのが yaml_db というRailsプラグインです。yaml_dbを使うと、RedmineなどRuby on Railsベースのアプリケーションのデータベースの内容をYAML形式のファイルに書き出すこと、そしてYAML形式のファイルに書き出した内容をデータベースに取り込むことができます。移行元のデータベースの内容をファイルに書き出し、移行先のデータベースに取り込めば、異なる種類のデータベースに切り替えることができます。
(引用終了)

【2】yaml_dbでMySQLからPostgreSQLに移行した - @znz blogによると、下記の方法がある。

(引用開始)
1.まず RAILS_ENV=production bundle exec rake db:data:dump で db/data.yml を作成します。
2.つぎに Ruby や Rails や Redmine のバージョンはそのままで config/database.yml を変更します。
3.必要に応じて bundle でデータベースアダプターの gem をインストールします。
4.データベースの作成をしたり db:migrate をしておきます。
5.RAILS_ENV=production bundle exec rake db:data:load で読み込みます。
(引用終了)

【3】yaml_dbは、そもそもRedmineのDBをSQLiteからMySQLやPostgersSQLへ移行したい用途に使う。
しかし、それ以外のDB移行作業で使えるだろう。

例えば、第7回Redmine.tokyo勉強会の事例発表であったように、複数のRedmineサーバーのDBを統合したい場合、双方のDBをyaml_dbで出力し、yaml_dbというテキストファイルをマージしたり修正して、インポートし直す方法も考えられる。
yaml_dbを使う利点は、rakeインターフェイスがあるのでコマンド1個で簡単にインポートできること、yaml_dbというテキストファイルを正規表現で操作しやすい点があるかもしれない。

個人的には、Redmineにrakeインターフェイスがあるという特徴は、いろんな場面で使えると思っている。
つまり、rakeインターフェイスをバッチ処理化することで、RedmineのDBやファイルの一括操作、メール一括送信が可能になることだ。

例えば、前ユーザのパスワードの一括リセットや、新規ユーザ・新規チケットの一括登録、他システムからのデータの一括インポート、期日間近のチケットを出力して警告メール送信、など、色んな使い方が考えられる。
すなわち、バッチ処理はrakeコマンドで実装して、汎用的に使いやすいインターフェイスにした方がいい。

他にも色々考えてみる。

| | コメント (0)

2014/11/16

「チェンジ・ザ・ルール」の感想

チェンジ・ザ・ルール!」の感想をメモ。
特にメッセージはなし。

【参考】
ゴール3 チェンジ・ザ・ルール [企業のIT活用] All About

読者レビュー|チェンジ・ザ・ルール! なぜ、出せるはずの利益が出ないのか|エルパカBOOKS

TOC:チェンジ・ザ・ルール

エリヤフ ゴールドラット:チェンジ・ザ・ルール!: 日々の学び

ERP導入はすごく難しいと感じる。
普通の日本の企業は、独自の業務プロセスを持ち、手順書も整備されていて、手運用であってもかなり組織化されている。

そんな状況にERPを入れたとしても、実際はERPの良さをなかなか発揮できない。
各業務は個別最適化されているので、ERPで全体最適化する方向に向かいにくい。
ルールを変えたくても、現場の反発も大きい。

チェンジ・ザ・ルール!」の主張は、ソフトウェアを入れただけでは効率化されるわけではなく、現場のルールも変えなければ本来の結果は生み出せない、ということ。
つまり、BPRの重要性を主張していると思う。

また、ERPのインストールとセットアップだけで終わりではない。
むしろ、既存の社内のシステムとERPがデータ連携する仕組みも別途作る必要がある。
この開発が意外に工数がかかる。

その理由は、社内システムとERPでは、データのインターフェイスも設計思想も全く違うので、データ変換が結構面倒なのだ。
両方のシステムの仕様を知り尽くしておかないと、そう簡単には設計しにくい。

ERPを導入すれば、ベストプラクティスも付いてくるし、ノンカスタマイズなら開発コストもかからない、というベンダーの謳い文句が多いけれど、色んな罠には注意すべきだろうと思う。

| | コメント (0)

TestLinkのインポート用ExcelマクロImportExcelMacroのリンク

TestLinkのインポート用ExcelマクロImportExcelMacroのリンクをメモ。

【参考】
MrBricodage/TestLink--ImportExcelMacro

TestLink Open Source Test Management

TestLink - Open Source Test Management - Gitorious

TestLinkの資料リンク: プログラマの思索

エンジニアがお薦めする 現場で使えるツール10選(5):脱Excel! TestLinkでアジャイルにテストをする (1/6) - @IT

以前は、日本のTestLink有志がTestLinkCnvMacroを公開していて、そのExcelマクロを使えば、テストケースの一括登録&一括修正、テスト実績や要件の一括登録&一括修正ができた。
このツールがなければ、TestLinkの画面上で数百~数千のテストケースを逐一手作業で登録しなければならないから、非現実的だった。

しかし、そのマクロも公開されなくなり、TestLinkのバージョンも上がってしまい、テストケースを一括登録する方法がよく分からなくなった。
TestLinkの1.8以降では、ExcelからXML出力したファイルを読みこませれば良かったらしいが、時々うまくいかない時があったから。

だから、TestLinkのインポート用ExcelマクロImportExcelMacroには期待している。
使い方のPDFを読むと、Excelでテストスイートで階層化したテストケースも読み込めるようだし、要件とテストケースを紐付ける機能もあるみたい。

テスト管理は、Excelとテスト管理ツールの連携が一番重要だと思う。
やはり、テストケースの元ネタはExcelで作り、実際のテスト実行履歴はTestLinkで管理し、顧客向けの資料はTestLinkからExcel出力すればいいようにしたい。
つまり、Excelは、ある時点のテスト実績のスナップショット。
したがって、Jenkinsのようなビルドツールで、TestLinkからテスト結果をレポート出力するように、定期的にキックする仕組みがあれば、なお良いだろう。

また試してみる。

| | コメント (0)

第7回Redmine.tokyoの感想 #redmineT

第7回Redmine.tokyo勉強会が無事に終わりました。
参加者の皆様、スッタフの皆様、ありがとうございました。
参加人数も60名近くと過去最高人数で、オープンディスカッションの議論も盛り上がりました。

【参考】
第7回勉強会 - redmine.tokyo

第7回redmine.tokyo勉強会 - Togetterまとめ

【1】Redmineはキャズムを超えた

@sakaba37さんのLTにもありましたが、Redmineの普及度合いはキャズムを超えたと思います。
勉強会の議論を聞いてみると、Redmineはアーリーアダプターが使うものではなく、マジョリティが使うプロジェクト管理ツールになったように感じました。
つまり、ソフトウェアに関わる人達にとって、Redmineのようなチケット管理ツールは当たり前の開発環境である、と。

アンケート結果が興味深い。
Redmine勉強会の参加者の半分は初めての方。

Redmineの利用バージョンは、以前と比べて、最新版に近いものを使ってる。
但し、Ver1.xを使っている方もおられる。

本日のオープンディスカッションでは、サンデル教授の白熱教室のように、Redmineの質問を2択で参加者に挙手してもらい、それぞれの意見の理由を話してもらいました。
おそらくのべ15人の方が、自分の現場でのRedmineの運用方法を語ってくれたと思います。
本来は30個近い質問を用意していたものの、議論が白熱して、質問3個だけで終わってしまいました笑。

ゲーム業界でプログラマだけでなくデザイナーもいる開発チームの話、製造業のインフラ部隊での部門管理の話、少人数のソフトウェア開発チームの話、などが出てきました。

例えば、課題管理をExcelでやっていると、Excelファイルのパスを忘れてしまって更新しなくなる。
あるいは、上司に報告する時にExcelで出さないと話ができない、とか。
でも、Redmineのチケットに書かれた課題をExcelで生で出力しても、その内容は細かすぎて、上司に説明するには要約しなければ使い物にならない、とか、実際の実体験に基づいた話が多く出ました。

それぞれのチームの構成、プロジェクトの構成は、当然違います。
少人数のチームでスタートアップ企業にいる人もいれば、ゲーム業界の案件でも100人月近い大規模プロジェクトになってしまい、何らかのプロジェクト管理ツールが必要になっている人もいます。
それらの条件を合わせて議論しなければ正しい回答は出て来ないでしょうが、むしろ、皆の現場の生々しい話の方がとても興味深かった。

共感できる内容もあれば、そんな現場が未だにあるのか、とか、そんな運用をやっているなら次は真似てみよう、とか。

プロジェクト管理の技法は、大学のような教育の場できちんと教わった人はほとんどいないだろうから、皆、仕事で試行錯誤しながら、自分なりのノウハウをためている。
でも、そのノウハウは、アンチパターン名のようにきちんと名前付けして、他人に説明できるレベルまで抽象化されていない場合が多いので、誰にも共有されず、蛸壺みたいになっている。

今日のようなディスカッションで、皆の現場のノウハウが暗黙知から形式知または経験知へ抽象化されて、共有できるようにしたい。
そうすれば、もっと奥深い議論と、チケット駆動開発のあるべき姿が見えてくるだろう。

【2】勉強会で出た名言

今日の勉強会で、名言が2つある、とスタッフの方から教わった。
一つは、「周りがExcelをやめてくれない」。
この名言の発端は、オープンディスカッションで、Redmineのチケット管理の方がExcelよりもたくさんの利点があるのに、Excelの運用から離れられない人がいる、という話。

僕の経験では、20代の若手なら、プログラミングに疎くても、すぐにRedmineに馴染んでくれる。
Redmine運用の教育にそんなに頑張らなくても、たんぽぽみたいに自然広がる。
多分、ネットやスマフォに慣れているので、ユーザインタフェースにも違和感がないみたい。

しかし、40代以上の中年SEやPMは、なかなか馴染んでくれない。
彼らは自分の仕事のやり方を持っていて、そこから進化することができないみたい。
また、仕事を離れると、PCやスマフォと縁がない世界に行く人も多いから、元々ITリテラシもあまり高くなかったりする。

もう一つは、「プロジェクト管理に興味がある人はおっさんだけだ」。
この名言の背景は、Redmine勉強会に女性を増やしたいよね~という話が発端。

そもそも、Redmineを使いたい人は、プロジェクト管理に興味を持っている時が多い。
すると、そのような立場の人が多いわけで、どうしても女性が少なくなってしまうのでは、という推測がある。

【3】Redmineのようなチケット管理ツールの面白さ

僕の経験では、Redmineに興味をもつ人は、プログラマ上がりのプロジェクトリーダーが多いと思う。
僕自身もそうだったし、ソフトウェアでプロジェクト管理の諸問題を解決できる、というやり方がとても斬新だったから、Redmineにのめり込んだ。

懇親会でお話した人には、Redmineを実際に使ってみて、「バージョン」がとても重要な機能であることが初めて分かった、と聞いた。
彼いわく、「バージョン」はリリースのタイミングであり、バージョンに対し、その期日までに必要な作業をチケットで起票してこなしていく、と。
つまり。「バージョン」はイテレーションであり、チケット管理とはタイムボックスによるタスク管理なのだ、と。

僕もその感覚はよく分かる。
Redmineのバージョン、プロジェクト、チケット、カテゴリなどの機能を使ってみると、ああ、本来はこのように使ってプロジェクト管理すべきなのだ、と悟る。
その感覚がすごく気持ちいい。

ソフトウェア開発プロセスの諸問題を、Redmineでソフトウェア開発プロセスをどのように制御して、どのようにプロジェクト運営を安定させるか、へ置き換えることで、色んな発想が出てくる。
しかも、自分でRubyやRailsを操れるなら、もっとたくさん実験できる。
プロジェクト管理の経験が少なくても、チケット管理ツールで実験することで、場数を増やすことができる。

そんなことを思うと、時代は進んでいる。
過去の成功体験は、逆に足かせになるから、捨てた方がいい、と思う。

【4】他のスライドはコチラ。

RedmineのスマフォアプリRedminePMの国別ユーザ数では、日本、ロシア、ドイツ、韓国の順に多い。
「実際のRedmineユーザの傾向と似ている」という指摘が正しければ、Redmineは日本、ロシア、韓国など世界の東の方が使われているらしい。

| | コメント (0)

2014/11/12

リレーションシップ駆動要件分析による実践的な要件定義手法の記事のリンク

リレーションシップ駆動要件分析による実践的な要件定義手法の記事のリンクをメモ。

【参考】
「要件定義」の4つの構造と依存関係に着目した実践手法 (1/5):CodeZine

要件定義工程の進め方 (1/4):CodeZine

構造に沿って要件をUMLで具体的に定義する (1/3):CodeZine

要件の精度を向上させる (1/3):CodeZine

レビューを軸に駆動する (1/4):CodeZine

既存システムを分析するコツは「システムの地図」を作ること (1/3):CodeZine

既存システムを分析するための考え方と対処法 (1/5):CodeZine

UMLを使った既存システムの分析 (1/3):CodeZine

要件定義ツールを使った既存システムの分析 (1/4):CodeZine

プログラムをマクロ(大域的)に分析する (1/3):CodeZine

RDRA リレーションシップ駆動要件分析 | システム設計日記

Satohru Note: 要件開発の進め方~私のRDRA運用法~

[RDRA] - 神崎コンサルノート

【1】リレーションシップ駆動要件分析(RDRA)は、UMLの図を使って、要件定義を進める手法。
RDRAが優れていると思う点は、システム要件を浅く広く収集して、要件定義の資料の元ネタを作れる点だと思う。

【2】実際の要件定義の現場では、顧客の要求からの網羅性の確保と、要件の実現可能性の調査(フィージビリティスタディ)にかなりの労力を割く。
しかし、要件定義の工程では、少人数のチームで限られた時間内で、要件を決定しなければならない。

また、要件定義の資料は、大量のドキュメントを作ることを強いられる。
そのドキュメントも、自然言語で書かされる場合が多い。
でも、実際はそんな要件定義の資料はほとんど役立たない。

長ーい文章で書かれた要件を理解してみると、実は一言に過ぎない、とか、行間にたくさんの意味が隠れていた、とか、よくある。
その結果、設計工程以降のSEや開発者は、要件を勝手に推測してシステムを開発し、出来上がったシステムは、顧客の要望と似つかないものになってしまう。

さらに、要件定義フェーズで顧客にヒヤリングしたり、チーム内で議論する時、ホワイトボードで、絵を描く時が多い。
日本語で書いても伝わりにくく、むしろ、おおまかな絵を描いて、システムの関係、機能の関係、要求からのトレーサビリティを議論する方が多い。
その方が理解が進むし、実際の要件定義では、チーム内のメンバーで意見が割れないように、全員で理解できる方が重要だ。

【3】そんな経験を踏まえると、UMLの技法は要件定義フェーズで使える。
業務フローをアクティビティ図でアクター毎のフローで書いたり、システム境界と外部システムの関係をクラス図で書いたり、色々できる。

【4】でも、UMLを要件定義フェーズでどのように使うと便利なのか、要件定義フェーズのどの場面でどのダイアグラムを使うと効果的なのか、というノウハウが自分はしっくり来ていない。
一つのアイデアとしては、RDRAのような方針で、各種のダイアグラムをシステム要件・外部環境・システム境界・システム内部で使い分けることがあると思う。

RDRAが思い切った考え方をしているな、と思う点は、RDRAで書いたUMLのダイアグラムはユーザが理解できない資料で良しとし、要件定義の資料の元ネタであり、要件定義の資料は別途作成する、という方針であること。

【5】但し、10個近いダイアグラムを作るので、UMLモデリングツールは必須。
RDRAはEnterpriseArchitectを推奨している。
astahでできると尚良いな、と思っている。

| | コメント (0)

2014/11/09

【事前公開】【第7回redmine.tokyo勉強会】RedmineのFAQとアンチパターン集~WBS駆動からチケット駆動へ #redmineT

第7回redmine.tokyo勉強会で予定している講演資料を事前に公開します。
勉強会のオープンディスカッションの元ネタになるので、参加される方は事前に読んで頂いて、自分なりの意見を持参してくれると嬉しいです。

【元ネタ】
第7回勉強会 - redmine.tokyo

第7回redmine.tokyo勉強会 - PARTAKE

【1】議題にしたいテーマ

第7回redmine.tokyo勉強会のテーマは「Redmineのアンチパターン集」です。
披露するアンチパターンは、私が過去6年、Redmineをいろんな現場で導入して運用した時、こうやればもっとうまくできたのに、と後で気づいたノウハウです。
おそらく他の人も同じように頷いてくれるアンチパターンがあると思います。

【1-1】前提条件は、以下の3つです。

前提①:自分でRedmineサーバーを立ち上げられる
前提②:チーム運営やプロジェクト運営の経験が少ない
前提③:前作のアンチパターン集以外の事例(2011/7)を出す

つまり、講演のイメージとしては、プログラマ上がりのプロジェクトリーダーがRedmineを使ってプロジェクト管理を始めようとした時、Redmineを使いこなせずに失敗した事例を集めてみました。

【1-2】アンチパターンの観点しては、以下の3つです。

・5人の小規模チーム x 20人の複数チーム
・自社開発 x オフショア開発
・大規模な受託開発案件 x 小規模な保守案件

今回は私は、チームや案件の制約条件(Force)によって、チケット管理を微妙に変える手法を議論したいと思います。

例えば、開発者3人のチームリーダーと、3つのサブチームを管理するプロマネの立場では、管理手法が違います
また、自社のフロアにメンバーが全員揃っている場合と、協力会社の開発メンバーとフロアやビルが違う場合、中国へオフショア開発している場合では、管理手法が異なります。
さらに、大規模な受託開発案件と、小規模なシステム保守をたくさん抱えている保守案件では、管理手法が全く違ってきます。

それぞれの前提をおいて、Redmineの運用方法について考えてみると、Redmineの使い方も大きく違ってきます。
Redmineを導入したがうまくいかない、という人は、特に、チームや案件の制約条件とRedmineの機能へのフィットギャップ分析を事前に行なっておらず、Redmineの豊富な機能を使いこなせなかったのだろう、と思います。

資料のように、「大規模受託案件のWBS駆動のプロジェクト管理」とか、消費税対応やWindowsOSのVerUp対応のような「複数システムを横断する短期案件のプロジェクト管理」は、その前提条件が全く違います。
しかしながら、Redmineの豊富な機能を使えば、利用シーンに応じて、細かい部分まで作業管理できる利点があります。

オープンディスカッションでは、参加者の現場の経験を引き出しながら、この辺りを議論してみたい。
こうすればもっと良かったはず、という失敗した経験を、暗黙知から形式知へ変換したいのです。

【2】伝えたいメッセージは3つあります。

【2-1】Redmineを利用して、プロジェクト運営能力を身に付けよう

チケット管理は、プロジェクトの問題を見える化してくれる利点があります。
こんなつぶやきにすごく同意です。

Gen NishimuraさんはTwitterを使っています: "Redmineにチームのタスクを作ってまとめはじめたら、なんかすこし見通しがよくなった気がする。 突然PMに今誰が何していてどんな状況?とか聞かれた時も、Redmineでタスクの一覧出せばいいので、話がしやすくなった。"

しかも、プロジェクト管理の経験が不足していても、Redmineでプロジェクト管理を実験できます。

例えば、大規模な受託開発案件の場合、小規模なシステム保守を1チームでまとめて管理する場合で、それぞれで実際にRedmineのチケット管理をシミュレーションしてもいいでしょう。
あるいは、消費税対応やWindowsXPの廃棄対応のような「複数システムを横断する短期案件のプロジェクト管理」では、チケット管理をどのようにやるべきか、事前に実験してもいいのです。

その結果、Redmineの豊富な機能を利用場面に応じて使い分けるノウハウが得られるでしょう。

逆に言えば、プロジェクト管理の経験が不足している初心者リーダーでも、RubyやRailsのプログラミングができるなら、いくらでもRedmine上で実験することで、プロジェクト管理の場数を増やすことができるのです。
今後は、自分のプロジェクト管理をもっと楽にしたい、という動機を持って、自分でRedmineを拡張してプロジェクト運営の経験を積んでいく、という人が増えていくのではないか、と思います。

【2-2】チケット管理はAgile開発を参考にしよう

チケットは「柔軟で変化に対応しやすい」特徴があります。
この特徴は、アジャイル開発のプロジェクト管理手法とすごくマッチします。

WF型開発で主流のプロジェクト管理手法である「WBS駆動のタスク管理」は変化に弱いのです。
アダプタブルWFが指摘することは、リスク管理はチケットで追跡していく方が良いというメッセージです。

【2-3】Redmineの課題の一つは「Git連携の機能強化」

但し、Redmineの機能が全ての利用状況でうまくいくわけではありません。
最近は、「アジャイル開発するならJira」という話をたくさん聞いています。
また、GitHubがオープンソース界隈における主流の開発ツールとなったように、開発環境はどんどん進化しています。

私が思うに、Redmineの課題の一つは「Git連携の機能強化」でしょう。
Git-flowモデル、プルリクエスト機能は、Redmineでは不十分なのです。
一つの試案としては、Redmine+GitLabでGitHub機能を実現するアイデアがあります。
この辺りも、オープンディスカッションで議論してみたい所です。

RedmineとGitLabを連携すると、RedmineをGitHub化できるか: プログラマの思索

RedmineをGitHub化するアイデア: プログラマの思索

RedmineとGitを巡る疑問点~Gitとの連携機能の強化がRedmineの課題: プログラマの思索

皆様のご参加をお待ちしてます。

【追記】前回(2011年)に公開したアンチパターン集はコチラ。

| | コメント (0)

Pandoc ユーザーズガイド 日本語版のリンク

Pandoc ユーザーズガイド 日本語版のリンクをメモ。
これは非常に助かる。

【参考】
ドキュメント変換ツールPandoc:ユーザーズガイドを熟読して分かったマニアックな使い方 - Qiita

Pandoc ユーザーズガイド 日本語版 - Japanese Pandoc User's Association

HTML - 多様なフォーマットに対応!ドキュメント変換ツールPandocを知ろう - Qiita

Pandoc - Installing

僕は、Pandocを愛用している。
よく使う利用シーンは、記事や原稿を書く時、資格勉強の専門知識をまとめる時に、PC上でMarkdownでテキストで書いておく。
そして、PandocでWordファイルやEpubに変換して、iPhoneに送って、隙間時間に読む。

記事や原稿は、何度も推敲して、文章を洗練させることが大事だが、PC上の原稿をEpubに変換しておけば、目次も作ってくれるし、画像ファイルも挿入して後から読める。
通勤の電車、歩いている時、ぼーっとしている時に、iPhoneで気軽に読めるのがいい。

Pandocの利点は、Markdownで書いておけば、色んな出力ファイルに対応していることだ。
GitHubやBitbucketでmdファイルをコミットしておき、CIサービスで定期的にepubへ変換してiPhoneに送るようにしておくのもありかもしれない。

下記の記事を読むと、てMarkdownをTextileに変換して、RedmineのWiki記法に合わせる事例もある。
色々な使い道があるだろう。

pandocでmarkdownからredmineのwiki文法に変換する - Qiita

MacにPandocを入れてMarkdownをTextileに変換 - Qiita

| | コメント (0)

2014/11/02

SysMLツールベンダー3社揃い踏みシステムモデリング事例&ツールセミナーのリンク

2014/9/26に開催された「SysMLツールベンダー3社揃い踏みシステムモデリング事例&ツール」セミナーのリンクをメモしておく。

【元ネタ】
SysMLツールベンダー3社揃い踏みシステムモデリング事例&ツールセミナー | 株式会社オージス総研

つれづれなる技術屋日記: SysMLツールベンダー3社揃い踏みセミナー

日々精進 - スパークスシステムズ ジャパン代表のBlog:9/26 SysMLセミナー 報告&感想 - livedoor Blog(ブログ)

日々精進 - スパークスシステムズ ジャパン代表のBlog:9/26 SysMLセミナーやります! - livedoor Blog(ブログ)

日々精進 - スパークスシステムズ ジャパン代表のBlog:SysML関連 情報2件 - livedoor Blog(ブログ)

インタビュー&トーク - 日本でも導入が始まるSysML、モデルベース・システムズエンジニアリングの基盤に:ITpro

【感想】
僕は参加していないのでネットで感想の記事を探してみたが、有用な記事はつれづれなる技術屋日記: SysMLツールベンダー3社揃い踏みセミナーの1件だけだった。
記事を読んで興味を引いたのは以下の通り。

【1】一つは、SysMLのようなモデリングツールはいじっていて楽しいので、「モデル設計で仮想的に動くのが面白くなって設計過剰になったり、かえって時間を浪費する」リスクがあること。

特に、SysMLでは、パラメトリック図を使ってシミュレーションする機能がモデリングツールにあったりするので、本来の設計を忘れて、シミュレーションが楽しくなってしまう、というリスクもあるのだろう。

僕も経験があるが、UMLは確かに設計技法として見習うべき点は数多くある。
しかし、UMLで表現できない部分もあり、UMLだけでは設計は十分とは言えない。
特にUMLが弱い部分は、サーバーやネットワークなどの配置図を表現しにくいことや、例外処理や代替処理(例えば、拡張ユースケース(extend))をすべて表現するのが難しいことがあると思う。
他にも、性能要件や使用性、要求管理、ER図などのデータモデリング、などはUMLでカバーできない。

UMLでシステム情報をすべて表現しようとすると、各ダイアグラムを粒度に合わせて階層化する必要があり、各ダイアグラムのトレーサビリティを確保するのが難しくなる。
1つの箇所を触ると、他のダイアグラムも影響を受けて、修正部分が増えてしまうのだ。
そして、どんどん、UMLで書いた設計図が複雑になり、設計の意図の伝達よりも保守のコストの方が上回ってしまい、最終的には保守されずに使われなくなる。

最新の仕様が反映されていない設計図や設計書ほど、扱いにくいものはない。
UMLは、設計のスケッチとして使うのが用途として一番いいだろうと思う。

【2】もう一つは、ソフトウェアとハードウェアの境界があいまいになり、IoTのようなバズワードが広がる状況で、メーカーがSysMLを使って、モデリング→製品の高速化を図り、工場のIT化を目指す動きがあること。

ドイツが目指しているインダストリー4.0にも関連しているらしい。
この辺りの動きは全く知らないけれど、普通の人がスマフォを持っていて、いつでもどこでもネットでつながる環境になった状況では、メーカーは、より一層、ハードウェアよりもソフトウェアに注力して、製品開発をより高速化し、頻繁な機能改善に耐えうる製品設計が必要になってくるのだろう。

インダストリー4.0とは何か?:日経ビジネスオンライン

ドイツの「インダストリー4.0」政策に感じる既視感 - WirelessWire News(ワイヤレスワイヤーニュース)

インダストリー4.0:ドイツが描く第4次産業革命「インダストリー4.0」とは?【前編】 (1/4) - MONOist(モノイスト)

おそらく、SysMLを担いでいる人は、SysMLでモデリングできたら、プログラムを自動生成できて、製品開発をより高速化できるというイメージを持っているのだろうと思う。
それは、以前夢見ていた、「モデルからソースを自動生成すれば、プログラミング工程は不要になる」モデル駆動開発と何が違うのか?
そのモデル駆動開発の失敗経験を踏まえて、SysMLはどのように成長してきたのか。

今後も調べてみる。

| | コメント (0)

Redmine 2.6のCHANGELOGのメモ

Redmine 2.6のCHANGELOGの日本語訳が公開されていたのでメモ。
@g_maedaさん、ありがとうございます。

【元ネタ】
MAEDA, GoさんはTwitterを使っています: "遅くなりましたがRedmine 2.6のCHANGELOGの抄訳を公開しました。 http://t.co/WlG99xGIXx"

Redmine 2.6のCHANGELOG (新機能のみ・日本語訳付き) | Redmine.JP Blog

【1】個人的には、下記のパッチが反映されたのが嬉しい。

Feature #16707: Integrate support of SSL for POP3 incoming emails - Redmine

このパッチが必要になる状況は、メールサーバーがSMTPs、POP3sになった場合だ。
会社のメールサーバーも、昨今のセキュリティ強化のために、SMTPs、POP3sになる場合が多く、Redmineチケットの更新通知メールが届かなくなるのは非常に困っていた。
だから、以前は、下記の記事のように、ChiliProject のパッチを当てていた。

Redmineのメール送受信設定をSMTPs、POP3sに対応する方法: プログラマの思索

【2】@naitohさんが尽力されたPDF機能の改善も要注目だろう。

akipiiさんはTwitterを使っています: "すごい! RT @g_maeda: PDFの改善を淡々と紹介されてるけど、みんな @naitoh さんがやってくれた仕事 #redmineT"

Feature #17570: use rbpdf gem instead of bundled rfpdf - Redmine

Patch #13589: Wiki PDF export for 2 column tables - Redmine

NAITOH JunさんはTwitterを使っています: "#Redmine 2.6リリース。新機能はPDF出力改善(αチャネル&16bit PNG、テーブル内書式対応)、ワークフロー一括編集、プロジェクト単位の非メンバー、匿名ユーザへの権限付与。なお今回がRuby1.8.7サポート最終版です http://t.co/ppwzxq3E0X"

NAITOH JunさんはTwitterを使っています: "#Redmine 2.6の次は3.0でRails 4対応。Redmine 1.x(Rails 2.3)→2.x(Rails 3.x)移行時に発生した各Redmineプラグインの未対応問題が今回も予想されるので、比較的互換性の高い2.6のリリースにPDFの修正が間に合ってよかった。"

Kuniharu AKAHANEさんはTwitterを使っています: "#Redmine 2.6.0, 2.5.3 and 2.4.7 released / @naitoh さんによるPDF出力改善、待ってましたm(._.)m / http://t.co/KKfyTIYJJH"

NAITOH JunさんはTwitterを使っています: "#Redmine Wiki記法で文字に色をつけられるんだけど、Redmine 2.6のPDF出力でPDFに文字に色がついて表示できた。実装したの忘れてたけど、これも2.6の新機能だ(笑) http://t.co/QXCuKIaKyI http://t.co/9aON0Njyyz"

Use The Gentoo, LukeさんはTwitterを使っています: "2.6.0でてた。PDF周りのサポートがいい感じになったらしい。 / “Redmine 2.6.0, 2.5.3 and 2.4.7 released - Redmine” http://t.co/wrcIrJE4Oc"

RedmineのPDF出力機能は、Ver1.1の頃まで日本語の文字化けがあったが、有志のおかげで対応されただけでなく、しおりもPDF出力できたり、Wikiの全頁を一括出力できるようになって、すごく便利になった。

Redmine 1.4新機能紹介: Wikiの全ページを一括してPDFに出力 | Redmine.JP Blog

Redmine 1.3新機能紹介: PDFエクスポート機能の改善 | Redmine.JP Blog

Redmine 1.2新機能紹介: PDF文字化けの解消 | Redmine.JP Blog

僕も、RedmineのWikiに、Redmineそのものの使い方とチケット駆動開発の運用ルールを記載して、メンバーに公開している。
Wikiに書いておけば、新規メンバーに事前に読んでおくように指示できるし、WikiページのPDF一括出力のおかげで、チケット管理の運用マニュアルとして配布することも可能だ。

また、ガントチャートもPDF出力できるから、プロジェクトリーダーが顧客向けに報告する資料としても使える。

今回のPDF改善対応で、Wikiの色付けにも対応されたらしい。

今回のPDF対応に至るまで、@naitohさんは丸3年かけて、PHPからRubyへPDFライブラリを移植していたらしい。
その尽力のおかげで、RedmineのPDF出力機能は、見違えるように改善されただけでなく、上司や顧客向けの報告資料にも使えるようになった。
オープンソースという仕組みのおかげで、ユーザから提案された機能改善パッチがコミッタに受け入れられて、どんどん機能改善されていくという、よい事例だと思う。

@naitohさんの移植に関する経緯は下記で公開されている。

| | コメント (0)

Redmineチケット一覧に添付ファイルアイコンを表示する機能改善

@g_maedaさんが、Redmineチケット一覧に添付ファイルアイコンを表示する機能改善パッチをRedmine本家にチケット登録されていたのでメモ。

【元ネタ】
Feature #15900: Add to Issues List column of the attachment icon - Redmine

MAEDA, GoさんはTwitterを使っています: "Redmineのチケット一覧に添付ファイルの有無をアイコン表示するパッチ。 http://t.co/v50poVaoYi"

Redmineチケット一覧に添付ファイルアイコンを表示するだけの機能なので、さほどすごい機能であるわけではない。
でも、添付ファイルの有無をチケット一覧で確認できれば、詳細はそのファイルを見ればいいのだな、と気づくこともできる。
前田さんのパッチを見ると、親子チケットの構造を持つチケットにも対応されているようだ。

Redmineをソフトウェア開発のタスク管理で使っているならば、添付ファイルの対象となる設計書やソースは構成管理の配下にあるから、添付ファイルの有無はあまり関係ないだろう。
一方、Redmineをヘルプデスク管理やインシデント管理で使っている場合、顧客からの見積書やログなどの証跡をチケットに添付してくれれば、その後の作業は添付ファイルを参照すれば理解しやすくなるし、チケットにその後のやり取りを記録すればいい。

つまり、この改善要望は、Redmineの機能性や信頼性の観点ではなく、使用性の観点での改善に相当する。

こういう細かな機能改善がRedmine本家にあがり、コミッタや他のユーザと一緒に議論して、よりよいシステムへVerUpされていくのだ。
オープンソースという仕組みは、より良いシステムを作るための仕組みなのだ、と改めて気付かされる。

| | コメント (0)

« 2014年10月 | トップページ | 2014年12月 »