無料ブログはココログ

« 2014年2月 | トップページ | 2014年4月 »

[#TiDD] チケット駆動開発によるメトリクス収集のメリット【勉強会告知】

「計測できないものは制御できない」などとも言われますが、計測できたからといって制御できるとは限りません。

計測したメトリクス(定量的尺度)が制御対象と関連が明らかである事はもちろんですが、制御対象の変化よりも早く収集できる事、誤差が少なく、改ざんがない事が必要です。

また、計測に必要なコストよりも制御によって得られるメリットが大きくなければ、計測する事に意味がないでしょう。

チケット駆動開発のメリット

チケット駆動開発はチケットで作業を管理します。そのタスクは開発者が、自分の作業を管理する目的で起票され、更新されます。

つまり、開発者はチケットに依存していますので、メトリクス収集の特別な作業はありません。チケットの更新時に必須の項目が若干増えるだけです。

また、チケットの更新はリアルタイムで確認できます。メールの転送がなくてもWeb画面でいつでも最新状況を確認できます。

チケット駆動開発は管理が目的でなく、開発の見える化、コミュニケーション、自律的なチームづくりが目的です。それは生々しい開発のデータで、偽リの少ないメトリクスが収集できます。

では、実際はどうなのか?

チケットを利用したメトリクスの収集は、障害を中心にすでに多くの企業で行われ(SPI Japan 2013SQiP2013)、IPAでも可視化ツールが開発されています。

今回はその中から、NTTデータの大杉さん、元IPAで書籍「チケット&計測でITプロジェクト運営の体質改善」著者の神谷(みたに)さんをお迎えして勉強会を開催します。パネルディスカッションもありますので、詳しく聞きたい方も、意見を言いたい方も、ぜひご参加ください。きっと、他では得られないものがあると思います。

【告知】第10回 RxTstudy/第57回 SEA関西プロセス分科会
テーマ:「チケット駆動開発とメトリクス」
http://kokucheese.com/event/index/156953/


[#TiDD] 手分けするより助け合い - FDDとチケット駆動開発 -

仕事を手分けするのがリーダーの仕事、単純にそう思っていきなり作業を手分けすると失敗しますよ。というお話です。これを書籍「アジャイル開発手法FDD」を元に説明し、チケット駆動開発との関連についても述べます。

原因はコミュニケーション

遅れを取り戻そうと増員するとデスマーチになリ易い事は有名です。新しい人がそれなりの生産性を発揮するには教育期間が必要ですし、単純に見える作業をうまく切り出せてもコミュニケーション量が増大するなど、投入工数に比較してあまり効果が出ないからです。

作業を手分けする場合も同じです。チーム内で関連技術や業務知識が共有され、さらにゴールが明確でなければ、手分けしてもうまくいきません。リーダーが一人のところに人手が足りないからと、増員しただけだからです。

「アジャイル開発手法FDD」にはこうあります。

より多くの人が並列で働くようにすると、ますますコミュニケーションと調和の問題に突き当たるでしょう。解決中の問題に重要な依存性がある場合、適正な場合に必要とする情報をだれもが持てるように、適正なコミュニケーション経路を適所に配置することに勤めなければなりません。(p.14)

これはチケット駆動開発でも同じです。とりあえずWBSができてもプロジェクトの成功が保証されないように、作業がチケットに分割されたからといって作業結果が正しいものである保証はないからです。

まずは共通理解

コミュニケーションの基本は言葉です。「人月の神話」にも出てくるバベルの塔は、傲慢な人間に、神様が言葉を通じなくして塔の完成を失敗させる話です。

古くはデータディクショナリ、最近ではドメイン駆動設計のユビキタス言語のように、言葉の定義は基本です。FDDではモデル駆動型らしく、こう書かれています。

ある言語から他の言語に変換するたびに、情報を損失したり間違った情報を伝達したりする可能性があります。<中略> そのため、情報を変換する回数を増加させないことと、情報が欠落する機会を限りなく減少させるように多くの変換を自動化することを望みます。(p.11)

もちろん、これらの言語で書かれたモデルは確証と検証のフィードバックループが必要です。

チケット駆動開発なら、Wikiも活用すると良いでしょう。用語集をまとめたり、関連情報を体系的に整理しておけば、知識の底上げができてコミュニケーションが容易になるでしょう。

全貌を共有する

言葉が通じるようになっても、プロジェクトをはじめる前に全体像を共有しておかないと、プロジェクトはとんでもない方向に向かいます(少なくとも直近の目標がずれていては、いつまでたってもムービングターゲットをとらえることはできません)。

XPで始まったアジャイル1次ブームでは、プロジェクト開始時に実施すべき内容があまり知られていませんでした。そこで、すぐに開発をはじめるにはモデリングの理解が欠かせないと、XPJUG関西ではビジネスモデリング分科会が立ち上げられるなどしました(これが後のチケット駆動開発勉強会に繋がりました)。

近年は、ビジネスに必要なソフトウェアを明確にするIMPACT MAPPINGアジャイルマーケティング/リーンスタートアップのリーンキャンパスのほか、インセプションデッキなどが紹介されています

FDDは、領域専門家と共同して領域オブジェクトモデルを作成することから開始します。実行されたモデリングアクティビティとそれ以外の要件定義のアクティビティから得られた情報を使用して、開発者はユーザ機能リストの作成に進みます。それで計画の概略が作成され、責任が割り当てられます。(p.61)

この場面でチケット駆動開発は、課題やQAの管理、スパイク(ラピッドプロトタイピング)などの管理で活躍するでしょう。

失敗への不安:気になる点は助け合う

「アジャイル開発手法FDD」には、失敗への不安についてこう書かれています。

情報を保留するという誤りになると思われることを極端に恐れていると、明確なコミュニケーションが明らかに危うくなり、しばしば長い間に誤りが増幅されます。(p.12)

独立性の高い構造を実現して、作業を手分けしてもコミュニケーションの問題は存在します。もし、なんらかの危険を感じたなら、その問題をいつ解決すべきかを決め、適切な時期に解決する必要があります。その際には担当の壁を打ち破ることも必要です。

失敗を恐れて守りに入るのではなく、気付いたことを報告して助け合うことが重要です。チケットは口べたな人との情報共有にも有効です。起票を柔軟にして意見を集約できれば、大きな効果が得られるでしょう。

ゴールはプロジェクトの成功

リーダーになると、効率的な作業、見た目の進捗、人を遊ばせない、と言ったことが気になります。しかし、時を見て作業を手分けしなければそれは逆効果になります。

目指すべきゴールはプロジェクトの成功です。プロジェクトの成功に向けてどうすれば、ゴールを共有し、メンバーの能力を最大限に発揮し、どのようにリスクを見極め、高品質で信頼性を高められる設計できるか、をしっかり考えることです。

手分けすることよりも助け合うこと。それがゴールに近づく方法だと思います。チケット駆動開発を活用すれば、情報を共有し、問題を見える化できます。

プロジェクトの状況に合わせて、チケット駆動開発を活用しましょう。手分けして進捗を管理するよりもより多くの効果が、チケット駆動開発の支援で得られるはずです。


[#TiDD] アジャイル開発のバリエーションからチケット駆動開発を考える

前回アジャイル宣言を実現するものの一つとしてFDDを取り上げ、アジャイル開発のプラクティスを従来型の開発の取り入れたハイブリッドアジャイル開発について考えてみました。今回はこれを元にチケット駆動開発のバリエーションに付いて考えます。

基本的な組合せは2種類

ソフトウェア開発はその対象や開発組織によってふさわしいプロセスが異なります。ベーム先生は「アジャイルと規律」の2章のまとめとして5つの重要要因として、人(の技術力)、変化の度合い、(自由な)文化、規模、重要度、を挙げ、これらを分析して、ふさわしいプロセスを構築すべきだとしました。

その方法はいずれかを選ぶか、カスタマイズするかです。「ハイブリッドアジャイルの実践」にあるインクリメンタルのハイブリッドと同じ様に計画駆動の要素をアジャイル開発に入れてスケールアップするか、単一リリースのハイブリッドアジャイルの様にアジャイル開発の要素を計画駆動に入れるかです。

これらは両書に共通する方法ですが、チケット駆動開発を考慮するとさらにバリエーションを増やす事ができます。

チケット駆動開発のバリエーション

「ハイブリッドアジャイルの実践」にはチケットによるタスク管理についても書かれています。作業階層では、ステージ、イテレーション、ストーリー、タスク、のチケットにわかれ、分類としては、設計タスク、開発タスク、テストケース、バグ、変更要望、環境整備作業、日次ルーチンワーク、その他、があります。

このようなチケットの運用からハイブリッドアジャイルの目指すプロセスがわかります。工程名のチケットがアンチパターンである3つの理由で述べた様に期間を表すチケットは変更に弱いので、作業が明確で変更が少ないことがわかります。また、作業中に見つかったチケットは追加されるとされていますのでチケットの自由度は高いと思われますが、その目的は“作業進捗の「見える化」”(P.109)のようです。

このような方法はFDDやハイブリッドアジャイルの様に、変動が一定の比率に納まる場合に有効です。その反面、開発者の自由な発想で、発見、発明、工夫が求められる場合にはあまり向いていないでしょう。

自由な発想を必要とする場合は、予定が大きく変わりますのでチケットのエクセル連携は工事進行基準と相性が悪いに書いた様に、そのまま進捗管理の情報にする事が難しいので、組織パターンを応用して門番をおいて情報を変換すると良いでしょう。このような場合は、チケット駆動開発をプロジェクト管理の視点だけで考えてはいけないのです。

このほかにもハイブリッドアジャイルはゆとりのある計画(p.117)を立てて変化を受け入れますが、スクラムなどでは理想見積もりで計画しておいてあふれた作業はあきらめます。このような違いもチケットのの記載内容に差が出るでしょう。

ふさわしいプロセスがプロダクトをより良くする

書籍「チケット駆動開発」12章のテーラリングガイドに書いた様に、 ここに挙げた以外にもチケット駆動開発のバリエーションはたくさんあります。プロジェクトの開発対象、人、組織、など様々な条件にふさわしいプロセスが構築可能です。

「良いプロセスが良いプロダクトを生む」とは限りませんが、「ふさわしいプロセスがプロダクトをより良くする」と思います。

おまけ

上記のような特徴のほか、チケット駆動開発を現場の道具として使うなら、開発のメトリクスを容易に、リアルタイムに、より正確に集める事ができます。

【告知】第10回 RxTstudy/第57回 SEA関西プロセス分科会
テーマ:「チケット駆動開発とメトリクス」
http://kokucheese.com/event/index/156953/

書籍「チケット&計測でITプロジェクト運営の体質改善」著者の神谷芳樹さん、 NTTデータの大杉直樹さんをお招きして、「チケット駆動開発とメトリクス」と題した勉強会をSEA関西とRxTstudyで共催します。

IPAで開発されたEPM-Xのお話や開発現場での事例を聞く事ができるほか、パネルディスカッションも予定しています。滅多にない企画ですので、ぜひ皆様ご参加ください。


[#Agile] FDDはアジャイル開発、ハイブリッドアジャイルは、、

アジャイル開発というとエクストリームプログラミングやスクラムを思い浮かべられる方が多いと思いますが、アジャイル宣言を実現するものはそれ以外にもたくさんあり、アジャイルと規律には、リーン開発やクリスタルのほか、RADの流れを汲むASDやDSDMなどにも触れられています。

アジャイルと規律ではアジャイル開発と従来型の開発の表(A-2)があり、RUPやTSPとよりもアジャイルな順位が低いアジャイル開発が唯一FDD(ユーザ機能駆動開発:Wikipedia)です。

FDDがアジャイル開発である理由

FDDの特徴はモデル駆動で、初めに製品の全体モデルを作成します。そして、ユーザ機能一覧を作り、計画を作成します。その後にイテレーションでユーザ機能を開発していきます。不正確な表現ですが、アジャイル開発の実装の前に上流が存在します。

アジャイル宣言を読まれた事のある方は、アジャイル宣言(日本語訳)に「包括的なドキュメントよりも動くソフトウェアを」と書かれているじゃないかと思われるかもしれませんが、その下に「左記のことがらに価値があることを認めながらも、私たちは右記のことがらにより価値をおく」とされていて、ドキュメントを否定せず、必要なドキュメントは作成します。

アジャイル開発で大切なのは変化を受け入れることです。FDDには「10%吸収ルール」があり、途中で見つかったユーザ機能を受け入れます。また、書籍「アジャイル開発手法FDD」では、コミュニケーションに1節、プロジェクトと人に1章が割り当てられているなど、いかにもアジャイル開発の内容になっています。

ハイブリッドアジャイルをアジャイル開発にする方法

書籍「ハイブリッドアジャイルの実践」によれば、結合テスト以前の一定の工程にアジャイル開発のイテレーションを導入するものの様です。リリースは1回もしくは複数で、複数のものは「ハイブリッドアジャイル(インクリメンタル)」と呼ばれています。

ハイブリッドアジャイルは、アジャイル開発ではありません。 本の中でも表(2-2)にまとめられていますが、インクリメンタルを除いてリリースが1回ですので、少なくとも「動くソフトウェアを、2-3週間から2-3ヶ月というできるだけ短い時間間隔でリリースします。」という原則を満たしません。

表(2-2)はアジャイル開発の原則に対して不完全なところや評価できないところも正当に書かれています。しかし、要求変更の歓迎が全てに対して「該当する」とされている点には疑問があります。

ハイブリッドアジャイルでは発注側が20%のバッファを用意しておき、イテレーションの中で変化を受け入れる開発法ですが、それは単体テストまでです。一方、アジャイル開発の原則には、以下の様に書かれています。

「要求の変更はたとえ開発の後期であっても歓迎します。変化を味方につけることによって、お客様の競争力を引き上げます。」

まとめて結合テストを実施する事で、リリースまで1ヶ月単位の期間が必要になるので、それでは、機敏(アジャイル)ではないですし、アジャイルの名称の次点となった「アダプティブ」でもないでしょう。

インクリメンタルな開発にすれば、テスト工程が分散し、後工程でも変化を受け入れることができると思います。

テストは日本の課題

FDDは10%、ハイブリッドアジャイルは20%のバッファを持ちますが、書籍「本当に使える開発プロセス」(p.40)によればSIベンダーのバッファー値1.5〜2倍とされていますので、より変化に色々対応できそうですが、繰り返していないので 変化をうまく取り入れられません。

(注:そんなにバッファを取った見積もりが通る訳ありませんし、SIベンダーの利益率もそんなにありません。倍率はユーザ見積もりとの対比で、あまり詳細でないことや、アジャイルラジオ 第63回「ミスターTOC登場!」西 東でダイワハウスの松山さんが語られていた様に顧客と牽制し合うことでムダな管理が発生するのかもしれません。)

そこで必要になると思われるのが、複数リリースを支援するテスト技術です。具体的には、自動化によるテストの軽量化と差分テストを可能にするグレーボックステスト、そしてそれを容易にする設計です。

テストの自動化:リリースごとに確認しないといけない内容は、自動化して負担を減らさないとリリース回数を増やせません。アジャイルと規律を除く上述の本で取り上げられていることでも、その重要さがわかるでしょう。

グレーボックステスト:アドホックテストなど自動化が困難な場合は、前回のリリースとの差分をテストします。その際にブラックボックスではなく、内部構造を意識すればテスト工数を減らす事ができます。リリースノートだけでなく、チケットやバージョン管理ツールで修正部分を確認すればより安全でしょう。

テスト容易化設計:良い設計であってもテストが困難ならばその価値は半減します。テストの自動化が容易で修正時に影響範囲が局所化される様な設計が求められます。

日本のソフトウェアの特徴は信頼性が高いことです。安易にブームにのって失敗する 事がない様に、プロセスは改善しないといけません。

アジャイル開発はビジネスの競争力を高める効果があります。日本で実践するには、五月雨ウォーターフォール開発など契約の問題、サーバントリーダーシップなど価値観の問題、そしてここに挙げた複数リリースが可能な高信頼性テストが必要でしょう。


[#Agile] アジャイル開発のエコシステム

前回、アジャイル開発宣言と原則をまとめました。わかり易くなったと思いますが「変化に対応して競争力を上げる」以外の効果は明確ではありません。

そこで、今回はアジャイル開発のプロセスが効率的である事を説明します。

プルシステム

前回のまとめでは、「ムダのないシンプルさ」「動くソフトウェアを継続的に作る」がプルシステム(必要性による引き取り)と関係します。XPのプラクティスの一つであるYAGNIやリーン開発の決定をできるだけ遅らせるとも関係します。

アジャイル開発では必要な事を必要なタイミングで行います。必要でないものや必要であっても適切でないタイミングで実施してもムダになるからです。プルシステムはムダを作らないことで効率化します。

ただし、アジャイル勘違い集に書かれている様に必要な事は実施しますので、必要なドキュメントは必要なタイミングで書きます。

フィードフォワード制御

「短い期間で繰り返す」中で「定期的なふりかえり」によって、改善されたプロセスが実施されます。また、「顧客との関係を変える。共に開発する関係にする」ことで手戻りを減らします。

ふりかえりは、手戻り作業を前提にするものではありません。次の繰り返しの際に、より良く実施するためのフィードフォワード制御の情報として、次のやり方を決めています。

アジャイル開発は全体の作業を終えてから確認し、多くの手戻りをするのではありません。顧客と協調して段階的に開発することで、手戻りを少なくし、顧客の構想を踏まえたより良い設計を実現できます。

さらに、ストーリーカードとタスクカードの関係では、後からトレーサビリティを確認するのではなく、作業方法によって漏れを無くすなど、フィードフォワードな仕組みが組み込まれています。

自律的である事

「積極的なコミュニケーションによって、自律的なチームを実現して開発を進める」「技術が大切」が関係します。xUnitやペアプロなどによって、それぞれが小さな単位の責務の実施を保証をすることで、確認や手戻りの作業を減らします。

ここでの自律性は個々の活動や受け身の活動だけではなく、全員同席など相互の働きかけを含みます。他の担当者や顧客と積極的にコミュニケーションする事で、自律的な組織を実現します。

自律的な組織では活発な双方向のコミュニケーションによって、独善的な判断ではなく、より良いアーキテクチャ・要求・設計を可能にします。

まとめ

このように、アジャイル開発は効率的な開発を実現します。プルシステムでムダをなくし、フィードフォワード制御によって手戻りを減らします。このような開発の基盤となるのが、高い技術をもつ自律的な組織です。

これらのうち、アジャイル開発でないと実現できないのは、短期間の繰り返しに基づく改善と、今回取り上げなかったマーケットなどの変化への対応力の向上です。

これらを参考に、ムダな作業を見直し、早めのサンプリングによって手戻りを減らし、チケット駆動開発などで双方向のコミュニケーションを活発にすれば、効率的な開発が可能になるでしょう。

[#Agile] アジャイル宣言と原則の私的まとめ

アジャイルソフトウェア開発宣言はアジャイル開発の4つの価値を示すと共に、 アジャイル宣言の背後にある12の原則を示しています。

4つの価値は宣言に合意した17人の共通理解をまとめたためか非常にシンプルです。それに対して12の原則は、価値の背景にある様々な方法論の主張をまとめたようなイメージで、一つにまとめられそうな内容や、4つの価値とまとめられそうな内容があります。

そこで、KJ法の様に類似の項目を並べてまとめ直してみました。4つの価値と関連する原則をまとめると以下のようになりました。

  • 顧客との関係を変える。共に開発する関係にする
  • 積極的なコミュニケーションによって、自律的なチームを実現して開発を進める
  • 動くソフトウェアを継続的に作る
  • 変化への対応を通じて、競争力を引き上げる

12の原則のうち、4つの価値あまり関係しないものをまとめると以下の具体的な内容になりました。

  • 短い期間で繰り返す
  • 技術が大切
  • ムダのないシンプルさ
  • 定期的なふりかえり

少しはわかり易くなったと思いますが、いかがでしょう。

私なりの解釈や表現によるものですので、人によって結果が異なると思います。ぜひ皆さんもまとめ直して、理解を深めてください。

たとえば、原則には「2-3週間から2-3ヶ月というできるだけ短い時間間隔」となっています。1週間のスプリント(イテレーション)は、アジャイル開発の原則から外れているなど、意外な発見があるかもしれません。

追記:2-3週間というのはリリースなので、1週間で繰り返しても原則から外れないとの指摘を受けました。確かにそうです。「リリースまでしていれば」ですね。

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

「ソフトを他人に作らせる日本、 自分で作る米国」を読んで

第30回 IT勉強宴会は、「動かないコンピュータ」なども書かれた著者の谷島さんをゲストに、「【ソフトを他人に作らせる日本、自分で作る米国】を語ろう」と題して行われました。

この本はとても面白い本です。「ソフトを他人に作らせる日本、 自分で作る米国」と聞くと、日本はダメだ、米国流に変えなければ、と考えてしまいますが、本に書かれている様に、どちらが良いとも結論付けられていません。ハウツー本があふれる中、事実を示して、読者に考えさせてくれます。

家族に「ご飯作るけど、何が食べたい」と聞くと、特定のメニューを指定しないで「ジャガイモとタマネギとにんじんがあるし、肉も色々あるから」と言われたら、あなたはカレーライスを作るでしょうか?

それ以外にも、シチューもありますし、ちょっと工夫してビーフ・ストロガノフにしも良いですし、寒い日ならポトフなども良いですね。事実を明らかにすることで、色々前向きに考える事ができます。(我が家なら「私が作る方が美味しいから置いといて」でしょうけどorz)

そういう本について語ったのですから、意見も色々、なかなか楽しい時間を過ごす事ができました。ここでは、以下の発表スライドにあまり書いていないところを含めてまとめておきたいと思います。

本とは違う視点で考えると、経済や政治の影響が大きいと思います。米国と日本を比べると、以下の様になります。

米国

国防・宇宙からソフトウェア開発が発展し、それと共にソフトウェア工学も発展しました。その後、NASAの予算や軍事費が減らされた後、インターネット技術が民間に解放され、起業ブームがおこりました。

産業界ではウォーターフォール開発がすすめられて標準化が進み、開発を発注するの基準としてCMMが普及し、 従来の開発がオフショアに流れ、技術者が新規ビジネスに活路を求めた事で、アジャイル開発をベーストしたスタートアップが増えたと思います。

日本

日本では1980年代から5年から10年遅れていると言われています。米国では産学の交流が盛んで様々な技術が並列に発展しましたが、日本ではそれほどの交流や広がりがなく、米国の技術を順に追いかけるような状況が続いています。

産業的に見ると、電電公社や金融機関のシステム等でソフトウェア産業が発展しました。しかし、インターネットの先駆けとなるべきシグマ計画では、メーカーのワークステーション規格を定めたものの普及せず、ネットワークも残らず、ルーターをばらまく企業が現れるまでインターネットブームは来ませんでした。さらに、失われた20年によって、流通やゲームなど新規ビジネスはあったものの起業ブームには至りませんでした。

戦略的視点

米国のやり方は横綱相撲で、リーンやスクラムの様に相手の強みを学んで技術体系を確立します。様々な人種のいる国なので、得意の標準化や体系化、アピール力でビジネスをします。

ヨーロッパはそれに 国際規格で対抗しました。CMMの際に日本は、それまでの組織文化を改めましたが、ヨーロッパは段階モデルだけを正解としないSPICEを国際規格ISO/IEC 15504(Wikipedia)にして、CMMIに影響を与えました。

かつて、トヨタはフォードに勝つために、フォードの後追いをしませんでした。それでは勝てないからです。大阪のTV局もはギャラの高い東京を追いかけてもうまくいかないので、お笑いやロケ等の安価な独自企画で勝負しています。

小さな国の日本はそのような戦略的な視点が必要です。幕末の頃、植民地化を進める列強に対抗するために、技術的に負けている事を認めて開国し、多少の内戦はあったものの力を合わせ、体制を刷新して近代国家を樹立しました。同じ事がソフトウェアでも可能だと思っています。

おわりに

関西に居ると様々なコミュニティのある東京がうらやましくもあります。しかし、それなりのコミュニティにいると一通りの情報が集約されて入ってきますし、地理的にも狭いので直接会って議論することも可能です。これは関西の強みです。

この本の中で米国の技術者が大変だと思ったのは、地理的な不便さです。最近は、インターネットがあればかなりの事ができますが、ディスカッションは直接会わないとできません。そこで、この本にある様に彼らはお金を出してカンファレンスに参加します。

ここに我々の強みがあると思います。カジュアルに語り合えるコミュニティで学び、語り合えば、未来を展望する事ができます。敵を知り、己を知れば、一枚上手(Go one better)をいけると思います。

今回、谷島さんの本と講演で、色々と考えさせていただきました。ありがとうございます。


卒業するA君へ

今日、新人研修を担当したA君の送別会がありました。長い間おつかれさまでした。

「相談してくれたら良かったのに」と思うものの、たぶん引き止めずにこんなことを言ったと思います。

自分がその立場ならどうするか

もしかすると、上の人やお客さんに不満が会ったのかもしれませんね。その気持ちはわかります。そんな時は、自分がその人の立場だったらどうするかを考えてみると良いと思います。

その人の期待していることがわかって、仕方ないなと思えたり、自分が期待に応えられていない事に気付くかもしれません。

案外、その人が役目を果たそうとしているのに、説明やアプローチが下手なだけかもしれません。人当たりの良いあなたなら、アドバイスできるかも知れませんね。

しみじみ教

とは言っても、どうしようもない人も居るかもしれませんね。そんな時はしみじみ教を読んでみてください。

これは、晴佐久神父のエッセイです。とんでもない人に腹を立てても仕方がないので、スゴい人だと思えば良いのです。

自分を追い込んだり、感情に支配されない様に、ちょっと離れて観察するんです。滅多にできない経験だと思えば、どうやりすごすか、どう対応するか、色々と考えられるかもしれません。

サーバントリーダーシップ

上の立場になると「XXでないといけない」という義務感と、必要とされる自分の能力のギャップについつい苦しんでしまいます。

「上の人間だから立派でないといけない」なんて考えていませんか?チームがうまくいくなら、何ですれば良いと思います。

こだわりを捨てて、チームと共にゴールだけを目指せば、色々とやる事があるはずです。大変かもしれませんが、とても幸せを感じるはずです。そんなあなたには、仲間がいるのですから。

どこに行っても

あなたが選んだ道ですから、ぜひそこで活躍してください。ここに挙げた内容は、どこに行っても役立つはずです。

社会人の成長は、転職してもしなくても一定の節目ごとにチャンスがあると思います。立場というもので人は成長するからです。

その立場に満足しなければ、上の人や別の立場の人を理解して、次のステップに進めるはずです。ぜひ新天地でも、活躍してください。応援しています。

[#TiDD] チケットを発行して3つの楽をする

以前の記事に書いたバージョン管理ツールと間連付けることを除くと、チケットを発行(起票)するのは「楽をしたい」からです。具体的には、以下の3つです。

忘れない

チケットを確認することで、作業の抜けをなくします。チケットを発行する時の気持ちは「忘れても良い様にする」と言った方が良いかもしれません。

協調して作業する

その作業は自分が担当すると宣言(コミットメント)して他の人に知らせます。自分の作業がムダになったら困りますから。

助け合う

他の人の様子がわかれば、不慣れな人を手伝ったり、経験者に手伝ってもらったりという関係も生まれます。優しさやお互い様の場合もありますし、自分の仕事をすすめるには、関連する他の人を手伝った方が効率的な場合もあるでしょう。

大切なポイント

もちろん、ルールだからという場合もあります。しかし、ルールを守るだけだったらフィードバックが得られない限り、なるべくまとめて楽をしたいと思うでしょう。

チケット駆動開発をうまく実践するには「現場が楽をする」目的で導入すべきだと思います([#TiDD] チケット駆動開発の落とし穴 - ベカラズとベシ -)。


« 2014年2月 | トップページ | 2014年4月 »