無料ブログはココログ

[#TiDD] プロジェクトを成功させるチケット管理

QuaSTom高品質ソフトウェア技術交流会 2017年度第2回例会で講演させていただきました。

Redmineの勉強会ではないので初心者の方が多いかと思いきや、9割の方がチケットシステムを使われていて、そのうちTracが24%、Mantisが8%、残りがRedmineを使われていました。

幹事の松谷さんに用意していただいたグループディスカッションも、みなさんのお悩みや経験で盛り上がりました。やはり、メンバーにきちんと理解してもらえないとうまくいかないようです。

同じような議論は、90年代後半以降のプロセス改善ブームの頃にもありました。みなさんの意見をうかがっていると、やはり「ツールの導入はプロセス改善である」という思いが強くなりました。

ディスカッションへのコメントで「ゴールはプロジェクトの成功」とお話ししたことや、講演のおまけでお話しした「サーバントリーダーシップ」もリーダーシップの議論をされているとのことで喜んでいただけました。

久しぶりに大いに刺激を受けることができました。ありがとうございました。

おまけ

講演の仲であまり詳しく説明しなかったチケット駆動開発のレフトウィングとライトウィングのお話は、以下の発表が元になっています。

[#redmineT] 裾野が広がるRedmine「チケット駆動開発導入のヒント - 自律と規律 -」

(今回はお話ししませんでしたが、改善にはフィードバックやタイミングも重要だと思っています)

この発表の際にも使わせていただいた乗松さんの資料(PDF)の23ページ「SPIモードの遷移」は認証の罠を標準化の罠に読み替えるとツール導入にも同じような問題が起きると思いますので、参考にしてください。

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


アジャイルジャパン大阪サテライト2017の感想

SS2017のポストイベントがなくなったので、 急遽スタッフとして参加しました。


(1)キーノート:シンアジャイル(Joshua Kerievsky)

モダンアジャイルについての説明。タイトルはAgileJapan2017のタイトルにあわせて変更されたようです(シン・ゴジラをまねた?)。

個人的にアジャイル開発のタイムボックス管理は、作業タイミングを固定化するので超短期開発にはフィットしないと思っていました。Kerievsky氏は早くからタイムボックスを守るよりも顧客のメリットを考えようと言われていたそうです(そのとおり!)。

提案する新しい4つの原則は従来のアジャイルマニュフェストに対応しながらも、顧客やソフトウェアの安全性に配慮したものでした。

講演概要
http://www.agilejapan.org/session.html#session01

Agile 2016の基調講演: モダンアジャイル
https://www.infoq.com/jp/news/2016/08/agile2016-modern-agile

チェンジビジョン/英和システム 平鍋さんの説明
https://anagileway.wordpress.com/2016/10/07/modern-agile-jp/


(2)ヴァル研究所 新井さんの講演

アジャイルを社内に広げる際の話。みんなが積極的になるように色々と工夫された中で、権限(部長)があるので、一部の活動が社内評価と連動するようにした。と言われていたので懇親会で質問させていただきました。

質問は、社内の仕組みと連動すると、義務感ややらされ感が出ると思うが、どのようにバランスをとられているか?

答えは、社員には積極的なできる人と、受身の人と両方いて受身の人も働いてもらわないといけない。ルールを決めても相手によって変えている。とのこと。

つまり、ルールはがちがちにせず、運用時に人を見て、たぶんチームによっても変えているのでしょう。エンジニアは、ついつい一貫性が気になりますが、個人個人を良く見ると言うことが重要だと思いました。

ちなみに、「上から見てなので、みんながどう思っているかはわからないですけどね。」と謙虚に言われていたのが印象的でした。


(3)コニカミノルタの久保さんによるエモイ話

人はなぜ生きているのか?それは人生を楽しむためである。

なぜ苦しみがあるのか?それは、いつかより人生を楽しめるからである。

いい人である必要は無い。人の顔色ばかり見る必要は無い。わかってあげるだけでいい。

そう、生きているだけで素晴らしい。

そう思いました。

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

Node-REDから見えた未来 - 変わるもの、変わらないもの - SS2017 WG13

ソフトウェアシンポジウム(SS2017)では、前回紹介した論文発表のほか、ワーキンググループにも参加しました。

ワーキンググループでは各グループのテーマに沿って、参加者がそれぞれのポジションを発表して議論します。私が参加したのはWG13「ソフトウェア開発の現状と今後の発展に向けたディスカッション」で「Node-REDから見えた未来 - 変わるもの、変わらないもの -」を発表しました。

Node-REDは高機能なノード(モジュール)がたくさんあり、それらを組み合わせて高機能なシステムを効率的に開発できます。また、簡単にデバッグできるほか、デプロイが一瞬で、開発から確認の繰り返しを素早く実行できます。

このような環境を使っていると、面倒臭いことがなくなり、ソフトウェア開発に重要な作業を中心に実施する様になります。この重要なことはみなさん合意できますよね。という発表でした。

しかし、Node-REDのデモのインパクトが大きかったのか、Node-REDに対する質問で持ち時間が終わってしまいました。Node-REDを知ってもらえたので、良かったことにしておきます。

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

Visual開発ツールNode-REDの導入によるプロセスの変化と考慮点 - SS2017 -

ソフトウェアシンポジウム2017(SS2017)で経験論文の発表をしてきました。経験論文とは研究論文の様に新規性はないものの、事例報告の様に経験を報告するものですが、問題設定や結果・考察を整理してより有効性や信憑性を高めて論文にまとめたものです。

今回はVisual IoTツールと呼ばれているNode-REDのアンケート結果を報告しました。ソフトウェア開発にツールは欠かせませんが、その導入報告はあまりありません。上流のツールであれば、コンサルタントに依頼することもできるかも知れませんが、下流のツールは小さい規模から始めることが多く、導入経験は他の人にも役に立つと思ったからです。

発表ではNode-REDの基本、長所・短所の説明と共にデモもしました。基本的な Hello World のノードを入れ替えてPathをセットするだけで、そのビジネスロジック(文字列の代入)をそのままWebサービスにできる様子をお見せしました。

このようにNode-REDは確認しながら開発するので短期間に品質の高いソフトウェアを作ることができ、アンケートにもある様に非同期処理が簡単に扱えます。その反面、ある程度の規模になれば、データやアーキテクチャなどの設計をきちんとしておかないと複雑になってしまいます。

そういった知識を持ち、ふさわしいプロセスで開発しないとうまくいかないことがアンケートからわかりました。まとめると

  • ツールの知識やノウハウを共有 する
  • 特性を活かした設計を行う
  • 実装を繰り返して常に確認する
  • 主体的にプロセスを変更し、品質 を上流から作りこむ

となり、これは、モダンアジャイル

  • 人々を尊重する
  • 安全な状態を前提とする
  • 素早い実験と学習
  • 価値を継続的に届ける

の基本理念と対応していて、Node-REDの良い導入が開発のアジリティ(機敏さ)を高めると考えられます。詳しくは以下の論文を読んでください。
(実は最終原稿の段階でモダンアジャイルの基本理念と対応していることに気付いたので追加しました)

Node-REDから見えた未来 - 変わるもの、変わらないもの - SS2017 WG13 につづく

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

複合主キーの扱い方

緊急開催:複合主キーは必須なのか?<第55回IT勉強宴会Light> に参加しました(主催者まとめ)。

議論の発端は渡辺幸三さんの「単独主キー専用環境」と賢くつきあうためにという記事。

乱暴に説明すると「データベースではきちんと複合キーを使うべきだ。OOPだからといってカスケードキーでいい加減に作るから、あとでわからなくなって保守ができなくなるんだ。ばかやろう!」ということ。

ここにはいくつか議論をしないといけないことがあります。一部追記したスライドを元に説明しましょう(追記部分は灰色の小さい文字になっています)。


RDBだから複合キーを使わずにできてしまう

渡辺さんのブログを読んでいると、RDBなのになぜ複合キーを使わないのか、という気持ちが透けて見えます。でも、実は多機能なRDBだから複合キーを使わずにできてしまうのではないでしょうか?

複合主キーを持てないKVSや連想配列があります。これらを使うとき、シーケンスの管理が
難しいこともあり、「キー1_キー2」のようにして開発しています。

このことから考えると、RDBなのに複合主キーを使わないのではなく、RDBだからサロゲートキーを作りやすいので、複合キーを使わない開発が簡単にできてしまうのだと思います。

つまり、単独主キーで開発を安易に行うことが問題です。

本来、複合主キーで表現されるデータをどう扱うかは、モデリングの問題ではなく実装の問題です。

複合主キーを使わないのは実装の都合なので、そこにある危険性を周知することが重要だと思います。

(もちろん、、モデリングしているのはあたり前としてです)


オブジェクト指向だから単一主キーとは限らない

渡辺さんのブログでは「OOP好きからは『テーブルに別途ユニーク制約を置くなり、クラスの中に制約のためのロジックを盛り込むなりすればよいだけではないか』と反論されそうだが、」と書かれていますが、それは時代に流されている人ではないでしょうか?

オブジェクト指向システム分析―上流CASEのためのモデル化手法には「オブジェクトのそれぞれのインスタンスを唯一に識別する1以上の属性の集まりは,そのオブジェクトに対する識別子です。」と複合主キーを認めています。

ソフトウェアを開発する場合、様々な視点で特徴や制約をモデリングしないとシステムの詳細は表現できないと思います。複雑な要素を如何に矛盾なく、いかにわかり易く統合していくかが設計者の腕の見せ所では無いでしょうか。


保守性の考慮

もちろん、実装の都合でモデルと異なる方法をとったり、モデル自体を実装に最適化することもあるでしょう。しかし、その場合は注意深く開発する必要があるでしょう。

渡辺さんのブログには「複合主キーを扱えない」という環境自体の特性ゆえの問題が書かれています。

  • エンティティのまとまりやそれに適用される複雑な制約が、開発者自身によって見い出されない
  • 使いづらく保守しにくい業務システム開発が生まれる
  • 単独主キーだけを用いた設計スタイルに逃げ込んでも、問題が見えにくくなるだけで事態はさらに悪化する

つまり、きちんとモデリングされず、保守しにくいシステムが作られ、どんどん深みにはまってしまいます。

このように考えると、複合主キーを使ったモデルそのままに実装できるならDBを見ればわかるかも知れませんが、モデルと異なる実装ならモデルからどのように実装に持ち込んだかわかる様にしておかないといけないと思います(もちろん、モデリングしている前提です)。


おわりに

渡辺さんの主張をより単純化すると「バグを出すなバカやろう」だと思います。

なぜ、バグが出るか、それは「複合主キー環境でないから」ではないと思います。たぶん、複合主キーが使えても同じようなDB設計をするのではないでしょうか?

もし、きちんとモデリングができるなら、本来必要な制約を理解し、わかり易く制約を実装し、必要ならドキュメントも作成するでしょう。

「もともとDB設計というものは高度な専門職」とは思いません。もし、そうなら、ソフトウェア開発のインタフェース設計、システムチューニング、保守、運用、すべて高度な専門職です。

エンジニアリングは一定の努力で誰もが習得できる専門知識です。きちんと勉強して、危険性を理解すれば良いと思います。

問題はすでにできてしまったお客様のシステムをどうするかです。危険性を考慮せずに勝手な思い込みで作られたやっつけシステムは、問題が起きた際は大変だと思います。作り直したくても予算も期間も無いからです。

担当される方のために祈らずにおられません。

彼らをお赦しください。自分が何をしているのか知らないのです(ルカによる福音書/ 23章 34節、日本聖書協会)

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


「深層学習の概要とドメインモデル」に参加してエモーションチップを考える

もっとも印象的だったのは、以下の言葉です。

適切に学習すれば、有限個のニューロンで任意の連続関数を近似できる
(universal approximation)

いつもお世話になっているIT勉強宴会で深層学習(ディープラーニング)のお話を聞いてきました(幹事の佐野さんが深層学習の概要とドメインモデル<第53回IT勉強宴会>に詳しくまとめられています)。ここでは、個人的な感想をまとめます。

ニューロンは判断するもの

深層学習の基本であるニューラルネットはは多層のニューロンから構成されます。このニューロンというのは「脳神経系における情報伝達を模した数学モデル」で、しきい値を超えると発火する、いわば入力に対する判断機構です。

ニューロンは20世紀からある技術で、ソフトウェア障害の有無などの判断をする論文などもありました。しかし、他の統計的手法がよく使われているのは、ご存じの通りです。

多層化による能力向上

その後、技術の発展や計算機能力の向上などでニューラルネットを多層化できる様になりました。ここで出てきたのが、初めに挙げた言葉です。

ニューロンを組み合わせれば何でも判断できる。そんな夢が広がりました。しかし、現実は厳しく、精度があまり上がりませんでした。

フレームワークの発展

近年の深層学習の話題を見ているとスゴいものばかりで、なぜだろうと思っていました。それらは、ニューラルネットの層に意味を持たせたり、途中で分岐したりと、より人間の脳に近づく事で精度が上がったそうです。

SF好きの私などは、より人間の脳に近づけばいつか人間の様に意識を持つのかと期待してしまいます。しかし、そこで障壁となるのが最初の言葉です。あくまで近似なのです。

機械学習あるいはデータ少尉の限界

新スタートレック(TNG)に出てくるデータ少尉を見ていると、機械学習の限界を感じさせます。人間と共に宇宙船の士官として働き、頭脳明晰、記憶や情報検索にすぐれ、技術を組み合わせた新しい提案や、過去の音楽家の味付けをして演奏する事が可能です。

しかし、友人がいても、悲しみや喜び、愛情を感じる事はありません。大切な人を失っても「何かが抜けたような」認識を持つだけです。仲間を作ったり、敵と戦うなど、本能的な能力が必要なのでしょう。

実はデータ少尉には兄がいてエモーションチップによる感情を持っています。しかし、性格が悪く失敗した様です。

おわりに

深層学習の発展によって人間の能力を超えるものが作られるかも知れません。しかし、それは人間が求めるゴールを実現するためのもので、ゴールを設定して深層学習の構造を作るのは人間です。

深層学習が話題になり出した頃、データを大量に突っ込めば答えを出してくれる様に勘違いしていました。でも、そんなうまい話は無く、良いものにするには人間の力が必要です。

エモーションチップが実現できるかどうかはわかりませんが、システムを作るのは常に人間です(今のところ)。ソフトウェアに関わるものとして、深層学習を野次馬的に眺めたり、変に恐れたりせず、ふさわしい場面があれば、ぜひ利用したいと思いました。

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

ランチェスターの法則にソフトウェア開発を学ぶ

はじめに

ランチェスターの法則(Wikipedia)はオペレーションズ・リサーチの数理モデルの一つで戦闘を2つのモデルで表現したものです。

この法則はランチェスター経営やグー・パー・チョキ理論などで知られていて、導入期などで力を一点に集中させる弱者戦略(グー)、 成長期の後半で多様な展開(ボリューム)で勝負する強者戦略(パー)、伸びが鈍化し衰退しだすと多様化を整理する(チョキ)。

ソフトウェア産業で考える

これはソフトウェア産業にもあてはまります。自分たちの立ち位置と世の中の情勢で戦略を考えます。

立ち位置は会社の規模ではありません。マーケットに対して強者であるか、弱者であるかの判断が必要です。

ソフトウェア産業は顧客の経営状況に影響を受けます。従来は新しい予算の切り替わるまでの期間が長く、半年から1年ほど遅れて影響が出ていました。

近年は世の中の情勢に応じて予算が変更される様になりましたので、これにあわせて利益重視(グー)、売り上げ重視(パー)、縮小(チョキ)を変更しないといけません。

参考:ランチェスターの法則と売り上げ、利益、利益率

ソフトウェア開発を考える

ソフトウェア開発においても同じような状況があります。プロジェクトの開始時期は、コミュニケーションや構成管理の基盤を作る、横展開の元になるひな形の開発し品質を向上させる、自動化を進めて手作業を減らす、など効率化を狙った施策を取ります(グー)。

やがて効率化の施策がすすむと、ガンガン開発するフェーズに入ります(パー)。しかし想定外の事象が起きた場合は見極めが必要です。

上司の視点で見ると、ついつい人を投入したくなると思いますが、状況をきちんと見極める必要があります。場合によっては戦略を転換して、必要に応じてスパイクやプロトタイピングといった「グー」戦略も必要でしょう。

ソフトウェア開発でも「チョキ」の戦略が最も難しいでしょう。プロジェクトが収束に向かう時、人を減らす必要もあるでしょう。あらかじめどのように引き継ぐか、誰を育てるかを考えて開発を進める必要があります。いわゆる「段取り8分」です。

参考:実装優先時の考慮点 その1 - プロトタイピングとスパイクソリューション -

状況を把握するには

いかにアンテナを張るかが重要です。顧客とのちょっとした会話が重要です。信頼を得て、関係を良好に保ち、時にはストレートに話して理解していただくと良いでしょう。

開発者の状況もよく見ておく必要があります。出勤時間や退勤時間、休み時間の過ごし方など、ちょっとしたことから、前向きに取り組めているか、負担になっていないか、を見極めます。

「現地現物」と言いますが、ほんの少しの時間であっても直に接して、状況を感じ取る事が重要です。

参考:[#TiDD] プロフェッショナルは本物で確認する

おわりに

ソフトウェア開発と戦略的な考え方は共通点があると思っていました。ランチェスターの法則を見直すと、そこにも戦略的な要素がありました。

グー・パー・チョキの分類はわかり易いので、今の状況を考える際にがどれに当てはまるか考えてみてください。色々と見えてくるかも知れません。

もし、上司がおかしいと思っても、それを愚痴のネタだけで終わらせないで下さい。あなたには、説得する、異動・降格を待つ、昇進して追い越す、転職する、といった選択肢があります。

ランチェスターの法則は様々なものに当てはめる事が可能です。現在のポジションと状況に応じて未来を選択してください。

参考:[#agileto2012] 『チェンジ!』の考え方 ~マネしやんと!~

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

口説くか、待つか、勧めるか、それとも聞くか - 求められる適性とオブジェクト指向 -

GWのタイムラインに気になるツイートが2つ流れてきました。

どちらも根本は同じで、「業務の違い」だと思っています。

口説くか、待つか、勧めるか、それとも聞くか

あなたに好きな女性がいたらどうしますか?

自分についてこいな人は口説くでしょう、女性に積極性を期待する人は待つでしょう、様子を見ていてあなたに必要なものはこれでしょうと理解者になろうとする人もいるでしょう。

でもさっぱりわからない不思議ちゃんには聞かないとわかりません。つきあい始めてもやっぱり不思議で、いつも聞いては理解を深める必要があるかも知れません。

実は

この話題、実はソフトウェア開発と同じだと思っています。パッケージなら口説くでしょうし、お客さんが主導権を持たいなら説明を待つでしょう。業務システムならある程度お客様のお話を聞いて提案するでしょう。

でも、組み込みの様に特殊な業務なら、納得いくまでとことん聞いて、設計するごとに発生する疑問もどんどん聞くでしょう。

もちろん開発者の個性もあると思いますが、業務によって開発スタイルが変わるのではないかと思っています。

オブジェクト指向前夜

オブジェクト指向の前の時代、いくつかの開発法がありました。

DB、データ構造、機能、状態遷移やシーケンスなど、どれを中心にするかは開発対象の業務によって違いました。それぞれに良し悪しがありましたので、適材適所で使われていました。

やがて、複雑で大規模なシステムの要求やWHATとHOWの断絶が少ないことからオブジェクト指向が注目される様になりました。

オブジェクト指向いろいろ

オブジェクト指向と言ってもモジュール化、モデリング、コードの効率や再利用性、記法など、それぞれの注目している視点で語られました。クラスとインスタンスの関係を表のカラム構成と行で説明している本もありました。

やがて、UML(統一モデリング言語)に記法が統一されほか、デザインパターンが登場しました。この頃にソフトウェア開発を始めた方は、これらこそがオブジェクト指向だと思われているかも知れませんね。

ということで

ソフトウェアの業務にあわせて色々な手法が生まれたのち、比較的オールマイティな言語としてオブジェクト指向が普及してきました。

オブジェクト指向には様々な技術が統合され、記法も統合されました。ある業務だけに注目すれば、全ての技術や記法は必要ありません。それぞれにふさわしいものを使えば良いと思います。

議論は尖った表現の方が盛り上がりますが、他を否定するよりは多様性を楽しみたいと思います。

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

考えろ、理解しろ、整理しろ

渡辺幸三さんのブログ:設計者の発言を読んでいて感じたこと。

日々の仕事をする中で口うるさいと思われても、年長者の務めなのできっかけを見つけては指導している。色々と言っているが、だいたい以下の3つに集約できるだろう。

考えろ

指示されたままに仕事をしたり、いつも通りで良いと思っていないだろうか。

渡辺さんの「論理削除」ではなく「無効化」をスタンプ属性や更新履歴テーブルの無駄っぽさを読んでいると、習慣ではなく考えて仕事をすることの重要性を感じる。

より良い方向を考えても、全体との調和の問題で実施できないかもしれない。しかし、きちんと考えてシステムを作り上げることはとても重要だ。次の仕事に活かせるからだ。

なぜかを理解しろ

学部の恩師の言葉で忘れられないのが「職人になるな勉強を続けなさい」という言葉(社内勉強会より社外の勉強会)。知っているだけではなく、きちんと理解していなければ技術者とは言えない。

人に聞いてわかったつもりで仕事に使い、うまくいったらそれでおしまい。それは技術者でも職人でもない。ただの人工(にんく)に過ぎない。

ものごとの原理は何なのか、その人はどうやって情報を知ったのか、広い目で深く理解していれば、自己流ではないより良い方法が選択できるだろう。

整理しろ

世の中のできる人を見ていると、常に考えて仕事をし、より深く理解しているだけでなく、情報を整理してコンパクトに理解している(できる人を観察して勝負する

得た知識はそのままにしておけば忘れてしまうし、量が増えれば大変になる。知識を活かしてステップアップするには、これまでの知識との関連を整理しておく必要がある。

体系化できていればすべてを覚えておく必要はない。どの資料に書いてあるかを知っていれば、いつでも確認できるからだ。経験のインデックスを作るのだ。

おわりに

世の中には新しい情報があふれているが、実は似たような議論を繰り返していることも多い。

渡辺さんの議論も、コードクローン(リンク先は阪大井上研)は全て悪か、より良いバランスはあるのか、と言う議論に見えなくもない(普及しているオープンソースには一定のコードクローンが存在するらしい)。このようにマッピングできるのは、ものごとを考え、理解し、整理しているからである。

ここに挙げた内容は技術者にとって基本的なことであるが、実践は難しい。自分のことはともかく、若者の可能性を信じて意見するのが年長者の務めだと思っている。

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


[#TiDD] ビジョンとコミットメントがチケット駆動開発を成功させる

Redmineを導入すれば問題は解決するのでしょうか?それだけではうまくいきません。では、チケット駆動開発を導入すれば良いのでしょうか?それだけでもうまくいきません。ビジョンとコミットメントがチケット駆動開発を成功させるのです!

うまくいく場合もある

いやいや、Redmineを入れるだけ、チケット駆動開発を導入するだけでうまくいく場合もあるでしょう。それは現状の問題が共通認識になっていて、ツール以外の問題やタスク管理以外の問題がない場合です。

たとえば、すでにアジャイル開発をしていて、拠点が分かれたのでタスクボードの代わりにRedmineを導入する場合など。あるいは、障害管理がうまくまわっている組織が新しい分野にチャレンジする場合に、気付いたことを効率よく共有できる様に補完型チケット駆動開発を導入する。といった場合です。

このように問題点が明確な場合は、チーム全体がチケットを中心にまわり、チケットで情報共有が進み、作業が効率化されます。

うなくいかない場合

反対にうまくいかない場合は以下のような状況がある様です。

  • 協力してくれない。チケットを行進してくれない。遅い
  • チケットと現状に差がある、適当。ごまかす
  • 期待した成果が出ない。勉強不足で効率が悪い

その背景には以下の問題が考えられます。

(1) 問題が共有されていない
そもそも何のためにRedmineやチケット駆動開発を導入するのか、目的がわかっていないのではないでしょうか。それがなぜ必要かもわからず、作業の負担増え、ただただやらされ感を感じさせているのではないでしょうか?

(2) 重要性が理解されていない
トレーサビリティやコミュニケーションの向上、あるいはデータ収集の効率化といった目的が共有されていても、その効果をフィードバックしていないなら徐々にいい加減になるでしょう。重要性を理解してもらうには、その効果を示す必要があります。

(3) 導入の段取りが悪い
ツールを導入する場合は新しい作業が負担にならない様に、レクチャーや指導が必要です。理解のないままに、いきなり高度な実施方法は負担が大きくなります。まずは障害管理から初めて、開発の道具になってからタスクの管理をはじめると良いでしょう。

違いはビジョンとコミットメント

コマンドコントロールにしろ、支援型のリーダーシップにしろ、新しい環境を導入する際にやらないといけないことは変わりません。それは、どのような改善がもたらされるか、ビジョンを示すことです。

状況によって、始まりは指示なのかお願いなのかわかりません。しかし、長く継続させるには、そのビジョンは理想のままではなく、結果で示さないといけません。

開発者が効果を実感できるか、明確なフィードバックがなければ、それは余分な作業が増えただけです。

フィードバックは定量的でなくても構いません。「障害対応が早くなったような気がする」「管理作業が楽になった」という感想が聞ければ、それは無駄な作業ではなくなります。前向きな協力が得られるかも知れません。

そして、何よりもコミットメントを得る事が大切です。やらされ感だけの作業は、いい加減になりがちです。

無理な導入は行わず、必要な教育を実施した上で、開発者にメリットのあるところから段階的に実施します。そして、その後も支援や適切なフィードバックを行いましょう。

まとめ

Redmineやチケット駆動開発に限らず、これまでのプロセスを変更する際にはリーダーシップが求められます。それが如何に大切なことであるかビジョンを示し、理解を得ないといけません。

それはソフトウェアを作る場合と同じです。はじめに必要な勉強をした上で、必要に応じて修正やフィードバックを行いながら、より良いプロセスを作り上げていきます。

ゴールの達成にはリーダーは余計なプライドを捨て、チームに期待して、何でもしないといけません。チームを支援することが、リーダーの仕事をセクシーにするのです。

参考:

[#TiDD]ウォーターフォール開発をアダプタブルにする(チケット駆動開発) - SQiP2015チュートリアル -

ピグマリオン効果とリーダーシップとリーダーの心理 - マンガで分かる心療内科14 -

リーダーはショットガン・アクションでボトルネックをなくせ! - マンガで分かる心療内科14 その2 -

求められるリーダー像と羊飼い型リーダーシップ - 「リーダーシップ3.0」の咀嚼 -

支援者としてのリーダー - 「リーダーシップ3.0」を読んで -

チームを守り育てる - セクシーな中間管理職 -

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


より以前の記事一覧