astahプラグインのタスク一覧が良い感じなのでメモ。
【参考】
astah*プラグイン タスク一覧(拡張タブビュー表示) 0.9.1公開 | 響雲
ノートに「TODO」と書いておけば、下部にTODOリスト一覧が表示される。
EclipseのTODOタグと同じ機能。
TODOリスト一覧をダブルクリックすると、TODOが記載されているダイアグラムが開くのもいい。
モデリングは1回では終わらない。
TODOを残しながら、1つずつ解決して描いていく時が多いから、重宝しそう。
Qiitaに掲載されていた「Gitでやらかさないための事前予防策や奥義のTIPS」が参考になったのでメモ。
【参考】
Gitでやらかした時に使える19個の奥義 - Qiita
Gitはコマンドが奥深い。
コミットの歴史を改変できるから、masterに取り込む時に、綺麗なコミット履歴になるように修正できるのが良い。
上記の記事で参考になったのは、コミットメッセージの書き方の解説。
コミットメッセージのフォーマット、コミットメッセージで使用する英単語をあらかじめ決めておく点はすごく参考になった。
確かに、あまり気にせずにコミットログを書いていて、後から自分でも理解不能になる時があるから。
CVS、SVN、Gitというバージョン管理の歴史を振り返ると、たかがバージョン管理といえども、開発環境はどんどん進化している。
その進化と共に、開発プロセスもどんどん変わってきて、もはやアジャイル開発はオープンソースでは当たり前。
先日のAgileJapanで参加者を話していて、つくづく感じた。
その辺りも今後追いかけていく。
Agile Japan 2015 大阪サテライト「アジャイル開発への架け橋」 でLT発表してきたのでメモ。
【参考】
Agile Japan 2015 大阪サテライト「アジャイル開発への架け橋」 - Agile Japan大阪サテライト実行委員会 | Doorkeeper
2015/04/19(日) Agile Japan 2015 大阪サテライト「アジャイル開発への架け橋」#agilejapanosaka #agilejapan - Togetterまとめ
【1】関西のコミュニティ紹介の中で、僕がコミュニティ活動のホームとしているXPJUG関西について、思いを発表してきた。
個人的には、コミュニティという場はすごく好き。
その理由は、今までIT業界の仕事をしてきて、精神的にも肉体的にもキツイ時が多くて、そのはけ口が欲しかったのだろうと思う。
また、IT業界のビジネスでは、PMもPLもSEもPGもデザイナーもどんな人でも、目に見えない値札(人月単価)が背中に付いているのが嫌だった。
IT業界では、技術者が商品そのもの。
いかに高く売るか、に精を出している。
でも、コミュニティでは、社会的地位や人月単価は関係ない。
お金で「貢献したい気持ち」を買えるわけではない。
コミュニティへの貢献度、その人自身の人格や技術に関する能力がそのまま評価される。
【2】最近、「アート・オブ・コミュニティ
【2-1】コミュニティとオープンソースは相性が良い。
例えば、LinuxやRubyは強力なコミュニティを持ち、コミュニティが中心になってビジネスが発展している。
おそらく最も成功している事例の一つだろう。
最近ならば、AWSのコミュニティが成功しているように思う。
玉川憲さんが何もない所から、各地にコミュニティを立ち上げて、人が集まり、技術ノウハウが公開されて、らせん状に拡大する循環が生まれた。
今では、JAWSは単なるコミュニティではなく、ビジネスの場にもなっているから、成功事例の一つだろうと思う。
AWSエバンジェリスト玉川憲氏を成長させた挫折と転機｜【Tech総研】
そんな事例を思うと、コミュニティがビジネスとどう関わればよいのか？という問題意識を持つ。
お金とは無関係で、技術者同士がお互いにノウハウを公開して切磋琢磨しあえる場も必要だし、うまくビジネスにつなげて、技術者が活躍できる場を提供する場も欲しい。
【2-2】この辺りの話は、「アート・オブ・コミュニティ
アート・オブ・コミュニティの感想～コミュニティは信用貯金という信用経済から成り立つ: プログラマの思索
「貢献したい気持ち」をメンバーから集めて、信頼貯金を蓄え、その信頼貯金を元にコミュニティ活動へ投資することで、大きな成果を成し遂げる。
そのサイクルを繰り返すことで、コミュニティが世界に対して、大きな成果と影響を与えることができる。
XP祭り関西2015の感想～IT投資とは一体何なのか？ #xpjugkansai: プログラマの思索
【3】また、エバンジェリストやコミュニティマネージャーという役割は何か、という問題意識を持つ。
「エバンジェリストが訴求するのは製品や技術ではなく市場を開拓すること」と長沢さんは喝破したが、まさにその通りだと思う。
単に製品の紹介だけではなく、ユーザを増やして新しい市場を作り出すのが本来の目的なのだ。
エバンジェリストが訴求するのは製品や技術ではなく市場を開拓すること: プログラマの思索
コミュニティマネージャーは、ビジネスと密接に関わるコミュニティを運営する推進者であるが、一方ではエバンジェリストでもある。
技術や製品を紹介する役割もあるし、エバンジェリストとして、新規のユーザを増やし、市場を拡大させる役割も持つ。
IT業界の動向を見ると、単にパッケージ製品を作って販売し、保守料で定期的に稼ぐストックビジネスも重要だが、そのパッケージ製品のユーザコミュニティを作ることも重要であるように思える。
パッケージ製品の利用ユーザがお互いの事例を共有する場をコミュニティとして提供することで、製品の価値を高めたり、新規ユーザを増やすことにもつながる。
日本では、パッケージ製品のコミュニティを作る意識はあまりないけれど、今後重要性が高まってくるだろうと思っている。
XP祭り関西2015の感想をメモ。
以下は、論理的でないラフなメモ。
間違っていたら後で直す。
【参考】
XP祭りin関西2015 - XPJUG関西wiki
XP祭りin関西2015 ～Agile S×T～ - 日本XPユーザーグループ関西 | Doorkeeper
XP祭りin関西2015 に参加しました - fkino diary(2015-04-11)
【期間限定！】アジャイル関連PDF版を特別価格で手に入れよう！ - オーム社書籍編集局
2015/4/11 XP祭り関西2015 #xpjugkansai - Togetterまとめ
【1】スタッフとして裏方でイベントを手伝っていました。
手作り感満載のイベントで、至らない所はたくさんあったと思いますが、参加率95％超えは成功だったのかな、と思います。
アジャイルな戦術・戦略というテーマだったので、昔はアジャイラーだったが中間管理職になった方を講演者にお呼びしたので、経験に基づいた内容になって面白かったと思います。
また、「実践 反復型ソフトウェア開発
【2】@yasuohosotaniさん、@tanigonさんの話を聞きながら、気になった問題意識がある。
@agilekawabataさんが言うように、ソフトウェア開発では、人が全てだ。
エンジニアの能力次第で、アウトプットの品質も使い勝手も大きく変わる。
駄目なエンジニアを100人揃えても、肝心のシステムはリリースできる保証すら無い。
だから、ソフトウェア企業は、エンジニアのスキルが常に高い状態であるように、エンジニアを大切にしないといけないし、エンジニアに投資しないといけないのではないか。
@yasuohosotaniさん、@tanigonさん、@agilekawabataさんのように、昔は僕らと同じアジャイルな一人の開発者だった人達が、管理職や経営者となって、アジャイル開発を実現するビジネスを作り出すだけでなく、ソフトウェア企業の財産と言えるエンジニアに対し、どのように投資して、ビジネスを拡大し加速させようとしているのか、という問題意識を持った。
【2-1】資本主義の原理として、貯蓄は投資して、投資の金額以上のリターンを得ることで、経済成長していくサイクルが基本にある。
資本主義経済である限り、経済成長率＞0が宿命であり、常にインフレ状態にしなければならないのではないか。
だからこそ、貯蓄をタンス預金として埋蔵させるのではなく、有望先に投資して、流通させなければならない。
製造業ならば、工場への設備投資によって、生産量や品質を劇的に増やすことができる。
新しい機会装置、新しい工場の建設によって、モノを大量生産し浪費することで、周囲の経済も活発化する。
この設備投資が行き過ぎるとバブルが起きるので、日銀や政府は公定歩合という金利によって、貯蓄から投資に回るお金の量をコントロールし、持続的に経済成長できる仕組みを作っている。
【2-3】では、IT業界における投資とは何なのか？
製造業や小売業のように、工場やお店、機械装置のようなモノに投資するのではない。
エンジニアという人がソフトウェア企業のコアコンピタンスならば、エンジニアそのものに投資しなければならない。
でも、エンジニアに投資すると言ったら、どんな方法があるのか？
せいぜい、教育研修に行かせる、OJTの案件に入れる、ぐらいしか方法がない。
他には、最新のPCやサーバーを導入するとか、座り心地のよい椅子やキーボードを買うぐらいだ。
それらの方法で、投資した直後に劇的に生産性やリターンがすぐに生まれるとは限らない。
むしろ、教育研修の効果は、数年経たないと分からない時が多いのではないか。
【2-4】製造業などがIT業界と違う点は、設備投資の投資対効果の速度が劇的に違う点だと思う。
新しい工場を作り、どんどん製品を作っていけば、短期間で大量の製品を調達・販売できる。
アップルが大量の注文を元に、iPhoneやAppleWatchを短期間に生産して販売するの典型例だ。
でも、エンジニアに投資したからといって、投資した直後からすぐに劇的にアウトプットが数倍以上も増えることは現実的にあまりないように思う。
人間は元々保守的な存在だから、簡単に考え方や習慣をすぐに変更して、生産量を増やすことはできないと思う。
エンジニアへ直接お金を投資するやり方は、多分、投資対効果は悪いのだろうと思う。
【2-5】では、IT企業の投資方法としては何が効果的なのか？
単純に考えると、M&Aで他の企業を買収したり、社外の優秀な開発者を抱え込むことだ。
つまり、外部にいる優秀なエンジニアを取り込むことで、ソフトウェア企業が生産できるシステム規模を拡大させる方法を採用するだろう。
GoogleやFacebookなどを見ていると、そんな傾向があるように思える。
でも、その手法はどのソフトウェア企業でも採用できるとは限らない。
【2-6】有効なIT投資はそれだけしかないのか？
@fkinoさんと話しながら気づいたことは、ITコミュニティへの活動やOSSへの貢献の活動もIT投資として有効ではないか？
エンジニアも人であるからには、ITコミュニティという場で、自分と違う価値観や立場の人達と交流することで、刺激を受けて、成長する意識を持ってくれればいい。
LinuxやRubyなど成功しているオープンソースのように、プログラムを自発的に公開したり、パッチを送ることで、最新の技術に触れることもできる。
また、社外の優秀なエンジニアに揉まれることで、エンジニアの能力を伸ばすこともできるだろう。
特に、オープンソースのライブラリやツールを自主的に開発したり研究することは、新しい技術の方向性を知ることもできるし、その技術が将来モノになるかどうかという判断力を磨くことにも役立つ。
最近はGitHubでオープンソースの開発を行うのが普通であり、エンジニア同士がより密接に刺激しあえる環境ができたように思う。
但し、日本企業では、売上につながらない業務活動は認められないから、ITコミュニティへの活動やOSS活動がやりにくい弱点があると思う。
個人的にこの手法が問題であると思う状況は、エンジニアがスキル向上を目指すには、業務時間外でITコミュニティに活動したり、OSSの活動をすることしかないことだ。
つまり、会社の労働時間以外で、エンジニア自身が自分自身に投資する意識を持たなければ、スキルは向上しない。
でも、折角の休日にOSS活動に専念するエンジニアはかなり少ないだろう。
日本人のホワイトカラーの生産性が諸外国に比べて低いというニュースを聞くと、何となく上記のような理由を連想してしまう。
【2-7】そんな状況でも、講演者の方の話を聞くと、彼らの立場で色々試そうとされている。
例えば、@yasuohosotaniさんが試されている「実験的アプローチ」は、一つのIT投資の手法だろうと直感する。
新しい技術を取り入れることで課題解決を試みる手法であるが、それだけが目的ではない。
実際、若手に新しい技術を試させて、実際に活動してみることで、若手エンジニアが成長する機会を作り出している。
@agilekawabataさん、@tanigonさんも、話には触れなかったやり方を持っているだろうと推測する。
@fkinoさんも別の発想を持たれていて、大変参考になった。
@g_maedaさんの「RedmineへのContributeとビジネス展開」の記事をリンクしておく。
【参考】
Redmineへのコントリビュートについて前田がRubyアソシエーションのセミナーで講演しました - ファーエンドテクノロジー株式会社
Redmineは日本で利用者が多いと聞くが、日本人コミッタの@marutosijpさん、コントリビュータの@g_maedaさんだけでなく、@naitohさんのPDFパッチなど、いろんな方がRedmineの機能改善に貢献されている。
オープンソースのツールを中心に、コミッタとユーザが有意義な議論をしながら、より良いツールへ進化できれば良いなと思う。
知人と話しながら、チケット駆動開発の理想と現実について気づいたことをメモ。
あくまでもメモであり、主張はない。
【1】Redmineを導入したならば、チケット駆動開発で運用するのが普通だと僕は思っていた。
しかし、実際の数多くの現場はそうではないですよ、と。
丁度、日本のソフトウェア開発の現場では、アジャイル開発ではなくWF型開発が主流であるのと同じように、と。
【1-1】チケット駆動開発はXPに影響を受けすぎているのでは？、と。
世間のアジャイル開発のイメージは、XPよりもScrumの方が有名だ。
Scrumのプロセスフレームワークの中で、タスクカードがチケットとして使われる場合が多いでしょう。
全ての作業をチケットにして作業をはじめる「チケット駆動」は特殊でしょう。
WF型開発の現場では、そうではない。
チケットの入力結果は、ガントチャートで確認する方が普通ですよ、と。
【1-2】チケット駆動開発のプラクティスは実際の現場では使いづらい時がある、と。
たとえば、No Ticket, No Workは確かに理想だけれども、実際は、チケット管理の対象は進捗管理だけでない。
また、Redmineというツールに頼りすぎるのも問題だ、という認識が現場にはある。
たとえば、No Ticket, No Commitもプログラマにとって評判は良くない時がある。
コミットログに逐一チケットNoを書くのが億劫だ。
また、ちょっとしたリファクタリングのコミットにもチケットNoを紐付けるべきなのか。
頻繁にコミットする場合、チケット一覧のコミット履歴が多すぎて、結局あまり使えない、と。
特に、GitHubのようなプルリクが使えないのもいまいちだね、と。
【2】僕が思っているチケット駆動開発は、理想にすぎないのかな。
「ソフトウェア開発の基本原理は、XPの小規模リリースと同じ」「頻繁にバージョンアップしながら、品質も機能も向上させていくのがソフトウェア開発の王道」と僕は思っているけど、違うのかな。
日本のソフトウェア開発は、製造業の成功体験を引きずりすぎていて、一度決めたら進路変更できない計画主導の開発プロセスにこだわり過ぎている、と思っているのは違うのかな。
僕の考えでは、チケット駆動開発は、アジャイル開発を実装する一プロセスであり、最も自然にアジャイル開発を実践できるプロセスの一つと思っているけど、そうではないのかな。
【3】チケット駆動開発は、フロー型プロセスでもあり、ストック型プロセスでもある二面性が利点を増幅させていると思っている。
チケットはカンバンでもあり、作業指示書や障害管理票のような記録できる帳票の二面性を持つ。
その部分の相互作用がすごく面白い。
Redmineによるチケット駆動開発はストック型プロセスとフロー型プロセスの二面性を持つ: プログラマの思索
【3-1】「Issue」を「チケット」と訳したRedmineは偉いと思う。
チケットはメタな概念。
「Issue」を「問題」「課題」に訳してしまったら、タスク管理に使う発想は無かっただろう。
Redmineを障害管理やタスク管理だけでなく、ヘルプデスク管理、インシデント管理、台帳管理、議事録の管理、農作業の予実管理などに使おうという発想すら出現しなかっただろう。
【3-2】ソースそのものに修正履歴を残すのではなく、コミットログやチケットに記録することで、ソースは常に最新で綺麗な形に残せる。
そして、コミットログやチケットというメタな概念に修正履歴や変更理由が残るので、メタな開発プロセスをチケット上に実現できる。
さらには、蓄積されたコミットログやチケットを集計したり検索することで、エンピリカルなソフトウェア工学の知見を適用して、メトリクスの採集による傾向分析ができる。
さらには統計学やビッグデータを適用して、仮説に基づくプロセス検証ではなく、データ主導によるプロセス検証もできるかもしれない。
【3-3】チケット駆動開発のもう一つの側面として、パッチ駆動開発の顔もある。
パッチをチケットに添付して、コードレビューのやり取りをする。
Redmineによるチケット駆動開発はパッチ駆動開発と同じ: プログラマの思索
パッチ駆動が重要である理由は、「ソフトウェア開発は頻繁なバージョンアップで品質も機能も改善していく」手法が基本原理ならば、変更管理や構成管理が非常に重要になるからだ。
でも、この開発プロセスは、GitHubのプルリクエストが普及した現在、正直古くなっている部分もある。
RedmineとGitを巡る疑問点～Gitとの連携機能の強化がRedmineの課題: プログラマの思索
RedmineとGitLabを連携すると、RedmineをGitHub化できるか: プログラマの思索
チケット駆動開発にGitの良さも組み込んで、もっとアジャイルな開発基盤にしてしまいたい妄想を今後も考えてみる。
教育学は人工知能の研究者によるデータ主導で置き換えられつつある記事が面白かったのでメモ。
【参考】
1000年変わらなかった教育業界が、今熱い！ | GLOBIS 知見録
MITの苦渋の決断がMOOCへの流れを作った | GLOBIS 知見録
MOOC前夜： カーンアカデミーの衝撃 | GLOBIS 知見録
異才セバスチャン・スランのMoonshots | GLOBIS 知見録
知的誠実さの大切さ～Moodleが持つ教育のイノベーションの可能性: プログラマの思索
教育学は、人間はどのように成長していくか、という根本問題を抱えている。
今までは、仮説に基いて思索するぐらいしかなかった。
でも、今では、MOOCに集められた大量のデータを元に、人はどのようにして知能を身につけるのか、を研究することができる。
MOOCを編み出した人達が皆、人工知能(AI)の研究者である背景を持つのも面白い。
自動運転、人工知能、機会学習、ビッグデータ、みたいなバズワードを連想させる。
教育学や心理学のような人文科学は、人工知能と統計学による研究結果でどんどん置き換えられていくのではないか。
古くて既に理論が確立されていると思われている学問に対して、新しい技術を用いて、新たな知見を見出して挑戦するのはすごく面白そうに思う。
多分、このような事象を破壊的イノベーションと呼ぶのだろう。
Redmineの運用の現場を見ていると、チケットをストックとして見る場合とフローとして見る場合で観点が異なるように思えた。
ラフなメモ書き。
【1】Redmineを運用し始めた時に、チケットよりもRedmineプロジェクトの分割に重きを置いたり、チケットをWBSと一体視して、1チケット＝1担当者で運用する現場を見かける時がある。
たいてい、上手く回っていない。
本来のチケット駆動開発では、チケットを経由して一つの作業を複数人が分担してやり取りする。
その流れがチケットで表現されるから、今誰がボールを握っているのか分かるのに、チケットをWBSで固定化してしまうと、手戻り作業が発生するたびに、現状を把握しにくくなる。
このアンチパターンを「WBS駆動」「担当者固定」と僕は呼んでいる。
【2】@akahane92さんも言っていたが、Redmineでは、チケットのコメントが長くなるような運用の方がやりやすい。
チケットのコメントに、障害の原因や解決方法を書いたり、ソース修正した後のテスト結果やフィードバックを書いたりする。
あるいは、仕様の質問に対し、回答や疑問点をやり取りする。
つまり、チケットのコメントが作業履歴になる。
さらに、チケットの担当者がステータスごとに複数人でやり取りされるようにすれば、チケットのコメントとステータスが紐付けられるので、読みやすくなる。
チケットをWBS駆動で運用して上手く回らなくなる原因は、チケットの担当者が固定されてしまうために、ペア作業のように複数人でチケットをチェックできなくなるから。
また、チケットに作業履歴が集約されず、複数のチケット(WBS)に作業記録が散らばってしまう。
【3】そんな症状の本質を考えてみると、チケットはストックなのか、フローなのか、という問題にぶち当たると思う。
【3-1】一つのチケットを複数人でやり取りしながら、ペアプロないしペア作業のように運用するなら、チケットはフローだ。
ステータスがどんどん変わる方がいい。
つまり、サイクルタイムは短い方がRedmineの運用は上手く回る。
すなわち、チケットはフロー。
【3-2】チケットをフローとしてとらえる場合、カンバンやGTDみたいな運用に近くなるように思う。
カンバンみたいにチケットを扱うならば、リードタイムやサイクルタイムが短くなるように運用する方針になる。
つまり、チケットを停滞させてストックするよりも、流通させる方が良い点がマッチする。
また、GTDでも、一旦Inboxに必要なタスクをチケットに書いて、それらを週1回のように定期的に精査して、チケットを棚卸する。
GTDでも、チケットがどんどん生まれては消える運用の方がやりやすい。
チケットをストックして停滞させる運用はあまり向いていないのだ。
【3-2】一方、一つのチケットを障害管理票のように扱い、障害の発見から修正、再テスト、リリースまでの作業を記録するなら、チケットはストックだ。
もちろん、チケットを作業指示書、課題管理票、顧客からのインシデント管理票として扱う時も、チケットに一つの作業やインシデントのやり取りを集約させるので、同じ。
つまり、チケットはストック。
チケットのコメントは、メーリングリストのメールのスレッドみたいに扱う方がいい。
【3-3】チケットをストックとしてとらえる場合、一昔前の掲示板みたいな運用に近くなるように思う。
チケットは一つのテーマに限定し、一つのスレッドの中で、皆が議論してやり取りして記録を残す。
そのスレッド(テーマ)の内容は、後から全文検索できるし、たくさんのスレッドのログがあるほど、その掲示板は価値が増す。
過去にこんなスレッドがあったから、見ておいたらいい、というアドバイスもできる。
特にソフトウェア保守では、過去の障害修正や仕様変更の経緯が記録されているとすごくありがたい。
このIF文を修正して良いのか、何故こんな汚いパッチが当てられたのか、という変更理由が数年後でも把握できるからだ。
また、チケットはストックの性質を持つから、記録されたチケットの属性を元に、メトリクスを採取できるのも良い。
特に、障害分析や生産性の分析では、メトリクス集計が威力を発揮する。
Velocity(スループット)、サイクルタイムを定期的に採取できれば、開発チームの生産性の傾向をモニタリングすることもできる。
【4】「チケットはフローでもありストックでもある性質を持つ」という二重性が、チケット駆動開発に大きな利点を与えているように思える。
フローの側面はアジャイル開発の利点につながる。
頻繁にリリースしていくために、チケットをどんどん流通させて完了させていくスタイルに都合がいい。
ストックの側面は、アジャイル開発をベースにしたチケット駆動開発に、従来のソフトウェア工学の観点を注入して強化する点につながる。
プロセス分析やメトリクスの性質については、既にたくさんの知見があるので、それらをアジャイル開発へ適用することで、より安定して開発できるようになるはずだ。
「ファーエンドテクノロジーのメール対応の仕組みの変遷」の記事が参考になるのでメモ。
【元ネタ】
ファーエンドテクノロジーのメール対応の仕組みの変遷 - ファーエンドテクノロジー株式会社
【1】ヘルプデスク管理は、顧客対応に直結するので上手く業務で回したいもの。
@g_maedaさんの記事では、代表メールアドレスとRedmineの連携→Redmineチケットでの受付へ変遷しているのが興味深い。
【2】以前は、顧客からの問合せメールをチケットに自動登録される運用をされていた。
Redmineにある「メールからのチケット自動登録」機能をうまく活用されていて、なるほど～と感心したし、色々考えていた。
僕も実際に運用してみて、結構使えると手応えはあった。
メールからRedmineのチケットを自動登録する時の注意点: プログラマの思索
RedmineはCRMソフトとして使えるか？: プログラマの思索
「メールからのチケット自動登録」機能は、ヘルプデスク管理だけでなく、インシデント管理のように、Zabbixのようなサーバー監視ツールが障害を検知したらメールを自動送信する時に、Redmineチケットも一緒に発行してしまう運用にも適用できる。
【2-1】しかし、下記の問題があるらしい。
(引用開始)
ただ、この仕組みも運用しているうちに問題点がわかってきました。
最も大きな問題点はメールのサブジェクトに依存した運用であることです。お客様がメールを送る際に、新たな用件のメールを以前やりとりしたメールの返信としてメールを作成されたために古いチケットに追記されたり、担当者が返信を行う際に誤ったチケット番号を記述して無関係のチケットに注記が追加されたりなどの問題が毎日のように発生していました。
メール返信時にチケット番号を入れ忘れないように注意したり、メールとRedmineの二つを見ながらサポートを行うというのも少し面倒でした。
(引用終了)
確かに、メールという機能の制約のために、チケットの内容の品質は正直良くない。
例えば、「いつもお世話になります」というタイトルのチケットが作られたりする。
RxTStudy勉強会で@g_maedaさんが話されていたように、90年代の頃はメールは短く的確に、と言われていたのに、今は手紙みたいに形式的な挨拶や駄文が多い。
また、顧客によっては、既に完了したメールのスレッドに、新しい問合せを混入させたりする。
すると、完了チケットに問合せメールの内容が埋もれてしまう。
つまり、メールというツールはもはや時代遅れなのだろう。
また、そんな古いツールでしかないメールにRedmineを従属させる運用は、本来のチケット駆動の運用ではないのだ。
【3】そこで、「Redmineチケットでの受付」では、Redmineのロールによる制御を上手く使うことで解決を試みている。
顧客がチケットに直接入力してやり取りする運用に変える。
顧客はプロジェクトのメンバーに所属させず、非メンバーに所属させる。
さらに、非メンバーのロール「チケットの参照」には、「作成者または担当者だけ」の設定を入れることで、他の顧客のチケットを参照できないようにしている。
つまり、Redmineの権限制御を入れたチケット管理で運用することで、チケットをやり取りする方が楽なわけだ。
この点はすごく参考になる。
【4】この記事を読んでさらに思うことは、Redmineのセキュリティ管理や権限管理はどんな場面でどのように設定すべきか、という問題だ。
ヘルプデスク管理では、「他の顧客の情報が漏洩されてはいけない」という大きな制約事項がある。
受託開発案件やオフショア開発でも、別プロジェクトのチケットは更新させないし閲覧させない制約事項が必要な場合もある。
そんな場合は、Redmineをどのように設定すればいいのか？
Redmineの権限管理の機能は、昔は正直貧弱だったが、バージョンアップされるにつれてすごく高機能になっている。
むしろ、複雑になりすぎているように思える時もある。
その辺りも一度整理してみたい。
「オープンソースソフトウエアがゾンビ化する事情」の記事が参考になったのでメモ。
以下、主張のないラフなメモ書き。
【元ネタ】
ゾンビOSSが危ない - ［2］オープンソースソフトウエアがゾンビ化する事情：ITpro
ゾンビOSSが危ない - ［1］オープンソースソフトウエアにも寿命がある：ITpro
ゾンビOSSが危ない - ［3］オープンソースソフトウエアの「ゾンビ化」を避ける心得：ITpro
(引用開始)
1)リスク高：新機能追求型
既存の商用ソフトにはない新機能の実現を目指して開発された「新機能追求型」のOSSは、ゾンビ化するリスクが最も高い。
ゾンビ化するパターンは大きく三つある。（1）新機能が他のソフトでも実現可能になることで、そのOSSの存在意義が無くなるパターン、（2）新機能を実現するOSSが乱立した結果、競争に敗北するパターン、（3）新機能を追求するあまり旧バージョンのサポートがおろそかになるパターンである。
(引用終了)
(引用開始)
2)リスク並：サポートビジネス型
サポートビジネス型OSSとは、ディストリビューションや有償サポートを販売するベンダーが開発を支えているOSSのことだ。OSS事情に詳しいNRIの高橋雅人OSS推進グループマネージャーは、このようなOSSを「商用OSS」と表現する。
(引用終了)
(引用開始)
3)リスク並：マーケティング型
マーケティング型のOSSとは、ベンチャー企業が販売・サポート収入を目的に開発したソフトを、世間にアピールするためにオープンソース化したものである。販売・サポート収入を前提にしているので、ゾンビ化リスクはサポートビジネス型と同程度である。
(引用終了)
(引用開始)
4)リスク低：呉越同舟型
呉越同舟型OSSとは、ライバル関係にある企業が「呉越同舟」で協調して開発するソフトを指す。SDN（ソフトウエア・デファインド・ネットワーク）ツール「OpenDaylight」やIaaS構築ソフトOpenStack、Dockerコンテナの運用管理ツール「Kubernetes」など、先端的なOSSの開発が大手ベンダーによる呉越同舟で進むケースが増えている（図5）。
(引用終了)
(引用開始)
5)リスク高：特殊事情型
きわめて特殊な事情でOSSが生まれることもある。その一例は、米InfiniDBが開発したデータウエアハウス（DWH）ソフト「InfiniDB」だ。
(引用終了)
【1】現代のソフトウェア開発では、オープンソースを上手く使ってスクラッチ開発する場合は多い。
特に、フレームワークなどの開発基盤、DBやWebサーバなどのミドルウェア、サーバーやインフラの監視ツールなどが思いつく。
個人的には、オープンソースをベースとした開発は好きだ。
2000年代前半までは、ベンダー主導のフレームワークやパッケージ製品で開発する方法が多かったが、開発者としては苦痛で仕方なかった。
俺様フレームワークに付き合わされるのは嫌だったし、すぐに技術が陳腐化するのに、パッチやバージョンアップの対応が遅かったから。
また、オープンソースに慣れている方が、そのスキルは他の職場でも通用するし、GitHubのように最新の開発プロセスも身につく。
しかし、オープンソースにも落とし穴はある。
コミッタとコミュニティが活発に活動しなければ、環境に応じてバージョンアップして、時代に追随できないリスクがある。
オープンソースのツールのコミッタは、普通は無償で趣味でやっているだろうから、その仕事量が増えてくると、多分持ちこたえられなくなる。
【2】上記の記事で興味深いのは「新機能追求型」と「サポートビジネス型」だ。
【2-1】「新機能追求型」のオープンソースで破綻するケースは確かにある。
一番怖いのは、後方互換性を考慮しないバージョンアップを行うオープンソースだろうと思う。
安易にバージョンアップしてしまうと、OSやブラウザごとに乱立してしまい、逆に保守コストが上がってしまう。
特に、新機能の追加を優先した場合に起きやすいと思う。
【2-2】オープンソースが開発者にとっても経営者にとっても、安定したビジネスモデルになるのは、「サポートビジネス型」だろう。
ソースを公開するのは著作権放棄と思われるかもしれない。
でも、逆に、開発者やユーザからたくさんのフィードバックをもらえることで、機能や品質の改善につながる。
また、ソースの公開によって、知名度が上がる利点もあるだろう。
その方向性を突き進めると「マーケティング型」になるだろう。
「サポートビジネス型」で重要な点は、オープンソースのツールを中心としたエコシステムを作り出すことだろう。
開発チーム、熱心な利用ユーザ、バグ修正のパッチを送ってくれる熱心な開発者の三者が一つのコミュニティを形成できれば、製品の方向性を事前に示すこともでき、それによってユーザも安心感を持てる。
定期的なバージョンアップをロードマップとして事前に告知できれば、セキュリティパッチやメジャーバージョンアップを区別してリリースすることもできる。
オープンソースを長続きさせるには、開発よりも保守が重要。
保守し続けたい、と思わせるパワーが必要。
そのためには、開発チーム・利用ユーザと開発者のコミュニティとエコシステムが必要だろうと思う。
この辺りのオープンソースのビジネスモデルも整理して、その特徴や方向性、焦点を明確にしてみたい。
最近のコメント