2015年11月29日

タスク管理ツール「Redmine」ができる3つのこと

redmine1.png


こんばんは、komeshogunです。


気付けば年末まっしぐらですね。忘年会の予定もボチボチ埋まってきました。仕事の方は絶賛結合テスト中です。諸事情によりRedmineを使っていないプロジェクトにもかかわらず、ついつい「あの不具合、チケット作っといて」と言ってしまうほど、自分に定着しているRedmineについて今回は紹介します。


図書館でこの本があったので、改めて勉強しようと思ったのもきっかけであります。今回はこの本の内容を紹介するのではなく、この本を読んで自分が使ってきて感じているところを紹介したいと思います。本の冒頭に書いてあったチケット駆動開発の基本ルールに、自分の考えを当てはめてみました。


Redmineによるタスクマネジメント実践技法 -
Redmineによるタスクマネジメント実践技法 -



Redmineのいいところ


@Wikiやチケットに情報を一元化できる


・ファイルのフルパスを書いておく

・新規メンバーの受入マニュアルをまとめておく

・間違いに気づいたら誰でも修正していいよ


Redmineなどのツールを使っていないプロジェクトを従来のプロジェクトと呼ばせてもらうと、従来のプロジェクトでは情報はメールか口頭で伝えられる。これがかなり曖昧で嫌い。そもそもメールで情報伝達するスタイルがかなり嫌い。というのもとにかくメールは面倒くさい。前に別の人にメールしたのを、新しく来た人にもう一度メールしないといけない。別に転送するだけかもしれないけど、探さないといけないいし、すぐ見つかるとしても転送という行為すら面倒くさい。そうじゃなくて、Wikiに書いているからググっといて的な、ファイルパスも適当な相対パスじゃなくて絶対パスで誰でも確実にファイルにたどり着けるようにしておきたい。そして、それを確認した人が「あれ、この情報、古くなってない?ファイルが移動されててちょっと違うよ」ってなったら修正してもらいたい。けど、こういう時って結構スルーされることが多い。修正するって行為のハードルが高いんだろうね、だから「間違っているところあったら教えてね」って事前2ちゃんと言っておくという細かいケアも必要です。報告受けたら「ごめん、修正しといて」って言えばいい。はじめから「間違っているところ見つけたら修正しといて」って言うと「間違っているとこみつけたけど、修正嫌だし気づかなかったことにしよう、別に自分は困らないし」ってなるんだよね。


とにかく多くの人に伝える可能性のある情報は、wikiに書くようにしたほうがいい。同時期じゃなくとも、タイミングが違って教える必要になることはよくある。一番多いのは、パソコンセットアップの手順や、プロジェクトの基本情報、事務所内での注意事項などなど新規メンバーの受入マニュアル的なやつだと思ってる。プロジェクトのメンバーは流動的だったりするので、その都度伝えるよりは遥かに効率的だと思っている。


Aチケットでタスク管理ができる


・タスクを頼む時は必ずチケットを起票して依頼する

・保守問合せを受けたら必ずチケットを起票する

・ステータスは「◯◯待ち」とする

・報告用資料「◯◯一覧」用のカスタムクエリを作っておく

・作業記録で工数を記録しておくと、保守契約の精算時に使える


従来のプロジェクトでのタスク管理って個人任せになっていることが多く、チームで管理するにも「課題一覧.xlsx」みたいなエクセルファイルを作ってると思う。このやり方のあかんところは、過去の類似タスクを見つけるのが大変、類似のタスクのひも付けも難しい、エクセルだとセル内に追記、追記になるから見にくい、タスクが今誰がボールを持っていて、どういう状態になっているのか、誰待ちなのか分からない等など山ほどある。だいたい、あのタスクはここに書いてあるけど、これは書いてなくてメールで頼んだだけとか、タスクの入り口はバラバラになることもよくある。あと契約形態によっては、どの問い合わせに対してどれくらいお金がかかっているのかを報告しないといけなかったりするけど、それのために別で「作業工数表.xlsx」みたいなのを作らないといけなかったりする。でそれを報告するために「課題一覧(顧客報告用).xlsx 」が生まれたりする。とにかくエクセルでの一覧ファイルが次から次へと生まれる。しかも情報源がまちまちで、一元管理できていないから後で調べるのが大変になる。でも、Redmineを使ったらこの辺の課題は解決できるようになった。



BTicket.No Commit.


・SVNコミットする時は必ずチケット番号を書く


ソースコミットするのに、コメントを書かずにコミットするなんてありえねぇ。さらに、絶対チケット番号書いて下さい。たとえ正しい実装、修正だったとしてもそんなコミットしちゃったら「ちゃんとやってよ」って言っちゃうレベルです。チケットがないソースコミットは撲滅させたいです。


Redmineでできるけど、やらないようにしていること


Redmineはツールなので、使うことを目的化しないように注意していかに今の仕事の進め方にFitさせるかを考えるべきです。そういう意味では下記はやらないようにしていることです。


@wikiを充実させようとし過ぎない


性格上の話ですが、「wikiに情報を集めるんだ!」ってなるとついつい時間を見つけてはコツコツ、wikiに凝ってしまうんですね。あれも書いとこ、これも書いとこって感じで。でも、意外と誰も見てくれないものです。時間をかけて書く割にはあまり意味が無いんです。もちろん、暇なら良いんですが、そんなことよりも自動化したり、リファクタしたり、モノを作ったほうが良いと思います。情報はwikiにわざわざ書かずとも、チケットを書くサイクルをしっかり回していればチケットにノウハウは溜まっていくので心配ご無用です。「wikiにあったら便利だろうな」と予測で事前に書いておくのではなく、「wikiに書いてあったら便利だったのにな」という経験をしてから書くという基準でよいかと思います。


Aガントチャートは諦める


なんでもかんでもチケットからはじめよう。って言ってるのですが、その分注意しないといけないのは、チケットに書かないといけないことは出来るだけ少なくすること。あれもこれも書かないといけないと思ったら、チケットを作るのを躊躇してしまいますからね。そうならないためにも、チケットには必要最低限なことだけ書けばいいようにしておくことが重要です。そこで、予定と期限、スケジュールに関することは捨てました。ガントチャートは、「開発マイルストン」を使ってます。


Bチームのやり取りにメールは使わない


せっかくRedmine入れたのであれば、メールは使わないようにしましょう。チケットが更新されたらメールで通知する機能もありますが、それは使わない。メールするくらいならチケットを起こしましょう。通知されないじゃんッて思うなら「くち」で伝えましょう。チーム内のコミュニケーションをとるのに、メールよりも口で会話するほうがよいので、「チケット作っておきました。◯番みといてください」と言えばいいだけ。こっそりメールで依頼するのはやめましょう。あとメールだと宛先に含まれていない人は、「え?なにかやりとりされてる?」って思うのはチーム不信にもつながるのでオススメしません。個人的にはこの「何か行われている」感はめっちゃ嫌いで、できるだけ情報はオープンにしようと心がけるべきだと思っています。


終わりに


冒頭にも書きましたが、つらつらと書いたけれども、今のチームではRedmineを使っていません。半客先ということもあり、制約のあるで難しいのかなと思います。ただ、だれも挑戦をしていないようなので、今回はナシにしても次は挑戦したいなと思っています。「ひとつのプロジェクトで、ひとつだけ新しいことに挑戦する」と決めているので、今回のプロジェクトでは見送っています。いろいろ新しいことをやりすぎると失敗するのも学んだので、”ひとつだけ”にするのがポイントです。


💡今回の学び


書籍と自分の経験をリンクさせると考えがより整理される。


👣明日への一歩


より活用できないか、一歩踏み込んで挑戦してみる。


なにかひとつでも気付きがあれば「MeetUp大阪@FBページ」に「いいね!」をお願いします。

posted by @komeshogun at 22:16 | Comment(0) | TrackBack(0) | @komeshogun | このブログの読者になる | 更新情報をチェックする

2015年11月15日

優れたマネージャーは情報を配るんだってばよ。

bsPAK85_kuronurisaretahoukokusyo201409051.jpg


こんにちは、komeshogunです。

久しぶりの連投にチャレンジします。


同じ部門ですが、違う拠点のグループに異動してはや3ヶ月が過ぎ、リーダー的立場からメンバー的立場に格下げされ、またココから信頼を勝ち得ていくのは大変だなあと感じている今日このごろ。べつにリーダーとして失敗したわけではなく、異動元グループよりも異動先グループのほうが仕事がありそうという上の都合で、異動され、なかなか大きめのプロジェクトに入ったため、メンバーとして頑張っているところです。


やっぱりメンバー的仕事よりリーダー的仕事のほうが面白いなって改めて感じていたので、のし上がってやろうって思う反面と、このグループの上の人達との考え方が自分にマッチしていない感じがしてシンドイなって思ってたりします。


さて、そんな現状で読んだのがこの本。


プロフェッショナルマネジャーの仕事はたった1つ -
プロフェッショナルマネジャーの仕事はたった1つ -



マネージャーの仕事、マネージャーは何をすべきかを知りたくて読みました。


p.44 優れたマネージャーは情報を配る。


p.47 状況情報、方向性情報、評価に関する情報、個別業務情報、気持ち情報。


たったひとつの仕事は「配ること」だと書かれていました。最近になり、より共感できる話だなと思って読んでました。というのも最初に書いたとおり、最近リーダーからメンバーになったことで、新しいグループになったこともあり、自分が得られる情報がめちゃくちゃ減りました。今までだとチーム会議が毎週開催され、同じチームの別プロジェクトの状況や、部内の別チームの状況などを共有する機会があり、部内の状況について知ることができていました。しかし、最近は全く分かりません。そんな会もないし、リーダーや上司からそんな情報が展開されることもない。このグループはこういうやり方で長らくやって来ているらしいのですが、これだと完全に帰属意識が薄れる気がしますね。「同じ会社、部門だけど、違う会社で部門で、こっちはこっちでやっとくから。」ってスタンスをとっているように感じてしまう。


自分が持っている情報は包み隠さずに、できるだけオープンにしてチームに展開し、共有し同じ方向を向いていくことを心がけないと、力を合わせて頑張ろうって口だけで言ってもなんの説得力もない。正直に話して、立前と本音を話せるような場を提供しないといけないんだろう。そういうことが上手にできる人がマネージャーとして優れている人のように思うなぁ。


p.51 「ある仕事をさせて、手応えを得る」というサイクルを体験させる。その仕事がどんな状況の中で、どんな意味を持つのかを認識させる。


p.58 部下の動機付けこそ上司のいちばん大事な仕事


p.62 どんな仕事であっても「働きかけ」と「手応え」の循環構造があれば、動機付けは上がります。


p.64 どんな人も自分のやっている仕事の状況や、組織の中における自分の位置づけ、周囲や上司からの評価、そして上司が考えていることを意識する


p.77 仕事の「手応え」は上司から部下に配るもの


メンバーの仕事のやり甲斐を与えるのはマネージャの仕事だっていう発想はなかったので新鮮でした。上に立つものとして、仕事を依頼するものとして、んぜこの仕事をするのか、どういう事を期待しているのかを伝えることはしないといけないと思っている。ただたんに作業することを依頼するのではなく、チームの戦略として顧客に対してこういう戦略があり、育成としてあなたにこうなってほしい、このプロジェクトからはこういう点を学び成長してほしいというべきだ。もちろん、そんなことは上から言われずとも、自分で掘り出して設定して決めるべきだと思っていた時もある。誰もそんなこと言ってくれないし、目の前の作業をひとつひとつクリアしていく事に必死になっていた。でも、上から期待値を提示され、それを達せられるとやり甲斐を感じることが出来ることを知った。自分の中でそこまではまだ早いって思っても、期待には応えようとがんばれたりする。だから、マネージャは期待を寄せ、つたえないといけないと考えるようになった。


リーダーからメンバーになってるので、マネージャーになろうと思うと、もう一回リーダーになって、信頼と実績を築いていかないといけない。なので、いつのことになるか分からない(そもそもあまりマネージャになりたいと思っていない)。でも、この本に書かれていることは決してマネージャだけでなく、上に立つものの心構えとして持っておきたい話だったので、肝に銘じておこうと思う。


💡今回の学び

情報を配るという表現。


👣明日への一歩

後輩への動機付け、期待を表現する。


なにかひとつでも気付きがあれば「MeetUp大阪@FBページ」に「いいね!」をお願いします。

posted by @komeshogun at 19:00 | Comment(0) | TrackBack(0) | @komeshogun | このブログの読者になる | 更新情報をチェックする

2015年11月14日

努力はまわりに見せること!


こんにちは、komeshogunです。

最近ちょっと自己啓発をサボりがちなんで、なんとかアウトプットしようとしています。今回もその一環で図書館で借りた本を紹介します。



ながーいタイトルの本で

p.197 できるだけ努力が負担にならずに、続けられるような方法論

が書かれている本です。著者の人は同世代の女性で、エリート街道まっしぐらな人な人のようです。
この本から良いなあと思ったのが

p.128 努力はまわりに見せること。影で努力をしてしまったら、結果が残せなかった時は、その努力は誰にも評価されずに終わってしまう。努力を公言し、評価やねぎらいという報酬を得ることで、努力を続ける生活が送れるようになる。

というところです。

社会人になるまでは、努力ってかっこ悪くて出来るだけ周りに見せたくないって思っていました。白鳥は優雅に見えるけど、水面下では足を必死に動かしているっていうやつですよね。テスト勉強した?全然してないよー。ってやつにも通じる話ですね。でも、社会人になると目標を達成するために、どういったことをしたのかを問われることになる。目標の達成はもちろんだが、そこに向けてのプロセスも評価される。目標が達せられずとも、そのプロセスが良ければ評価されることもある。

学生のころは、プロセスを評価してくれるころなんて無かったから、なかなか努力を見せるっていうことに抵抗がある。だからなのか、「こういうことをやろうとおもっている」って宣言して進める人はいない。宣言してしまうとリタイヤできなくなっちゃうし、自分へのプレッシャーになるのが嫌なのかな。でも、書かれている通り、宣言したほうが周りの協力を得やすいし、本当に目標を達成したいと思っているなら宣言すべきだと思う。たとえ失敗したとして、宣言しなかったからといって評価があがることがあるだろうか。宣言しなくとも目標を達成しなかったなら評価されない。宣言したほうがフォローしてもらえるし、プロセスを見守られる機会が増えて評価されやすくなるんじゃないかな。

なんてことをこの箇所を読んで考えていました。

💡今回の学び
努力は見せる。有言実行。

👣明日への一歩
いまの目標を考える

なにかひとつでも気付きがあれば「MeetUp大阪@FBページ」に「いいね!」をお願いします。

posted by @komeshogun at 22:52 | Comment(0) | TrackBack(0) | @komeshogun | このブログの読者になる | 更新情報をチェックする

2015年11月08日

可能な限り価値の高いプロダクトを生産的かつ創造的に届けるため

4687936476_bd53a221b7_o.jpg


お久しぶりです、komeshogunです。仕事場が変わって、なかなか本を読むリズムをつかめずな日々です。それでもやっぱり続けないとだら〜ってしてしまうなと痛感しており、今までは電車で読んでいた分を就寝前に読むことに変更して続けようとしています。


今回は"スクラム実践入門"って本を読んだので紹介します。スクラムって聞いたことはあるんですが、なんぞやってレベルで読み始めました。ラグビーが語源だったみたいです。かなりITよりな本ですが、もしかしたら他の業界の方にも気づきがあるのかもしれません。自分の頭を整理するつもりで書いていますのでご容赦を。


スクラム実践入門 ── 成果を生み出すアジャイルな開発プロセス (WEB+DB PRESS plus) -
スクラム実践入門 ── 成果を生み出すアジャイルな開発プロセス (WEB+DB PRESS plus) -


スクラムってなんぞや?


p.17 リレー競争型、ラグビー型。リレー競争型開発プロセスでは、各工程を、それぞれが交わることなく、1つずつ順番に進めます。ラグビー型開発プロセスでは、各工程が、次以降の工程にオーバーラップしていくように、すなわち、あたかもラグビーにおけるスクラムのように、がっちりと協働しながら製品開発が行われます。


10年近く働いてきた感覚では、ほとんどのプロジェクトで工程はオーバーラップしていました。大規模な開発になると次工程へ進むために部長や事業部長など上位者のレビューがあるのですが、そんなプロジェクトはほとんど担当したことなく、小規模な短期のプロジェクトばかり担当していたので、ほとんどがオーバーラップして次へ次へ進める。ウォーターフォールで開発するのですが、納期に向かってひたすら前に進む。次工程の作業を意識しながら、現工程でやるべきことを粛々とやりながら、なし崩し的に次工程へ移る。ニュアンスが伝わりづらいので、「それは違うぜ」と言われてしまいそうですが、"各工程が、次以降の工程にオーバーラップしていくように "ってとこがポイントで、「次の工程の作業をスムーズに進めるためにはどうすればいいかを考えて現工程を進めていくこと」が必要だと経験から感じています。


スクラムマスターってどんな人?


スクラムと一緒に聞く言葉で、スクラムマスターって言葉もよく聞きますが、どういう意味かが書かれていました。


p.22 スクラムマスターは、どのようにすれば効率よくプロダクトを作り上げられるのか、コミュニケーションが円滑にまわっていくのかについて責任を負う。


p.23 課題達成のために何を作るべきかを明確に定め、責任を持つのがプロダクトオーナーであり、人間関係を初めとするコミュニケーションをどのように円滑に進めるのかに責任を持つのがスクラムマスターです。


今までやっていた振る舞いって結構スクラムマスターっぽいことが出来ていたのかな。何をつくるかも重要だけど、それよりもどのように作るのかのほうをしっかり考えないといけないっていう意識が自分は強い。ある程度技術を持っていても、結局はチームでコミュニケーションを取らないと上手く、良いものはできない。システムという無機質なものを作る仕事だけど、やっぱり人間関係がものづくりのエッセンスとして効いてくる。いろんな人の話を聞いてみてもそういう話が多くて、間違いなくそうだと思っている。その一方で、


p.34 スクラムマスターは、プロダクトオーナーや開発チームと異なり、プロダクトには直接関わりません。


とも書かれていたけど、「これはちょっと無理。」って思った。さっきも書いたとおり、3〜4人くらいの小さなプロジェクトでは直接のモノ作りに携わらない人を雇えるほどの余裕はない。だから、プロダクトオーナーや開発チームと分離するというのはそんな簡単に出来るものではない。会社の働き方、役割、キャリア制度を見なおしてくれっていうレベルだと思う。でも、だからといって「スクラムいらね。」ってのも違うので、「そうかもしれませんが、兼務でスクラムやらせてくださいよー」でやるしかない。「絶対に分離せなあかん!」って固執するところではないのかなって勝手な解釈をさせてもらうことにした。本当は分離しないといけないものを兼務でやっていると認識しているのとしていないのでは全然違うだろうから、そこはしっかり踏まえておく。


さらに読み進めると具体的な手法が次から次へと書かれていて、この辺は実際に取り込んでいかないといけないなってものや、名前はついてなかったけど同じようなこと出来ているなってことに分別しながら読み進めた。


とりあえずキーワードの羅列。知らない言葉あればググりましょう。


スプリント、スプリントプランニング、デイリースクラム、スプリントレビュー、スプリントレトロスぺクティブ。

インセプションデッキ、リーンキャンバス、ユーザーストーリー、ユーザーストーリーマッピング、プランニングポーカー、バーンダウンチャート、パーキングロット、KPT、技術的負債の返済、継続的インテグレーション


実際に取り込んでいかないといけないなってもの


p.48 スプリントゴールを設定する際にはベロシティを利用する。ベロシティは1スプリントにスクラムチームが完成させることができる仕事量です。


p.52 スプリントレビューは、スプリントの成果を確認する


p.173 見積もりができるようになるまで見積もらない。


ベロシティ関連のところが全然出来ていないですね。スプリントで区切ったこともないし、どれくらいの仕事量をこなせたかを量るってことをしたことがない。本来はチームのパワーを量るためには必要なことなのでしょう。テスト工程に移るとケース数という簡単に量る指標があるので、1日にどれだけ消化できているかを簡単に量ることができるけど、設計や実装など上流工程での作業量を量ったことがないなあ。ぶっちぇけ手をだすのは早い方なので、(オットマチガエタ)手を動かすのは早いほうなので、量ってもらったほうがいいかもしれない。普通の人よりは良いスループット出していると思っているので、良い評価がされるかもしれないね。ソンシテル。


名前はついてなかったけど同じようなこと出来ているなってこと


p.58 作成物は誰もがいつでも触られる場所におく。


仕事場所が変わって驚いたことのひとつにメンバーの人がローカルでファイルを保管しまくっていること。つまり、説明を受けたあとに「そのファイルどこにありますか」って聞くと「自分のパソコンにしかないからサーバーにおいとくね」って言われることが多い。特定の人だけでなく、いろんな人から言われる。別に最近作られたであろう資料でもないのに、何でだろうと思っていた。作った資料はサーバー上に置いておくっていうのが自分の中では普通であり、自分のパソコンにしか置いてないなんて怖くて(いつクラッシュするかわからないという発想)できない。なぜローカルにしか置かないという行動に出ているのか理由は分かってないけど、なんとなく文化の違いだけでないナニカが潜んでいるような気もするので、いつか理由に気付けるように意識しておこう。


p.44 リリーススプリント


p.45 スプリントプランニングでは、期間内で何ができるか、どうやって達成させるかの2点をあきらかにする。


p.50 デイリースクラムは、朝会。昨日したこと、今日やること、スプリントのゴールの達成の障害となることを説明する。特に困りごとや不安に感じていることを積極的に発言する


p.54 スプリントレトロスぺクティブは、仕事の進め方を改善する。ふりかえり。


p.55 改善案は、いつどこで誰が何のアクションをとると困り事を解消できるかと具体的に話し合う。


キックオフ、朝会、振返り、KPT。これらはよほどの理由がない限り実施しようと心がけていたし、自分が考えていた、感じている狙いと同じようなことが書かれていたので、保証してもらった感覚になった。カタカナはよくわからないので、本で書かれているスクラムでの呼び方には慣れなさそうだけど、そんなことは全然どうでもいいかな。保証してもらった分、ますますちゃんと実行していかなければと思えた。


参考リンク


参考になるリンクが結構貼られていたので時間を見つけて読んでみよう、やってみようと思う。


Scrum Pattern Community http://www.scrumplop.org/

Pattern Writing Sheet | CreativeShift http://creativeshift.jp/sheet/

スクラムの基本概念から拡張Tipsまでを俯瞰できる、「非公認スクラムチェックリスト by Henrik Kniberg」 を更新しました。 - kawaguti の日記 (id:wayaguchi)http://d.hatena.ne.jp/wayaguchi/20111001/1317477673

継続的Webサービス改善ガイド:特集|gihyo.jp … 技術評論社http://gihyo.jp/dev/feature/01/webservice-guide

「「技術的負債」を問いなおす」というタイトルでJAWS DAYS 2014で話してきた #jawsdays - Kentaro Kuribayashi's bloghttp://blog.kentarok.org/entry/2014/03/15/224227

すくすくスクラム | Doorkeeperhttps://sukusuku-scrum.doorkeeper.jp/

スクラム道http://www.taoofscrum.org/contents/

POStudy 〜プロダクトオーナーシップ勉強会〜http://www.postudy.com/


💡今回の学び


実務をこなした経験から学ぶ、スキルを伸ばすという事も大事だけど、やはり書籍から改めて学ぶというのも大事だ。自分の経験則からの学びを裏付けることができるし、よりより方法を学んだり、さらに幅を広げることも出来る。かと言って書籍だけに頼るのもおかしく、ただの頭でっかちの口だけ野郎になる。このバランスの大切さを学んだ。


👣明日への一歩


ベロシティ関連。振返りを定量的に出来るようにしてみよう。


なにかひとつでも気付きがあれば「MeetUp大阪@FBページ」に「いいね!」をお願いします。

posted by @komeshogun at 10:17 | Comment(0) | TrackBack(0) | @komeshogun | このブログの読者になる | 更新情報をチェックする
なにかひとつでも気づきがあれば、Facebookページに「いいね。」をお願いします。