« 2014年11月 | トップページ | 2015年1月 »

2014年12月

2014/12/30

Redmineとシステム連携できるOSSのツール一覧

Redmineとシステム連携できるOSSのツール一覧についてメモ。

【1】Redmineと他のOSSツールをシステム連携するメリット

Redmineは高機能なチケット管理ツールなので、タスク管理、課題管理、障害管理など、一通りのプロジェクト管理が可能だ。
また、ソフトウェア開発だけでなく、インフラ保守、ヘルプデスク管理、ITILのようなITサービス管理、PC資産管理にも適用できる。
しかも、利用シーンとして、IT業界だけでなく、製造業やデザイナーのタスク管理、営業支援などにも適用できるから、幅広く使える。

しかし、Redmine単体だけでなく、他のOSSツールと連携できると更にメリットが増す時がある。
例えば、RedmineとSVNのような構成管理ツールを使えば、成果物の履歴管理とチケットによる作業の履歴管理を密連携できるから、トレーサビリティを実現できる。

構成管理ツールと連携しした事例としては、Excelの設計書の1ページ目にある「変更履歴」は、Redmineのチケットへの相互リンクで代用でき、廃止できることがあるだろう。
Redmineの優れたチケット集計機能や検索機能によって、いくらでも修正理由を検索できるし、関連するチケットの影響度合いも探ることができる。
この運用は「No Ticket, No Commit」につながる。

では、Redmineとシステム連携できるツールや機能としては、構成管理ツール以外に何があるのだろうか?
ちょっと探してみた。

【2】構成管理

一つは、Subversion、Gitなどのソース管理ツールと連携すること。
Redmineは5種類くらいの構成管理ツールと連携できるから、かなり使い勝手が良い。

もう一つは、Gitリポジトリ管理ツールであるGitLab、GitHubなどと連携すること。
Redmineで唯一弱い機能であるGit連携機能を、他のGit管理ツールで実現する。
例えば、ブランチ管理やマージ、プルリクエストなどは、GitLab、GitHubで作業し、チケット管理は使い慣れたRedmineで使い分ける、など。

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

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

【3】ビルド管理ツール

JenkinsとRedmineの連携は、Hudsonプラグインで実現されている。
Jenkins側でも、ITSとの連携は簡単。

Hudson - r-labs

JenkinsとRedmineを相互に連携させてみる | メモ帳代わりのブログ

codefirst::blog ? codefirst を支える開発環境 09: Jenkins-Redmine 連携

JenkinsとRedmineを連携できると、ビルドモジュールとソースのリビジョン、チケットの間での相互リンクだけでなく、色んな利用シーンがあると思う。
ビルドエラー通知メールからRedmineチケット登録、Jenkinsでマージ後のビルドOkならチケットを完了ステータスへ自動でチケット更新、などいろんな手法が考えられる。

Jenkinsビルド後の処理でRedmineにチケット登録ができるプラグインを作った話 - Qiita

JenkinsからRedmineのチケットをクローズとかするPluginつくったった - うさぎ組

アーキテクチャとしては、Redmineの「メールによるチケット自動登録」「REST APIによるチケット更新」を使うだけなのだが、Redmineの外部接続APIが豊富なおかげで、利用シーンを明確にして仕様を提示できれば実現可能だと思う。

プロジェクト管理サーバーとは: プログラマの思索

アジャイル開発の弱点をプロジェクト管理サーバーが助ける: プログラマの思索

【4】テスト管理ツール

OSSのテスト管理ツールと言えば、TestLinkがある。
最新版のTestLinkなら、下記のような設定で使えるようになる。

TestlinkとRedmine連携で、RedmineチケットにTestlinkへのリンク挿入 | テックラボ 来夢多゛

「Redmineによるタスクマネジメント実践技法」に書いたけれど、障害管理とテスト管理を連携できると、結合テストやシステムテストの工程で大きな威力を発揮する。
テスト管理は、ソフトウェアのプロジェクト管理の中で最も難しいものの一つと思う。
実際に使いこなしてみれば、「ブロック」「みなしバグ」「みなしOK」などのテストの概念が分かってくると思う。

TiDDを実践して気づいたことpart4~TestLinkによるテスト戦略: プログラマの思索

【公開】ETWest2009講演資料「TestLinkでアジャイルにテストする」: プログラマの思索

【5】文書管理

Alfrescoと連携できるみたい。
但し、Redmine2.4ではエラーが出る、と下記に書かれている。

Cmis for Redmine 2.x - Plugins - Redmine

既に、RedmineとAlfrescoを連携した事例もあるみたいで、詳細が知りたい。
成果物の構成管理だけでなく、Web上の文書管理とチケットを連携する場合、何がメリットになるのか?

「Redmine(課題管理)とAlfresco(文書管理)の連携で、プロジェクトマネジメントを改善することができました」 | Alfresco | oss-comcre

【6】その他に考えられるツール群

個人的に欲しいと思う機能は、ITILに関連したツール群との連携だ。
特に、サーバー監視ツールとRedmineを連携することによって、インフラ保守のインシデント管理をRedmineのチケット管理で強化することだ。

既にそのアイデアは色々公開されているみたい。
OSSのサーバー監視ツールZabbixで障害通知メールを発行したら、そのメールを起点としてRedmineチケットを自動登録する機能も考えられる。

Zabbixコラボ企画「第2弾 Redmineと連携しよう!!~Part1~」|zabbix|クラウド関連技術ブログ|クラウドデザインのFL.OPS

また、JobSchedulerというOSSのジョブ管理ツールとRedmineを連携することで、バッチジョブの障害をRedmineチケットに自動登録する機能も考えられる。

OSS「JobScheduler」で実現するこれからの運用自動化(1):JobSchedulerの機能と設定~基礎編 (1/2) - @IT

JobSchedulerの下記資料の28ページには、Redmine・JobScheduler・Git/SVNと連携して、継続的デリバリーを自動化するアイデアが公開されている。

色々考えてみたい。

| | コメント (0)

2014/12/26

マイクロサービス~疎結合なアーキテクチャが時代に合っている

マーチン・ファウラー氏による「マイクロサービス」パターンの記事を最近よく見かける。
関連する記事をメモ。

【元ネタ】
マーチン・ファウラー氏による「マイクロサービスの前提条件」 - Publickey

クックパッドとマイクロサービス - クックパッド開発者ブログ

"Microservices"を読んだ | SOTA

マイクロサービスとSOA

マイクロサービス設計概論

akipiiさんはTwitterを使っています: "なるほど。RT @yusuke_arclamp: なんとなくですが、SOAは「いかにシステムを統合化するか」ということであり、マイクロサービスは「いかにサービスを分割して構成するか」ということかなと。同じテクニックではありますが、考える方向が逆なのが面白いところです。"

akipiiさんはTwitterを使っています: "#DevKan マイクロサービスは一昔前のSOAやEAIと何が違うのか?"

akipiiさんはTwitterを使っています: "#DevKan アーキテクトやアーキテクチャーの話はすごく良いけど、アーキテクチャーの事例をパターンで表現できないものか。超高速開発も同じ方向と思うがノウハウが体系化されてないから、使いにくい"

【1】(抜粋の引用開始)
・“Microservices” とはソフトウェアシステムの開発スタイルである

・Microserviceは一連の小さなサービスで1つのアプリケーションを開発する手法
 それぞれのサービスは自身のプロセスで動いており,軽量な機構(e.g., HTTP API)を通じて情報をやりとりする
 これらのサービスは独立して自動デプロイされる

・Monolithicシステムの構築は一般的には成功したスタイルである
 リクエストを処理するロジックは単一のプロセスで動く
 ロードバランサを配置しスケールアウトさせることもできる
 クラウドに多くのアプリケーションがデプロイされ始めるとMonolithicアプリケーションはフラストレーションになってきた

・これらのフラストレーションがMicroservicesアーキテクチャーを導きだした,
 Monolithicなアプリケーションと比較してMicroservicesは:
 独立してデプロイできる
 独立してスケールできる
 しっかりしたモジュールの境界をもつ(影響範囲の限定)
 様々なプログラミング言語を利用できる
 異なるチームで運用できる

・Microservicesは新しい考え方ではない
 少なくともその根源はUNIXのデザイン哲学に立ち戻っている
(抜粋の引用終了)

【2】モノシリックなアーキテクチャの例は、ERPが典型例だろう。
一つのシステムが、販売管理・生産管理・発注管理・原価管理・会計管理など、会社に必要なモジュールを全て持っている。
統合DBだからこそ、データを一元化できるメリットが生きる。

しかし、膨大なソースコードになり、システムの変更や保守が大変。
本来のアーキテクチャの思想に基づくモジュール構造を維持していくのも大変。
また、一つのシステムであるがゆえに、1個の機能をスケールすることはできず、システム全体でスケールしなければならない。

一方、マイクロサービスはモノシリックの対極だ。

それぞれの機能は普通、Webサービスとして独立しており、REST APIのような軽量なI/Fでデータがやり取りされる。
サービスとして独立しているから、ソース変更やデプロイの影響範囲が狭いし、気軽に頻繁にリリースできる。
また、サービスごとにスケールすることも簡単。

つまり、マイクロサービスの概念は、UNIXのデザイン哲学に似ている。
単純な処理をパイプでつなげて、大きな機能を実現する、みたいな。

【3】マイクロサービスの概念を実現した事例として、クックパッドとマイクロサービス - クックパッド開発者ブログが詳しい。

クックパッドの記事を読むと、マイクロサービスはドメイン駆動設計と相性が良いようだ。
「境界づけられたコンテキスト」「公表された言語」が適用できるらしい。

akipiiさんはTwitterを使っています: "マイクロサービスのDDDパターンとしては「境界づけられたコンテキスト」「公表された言語」が中核にあるのか。すごく分かりやすい。マイクロサービスはWebシステムに向いているか。クックパッドとマイクロサービス - クックパッド開発者ブログ http://t.co/QXdOCDdjyh"

(引用開始)
マイクロサービスの文脈でしばしば取り上げられる概念のひとつに、『ドメイン駆動設計』で紹介されているパターンである「境界づけられたコンテキスト(Bounded Context)」があります。
(中略)

境界づけられたコンテキストという概念を採用するならば、それらの間でどのように情報をコミュニケーションさせるかということも、同様に重要となります。そのためのパターンが、「公表された言語(Published Language)」です。

必要なドメインの情報をコミュニケーションにおける共通の媒体として表現できる、明確にドキュメント化された共有言語を使用し、必要に応じてその言語への変換と、その言語からの変換を行なうこと(Evans 2003)

クックパッドにおけるGarageは、ちょうどこの公表された言語の機能を持っています。どのようなアプリケーションであれ、Garageという公表された言語を備えることで、他のアプリケーションと統一的で一貫した情報のやりとりができるようになっているのです。
(引用終了)

確かに、サービスごとにモデルのコンテキストがあり、サービス同士のI/Fがコンテキストの境界になっている。
サービス同士のI/FがREST APIのような「公表された言語」で、やり取りされているわけだ。

【4】もう一つ気になるのは、マイクロサービスが、一昔前のSOAやEAIと何が違うのか、という点だ。

EAIとは 〔 エンタープライズアプリケーション統合 〕 【 Enterprise Application Integration 】 - 意味/解説/説明/定義 : IT用語辞典

SOAとは 〔 サービス指向アーキテクチャ 〕 【 Service Oriented Architecture 】 - 意味/解説/説明/定義 : IT用語辞典

僕の理解では、EAIはシステム関連形容のパッケージ製品、SOAはSOAPのようなXML HTTPのI/Fと理解している。
一方、マイクロサービスは、REST APIやJSONなどのように、もっと軽量なI/Fかつ現代風のI/Fと理解している。

つまり、マイクロサービスは一昔前のSOAやEAIと同じような発想から作られた概念と思うが、マイクロサービスは、アジャイル開発やDevOps、クラウドなどの最新の技術のトレンドを踏まえて、より軽量に素早く開発できることを意識したように思える。

「犠牲的アーキテクチャ」と合わせて「マイクロサービス」も、最近の技術のトレンドの一つ。
これらの概念も含めたアーキテクチャの鳥瞰図がそろそろ欲しいなあ、と思っている。

| | コメント (0)

犠牲的アーキテクチャ~リプレースを正当化するアーキテクチャ

「犠牲的アーキテクチャ」に関する記事をメモ。
ラフなメモ書き。

【元ネタ】
Martin Fowler氏の語る“犠牲的アーキテクチャ"

Martin Fowler's Bliki in Japanese - 犠牲的アーキテクチャ

akipiiさんはTwitterを使っています: "定期的なリプレースを正当化するアーキテクチャ。Martin Fowler氏の語る“犠牲的アーキテクチャ" http://t.co/cgjQXpf3v2"

神宮式年遷宮と犠牲的アーキテクチャ

Martin Fowler氏の語る“犠牲的アーキテクチャ” | InfoQ翻訳日記

Martin Fowler氏の語る“犠牲的アーキテクチャ"

【1】(引用開始)
システムあるいはアーキテクチャの陳腐化を前提として捉え、設計時からリプレースを意識しておくという、現実的ですが斬新な提案です。今後流行るかも知れません。

こうなると、ソフトウェアやシステムのコードも、資産というよりも負債になってきます。考え方を大きく変える必要がありそうですね。
(引用終了)

【2】昔は、基幹系業務システムを新規開発する時、1~3年かけて開発し、10年かけて運用するような開発スタイルが多かった。
初期構築費や運用保守費用を考慮すると、5年で減価償却し、それから元を取っていくような原価管理になる。

このようなウォーターフォール型開発手法は、現代のように3年で技術革新がどんどん起きる時代には都合が悪い。
3年かけて頑張って作っても、開発当初から5年立つと、既にアーキテクチャやインフラが劣化ないし、陳腐化してしまっているからだ。

だから、業務システムは、サーバー増強ないしハード強化のタイミングで、OSやJavaやDBのVerUpも兼ねてリプレースする時も多い。
すると、数年かけて少し運用したら、すぐに全て壊して作り直すという開発を何度も繰り返すようになる。
ソフトウェアを作っている者としては、なにか無駄な気がする。

【3】しかし、「犠牲的アーキテクチャ」の概念を読んでみると、アーキテクチャを入れ替えてシステムをリプレースする手法を正当化する。
むしろ、アーキテクチャの寿命は短いから、数年でスクラップアンドビルドを前提として、システム開発すべきだ、と。

犠牲的アーキテクチャの事例としては、TwitterがRailsからScalaへ少しずつ切り替えた事例など、多々ある。
この辺りの事例を集めて、犠牲的アーキテクチャの本質を見出すのも面白いかも知れない。

【4】神宮式年遷宮と犠牲的アーキテクチャを読むと、犠牲的アーキテクチャは式年遷宮と同じ、という喩えがある。
式年遷宮の意図として、建物を定期的にリプレースして長持ちしやすくするだけでなく、建替えの技術の伝承を行うことがあるらしい。
その意図を踏まえると、「当時の寿命や実働年数から考えて、20年間隔が適当」ということらしい。
その意味では、「犠牲的アーキテクチャは式年遷宮と同じ」発想は面白い。

犠牲的アーキテクチャの考えを推し進めると、システムのロードマップや投資計画につながると思う。
長期間システムを運用する前提で、アーキテクチャをどのスパンで入れ替えて、最新技術を取り入れながら、初期構築コストを回収していくか。

つまり、単なる技術的観点だけでなく、システムのあるべき姿や開発コストも考慮して、初めてアーキテクチャが定まる。
アーキテクトの立場ならば、犠牲的アーキテクチャの考え方は重要になってくると思う。

| | コメント (0)

2014/12/23

Redmineの情報のサイロ化を解決したい問題

「Redmineの情報のサイロ化を解決したい」問題がGoogleGroupにアップされていた。
その議論が興味深かったのでメモ。

【元ネタ】
情報のサイロ化を解決したい - Google グループ

nanego/redmine_multiprojects_issue

【1】問題

(引用開始)
Redmine便利に使っていますが、困っているのが情報のサイロ化です。
他PJに情報(チケット)を横展開する場合、コピーすることになると思いますが、どうもかゆいところに手が届かい感じがしています。
横展開するPJが1つか2つなら手作業でコピーできなくもありませんが、3を超えると忘れ(サボ)られがちです。

1つのチケットを一度に複数のPJへコピーする方法(プラグイン)、または情報のサイロ化を防ぐ手段、ツール、運用方法とあればご教授頂きたいです。
(引用終了)

問題の発端としては、あるチケットが他の複数のRedmineプロジェクトにも影響があることが判明したので、横展開したいことがある。
例えば、ある顧客向けのパッケージ製品でバグ修正や機能改善した時、他の顧客向けの製品にも影響があるね、と分かる時もある。
あるいは、あるモジュールの修正が後続の外部システムに影響があるので、情報を連携したい時もある。

問題の前提としては、少人数のチームではなく、複数チームで複数のシステムを開発・運用していて、相互に密接に関連する場合があるだろう。

個人的には、課題管理のチケットで上記のような問題が発生しやすいだろうと思う。
なぜなら、課題の重要度や緊急度を判定するときには、リソース・スケジュール・スコープなどへのインパクト(影響度)を把握する必要があり、その時に、影響するプロジェクトを指定したい場合があるからだ。

【2】技術的課題

nanego/redmine_multiprojects_issueを使うと、一つのチケットを複数のプロジェクトに所属させる機能を実現できる。
使い道としては、チケットに対し、影響するRedmineプロジェクトを選択すればいいだろう。

しかし、実際の運用では下記のように、迷ってしまう場合が出てくる。

(引用開始)
(redmine_multiprojects_issueプラグインの)運用としては以下のようになるかと思いますが、少し使い難いと思った点があります。

例)
1.Project Aで問題が見つかる
  →チケットを発行
2.類似プラットホームのProject B にも影響するので、問題を横展開する
  →チケットをProject Bにも所属させる
3.Project Aで問題は解決した、Project B では未対策
  →このタイミングではチケットをクローズ出来ない
   Project A上でこのチケットは残ったままになる
4.Project Bでも問題解決した
  →このタイミングでチケットをクローズする

難点としてはクローズするタイミングが全てのPJで同じになってしまう点だと思いました。

上の例だと、3のところでProject A上では問題は解決しているのでクローズさせたいところですが、
Project Bに対しては解決出来ていないのでこのチケットをクローズ出来ません。
プロジェクトの進行によっては3と4の間に期間が大きく空いてしまう場合もあると思います。
情報を横展開した後は、各PJ毎に任意のタイミングでクローズさせる必要があると考えております。
(引用終了)

つまり、影響するプロジェクトでCloseできなければ、チケットのステータスをCloseにできない問題がある。
チケットの作業状況がチケット一覧から見えにくい短所がある。

したがって、チケット管理で進捗状況をリアルタイムに見える化したいのに、redmine_multiprojects_issueプラグインを使うと、ステータスから進捗度合いを把握するのが難しくなる。

【3】解決策の提案

一つの解決策としては、下記の提案のように、プロジェクトごとに終了ステータスを記録するカスタムフィールドを作る方法もある。

(引用開始)
参考になるかどうか判りませんが、私の所では、プロジェクト毎に終了ステータスが記録できるカスタムフィールドを作り、
それぞれ記録しています。 全て終わったら Redmine のステータスが 「終了」 になります。

前提としては 「同じ案件なら同一チケットに集約したい」、「プロジェクト数はそんなに多くない」 という条件があります。
この条件にマッチすれば、ひょっとしたら参考になるかもしれません。

この話は 解決アプローチが何通りかありそうで、興味深い内容だと思いました。
(引用終了)

しかし、このやり方では、Redmineプロジェクトが増えるたびにカスタムフィールドが増殖してしまうリスクもある。

【4】僕の考えでは、影響するRedmineプロジェクトごとに、チケットをコピー(複製)する機能を使い、各プロジェクトごとにチケットを作り、元のチケットを関連チケットで関連付ける運用が良いと思う。

他のRedmineプロジェクトに影響すると分かっても、各プロジェクトごとに、その意味合いは異なる。
あるプロジェクトでは重大な課題になる場合もあれば、他プロジェクトでは後回しにしてよい課題の場合もある。
チケットは各プロジェクトごとに記録していく方が良い。

関連チケットにしておけば、チケットの関連チケット欄にステータスも表示されるから、他チケットの対処状況も把握可能だ。
わざわざredmine_multiprojects_issueプラグインで運用を複雑化させる必要もないと思う。

つまり、「1個のチケットで一つの情報の記録を集約させていく」「Redmineプロジェクトで案件や製品を分割し過ぎない」運用ルールで進めた方が良いと思う。

色んな現場を見てみると、WBSライクに親子チケットで分割し過ぎたり、Redmineプロジェクトを分割し過ぎて階層化しない「サイロ型プロジェクト」のようなアンチパターンをよく見かけるからだ。
Redmineはチケットやプロジェクトの機能の柔軟性が高いので、チケットやRedmineプロジェクトを分割し過ぎてしまいがち。
すると、逆に、情報がたくさんのチケットやRedmineプロジェクトに散在されてしまうので、履歴を追いにくくなる。

むしろ、「情報はチケットに集約する」「チケットは製品に従う」「Redmineプロジェクトは製品単位に作る」ような運用ルールに従う方が、その後の運用保守で使いやすくなるだろうと思う。
この辺りのプラクティスやアンチパターンも集めてみたいと思った。


| | コメント (0)

エンタープライズアジャイルの手法であるDADとSAFeのリンク

エンタープライズアジャイルDADとSAFeのリンクをメモしておく。
DADもSAFeも僕はよく知らないので、感想をメモ。

動き出した エンタープライズアジャイル - [DAD解説 前編]複数のアジャイル手法を組み合わせて誕生:ITpro

動き出した エンタープライズアジャイル - [DAD解説 後編]比較表からプラクティスを選択してアジャイルを実践:ITpro

動き出した エンタープライズアジャイル - [SAFe解説 前編]アジャイルの考えを企業活動全体に拡張:ITpro

動き出した エンタープライズアジャイル - [SAFe解説 後編]3階層のマネジメントで企業をアジャイルに :ITpro

SAFe (Scaled Agile Framework) 入門(第1回) | オブジェクトの広場

SAFe (Scaled Agile Framework) 入門(第 2 回) | オブジェクトの広場

Scaled Agile Framework

【1】DADを見た感想は、RUPのアジャイル版みたい。
方向付けフェーズ→構築フェーズ→移行フェーズで開発の工程が分けられている箇所は、RUPの方向付け→推敲→開発→移行のフェーズにすごく似ている。

RUPが案件ごとにカスタマイズが必要だと言っているように、DADも現場の案件ではカスタマイズが必要らしい。
だとすれば、DADもRUPと同じように開発プロセスのフィットギャップ分析が事前に必要で、計画駆動になりやすい罠があるのではないか、と思ったりする。

【2】SAFeは、Scrumを大規模案件にも使えるように拡張した印象を受ける。
スプリントをアジャイルリリース列車に言い換えたり、スクラムマスターをリリース列車エンジニアと言い換えたりする箇所では、複数のソフトウェアを並行開発するアナロジーとして「アジャイルリリーストレイン」という概念を当てはめようとしている意図が見える。

(5/8)動き出した エンタープライズアジャイル - [SAFe解説 後編]3階層のマネジメントで企業をアジャイルに :ITproの表のように、Scurmと対比させようとしているので、Scrumの経験がある人から見れば、理解しやすいだろうと思う。


| | コメント (0)

2014/12/22

「入門Redmine第4版」が出版されました

入門Redmine第4版」が出版されました

『入門Redmine 第4版』に仕込まれた小ネタ - ファーエンドテクノロジー株式会社

「入門Redmine」は初版の頃からお世話になっている。
僕がRedmineを使い始めた2008年頃、Trac本はたくさんあったが、Redmine本は「入門Redmine」が唯一の参考書だった。
ネットでも情報が少なく、貴重だったのを思い出す。

入門Redmine第4版」で面白い箇所は、巻頭特集にある「Redmineで農作業を記録する」章かな。

ソフトウェアエンジニア兼農家の人が、JAに出荷する農作業の履歴をRedmineに記録するようにした運用事例が書かれている。
最も興味深いのは、農作業の履歴をRedmineにどのようにマッピングしたのか、という問題。

解決策は「田んぼ仕事=プロジェクト、年=バージョン、田んぼ=カテゴリ、1回の作業=1チケット」。
運用ルールは、チケット管理は進捗管理ではなく記録管理なので、作業後にチケットを起票し、開始日=終了日にセットする。
チケットに実績工数を残し、カレンダー画面で、過去の年月の作業を一覧できるように工夫している。

この方法の良い点は、チケットに田んぼ作業の作業履歴が残り、紙のカレンダーのように、過去の作業日程や作業内容をすぐに検索しやすい点だろう。
バージョンが「2013年」「2014年」のように区別されているので、去年はいつどんな作業をしていたのだろうか、と思い出しながら検索できる。
また、田んぼの毎年の作業履歴が1プロジェクトに閉じているので、カレンダーで一瞥できるのも良い。

Redmineの運用で失敗しやすいアンチパターンの一つとして「サイロ型プロジェクト」があるが、作業をRedmineプロジェクトで分割しすぎると逆に管理しにくくなる。
ロードマップなどのチケット集計機能は、プロジェクトを横断する時、チケットの更新操作が結構面倒になるから。

なお、第3版から内容は大幅に変わっている。
第3版にあった「ヤミ作業」というアンチパターンはなくなったのがちょっと残念かな。
でも、Redmine初心者ならば、「Redmine超入門」「Redmineによるタスクマネジメント実践技法」と合わせて、「入門Redmine第4版」もお勧めだろうと思う。


| | コメント (0)

2014/12/21

「開発組織のマネジメント」のスライド資料が素晴らしい

「開発組織のマネジメント」のスライド資料が素晴らしいのでメモ。

資料の内容を理解したレベルで書く。

【1】問題意識としては、最近15年でWeb開発は従来よりすごく難しくなり、重要度が増している。
付け焼刃で簡単にプロダクトを作れるレベルではなくなった。

その理由はいくつかある。
一つは、開発基盤やシステムがレガシーであるため、ビジネスの変化に追いつけないこと。
2つ目は、企画チーム・開発チーム・運用チームのそれぞれで異なるやり方が根付いており、押し問答の状態になっていること。
サイロ型組織故に、開発組織の行動が局所最適化されてしまい、全体最適になっていない点に問題がある。

本来解決されるべき姿は、レガシー化を防ぐ作業に継続的に取り組むことと、サイロ型組織から自己組織化されたチーム構造へ組織を変化させること。
チームが都合で解散されるようでは、習熟度はいつまで経っても向上しない。

【2】一番の問題は、CTO不在問題。
CTOが本来果たすべき機能が組織に欠けている。
そのために、開発組織全体が全体最適にならない。

【2-1】昔は多分、品質保証部門のような部門が、開発基盤の標準化、開発環境の標準化などを行なっていた。
しかし、標準化作業はすぐに時代に乗り遅れる。

標準化された成果物ないし開発プロセスのバージョンアップや保守作業に多大なコストがかかるから、現場は疲弊する。
また、標準化の作業はトップダウンで現場に押し付けられがち。
現場からボトムアップでプロセス改善する空気を損なう。

【2-2】CTOの役割としては上記の資料でいくつかあげられている。

技術戦略、採用戦略。
アーキテクチャ、プロセスなどの開発プロセスサイクルの監督。
エンジニアの評価制度とモチベーション構築。

技術的な文化を根付かせる。
組織構造の継続的な最適化。

技術的な観点で経営にコミットする。

上記資料の一番最後の言葉が痛烈だ。
「開発組織には、開発組織特有のマネジメント手法(が必要だ)」。

ソフトウェアエンジニアやソフトウェア開発組織のマネジメント手法は、今後も試行錯誤してでも解決すべき課題だろうと思う。

| | コメント (0)

「60%の人間はプログラミングの素質がない」記事のリンク

「60%の人間はプログラミングの素質がない」記事をリンクしておく。

本の虫: 60%の人間はプログラミングの素質がない

(前略)
Jeffも読んでいるある論文をあげて、この議論の参加するためには、必ずこの論文を知っておくべきであると書いた人がいる。この論文は有名で、非常に興味深いので、全プログラマーが読むべきである。

ふたこぶラクダという名前で知られている有名な論文がある。この論文では、60%の人間にプログラミングの素質がないと推定している。翻訳ではなく、まとめ的な感想として紹介してみる。

The camel has two humps

なぜふたこぶラクダなのかというと、プログラミング学習者の集団において、その成績をグラフ化すると2つの山があるからだ。低成績の山と高成績の山だ。大学でのプログラミング教育の中で、経験的に、プログラミング学習者には三種類いることが知られている。全然できない者と、かろうじてできる者と、すばらしくできる者だ。その中間はほとんど存在しない。できない者とかろうじてできる学習者は、授業の進み方が速すぎると文句を言い、すばらしくできる者は授業の進み方が遅すぎると文句を言う。こんなに学習にばらつきがあっては、すべての初学者向けのプログラミング教育ができない。

この傾向は、年齢、性別、教育レベルの差にかかわらず、等しく起こるものであることも、経験的に知られている。どうやら、世の中にはプログラミングを理解できる人間とそうでない人間がいるように思われる。
(後略)

プログラミングのスキルは先天性のものなのか?
あるいは、後天的に身に付けられるものなのか?

「代入とシーケンス実行」という最も初歩的な部分で、初心者がつまずく、という指摘は興味深い。
多分、ポインタも初心者は理解できないのだろう。

でも、上記の記事を僕も笑えないと思う。
手続き型言語は読めるけれど、関数型言語のソースは正直まだ理解できない。
関数型言語のソースを理解する時も、上記と同様の問題を孕んでいるのだろう、と推測する。

| | コメント (0)

「アーキテクチャについて知ってみる」の感想 #Devkan

DeveLove関西の「アーキテクチャについて知ってみる」に行ってきた。
感想をメモ。
後にスライド資料が公開されたら、リンクしておく。

【元ネタ】
アーキテクチャについて知ってみる - DevLOVE関西 | Doorkeeper

情報処理推進機構:日本型企業が目指すエンタープライズアジャイルの世界
~開発現場の苦労話を聞き、成功への道をイメージしよう化

アーキテクチャとアジャイル プロジェクトをまともに進めるための両輪について #DevKan #devlove - Togetterまとめ


アーキテクチャについて知ってみる 「ゆらぎのある決定」以降のまとめ #DevKan #devlove - Togetterまとめ

DevLOVE関西 アーキテクチャについて知ってみる 2014/12/20 Hiroya Blog

「アーキテクチャは組織構造に従う」という経験則には2つの意味がある: プログラマの思索

【1】僕の問題意識としては、「アーキテクチャは組織構造に従う」という経験則には2つの意味がある: プログラマの思索に書いたように、プログラマが考えている「あるべきアーキテクチャ」がサイロ型組織や政治的利害によって、複雑怪奇なアーキテクチャに変わってしまう理不尽さにある。

多数の利害関係者の要望を受け入れていくうちに、アーキテクチャは複雑怪奇になり、保守性も低くなる。
結局、保守コストが増大し、機能追加すらも多大な工数がかかり、顧客自身も不満を漏らす。
そして、同じような目的を持つ業務システムを4~5年おきにリプレース案件と称して、リビルドし直す開発サイクルを繰り返す。

そのやり方は、丁度、購入したマイホームを新規建築しても、30年おきに壊しては作り直す日本の土建業界の風景に似ている。

【2】講演では、@yusuke_arclampさんの講演がすごく参考になった。
@yusuke_arclampさんのスライドで興味深いのは、ITサービス運営モデルに、開発プロセス・業務プロセス以外にも、運用プロセスや企画プロセスが明示されている点。

【2-1】4つのプロセスは、僕は下記で理解している。

1)開発プロセス・・・プログラマによるシステム開発
2)運用プロセス・・・インフラ・アプリ保守チームによるシステム保守
3)業務プロセス・・・ユーザ企業の従業員・情報システム部門メンバーが利用者にサービスを提供するための業務
4)企画プロセス・・・情報システム部門が、利用者の行動履歴をKPIなどで分析し、システムの機能改善やシステムのあるべき姿を見出して、開発チームへ要件を渡す

【2-2】実際のシステム開発では、開発したら終わりではない。
業務システムの初期構築費用は数千万~数億円もかかるから、最低5~10年は使わないと減価償却で元が取れない。
だから、その後の運用保守を想定したシステム構築をしなければならない。

その場合、システム側の観点である運用プロセスとユーザ企業の観点である業務プロセスの整備が重要になってくる。
運用プロセスの目的は、システムを安定稼働させることだ。
普通は、SLAを運用チームとユーザ企業が結び、サービス品質を保つ。

業務プロセスの目的は、例えば、バックエンドで従業員の業務や利用部門の業務をサポートすること。
あるいは、ECサイトの問い合わせ窓口やヘルプデスク業務を支援すること。
業務プロセスを円滑に行うために、ユーザマニュアルないしオペマニというドキュメントが必要になってくる。

企画プロセスの目的は、実際のシステム利用ユーザの行動履歴や利用ユーザの要望を元に、システムの改善要望をまとめることだろう。

【2-3】しかし、普通の観点では、運用プロセスや業務プロセス、企画プロセスは当たり前すぎて、漏れてしまうような気がする。
システム開発時は、納期までに納品させるだけで精一杯だ。
その後の保守、業務プロセスはシステム企画段階で検討はするものの、開発案件になったら、とにかく作るだけで精一杯。
納品間際に、オペマニを作って、保守チームと業務担当に渡して、後は任せました、で終わってしまいがち。

だから、アーキテクトは、システム企画段階だけでなく、システム開発の各工程でも、現在作っている成果物が運用・業務・企画プロセスにどのように影響していくか、考えておくべきなのだろう。

【3】僕は、渡辺幸三さんのDOAの3機能モデルを念頭に、@yusuke_arclampさんのITサービス運営モデルでは、アーキテクチャの複雑さをどのプロセスに押し込めるか、という方針はあるのか、と聞いた。

【3-1】その意図としては、「販売管理システムで学ぶモデリング講座」によれば、渡辺幸三さんのDOAの3機能モデルでは、システムは業務・機能・データの3階層にレイヤ化されるが、業務とデータ層は複雑にし、機能レイヤはシンプルにする、という話があったからだ。
その理由は、機能に当たるプログラムは、開発保守にコストがかさむし、複雑過ぎる機能は業務体制の硬直化を招くから。
特に、めったに使わない機能を作りこむよりも、そんな状況ではどのように対処すべきかを業務マニュアルに書く方がシステムコストは安く付くから、と。

@yusuke_arclampさんの解答は、利用状況によって異なる、ということだった。
運用プロセスに負担を掛ける場合もあれば、開発プロセスを軽くしてシステムを作って業務プロセスでカバーする方法もありますね、と。

【3-2】僕としてはちょっと肩透かしを食らった感じだったけれど、確かに、@yusuke_arclampさんのコンテキストでは、こうあるべきという方針は言いにくいように思えた。

個人的には、渡辺幸三さんのDOAの3機能モデルが主張するように「データモデルと業務モデルは複雑にし、機能モデルは単純にする」方針が一番しっくりする。
機能モデルに相当するシステム部分は、長年のシステム改修によって、どうしても肥大化し複雑化して、手に負えなくなる。
また、業務システムでは、肝心のトランザクションデータやマスタデータの精度を維持していく方が重要であり、そのためには、業務プロセスの精度を上げてデータの精度を上げていく手法を取る方向になるだろう。

【3-3】例えば、「販売管理システムで学ぶモデリング講座」では、出荷指示時に帳簿の在庫数と実際の倉庫での在庫数が違う場合、積極的に差数を認めて出荷指示する場合と、出荷指示を一旦取り消して在庫に応じた出荷予定を作り直す場合の2種類のどちらを選ぶべきか、という問題を提示している。

前者は業務モデルよりも機能モデルを複雑化する方向、後者は機能モデルよリも業務モデルを複雑化する方向の立場で異なる。

渡辺幸三さんの考えでは、後者のように、実在庫と帳簿在庫が一致するような運用品質を追求すべき、という立場を取る。
なぜなら、実在庫と帳簿在庫で差が発生する状況をずっと放置していては、在庫管理レベルはいつまで経っても向上しない。
だから、実在庫と帳簿在庫は一致すべきである、という運用になるように、業務プロセスがたとえ複雑になったとしても、業務プロセスの品質を上げるべきだ、と。

僕も渡辺幸三さんの考えに同調する。
その観点から考えると、データ重視の立場ならば、運用・業務プロセスが複雑化しても、企画・開発プロセスは軽く回すべき、という方向になるのだろうと推測する。

【4】他に気づいた点は、@yusuke_arclampさんのITサービス運営モデルでは、運用・業務プロセスは保守的かつ重厚になりがちで、企画・開発プロセスは変化に追随しやすく、軽量化の方向になりがちだという点だろう。

なぜなら、運用プロセスを担当する保守チームは、本番システムが安定稼働するのが最優先であり、頻繁な機能追加でシステムを不安定にさせたくない。
アジャイル開発のように、毎週・毎日のようにリリースするリスクは犯したくない。

また、業務プロセスを担当するユーザ企業の従業員も、バックエンドの事務作業の手順が頻繁に変わるのは好まない。
毎週のように新しい作業手順を覚えるのは苦痛だし、開発プロセスや運用プロセスでカバーしきれなかったデータ補正を担当させられるのは嫌だから。

一方、開発チームはアジャイル開発で小規模リリースを実現して、安定してリリースできるようにしたい。
最新の技術を取り入れたり、開発環境をブラッシュアップして、生産性を高めたいから。
そのためには、開発プロセスを作り直すことも厭わない。

また、企画プロセスでは、利用ユーザの行動履歴をデータマイニングして、新規事業を生み出したい。
リーンスタートアップのようなプロセスを導入して、システムの価値を高めるような方向へ持って行きたい。

すなわち、運用・業務プロセスの担当者と、開発・企画プロセスの担当者は、根本的に対立し合う状況にある。
前者は保守的であり、後者は革新的な立場になるからだ。

アーキテクトは、双方の利害を認識し、上手く調停する役割が求められるわけだ。

【5】最後に@yusuke_arclampさんへ質問した内容は、アーキテクトはユーザ向けにポンチ絵を描いて説明する時が多いが、アーキテクトが使うモデリングツールはお勧めの物があるか、聞いた。

解答は、パワポですね、と。
思わず皆笑ってしまった。

LibreぽざうねさんはTwitterを使っています: "質問:「使っているモデリングツールは何?絵で書いて意図を伝えるためにうまく使えるツールはある?」 #DevKan"

かわべ たくやさんはTwitterを使っています: "鈴木さん 「パワポ!(即答  これは理由があって、経営者の年齢層の方が見れるフォントサイズで作らざる得ない制約があるので、使ってます。」 #DevKan"

astahとか、Enterprise Architect、ERWinなどを期待していたが、やはりパワポだよね~と理解した笑

とはいえ、僕としては、astahを使って、アーキテクトが説明に使うモデルを表現できないか、色々試してみたいと思っている。


| | コメント (0)

2014/12/20

「アーキテクチャは組織構造に従う」という経験則には2つの意味がある

「アーキテクチャは組織構造に従う」という経験則には2つの意味があるのではないか、というアイデアについてラフなメモ書き。

【元ネタ】
akipiiさんはTwitterを使っています: "これに今悩んでる。RT @sys_architect1: アーキテクチャは、ステークスホルダーのニーズを満たすためだけに作成される。また、優れたアーキテクチャとは、ステークスホルダーの目的や目標及びニーズと見事に一致しているもののことである。p.21"

akipiiさんはTwitterを使っています: "「アーキテクチャは組織構造に従う」という経験則には2つの意味があると思う。1つは、サイロ型組織の構造はそのままソフトウェアに反映されて複雑な仕組みになってしまうこと。例えば、4つのチームでコンパイラを作ると無駄な4パスコンパイラになる。1パスコンパイラでいいのに。"

akipiiさんはTwitterを使っています: "もう一つの意味は、アーキテクチャとは、多数の利害関係者の思惑や要望という政治的利害によって決まる場合があること。経営企画部、営業部、製造部、ベンダー、運用部隊などの思惑を全て満たすアーキテクチャを決めようとすると、本来は単純な構造で良いはずなのに、複雑な構造になってしまう時がある"

akipiiさんはTwitterを使っています: "エンタープライズ界のアーキテクチャは、プログラマが考えている「ソフトウェアのあるべき姿」で決定されるのは稀。むしろ、アーキテクチャはステークホルダーの政治的利害によって決まる。だから「ソフトウェアは政治的利害を持つ組織群の構造に従う」。"

akipiiさんはTwitterを使っています: "アーキテクチャは、エンタープライズ界よりもオープンソース界の方が、プログラマが考えるあるべき姿で決めやすい。受託開発ならコスト・納期の制約でアーキテクチャやテストは制約を受けるので、無限のコストをかけて理想のシステムまで開発できない。でもOSSなら自分の気が済むまで開発できる。"

akiyama924さんはTwitterを使っています: "“@akipii: 「アーキテクチャは組織構造に従う」という経験則には2つの意味があると思う。・・・” 私の周りでは逆、すなわち、「組織構造は、開発対象商品のアーキテクチャの変化に依存して作りかえられる」でしたが、組織構造を変えるのが好きな会社だったからなのだろうか。"

akipiiさんはTwitterを使っています: "@akiyama924 製品に合わせた組織構造にする会社はトップダウンの会社でしょうね。マーケットの動きに敏感でビジネスライクな部分はいいでしょうが、慣れ親しんだ部署から突然、人事異動を受けて単身赴任させられたり、子会社に出向されたり、リストラされるのは嫌ですね笑"

鈴木雄介/Yusuke SUZUKIさんはTwitterを使っています: "そうか、生産性や保守性といった作り手の論理で考えると中央集権的な標準フレームワークが重要になるけど、サービスの論理では個別ドメインの課題に沿ったフレームワークが求められて分権化されたマイクロサービスが求められる、という説明が分かりやすいな。"

akipiiさんはTwitterを使っています: "この議論に注目。RT @haradakiro: @yusuke_arclamp ステートを持っている場所の移り変わりという話をすると面白いかも、と思っています。場所とちらばり具合の変化。"

鈴木雄介/Yusuke SUZUKIさんはTwitterを使っています: "アーキテクチャ設計ってのは四角と線を引く仕事じゃない。可能な限り情報を仕入れ、予測から判断し、関係者を調整し説得する。この泥臭さこそがアーキテクトの醍醐味なんだよ。"

【1】「アーキテクチャは組織構造に従う」という経験則には2つの意味がある。
1つは、サイロ型組織の構造はそのままソフトウェアに反映されて複雑な仕組みになってしまうこと。

例えば、4つのチームでコンパイラを作ると無駄な4パスコンパイラになる。
本来のあるべきアーキテクチャは、1パスコンパイラでいいのに、開発組織の無駄な構造がそのまま反映されてしまい、その後の保守がすごく大変になってしまう。

この事象は、個人的には日本の製造業系のSIで多いのではないかと思う。
普通のメーカーでは、一つの工業製品を作る工程では、営業→設計部門→製造部門→各工場→品質保証部門→サポート部門のように、故意に複数の部門を横断させるように担当させる。
品質チェックするために、複数の部門の相互牽制を効かせるみたい。

すると、一つの製品を作るリードタイムは、単なる作業時間だけでなく、複数の部門間のコミュニケーションロスも含まれるから、かなり長くなる。
工業製品なら仕様や規格が明確に決められているから問題ないように思えるが、ソフトウェア開発では、このやり方が正直うまくいった事例を見たことがない。

ソフトウェア開発はコミュニケーションロスの塊だ。
ユーザ企業の経営企画部門→ユーザ企業の情報システム部門→プライムSI→2次請けSI→オフショア開発→品質保証部門のように工程が分断されると、コミュニケーションロスがすごく大きくなる。
下請け会社ごと、人ごとに作ったソフトウェアのI/F部分で設計仕様が分断され、結合テストになって初めて大きな問題が発覚し、その後のテスト工程で火を噴く。

日本のSI業界の悪しき慣習である多重請負構造は、サイロ型組織を蔓延させ、ソフトウェアのアーキテクチャを無駄に複雑化させる。

【2】もう一つは、アーキテクチャとは、多数の利害関係者の思惑や要望という政治的利害によって決まる場合があること。
経営企画部、営業部、製造部、ベンダー、運用部隊などの思惑を全て満たすアーキテクチャを決めようとすると、本来は単純な構造で良いはずなのに、複雑な構造になってしまう時がある。
最近は、そんな事例を経験して、正直不思議に思っている。

それは、ステークホルダーの要求によって、アーキテクチャが決まってしまうこと。
つまり、ステークホルダーが持つ政治的理由の方が、プログラマが持っている「システムのあるべき理想像」からなる「より良いアーキテクチャ」よりも、勝る点だ。

例えば、自分たちが開発するシステムは、単独では動かない場合がある。
なぜなら、ユーザ企業内の既存システムからユーザマスタや商品マスタを複製する処理が必要だったり、外部システムから発注データを取り込んだりする必要があったりするからだ。
すると、外部接続というI/Fを別に開発する必要がある。

その場合、既存システムや外部システムの保守チームに、自分たちのチームの要望を簡単に受け入れてもらえるようなら問題ない。
ドメイン駆動設計」の「顧客・供給者の開発チーム」パターンのように、既存・外部システム(上流側・供給者)が自分たちのチーム(下流側・顧客)の言いなりになってくれるなら問題ない。

しかし、普通は、既存・外部システムは本番運用中なので技術的な冒険はあまりしたくないし、保守チームのリソースから考えて、大きな開発を担当できるほどの開発リソースもない。
だから、むしろ、「ドメイン駆動設計」の「順応者」パターンのように、自分たちのチーム(下流・順応者)は既存・外部システム(上流・供給者)の意向に逆らえず、彼らが準備しているI/F仕様に合わせて、古臭いやり方を踏襲するしかない場合が多い。

そんな場合は、「ドメイン駆動設計」の「腐敗防止層」パターンのように、外部システムの古臭いI/Fが侵入しないように、外部接続用のファサードを設けて、ラッピング処理のアーキテクチャを作る場合が多いだろう。
本来は、ラッピング処理のようなクッション(腐敗防止層)の処理を作る必要はないのに、無駄に複雑な間接層を作りこんでいるのだ。

自分たちのチームの業務システムはもっと簡単なアーキテクチャでいいはずなのに、外部の環境のせいで、無駄に複雑なロジックを抱え込んでしまうリスクがあるのだ。

特にエンタープライズにおける本来の業務システムのアーキテクチャは、もっとシンプルに作っていいはずだと思う。
しかし、現実は、利害関係者の思惑の方が、プログラマが本能的に知っている「より良いアーキテクチャ」よりも勝る。

【3】一方、オープンソース界では、プログラマが本来の理想像を求めて、より良いシステムを作れる環境があるみたいだ。
エンタープライズ界の業務システム開発では、政治的利害やサイロ型組織によって、アーキテクチャが複雑化しがちな例と好対照だ。

例えば、とある別のプログラマから聞いたけれど、仕事のプログラムのテストは、正直手を抜いている。
その理由は、スケジュール・コスト・品質の制約があるから、カバレッジを100%通すように作りこむことはできない。
だから、プログラマの直観や経験の勘によって、この部分のテストをやっておけば品質は担保されるだろう、と見込んで、テストを「ほどほど」にして終わらせる。
限られた時間内でプログラム開発を完了させる必要があるからだ。
無駄なだコストをかけてまで、赤字にしてでも、高品質にする必要はない。

しかし、オープンソースでは、自分の余暇を使って、好きなだけテストできる。
また、GitHubで自分のソースを公開する場合、この人はどこまできちんとテストしたのか、という成果物まで全部見られてしまうから、きちんとテストした方がいい、という動機も働く。
だから、オープンソースの開発では、テストプログラムはちゃんと書くし、カバレッジも100%に近くなるまで通します、とそのプログラマの方は言っていた。

そんな話を聞くと、エンタープライズ系の業務システム開発は、アーキテクチャの制約条件がきつすぎるのだろうと思う。
サイロ型組織、ステークホルダーの政治的思惑、コスト・スケジュールの制約などのトレードオフによって、本来はもっとシンプルであるべきアーキテクチャは、グチャグチャになり、綺麗な構造にならない。
テストもほどほどのレベルで終わらざるをえない。
その後の保守も大変だ。

一方、オープンソースの開発では、自分のアイデアを好きなだけ試すことができるし、プログラマが持っている「本来のあるべきアーキテクチャ」を作りこむことができる。

そんなことを思うと、大企業のような複雑な階層組織、サイロ型組織を持つ会社では、シンプルなシステムは作りにくいのだろうと思う。

シンプルなシステムを作ろうとすると、たくさんのシステムを共存せざるを得ず、SOAやEAIのように外部接続I/Fが増殖してしまいがち。
そんなアーキテクチャを多分「マイクロサービス」と呼ぶのだろうが、個人的にはそれが本当に良いアーキテクチャであるのか、僕は分からない。

| | コメント (1)

2014/12/15

乱立するRedmineの情報をREST APIで集約する記事が面白い

乱立するRedmineの情報をREST APIで集約する記事が面白いのでメモ。

【元ネタ】
イライラを解消! 乱立するRedmineの情報をまとめて確認できる環境を構築する (1/3):CodeZine

さかばさんはTwitterを使っています: "おぉ、詳しく書かれていますね。 RT @akipii すごく良い記事!RT @lyumei: CodeZine に寄稿しました。Redmine をネタに Python で API を叩いています。 http://t.co/dhSzlAom1I @codezineさんから"

上記の記事のように、社内でそれぞれの部署ごとに、Redmineサーバーが立ち上がって運用されている現場は多い。
その理由は様々だ。

僕も、最初に自分が所属する部署でRedmineを広げていった結果、100人くらいの部署で運用が根付いた。
そして、人事異動で他の部署に移るたびに、Redmineサーバーを立ち上げて、チケット駆動開発の運用ルールをWikiに書いて、そして立ち去っていくサイクルを繰り返した。
すると、一度運用が根付いたRedmineは、バージョンが古いまま、ずっと稼働し続ける時が多い。

Redmineが止まると、文字通り、受託開発案件のソフトウェア開発の業務が止まってしまう。
だから、下手にRedmineのプラグインを追加したり、Redmineのバージョンアップを試して、失敗するようなことはしなくなる。

また、それぞれの現場で使われるトラッカーやカスタムフィールドはどこも違う。
例えば、大規模な受託開発案件で使う現場もあれば、毎月30万の保守案件を十数個抱える保守チームの現場もある。
それぞれの現場で、Redmineの運用ルールは、基本的なチケット駆動開発の思想は同じでも、詳細はかなり異なる時が多い。

すると、それらのRedmineを集約して、製造業の現場のかんばんのように、リアルタイムに進捗を横串で見たい要望が出てくる。
上記の記事では、そんな状況において、複数のRedmineサーバーからREST APIでプロジェクト情報やチケット情報を取得して、情報収集端末にそれら情報を集約してHTML表示する方式を採用している。

このやり方が面白い点は、RedmineのREST APIを使えば、CurlなりPythonなり、自分の得意な言語でRedmineの情報を取得して加工できることだ。
上記の記事では、Redmineのチケット情報をJSONで取得し、PythonやCurlでパースするやり方を紹介している。

部課長の要望を聞き出して、情報を表示するようにすればいいだろう。

Redmine本家でも、REST APIは常に更新されており、内容はとても詳細に書かれているので便利だ。

Rest api - Redmine

Redmine本家を読むと、下記の言語が使えるらしいので、試してみると面白いだろうと思う。

Ruby
PHP
Python
Java
cURL
Drupal Redmine API module, 2.x branch
.NET
Delphi

| | コメント (0)

2014/12/07

「社内スタートアップによる組織の成長に伴い発生する痛みとその解決策について」の資料が素晴らしい

「社内スタートアップによる組織の成長に伴い発生する痛みとその解決策について」の資料が素晴らしいのでメモ。
以下はラフなメモ書き。

【参考】
hideakihalさんはTwitterを使っています: "このアジャイル開発のノウハウはすごい。/ 社内スタートアップによる組織の成長に伴い発生する痛みとその解決策について(Rebuild) #devlove http://t.co/pSVThDbN3b @SlideShareさんから"

村田 こーへいさんはTwitterを使っています: "なるほどー勉強になりました/社内スタートアップによる組織の成長に伴い発生する痛みとその解決策について(Rebuild) #devlove http://t.co/5KeLg5YyhF @SlideShareさんから"

【0】自社サービス開発案件に対し、アジャイル開発とリーンスタートアップを適用した経験事例。

【1】当初はわずか4~5名のチームが数十名のチームに膨れ上がり、リードエンジニア(事実上のサブリーダー)がボトルネックになって、チームが回らなくなる問題があった。
よくある伝言ゲーム、身がないたくさんの会議、など。

そこで、スクラムを取り入れて、複数の小さなチームに分割し、プロダクトオーナーチームとスクラムチームを形成するようにした。
つまり、リーダー制度を廃止した。
他にも、バグのトリアージ、リリースカレンダーなどを取り入れて、定期的にリリースできる仕組みを取り入れた。

こういう話を聞くと、すごく同感する。
最近は、プロジェクトリーダーという役割がボトルネックになっている気がする。
プロジェクトリーダー一人で全員のスケジュール・コストの管理をするのは至難の業で、たくさんの労力がかかる割には、意思決定がすごく遅い。

アジャイル開発がスムーズに回るチームにいると、プロジェクトリーダーのロールの人は、管理の役割からプロダクトオーナーの役割に自然に移っていく。
チームはいつまでに何をリリースすべきか、というプロダクトバックログを常に保守するようになっていく。

すると、プロダクトオーナーのスキルは、単純な管理だけでなく、経営や戦略と言ったもう一段階上の高い視点の意思決定が要求されるようになる。

【2】しかし、スクラムを取り入れたからと言って当初の課題であった「成長スピードの鈍化」が改善されなかった。
プロダクトバックログに起票されるタスクが本当にやるべきことなのか?
そのタスク(機能)をリリースしたあとの効果はタスク(機能)毎にわかるのか?

無駄な機能をたくさん作ってリリースしても、売り上げにつながっているのか?

そこで、リーンキャンパスやリーンスタートアップのBuild→Measure→Learn、顧客開発モデル、MVPを適用して、スクラムの各タスク(機能追加) の効果(結果)を正しく計測していった。
そこから得られた結果を元に、ビジネス仮説をブラッシュアップして、サービスを成長させた。

この話を聞くと、やり方がうまいなーと思う。
特に印象深いページは、P.82のリーンキャンパスの絵。

P.82には、リーンキャンパスの9つのエリアごとにMVPの機能を作って「構築→計測→学習」のプロセスを実行し、MVPの効果を評価検証するようにもうけている。
つまり、リーンキャンパスというビジネス仮説を評価検証した後、プロダクトバックログへその内容を反映してブラッシュアップし、製品開発のサイクルを早めている。

リーンキャンパスは僕も書いた経験があるが、書いてみると色々ブレインストーミングできるし楽しい。
しかし、その仮説が本当に正しいのか、という実証データは、リーンキャンパスだけでは分からない。
やはり実際に製品をリリースして試して、結果が得られなければ分からない。

でも、P.82のリーンキャンパスの絵を見ると実際に実行してみて、その結果を反映して色々試している。
この辺りのノウハウが公開されているのはすごいと思う。

| | コメント (0)

2014/12/06

Redmineとチャットツールを連携する方法~Slack、Hubot、HipChat、Github

RedmineとSlack、Hubot、HipChat、Githubの連携方法のリンクをメモ。

【0】Redmineでチケット管理すると、チケット更新のたびにメール通知されるので、10人くらいのチームなら1日100通以上流れる場合は良く起きる。
すると、チケット更新の通知が多すぎて、逆に鈍感になってしまい、情報共有しづらくなる状況も発生する。

つまり、Redmineのチケット管理による情報共有は、どの機能を使って実現すべきなのか?という課題がある。

Redmineのチケットのウォッチャー操作に関する課題: プログラマの思索

メール通知をよく使うチームでは、ウォッチャー機能を使って、メール通知するユーザを事前に選択して使い分ける運用もよくする。
しかし、最近なら、社内であってもチャットツールを使うのが普通だろう。

チャットツールにRedmineチケット更新通知、Jenkinsの通知などが流れる方が運用しやすい時も多い。
実際、Redmineとチャットツールを連携する事例をよく見かけるので、リンクをメモしておく。

【1】Slack
最近よく聞くチャットツールはSlackかな。

sciyoshi/redmine-slack

SlackとRedmineを連携し、登録したチケットの更新を通知する方法 | 株式会社LIG

SlackにRedmineのチケット更新を通知する | Z BLOG

【2】HipChat
Attlasian謹製のチャットツールで、最近は無料で無制限にチャットできるみたい。

hipchat/redmine_hipchat

qnypではHipChatでどんなふうに開発を快適にしているか // qnyp blog

チームで使うチャットサービスにHipChatを採用した話 - reBuild *;

iOSアプリ開発でもCI/継続的デリバリしようぜ(終):Jenkins+HipChat+Hubotをチーム開発に導入してお手軽CI (1/3) - @IT

【3】Hubot
GitHub謹製のbotフレームワークで、botを介してチャットする。
SlackやHipChatに比べると、設定手順が多少必要。

チャットボットでチーム開発効率化入門(2):Redmine連携でチケットをチャットに通知&開発を楽しくするHubotスクリプト6選 (1/3) - @IT

Redmineのチケットの変更をHubotを経由してチャットに通知する - Qiita

Redmine に Webhook を追加するプラグインを作った - すえひろがりっっっっ!

suer/redmine_webhook

【4】redmineとGithubの連携

GitHubはチャットツールではないが、RedmineにGitHubのリポジトリ一覧を表示したい要望はある。
調べてみたら、すでにプラグインがあるので、使った事例があるみたい。

koppen/redmine_github_hook

redmineとgithubの連携 - katashiyo515's diary

RedmineとGithubの連携 - Qiita

Redmineとgithubの連携 - 駆け出しプログラマーの開発メモ

RedmineのGit連携の課題については、以前書いた。

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

GitHubのIssue機能をRedmineのチケットで代用するとか、GitHubのリポジトリをRedmineのリポジトリに表示させる、という手法は、Redmineで情報を一元管理したい要望から発生していた。
しかし、本来は、GitHubの優れた機能である「プルリクエスト」「ブランチ管理やマージ作業の容易さ」もRedmineで実現したいという課題もある。

色々試してみたい。

| | コメント (0)

2014/12/04

「ローバー、火星を駆ける―僕らがスピリットとオポチュニティに託した夢」の感想

ローバー、火星を駆ける―僕らがスピリットとオポチュニティに託した夢」を読んだ。
感想をメモ書き。

【参考】
ローバー、火星を駆ける―僕らがスピリットとオポチュニティに託した夢(スティーヴ スクワイヤーズ/Steve Squyres/桃井 緑美子) - ただのにっき(2008-02-05)

404 Blog Not Found:書評 - ローバー、火星を駆ける

2014年12月3日に、小惑星の岩石を持ち帰るために、はやぶさ2号が飛び立った。
この本はもっとスケールが大きく、火星探査の調査機オポチュニティが、10年以上も稼働していることだ。

気に入った点は2つ。
一つは、ソフトウェア開発のプロジェクトリーダーの立場にいるので、NASAの案件を取る試行錯誤、案件開始後に火星調査機の製造を巡る試行錯誤は、とてもリアルに感じる。
そして、火星に到着後に火星探査機が水の痕跡を求めて調査しているのを地球でフォローしているチームは、まさにシステム稼動後の本番運用フォローの部隊と同じだ。

もう一つは、科学者とエンジニアの宿命的対立と、それを乗り越えた科学者とエンジニアの共同作業による成果の偉大さだ。

つまり、科学者の立場は、真実の探求、自然界の仕組みの探求、制約なしの研究の結果を重視する。理想主義者。
一方、エンジニアの立場は、技術的課題の単なる解決ではなく、最も優れた方法で問題解決する。限られた予算、開発スケジュール、納期の制約の下、「まずまずのところ」で折り合って解決する。がんこな現実主義者。

しかし、科学者とエンジニアは宿命的な対立構造があるが、それを乗り越えたら、偉大な成果が得られる。

そんなエピソードが満載で、読んではらはらドキドキして面白い。

| | コメント (0)

« 2014年11月 | トップページ | 2015年1月 »