無料ブログはココログ

« 2015年6月 | トップページ | 2015年8月 »

OSSを応援してソフトウェアの自由を得よう - 話題のRedmineの魅力を知ろう その2 - #benkyoenkai

第42回IT勉強宴会 話題のRedmineの魅力を知ろうの続き、前田さんの講演の感想です(その1)。

前田さんの発表は3本立てで、まずRedmineをプロジェクトに適用しようRedmineによるwebサポート窓口の実装と運用からの抜粋したお話がありました。そのあとのRedmineへのContributeとビジネス展開は色々と考えさせられました。

FLOSSふりかえり

フリーソフトウェア(FLOSS: wikipedia)が生まれたのは、元々は相互扶助でした。「良かったら使って!」と無料で公開されたると、利用者は感謝の言葉や感想、バグ報告や修正パッチ等を返していました。レスポンスを得ることで開発者は元気をもらい、開発を続けました。

ソフトウェアやユーザの規模が大きくなるにしたがい、開発者と利用者の距離は離れ、協力する人の比率は少なくなっていきました。やがて、無料である以外は商用ソフトとあまり変わらない、シェアウェアやフリーミアムのようなビジネスモデルが出てきました。利用者からすると無料であれば良かったのかもしれません。

その後、セキュリティ面の優位性やベンダーロックインをさける目的などから、市販アプリの対抗馬として、市販アプリと同じ評価軸で考える人が増えていきました。事業の継続性や有償のサポートの有無など、フリーソフトウェアが生まれた頃には考えられない見方です。

すると今度は、有名なフリーウェアを単に支援するだけでなく、自社のビジネスに都合の良い方向にコントロールしようとする企業が現れ、著名なFLOSSプロジェクトが買収されました。

FLOSSの"L"は利用するプログラムのコードの改良や公開の自由を指しますが、このような買収によって、コードの修正の自由を特に望まないような一般の利用者の使い続ける自由も危険にさらされました。

結果的には、コードが公開されている事で、あるべき姿を望む人たちによって分裂(フォーク)し、下心を持ったチームは衰退し、利用者の使い続ける自由が守られました。

ファーエンドテクノロジー社の支援

前田さんの会社の支援は、Redmineの開発コミュニティに協力するものです。もちろん企業ですから「情けは人のためならず、巡り巡って我がのため」ではあるのですが、直接的な利益は求められていません。どちらかというと、メリッットを享受したからお返しするような印象を受けました。

変なスポンサーがつかなくても、開発がチームで行われ、相互扶助のわかる利用者のいるFLOSSは続くと思います。資金でなくても、パッチ、コメント、感謝があれば、開発コミュニティは継続するでしょう。

おわりに

ソフトウェアの寿命は長いと言われますが、市販ソフトやスポンサーのついているオープンソースだからといって永遠に続くものではないことは周知の事実でしょう。開発している人たちが継続しようと思える相互扶助的な環境を維持できる事が、ソフトウェアの寿命を延ばし、結果的に利用者の自由を守ると思います。

あまり貢献できていませんが、少しでも協力したいと思います。

このエントリーをはてなブックマークに追加


Redmineからワークフローを考える - 人間の可能性を生かすには -

先日のRedmineの紹介を終えてから、そのワークフローの思想を考えてみました。

一般的なワークフロー

Wikipediaによれば、

ワークフロー(英: workflow)は、リソース(資源)を体系的に組織化した反復可能な業務活動のパターンである。

とされていて、障害票や経費伝票などのハンコ欄やの確認日欄などもワークフローを処理する仕組みの一例と言えると思います。

ワークフローを表す場合によく使われるのは、状態遷移図のようにある条件によって状態が変わるモデルです。ワークフローのモデルは作業の分析や自動化にも用いられますが、例えば「リーダの確認によって完了状態になる」のように、作業の進め方のルールをホワイトリスト的に示したものでもあります。

たとえばTracでは、TICKET_MODIFY権限を持つユーザがacceptすると担当をユーザにして、状態をacceptedにする場合は、以下のように書く様です(Tracプロジェクトのサンプルより引用)。

accept = new,accepted -> accepted
accept.permissions = TICKET_MODIFY
accept.operations = set_owner_to_self

このような記述でルールを追加していきます。

Redmineのワークフロー

これに対してRedmineのワークフローは状態遷移表の様に、ロールとチケットの種別毎にステータス間の遷移を許すかどうかをマトリクスで設定します。

 

2_1_4

 

Redmineはブラウザからワークフローを設定できて便利です。しかしTracのようにルールを追加していく場合は、全体が見渡せないので、かえって不便です。

これは実装の都合のようにも思えますが、実は設計思想が違うのではないかと思いました。つまり、ほとんどの遷移は許すものの「リーダ以外が完了状態にする事は許さない」のように、いわばブラックリスト的な設定を容易にしているのではないかと思います。

人間の可能性を生かすには

さて、前述のWikipediaには、このような事も書かれています。

21世紀初頭のインターネットバブルの崩壊により、高度なワークフローの概念化に対する不信感が生まれた。今日、様々な人々が、合理的で柔軟で国際化(作業場所の分散)に対応可能で人間の可能性を十分に生かす新たな作業モデルの開発という問題に立ち返っている。その中でも、オープンソースコミュニティで育ってきた、一見して無政府主義的なシステムに対する真剣な考察は重要である。

Redmineのワークフローはそのドメインのモデルとして、基本は自由でありながら人間がミスを犯しそうな場合には制約を与える方法をとったのではないかと思います。

人間の可能性を生かすには、サーバントリーダーシップ(アジャイル開発への壁は価値観の壁)のように、ルールによる管理から最大限の能力を発揮できるような支援への発想の転換が必要なのだと思います。Redmineのワークフローには、そのような抽象度の高いドメインモデルが隠れているのかも知れません。

このエントリーをはてなブックマークに追加


Redmineチョット入門 - 話題のRedmineの魅力を知ろう- #benkyoenkai

第42回IT勉強宴会 話題のRedmineの魅力を知ろうで発表しました。

これまで雑誌やムックにRedmineの紹介記事は書いていましたが、人前で30分もRedmineの紹介をするのは今回が初めてでした。 入門なので障害管理の定義から入る事も考えましたが、 Redmineがなぜはやっているかというテーマ、かつ、前田さんの前座なので問題から入ったのですが、前田さんとかぶったり、物足りなかったりで、難しかったです。

チケット駆動開発はRedmineだけのものではありませんが、やはり多機能なRedmineの魅力はチケット駆動開発で活きるのだと思いました。

以前Redmineは帳票ワークフローシステム?に書いたRedmineの特徴の一つであるワークフローの設定について、発表では開発の都合でUIが設計されている様に説明しました。しかし、説明をしたり懇親会の話を聞いていて、少し違う(ドメイン分析の結果)かもしれないと思いました。詳しくは別記事にまとめました。

なお、Redmine.jpの前田さんの発表についてはその2をご覧下さい。

このエントリーをはてなブックマークに追加


会社の愚痴と上司の視線3 - 直接話をして自分の問題を考える-

「会社の愚痴を言いませんね」と言われて理由を整理しました。

初回の上司の視線で考え、腐った時期があり、ひょんな事から留学し、前回の自分から少し離れた夢を持つようになったあと、職場復帰後に居た研究所は恵まれた環境でした。

文科省の共同研究やIPAの公募事業のほか、アジャイルな友人と論文を書いてICSEに採録されるなど充実していました。しかし、ソフトウェアプロセスを学んだ私が現場にいないのは、会社にとっては良い事なのかと考える様になりました。

上司の立場で考えてみる

そして、もし自分が上司や人事の立場ならどう判断するだろうと考えました。その結論は、現場に戻すべきだと思いました。知識を活かして現場のプロセス問題を解決すべきだと考えたのです。

当時の仕事もありましたので、自分からは言い出しませんでしたが、その後の社会情勢の変化もあって、2年後に現場に異動になりました。

当時の上司は「残念なお知らせ」と言っていましたが、私にとっては2年遅れの判断でしたので、不安はあったものの覚悟はできていました。

納得できない時は直接言う

現場に戻ってからも自分だったらどうするかを考えていました。当時、2つの問題プロジェクトがあり、規模の小さい方のプロジェクトを担当しました。

その間に、もう一つのプロジェクトは大火事になりました。この時は、なぜあの大変なプロジェクトに入れなかったのかと、上司に直接言いました。

しかし、私がもう一つのプロジェクトを担当した時は、そちらの方がどうにもならない状態だったので予想できなかったのは仕方の無い事でした。また、私自身にもプロセスの知見について「うまくアピールできていない」という反省点もありました。

プロジェクトマネージメント

現場でプロジェクトマネージメントをするようになると、さらに自分の気持ちは考えなくなりました。技術的に安定した開発ならリーダーがすべてを把握して、トップダウンに管理する事も可能です。しかし、技術要素が増えてくると知見者を集めての総合力勝負になるので、いかに全体の能力を発揮するかが勝負になるからです。

いわゆるサーバントリーダーシップ(アジャイル開発への壁は価値観の壁)を発揮しないといけません。自分が実装してノウハウを貯めたい部分であっても、効率を考えて能力を発揮してくれそうな人に譲り、ノウハウの取得は方式設計とコードレビューで我慢して、総合的に自分がやると効率が良くなりそうなところを担当することも必要になります。

「プロジェクトが成功するためならなんでもする」と言いますが、 管理する人間はゴールに向かって、自分の思いすら捨てないとうまくいかない時があると思います。

納得できない時の対策

しかし、話し合ったり、ゴールだけを見る様にしても、会社の方針が納得できない事もあるでしょう。納得できない時には、以下のような対策があると思います。

  • 正しく判断してもらえる様に説明やアピールをする:自分のことや考えが伝わっていないなら、時間がかかっても説明する必要があるでしょう。
  • 受け入れた上で方向性を見直す:「なぜか」を理解して、判断そのものが理解できるなら、改善策を考えて理想に近づける方法があります(後述のおまけ参照)。
  • 自分の問題を改める:自分の問題を見極めて、もし自分が未熟なら、自分を磨かないといけませんし、任せてもらえるだけの信頼貯金も必要でしょう。
  • 上司の異動や退職を待つ:会社や部門によって違うと思いますが、異動や定年が予想されるなら、待つのも一策です。もちろん、ただ待つのではなく、その時に向けて準備を進めます。
  • あきらめて異動や転職を考える:冷静に上記の可能性を考えて、 どうしても方向性が合わないなら移るしかありません。愚痴を言っている暇はありません。すぐに動くべきだと思います。

ということで、腐っている時間や愚痴を言っている時間があるなら、行動をした方が前向きだと思います(心が折れそうな時には、ガス抜きも必要です)。

まとめ

転職は離婚や引っ越しと似ていると思います。いずれも続けるかやめるかの二者択一の問題です。

もし、うまくいかないなら良く話し合った方が良いと思います。説得したり、アピールも必要で、妥協したり、自分が変わらないといけない事もあるかも知れません。

どうしても我慢できなかったり、方向性が合わないなら、早く新しい人生を歩む方が良いと思います。でも、やっぱり共に居たいという思いが強いなら、何とか折り合いをつけないと仕方がありません。

持ち家派と賃貸派の様に、長期的な計画や社会的信用を選ぶ方と、状況に合わせて選んだ方が得だという考え方もあるでしょう。いずれが良いかはそれぞれの価値観だと思いますし、予想外の事態もあるでしょう。

しかし、どのような状況であっても、愚痴ったり腐ったりせずに、冷静に考え、決断は早く、的確に行いたいと思っています。

「気は早く、心は静か、身は軽く、技は激しく」
  
(北辰一刀流の教え:「竜馬がゆくより」)

おまけ

個人的にアジャイル開発がフィットするマーケットは、今後広がると考えています。所属する会社でも少しは実績があるのですが、もっと積極的に展開する様にと、何度か提案しています。

しかし、話は進んでいません。諸条件が揃わないからで、理由は納得できるものです。私自身も開発手法を実践したいのではなく、これからのソフトウェア開発にはアジャイルの価値観の実践が必要だと考えていたので、現状を改善する方向で考えました。

[#TiDD] ウォーターフォール型開発をアダプタブルにする3+1

対象とするマーケットはアジャイル開発と若干異なり、従来の案件のうちアジャイル寄りのところになると思います。これはこれで面白いアプローチだと思っています。

ピンチはチャンスと言いますが、どんな時も腐ったりせずに行動すれば、得るものがあると思っています。

このエントリーをはてなブックマークに追加

会社の愚痴と上司の視線2 - 夢は大きく -

前回の会社の愚痴を言わない理由の続きです。

転職を考えた方が良かったかもしれないタイミング

社会人を長くやっていると、お誘いを受けることもありました。そういう時はたいてい仕事が調子に乗っている元気な時でした。仕事が面白い時ですから、もちろんお断りしました。

しかし、転職を考えた方が良かったかもしれないのは、前回書いたSONY NEWSのブームが落ち着いて、SRAが他のワークステーションも売る様になった時です。

NEWSの技術サポートを始めた頃は、TCP/IP関連の工数を受けたり、暇を見つけてはユーティリティを販売して部長賞をもらうなど、それなりに面白かったです。

しかし、NEWSがSystem Vを採用するなどして方向性が変わり、いわゆるSI的な売り方が始まったのです。技術的に興味深い事も減って、システム開発の裏方に回るようになりました。

元々はプログラミングがしたいのですから、面白くなかったのです。やがて、技術的な事にも興味がわかなくなりました。当時のように腐っている状態が続いていたなら、転属か転職を考えた方が良かったかも知れません。

夢が小さかった

振り返ってみると、開発をしている時も、技術サポートをしている時も、自分のメリットだけを考えていました。ものづくりの喜びや技術的な興味、つまり自分の欲望が仕事の目的だったと思います。

欲望というのは満たされる事がありません。美味しいものはもっと食べたいですし、お金はもっと欲しいです。欲望が止まる時はそれで何かを失う時だけです。

当時は仕事に楽しい事を求めていて、仕事を楽しくする努力もせず、そもそも仕事で実現すべき事は何かを考えていなかったのです。

喜ばれる報告書

あるとき、1番目の候補者が断ったということで、奈良先端大に留学する話がありました。現状に不満を抱いていたので、家族に確認もせずにOKしました(残業手当が出なくなるので、かなり怒られましたw)。

留学後、学会の研究会に出ると「何をされていたのですか?」と聞かれ、「営業の技術支援です」と言うと妙な顔をされました。まあ、普通はいませんよね。そこで「会社が新しい事をする時に何でもさせられるんでよね」というと、不思議に納得されたりしました。

あるとき、同期入学のWさんが会社への報告書を書いているので読ませてもらうと、まるで旅行記の様な面白い文章を書いていました。それまで、報告書というのは義務的で、面倒臭いものだと思っていましたので、とても驚きました。

Wさんに聞くと、こう言いました。

「報告書なんて誰も読みたくないんですから、面白い事を書いておかないと読む人がかわいそうですよ」

「目からウロコ」というのは、こういう事を言うのでしょう。 報告書というのはお決まりの内容を真面目に書けば良いものだと思っていました。

ましてや この友人は大手メーカー系の会社の人なので、几帳面な報告に違いないと思っていました。読む人に喜ばれるように報告書を書くとは驚きました。

夢は大きく

Wさんの話を聞いて仕事とは何か、それまでの自分の考え方が小さく感じられました。これまでは、自分が作るとか、自分が成長するとか、自分が楽しいとか、常に自分を中心に考えていました。

もちろん仕事は楽しくしないと能力が発揮できませんが、自分だけが幸せではダメだったのです。そんな小さな夢ではなく、大きな夢、人間的に豊かな夢を抱かないといけなかったのです。

自分が1番になるとか、給料を増やすとか、人の欲望はキリがありません。いつまでも満たされません。小さな夢では満足できないからです。

これに対して、人のため、社会のため、といった大きな夢は、たった一つでも幸せになります。昔、腐っていた時も、お客様に感謝されるとか、基礎的な技術を整理して発表するとか、もっと仕事を通して人の役に立つ事を考えていれば、有意義な時間が過ごせたと思います。

少しだけで良いので、自分の枠を超えた夢を持つ事が必要なのだと思います。それは、仕事に対する見方が大きく変わる第一歩なのでした。

(まだつづく

このエントリーをはてなブックマークに追加

会社の愚痴と上司の視線1 - 上司の視線 -

勉強会が終わり、居酒屋の片隅で転職は離婚とか、引っ越しと同じだ。とか言ってたら、「そういえば、さかばさんは会社の愚痴を言いませんね」と言われて気付きました。あまり言った事は無いかもしれないですね。だから、転職もしないのか、などと思いました。

では、会社に不満は無いかと言うと、これも家族とか、家と同じで、何らかの不満はあります。でも、人に言わないのはそれなりに納得してるからでしょうね。

わたしが納得しているのは、上司の視線で考え、夢を大きくし、 直接話をして自分の問題を考える、からだと思います。

若かりしころ

では、昔から納得する事ばかりかと言うと、そうでもありません。いつからか、自分が上司だったらと考えているからだと思います。

最初のきっかけは、入社3年目にソニーのNEWSというワークステーションの技術支援をした時です。岸田さんの書籍「ソフトウェアグラフィティ」(おぉ、モンブランか! - ソフトウェア・グラフィティ -)にあるようにSRAはNEWS(NET Work Station)への技術協力をしました。販売も協力する事になり、私も営業の支援にかり出されることになりました。

それまで自分はSRAという船で「生涯一プログラマ」として過ごすと思っていましたから、どうしようかと思いました。Cプログラミングは誰にも負けない自信がありましたから、会社を移ってプログラマを続けることも含めて色々考えました。

考えているうちに、なぜ自分が選ばれたかも考えました。当時、候補に挙がりそうな人は数名いましたが、たまたまプロジェクトの切れ目でしたし、JUS(日本UNIXユーザ会)やSEA(ソフトウェア技術者協会)で発表もしていましたので、こいつだったら人に説明もできるだろうと思われたのでしょう。

そう思うと会社への反発はあまり感じなくなり、冷静に考える事ができました。NEWSはそれまでは1,000万円以上するSUNのワークステーションしか無かった時代に、SUNと同じ様にネットワークの標準であるBSDを採用し、200万円程度で使える環境を提供する画期的なマシンでした(ちなみにその後AIBOを事業部長として担当されたSONYの土井さんが部長として担当されていました)。

当時はIPAがシグマ計画を進めている時期でSYSTEM Vの国産UNIXマシンを推進しようとしていました。それに対抗して、商用でUNIXを初めて導入したとはいえSRAという小さな会社と手を組んで、本来あるべきワークステーションを売るというのですから面白いお話です。

やがて、入社前のSRAの採用案内に「SRAは小さな船です。同じ方向に行くなら一緒に乗ってください」と書いてあったのを思い出し、面白そうだからもう少し乗っておこうかと思いました。

上司の視線

会社に不満を持つという表現をしますが、実は上司への不満がほとんどではないでしょうか?

全社的なリストラでもない限り、会社という大きな意思はあまりありません。大抵は上司が仕事に関する事を決めています。

「なぜ自分が!」と思う時は、上司の立場で考えて考えてみると良いと思います。案外、納得してしまうと思います。そして、落ち着いた中で、それを受け入れる事ができるかどうかを考えると良いと思います。

自分の視線からは不条理に見える事も、その上司は色々と考えた上の結論かも知れません。もし、同じ立場で考えられたなら、より良い方法が見つけられるかも知れません。

おまけ

たまに異動させてくれないと言う人がいますが、会社として決定しないといけない事は、会社スケールで動かないとうまくいきません。役に立っている人なら上司も離したくないので、なおさらです。

人事に異動を願い出てもうまくいきません。うまくいくのは、たまたま異動先がある場合だけです。

本当に異動したいのなら、異動先を見つけて引っ張ってもらう事です。人事に話をしてもらえれるだけでも話が前に進むでしょうし、もし上司に話をしてもらえたなら異動できる可能性がより高くなるかも知れません。

つづく

このエントリーをはてなブックマークに追加


Redmineは帳票ワークフローシステム?

Redmine本やチケット駆動開発の本を共著させていただいた@akipiiさんと知り合って長いですが、未だにピュアな感性が魅力的な方です。古くはチケット駆動開発を@akipiiさんから聞いたとき、「説明がよく分からない。一層の事チケットはタスクカードと言うのならわかる」と苦情を言ったところ、たいそう気に入っていただいたようで「チケットはタスクカードのようなもの」がアジャイル型チケット駆動開発の説明になりました。

今回は「Redmineは色々なものに使えますけど、一体何なんでしょうね?」と問われて、苦し紛れに「帳票のワークフローシステムじゃないですか」というと、ブログに書いていただけました。

どちらも正直な気持ちで嘘は無いので、光栄な事です。ただ、帳票のワークフローシステムという考えは説明が必要だと思いますので、まとめておこうと思います。

ベースは障害票のワークフローシステム

Redmineがスプレッドシートと違うところは、データが正規化されているところです。スプレッドシートでは一覧の中に障害情報がまとまっているだけですが、Redmineではそれぞれのチケットが帳票として独立していて、一覧で参照したり、コメントを追記していく事ができます。

また、スプレッドシートでは誰でも状態を変更できますが、Redmineでは予め設定されたワークフローで許されたユーザだけが次のステータスに変更する事ができます。

また、Webだけでなくメールを使って参照や更新ができますので、遠隔地からも利用する事ができます。

プロジェクト管理ツールへ

ここまでは、昔から障害管理ツールでできた事です。これがtrac以降のITSとかプロジェクト管理ツールと呼ばれるツールでは、Wikiを内蔵しているほか、バージョン管理ツールと連携する事ができます。

Redmineのチケットは障害だけでなく仕様変更も管理できますので、バージョン管理ツールと連携する事で、障害管理、変更管理、構成管理、ができる様になります。この3つが連携する事でトレーサビリティが大きく向上します。

Redmineではさらに独自機能としてプロジェクト管理が容易な様に、ガントチャート、階層的なプロジェクトとチケット、REST API、LDAP認証、などの機能で柔軟に管理できます。

汎用的な帳票ワークフローシステムとしてみると

ここで、Redmineを汎用的な仕組みとしてみると、基礎となる帳票ワークフローシステムが大きく拡張されている事がわかります。もちろん、プロジェクト管理に有用な機能ですので限界はありますが、汎用的で柔軟な仕組みになっています。

最近はプロジェクト管理だけでなく、カスタマサポート、資産管理、創薬管理、などなど、プロジェクト管理に限らず、色々な業務に使われる様になりました。そんな様子から、Redmineに詳しい@akipiiさんの「Redmineは色々なものに使えますけど、一体何なんでしょうね?」という問いに繋がったのです。

業務システムにも使われているRuby on Rails上の、良くできた帳票ワークフローシステムですので、簡単なものから色々な業務に使ってみると良いと思います。

このエントリーをはてなブックマークに追加


« 2015年6月 | トップページ | 2015年8月 »