無料ブログはココログ

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

怒るな教えろ

「たしなめる」という言葉があります。感情に任せて怒っても、人は変わりません。でも、自分の対応は変えることができます。

「なにしてんねん!」そう思った時の対応を変えれば、結果も変わります。すでに何度も注意していたのかもしれません。でも、怒ってもなおりません。人は変わらないからです。

わかっていないことは教えることができます。知らないことを理解すれば、もっとうまくできるかもしれません。

怒ることで反省するそぶりを引き出しても、理解していなければ改善することはありません。その場をやり過ごしているからです。

うまく教えられない自分に怒っても、説明していないことが伝わることはありません。怒ってしまうと、成長の可能性をつぶしてしまいます。

怒るのではなく、教えることが大切です。

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

[#TiDD] バージョン管理ツールのコミット時にチケットと関連付ける3つの理由

チケットと関連づけなくてもコミットメッセージで十分と言われる方もおられますが、コミットメッセージとチケットを関連付けるメリットは以下の3つです。

情報の関連付け

コミットメッセージは同時にコミットしないと、更新情報を関連付けることができません。チケットと関連付けておけば、複数の更新をまとめることができます。

間連付けは、コミットメッセージからチケットだけでなく、逆方向も関連づけられます。チケットにwikiや関連チケットのへリンクしておけば、他の様々な情報とも間連付けることができます。

トレーサビリティ

アジャイル開発ではストーリーカードからタスクカードを作成することで、ストーリーとタスクのトレーサビリティが保たれます。XPではタスクカードにストーリー番号を書くことで、タスクからストーリーを追うことができました。

チケット駆動開発では、ストーリーとタスクのチケットを親子関係にすることで、双方向に間連付けて、トレーサビリティを確保できます。

検索を容易にする

探したい修正がどのモジュールにあるか、何時頃の修正であるかがわかってるなら、コミットメッセージを元に修正内容が確認できるかもしれません。しかし、それが1カ所でなく、テスト中など異なる時期に修正が行われていたなら、関連する修正を見つけられないかもしれません。

チケットにはタイトルや説明だけでなく、様々な属性が記載され、他の情報と関連づけられています。様々な検索条件でチケットを探し、関連する修正を見つけることができますので、仕様変更やトラブル対応の際に参考にできます。

トレードオフを考える

このように、バージョン管理ツールのコミットとチケットを間連付けると、多くのメリットがあります。しかし、少しとはいえ負担がかかりますので、メリットが感じられないなら安直に導入すべきではありません。

どのようなプロセスも、(最適ではないかもしれませんが)現場の工夫によってその組織や開発対象に最適化されているからです。

プロセスを実行するのは人です。プロジェクトの中で議論して、より良いプロセスを実現してください。


[#TiDD] アダプタブルな開発を実現するチケット駆動の3要素

批判の多いウォーターフォール開発ですが、チケット駆動開発をうまく導入するとより柔軟で安定したプロセスを実現できます。従来法では難しいアダプタブル(柔軟)な開発が可能になります。

1.従来型開発開発の課題

従来型開発は以下のような理由で変化にへの対応力が弱くなっていました。

ウォーターフォール型

リリースが1度しかなく、仕様変更があると手戻り作業が発生します。全体の計画を見直すことになるので、混乱が生じ易くなります。残業や増員でカバーできない場合は、リリースを延期することになります。

単純作業をうまく切り出せない場合は増員は逆効果になります。かえって混乱を増すだけで、費用の増加やリリースの遅延を招きます。

文書による情報共有

文書による情報共有は組織的な管理には便利なものです。しかし、仕様変更などをきっかけにした遅延が発生した際に行われる管理強化によって負担が増加して、生産性の低下を招いてしまうことがあります。

このように負担が増えても管理強化をせざるを得ないのは、文書による情報共有の場合、開発作業と独立した作業なので強制や支援が容易、伝搬が遅いので後手後手の対応になっていたものを取り返さないといけないこと、文書化の際に知らず知らず、あるいは、意図的に情報の改ざんが行われるのでより詳しく聞かないといけない、からです。

トップダウン文化

コンウェイの法則(リンク先はWikipedia)に従って、トップダウンに開発を進めると、組織もトップダウンになり、メンバーはコマンドコントロールによってのみ作業し、受け身になってしまいます。

受け身になると自発的に情報発信しなくなり、課題を見つけても情報共有せず、解決法の提案もしなくなります。また、プロジェクトが危うくなるに従って守りに入るようになり、担当が不明確な作業が宙に浮く様になります。あらかじめ全てを決めないと回らないので、変化に短期間で対応できなくなります。

2.チケット駆動によるアダプタブルな開発

チケット駆動開発を導入する際に、上にあげた問題を意識して改善するなら、プロジェクトは変化に対応可能になり、アダプタブルな開発が実現できます。

プロセス

あらかじめ仕様変更作業を計画に含める、五月雨ウォータフォール型開発をするなど、リリースを複数にします。いずれも請負開発で可能ですが、発注側・請負側の合意が必要になります。

チケット駆動開発で用いるITSでは、複数リリースが支援されています。要件や作業記載したチケットをリリース(マイルストーン/バージョン)ごとに管理することができます。

見える化

チケット化によって、ゴールとそれにいたる作業や課題を明確にします。ステークフォルダー全員でチケットを共有することで、問題が見える化されます。

開発の起点がチケットになりますので、情報作成の負担が少なく、リアルタイムの情報で、齟齬やごまかしの少ない生データを共有できます。

自律的

プロジェクトのメンバーが守りに入る理由の一つは、プロジェクトの全体の状況がわからないからです。プロジェクトを失敗させたいと思っていなくも、全貌がわからないのでは手の出しようがありません。どうしようもないので、ついつい「危なそうだから休めるうちに休もう」と考えてしまいます。

このような状況を改善するには、課題・障害・作業と言った状況を共有し、協力を促すことで大幅に改善されます。自分の作業が終わったからと帰っていたメンバーが、協力し、チケットを介してシャイなメンバーが活躍しだします。

3.ソフトウェアプロセスとしての視点

ソフトウェアプロセスもソフトウェアであると考えると、これらはプロセスプログラミングの問題だとわかります。

アーキテクチャの視点

プロジェクト全体を大きなシステムにすることが実現を困難にしていました。段階的なトランザクションや優先度の視点を持ち、期限付きのジョブキューを詰まらせない様に考えるとうまくいきます。

実装の視点

変化に対応し易いようにオブジェクト指向の考え方を取り入れます。前の記事で仕様変更の影響が複数の工程にまたがるのは構造化設計になっているからです。

データ構造の視点

データ(情報)量が一定以上になると、ファイル共有では不整合を起こさない様にするだけでも大変です。集中型データベースを導入し、トリガー(メールなどの通知)を使って効率的な処理を実現します。集中が難しければ(サブプロジェクトなどで)分散・連携します。

4.まとめ

このように、現状に問題意識を持ってチケット駆動開発を導入すれば、プロジェクトの問題を解決できます。ここではプロジェクトをアダプタブルな開発を実現する3要素について説明しました。

大切なのは問題を見極めることです。ここに挙げた要素はアジャイル開発をヒントにしたものですが、複数リリースをうまく制御するには単純なタスクカードでは難しいでしょう(リーンかんばんなら可能かもしれません)。

アダプタブルというのはアジャイル開発のなめの候補であったアダプティブを参考にしました。問題を見極めて工夫を継続することで、よりよい開発が実現できるでしょう。

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


[#TiDD] 工程名のチケットがアンチパターンである3つの理由

開発作業をチケットで管理するチケット駆動開発には完全型と補完型があります。このうち、工程名のチケットは完全型に比較的多く見られます。

チケット駆動開発は従来型の開発でも利用可能で、従来の進捗管理からあふれた作業を管理する補完型が多く行われています(2つのアダプタブル・ウォーターフォール開発)。障害はもちろんのこと、仕様変更や課題を見える化できますので、経緯の確認に有益な履歴が残り、コミュニケーションが改善され、管理も容易になります。

チケット駆動開発はとても便利ですので、完全型に移行すればもっと効果が出るだろうと、既存の管理を置き換えようと考えられる方も多いでしょう。しかし、安易に置き換えるとメリットが感じられなくなってしまいます。

それはWBSのように、工程-成果物-作業の階層でチケットを作ってしまう場合です。このような階層をチケットに対応させると、変更に弱くなります。

クローズされないチケットは見える化を阻害する

チケット駆動開発はチケットのステータスを管理します。クローズされていないチケットを管理して作業の漏れや遅延を防ぐことができます。

工程名のチケットは進捗の集約には役立ちますが、工程の作業が終わるまでクローズされません。このようなチケットは、他の作業の遅れや遅延を見えにくくしていまいます。

仕様変更で混乱する

仕様変更の作業はそれまでの工程の作業を含みます。作業チケットやコミット時に色々な工程を関連づけると論理的であっても煩雑ですし、クローズしたチケットが更新されるのも管理を混乱させます。

仮に仕様変更を工程に含まれない作業としてしまうと、現在の工程の進捗が見えなくなってしまいます。そこで仕様変更は現在の工程の作業チケットとすることになりますが、これでは現在の工程のチケットは仕様変更がつづく限り、いつまでも閉じることができなくなります。

ゴールが曖昧になる

仕様変更が発生した場合、当初のリリース予定を延ばして良いとは限りません。すると一つの工程に対してリリースが複数になってしまいます。

こうなると、工程チケットとリリースが対応しなくなり、チケット駆動開発のメリットである管理も難しくなります。チケットがゴールを表さなくなるからです。

解決法

このような理由で、工程名のチケットはアンチパターンと言えます。WBSを用いて工数見積もりをする際に工程は便利なものですが、仕様変更の多い現場では工程のチケットは足かせになります。

そこで元々工程と考えていたものは、段階的な期間と考えます。この期間はゴールとなるマイルストーンまでの期間(ITSのマイルストーン/バージョン)と考えます。

チケットを階層化する際は、要件(ストーリー)に対応するチケットを作り、その子チケットとしてタスクのチケットを起票します。

これらの解決法は、アジャイル開発におけるチケット駆動開発と同じ方法です。もし、すべてのタスクをチケット化しなくても良いなら、進捗管理は従来のままに、想定外の作業をチケット化する補完型のチケット駆動開発を検討しても良いでしょう。

追記:工程をプロジェクトやバージョン(マイルストーン)に割り当てるのもアンチパターンと言われています。
プログラマの思索「WF型開発にとらわれすぎたTiDDのアンチパターン #tidd


PythonでTSVファイルをJOINする

複数のTSVファイルをJOINする時に、UNIX/LINUXコマンドのJOINを何回もすれば実現できます。でも、それなりに面倒臭いですし、出力をハンドリングするにはawkか何かを組み合わせないと行けません。そこで、お勉強がてらPythonで作ってみました(Python 2.7.1 on Mac)。

仕様:
第1カラムをキーとして引数で指定されたTSVファイルをJOINする。結果はキーでソートしてTSVを標準出力する。

応用:
デリミタを削除してcsv対応するなり、出力をSQL分にするなり、ご自由にお使いください。

感想:
Pythonは、インストールしなくても使える環境が多いので便利ですね。ちょこちょこRubyとの違いを感じますが、できることはあまり変わりませんね。比較のページもあるなど、いろいろな言語が使われる様になっていると思いました。
(参考:配列操作の比較表: Ruby, Python, JavaScript, Perl, C++



#!/usr/bin/python
import sys
import csv

files = sys.argv
files.pop(0)

out_data = {}

for in_file in files:
    tsv = csv.reader(file(in_file, 'r'), delimiter = '\t')
    for line in tsv:
        key = line[0]
        line.pop(0)
        if key not in out_data:
            out_data[key] = [key]
        out_data[key].extend(line)
for key in sorted(out_data.keys()):
    print '\t'.join(out_data[key])


[#TiDD] 標準化のトレードオフ その8 - チケット駆動開発はソリューションライブラリ -

チケット駆動開発もリーンソフトウェア開発と同じ様に考えるプロセスです。チケット駆動開発を実践するには以下の実施方法を考えないといけません。

見える化

チケット駆動開発の見える化は、チケットの可視化で行われます。カスタムレポート/クエリと呼ばれるチケットの一覧です。タスクのチケット一覧の方法によって、問題を見える化できます。

見える化の必要な問題が、開発が安定しないことであれば緊急度順の一覧にすれば良いですし、仕様漏れであればトレーサビリティマトリクスのように親子関係を確認すれば良いでしょう。進捗が問題ならガントチャートが良いでしょう。

プロジェクトの情報

見える化の元になる情報を決めます。チケット、Wiki、関連ツール、ドキュメントをどのように利用するかを決めます。

バージョン管理ツールのリポジトリの構成やチケットとの関連付け、Jenkinsなどツール連携情報など、情報間の関連付けも考えます。

制約

情報にどのように制約を与えるかを考えます。作業や情報の抜け・漏れを無くすことができます。

段階を踏むべき作業が漏れるのであればワークフローを利用すると良いでしょう。構成管理とチケットが関連づけられていないのであれば、バージョン管理ツールにチケット連携の制約を付ければ良いでしょう。

チケット駆動開発はソリューションライブラリ

プロジェクトの直接的な問題には、状況が把握できない、 情報共有できない、 煩雑で能力が発揮できない、開発環境が不十分、などがあります。しかし、実際は上記のようにプロジェクトの情報をどのように扱うかが決められていないことが根本原因かもしれません。

これらを決める際には、現場主導で標準化のトレードオフを避けることも、管理を強化してプロセスを安定させることも可能です。現在のプロジェクトにどのような問題があり、どのように解決すべきか、それを考えることからチケット駆動開発が始まります。

チケット駆動開発は様々な問題に対する解決策の集まり、ソリューションライブラリです。プロジェクトの原則を整理し、プラクティスを作り、フレームワークを作ることができます。

ソリューションを知る方法

とはいっても、他の会社でどのように利用され、自分たちは何ができていないかを知らなければ、問題に気付くことも難しいかもしれません。書籍のほか、品川RedmineRxTstudy(Redmineとタスクマネジメントを考える勉強会@大阪、facebook)といった勉強会に参加すれば、そのヒントが得られるかもしれません。

次回の品川Redmineは2月15日(土)です。「Redmine超入門」の出版を記念して、入門的な内容を中心に開催される様です。初めての品川区開催です。

次回RxTstudyは4月5日(土)で準備中です。「チケット&計測でITプロジェクト運営の体質改善」の神谷芳樹さんをお招きする予定です。もう一人のゲストもご期待ください。

#他の視点は、書籍「チケット駆動開発」12章にまとめています。

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


標準化のトレードオフ その7 - リーンソフトウェア開発の考える仕組み -

スクラムはプロセスをフレームワークとして固定化し、プロダクトの開発に集中する仕組みですが、リーンソフトウェア開発のカンバンはプロセスを開発にさわせて最適化する仕組みです。

XPのタスクボードはプロジェクトの状況を見える化するものですが、リーンかんばんはWIP制約(作業の並列度を制限する仕組み)など、プロセスの構造も見える化します。

見える化とは「問題点が常に「見える」ようにしておく工夫のこと」(リンク先は日経BP)ですから、開発者も常にプロセスのことを考える様になります。

その様子は、リーン開発の現場(感想:その1その2その3その4)や翻訳者のお一人である藤原さんの経験談で知ることができます。

リーンソフトウェア開発の考える仕組みはかんばんだけではありません。スクラムがフレームワークであるのに対し、リーンソフトウェア開発では原則とツールがあり、それに従ってプロセスを構成します。

組織的に導入する場合には一定の規律が生まれると思いますが、リーンソフトウェア開発の場合には「どのツールからどのようなプラクティスを導き出し、どの程度実践するかは状況に応じて行われるべきだ」(ITmedia)とされています。

標準化のトレードオフを考えたとき、このように問題を見つけ出し、プロセスを考えることが大切だと思います。

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


標準化のトレードオフ その6 - スクラムの形式知が大切な理由 -

標準化のトレードオフで最も気になるのは、スクラムが規律であることです。

実装優先の視点で考えるとアジャイル開発は、実装優先時に考慮すべき点をパッケージングした開発法です。アジャイル開発には実装優先に、自律的組織、繰り返しのリズム、メトリクスやふりかえりによる改善といった特長が加えられています。

そのようなアジャイル開発の代表格であるスクラムを標準化のトレードオフで考える前に、歴史を振り返ってみましょう。

アジャイルと規律

ベーム先生が「アジャイルと規 律 ~ソフトウエア開発を成功させる2つの鍵のバランス~ 」という本を出されたように、アジャイル開発1次ブームを牽引したXP(extreme programming)は、標準プロセスの規律のアンチテーゼとしてとらえられました。

ベーム先生は「アジャイルと規律」で、TSP/PSPを規律の例、XPをアジャイルの例として挙げています。共に会議を開きますが、TSP/PSPでは規律に従って再計とドキュメントの変更とレビューを休日出勤を含めて行い、XPではスコープの変更とテストコードを使ったリファクタリング(変更)の様子を示しつつ、そこでCRACKと呼ぶ顧客の代表に求められる特性を示しています。

CRACKは、協力的(Collaborative)、意見を代表する(Representative)、権限を持つ(Authorized)、献身的(Committed)、知識がある(Knowledgeble)の略です。XPは価値(価値観)とプラクティスを定めて開発者たちの自律的なチームづくりを推進しますが、開発チームと顧客との関係の規律は定められていなかったのです。

スクラムの特徴

スクラムは組織パターンを考慮したアジャイル開発のフレームワークです。開発チームだけではなく、プロダクトバックログを管理するプロダクトオーナーというロールなどが定められています。

プロセスをどのように構成するか、必要最低限の標準化によって一から考えなくて良いようにフレームワークが形式知として構成されています。スクラムが特徴的なのは、認定スクラムマスターを初めとする多くの資格が研修で与えられることです。

フレームワークという標準の形式知を与えながら、研修による暗黙知で正しい方向に導くというバランスの取れた仕組みができています。

標準化の危険性

しかし、これも標準化であるので、思考停止に陥り易い問題を見極めなくなる応用できない過去の経験に引きずられる、といった問題の可能性があります。

このような危険性があるのは、規律が形式知である一方で、アジャイル開発の良さは文章では伝えにくく、主に経験を通じた暗黙知で伝達されるからです。特にトップダウンアプローチで導入される場合は形骸化しやすい危険性があります。

一般に、コミュニケーションや自律的な組織、サーバントリーダーシップといった経験を通じた方が得易い暗黙知は、管理が容易な規律という形式知に比べて、以下のような特性があります。

スクラムの形式知

このような規律の特性に引っ張られないためには、スクラム開発で大切なことをきちんと学ぶしかありません。勉強会などを利用して、スクラムを味方につけることが大切です。

しかし、上述の様にそのスピードは規律に比べて遅く、組織的な導入には追いつきません。そこで、アジャイル開発とスクラムでその基本を学び(壁を打ち破れ! - アジャイル開発とスクラムを読んで -)、SCRUM BOOT CAMP THE BOOKを読んで実践方法を学んでおく必要があると思います(日本文化に仕立て直した実践書使えるアジャイル開発の本学び 工夫が凝らされた構成日本でスクラムを実践するなら読んでおきたい本)。このような経験を形式知化した情報が、組織的な導入には必要です。

アジャイル開発でも、アジャイル開発だからこそ、形式知として公開し、学ぶことはとても大切だと思います。

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


スルーと情報発信で良い情報を集める - 情報量とは驚きの量 -

「情報量とは驚きの量です。砂漠で晴れの予報に驚きはないですが、雨が降る予報には驚きがあります。それが情報量です。」このように教わった情報量(リンク先はwikipedia)を元にインターネットの情報を考えると、retweetやshareによって情報量が最大化される傾向があると思います。

この驚きは、データ圧縮ツールを考えるとわかりやすいでしょう。単調なデータは圧縮して小さくできますが、複雑なデータはあまり圧縮できません。しかし、一見複雑なデータであっても、そこに規則的なパターンがあれば圧縮できます。

人は社会的動物ですので、情報交換が必要です。情報量が多いとそれに賛同するか否かに関わらず、ついつい人に伝えたくなります。インターネットによって情報交換能力が飛躍的に向上すると、普通の情報は伝達されにくくなり、以下のような情報が増えるようになりました。

良質な情報

良質な情報の代表は物事を端的に表した情報です。普通に伝えるとなかなか伝わらない事を圧縮して伝える事ができます。

整理された体系的な情報も良い情報の一つです。バラバラにあると普通の事でも、まとめられる事で、それまでにない概念や思想が生まれます。

奇異な情報

良いかどうかはともかく驚かせること、刺激を与えることを目的とする情報です。いわゆる「釣り針」や「まさかり」などが飛び交うのは、その一例です。

意識的に、いわゆるウケ狙いで発せられる事もありますし、インターネット(あるいは世の中)とはそんなものだと思われている方も見かけられます。

対策

良質な情報を受け入れるには、奇異な情報に踊らされない、いわゆる「スルー力(りょく)」が求められます。もちろん、一緒になって楽しむのも自由ですが、より良い情報を得たいならウケ狙いの情報はそっとしておけば良いと思います。

ウケ狙いは一発屋の芸人に似ています。一時的に話題になっても、実力がなければ長続きはしません。奇異な情報もパターン化されれば情報量が減るからです。

ウケ狙いをして楽しむのは自由ですし、知名度を上げるきっかけにもなるでしょう。でも、それだけでは良い情報は集まりません。

より良い情報を得るには、良い情報を提供する事です。そうすれば、自然と良い情報が集まる様になると思います(情報を得るには Give & Give)。

標準化のトレードオフ その5 - 従来法と改善 -

「ウォーターフォールなんて!最初に全部決める事はできないだろう!」アジャイラーには、そんな意見もある様です。たしかにそういう組織もあるでしょうが、そうでない組織もあると思います。

現場でウォーターフォールをベースとした開発と言われている従来法には、ロイスでもDoDの定義でもなく、ドキュメントを必須とする計画駆動で、標準プロセスを元に監査が行われていることも多くあります。

このような開発法では工程をまたがる作業を許容していたり、プロトタイプの開発も可能な場合があり、 最初に仕様を全部を決めているとは限りません。

しかし、実際にはプロトタイピングをした方が良い局面でも、実施できない場合があります。その理由には以下のものがあるでしょう。

  • 技術検証チームが別にある
  • 開発標準で禁止されている
  • プロジェクトの立ち上げ時に想定(テーラリング)していない
  • 計画や契約に入れていない

安定した技術を採用してプロトタイピングを不要にし、手戻りが生じる事になっても工程毎のレビューを厳密にする事が選ばれる事もありますが、ルールとしてプロトタイプの開発を禁止していない組織も少なからずあります。

しかし、プロトタイプに積極的でないことで計画や契約で考慮されず、現実的にできない場合もあるでしょう。

その背景として考えられるのは、管理者や現場がプロセスに対して保守的になっている場合でしょう。過去にプロセスを工夫しようとして許可されなかった事がトラウマになって、チェックに対して安全策を取るような場合です。

プロセス標準を決めるのは習慣で実施されていたプロセスを定義する事で、組織的に改善するための基盤を構築するためです。抜けのない作業を全てのプロジェクトがきちんと実施していれば、改善に成功した試策が他のプロジェクトへの適用が容易になります。

しかし、現場が改善活動に協力しなかったり、上に書いたように現場が守りに入るようでは、プロセスの安定が得られても改善に結びつきません。

そこで、プロセス改善の集まりであるJASPICのSPI Japanやソフトウェア技術者協会のソフトウェアシンポジウムなどでは、現場と共に改善する方法について多くの議論が行われました(他にもたくさんあるでしょう)。

その結果、多くの成果が発表されました。その反面、そのような活動に参加せず、トップダウンに標準プロセスを強要することに終始して、改善に結びついていない会社もある様です。

その理由を考えると、組織の標準プロセスというトップダウン的なプローチが、そもそも危険を含んでいたのかもしれません。しかしそれ以外にも、現場と共に行うプロセス改善の議論がコミュニティ中心で、プロセス改善の営業的な利用の勢いに負けた事も原因の一つではないかと思います。

ウォータフォールだからという単純な理由ではなく、トップダウンに標準化する際のノウハウの不足が、プロセス改善がうまくいかなくなる大きな原因ではないでしょうか。

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

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