先日、2013/3/23（土）に弊社でチケット駆動と開発環境に関するイベントを開催しました。リンク先には資料も上がっていますので参照ください（※アトラシアン製品関連のイベントです）。 基調講演にはチケット駆動開発を推進されている関西XPUGのあきぴーさんをお招きして「チケット駆動開発をパターン言語で読み解く」という話をしていただき、最終枠ではパネルディスカッションをしました。 チケット駆動開発とウォーターフォール パネルディスカッションでは、僕が「チケット駆動開発を作業計画に使うのは難しく、WBSとの併用が現実的」と話し、あきぴーさんが「作業計画をチケット駆動開発で回していくには」というノウハウを紹介されていました。 この違いは僕がウォーターフォール的な新規案件を、あきぴーさんがアジャイル的な開発/保守運用案件を前提にしているためです。 僕自身はBTS（Bug Tracking Syste

ちょっと大人数で行うプロジェクトに参加したことがある人なら、WBS (ワークブレークダウンストラクチャー) を目にしたことがあるだろう。 日本語だと作業分解構成と説明されることが多い。Work(作業) Breakdown(分解) Structure(構造) というわけだ。日本語の説明では、そういう説明が主流のようだ。 でも、WBS の Work は実は作業ではない。 WBS を定義した標準の最新版MIL-STD-881Cを見てみると、"A product-oriented family tree composed of hardware, software, services, data, and facilities." 「WBS の定義は、ハードウェア、ソフトウェア、サービス、データ、設備などからなる成果物指向の分解ツリーである。」 ここでいう Work は、成果物のことだ。Workb

※インテリジェントネットではWBSを引いたり、WBSに沿って一緒にものづくりをする仲間を募集しています。詳しくは【インテリジェントネット採用情報】をご覧ください。 先日、当社インテリジェントネットにてフリーランスとしてご活躍されているd-threeの大崎さんをお招きして社内勉強会「WBS講座」を開催しました。 ほぼ全員参加だったため、全くWBSやスケジュールをひいたことのない初心者もいれば、日頃から中～大規模サイト構築案件のディレクターとしてWBSをひいてプロジェクトマネジメントをしている中級者（どこまでが中級者でどこからが上級者かわかりませんが）まで幅広いメンバーが参加しました。初心者向けのレポートは新人ディレクターがアップしますので、このエントリでは中級者向けのレポートをアップしたいと思います。 そもそもWBSとは？ 「Work Breakdown Structure」です。ここまでは

システム開発の現場ではおなじみになりつつある振り返り。 実際にやってみると 「何かが足りない・・・。何故か上手くいかない・・・」 というケースは無いでしょうか？ 実は振り返りとともにもっておくとことが好ましい思考法が不足しているのかもしれません。 振り返り手法 まず振り返り手法について考えます。 振り返り手法には様々な手法があります。 PDCAサイクル - Wikipedia 自律的に現場を改善できるチームをつくるための「ふりかえり」の進め方 〜 KPTと進め方のノウハウ | Social Change! はてなインターンの振り返りをYWTを使ってやってみた - だいくしー(@daiksy)のはてなブログ OKR (目標と主な結果) – 前田ヒロ 1 on 1 で 何を話すのか？ マネージャ/ソフトウェアエンジニアの立場から - サンフランシスコではたらくソフトウェアエンジニア - Hig

こんにちは。ざっくんです。 最近は記事の更新頻度がめっきり少なくなっていました。その辺の、習慣化なのか自制・意志の強さなのかとかの振り返りはまた今度記事にするとして。 今回は前々からまとめようと思っていた「振り返りツール」的な奴らの話をしたいと思います。いろんな種類があって、どれがいいの？とかってなることが多いと思うので自分の中の整理も兼ねて。 この記事の要約 ◆それぞれのツールをいい感じにまとめるとこんな感じ 概要 思考(実行)の流れとの対応 ◆「こんな時はこれを使え！」ってやつははっきり言ってない。目的に合わせてカスタマイズして使うといいと思う。ただまぁ一応、オススメの使い方はこんな感じ。 毎日の個人の振り返り：YWT+経験学習モデル+α イベントの運営振り返り：YWTかKPT イベントでの参加者の学びを深める振り返り：経験学習モデル+グラフィックハーベスティング チームの改善：KPT

ところで私は、かつて「手を動かさない人」でした。 仕事にせよ、勉強にせよ、創作にせよ、音楽にせよ、どんなことでも「ごちゃごちゃ考えているより、まずやってみて場数をこなした方がスキルは育つ」というのは、大体の場合で当てはまる普遍的なセオリーであると思います。 ゲーム開発、アプリ開発なんかでも、実績を残している人はみんな「いいからまずやってみろ」って言いますよね。 手を動かすこと、超大事です。手を動かすことによって、課題が生まれ、自信が生まれ、ノウハウが蓄積されていく。頭で考えているだけでは何も始まりません。考えたものは、出力しなくてはいけません。 ところが、世の中には「手を動かさない人」がいます。取り敢えずやってみろ、というアドバイスを受けつつも、なかなか「取り敢えずやってみる」という実施タームに移れない、もしくは移らない人ですね。先日、Books&Appsさん内でもそれについての記事が掲載

前回たくさんブックマークをいただいた記事のトラックバックから 「Doingリスト」なる単語を見かけました。 どぅいんぐりすと？、、、なんじゃらほい？ 、、で、調べて出てきたのがこれ。 ■ゆっくりと動きながら高速でこなす、一流の研究者の Doing リスト | Lifehacking.jp ■今、そこにある未来：脳内バイパスを作る Doing リストの実践例 | Lifehacking.jp 「いま、なにをしているか」のリスト Doing リストって、「ToDo リストと何が違うの？」と言われるかもしれませんが、何も違いません。 誰しもが書いている、やるべき事を適度の粒度で書き込んでいるだけの単純なリストです。 ただし、その考え方に３つのポイントがあります。 １ 「今やっていること」がアンカーされていて、かならずリストから行動が生じている。 リストに書かれていない事はしてはならない。 ２ 途

何度か書いていますが、しんざきはシステム関係の仕事をしており、今はそんな大きくないチームの責任者です。自分でも色々作業しますが、一応マネジメントもする立場です。 今とはまた違うチームにいた頃、チームの統合・再編成が行われたことが何回かありました。 チームメンバーは増えたり減ったりしますが、大体毎度、新しいメンバーを何人かは見ることになります。 当たり前のことですが、知らないメンバーと一緒にやっていく際には、まずその人にどんなタスクを振るか、どうタスクを振るかを考えないといけません。 何か新しい技術に触れていくならどのようにスキルのキャッチアップをしてもらうか考えないといけませんし、引き継ぎがあるなら引き継ぎの計画を立てなくてはいけません。 だからチームの再編成の時には、本格的に仕事を始める前に、それぞれのメンバー、及びそれぞれのメンバーの以前の上司に必ず面談とヒアリングをします。いや、別に

長男(今年9歳)が通っている学校は、かなり宿題が多い学校のようで、低学年でもそれなりの量の宿題が出ます。当然、夏休みの宿題も結構な量です。 長男は、普段の勉強については特に苦労をしていないようですが、やはり小学生であって、計画的に宿題をするのは苦手です。 一年生の時の夏休みの宿題も、結局すべて片づけるのはかなりギリギリになっていたようで、8月下旬くらいに泣きべそをかきながら宿題をやっているのを観測しました。 小学校の宿題に親が口出しするのもどうかなと思いまして、一年の頃はあまり干渉しなかったんですが、ちょっとそれを見て反省というか、考えを改めました。 宿題の本来の意味は、「家庭での勉強の習慣を作ること」だと思います。それが機能しないばかりか、単に嫌な思い出ばかりになってしまい、机に向かうこと自体がイヤになってしまったら可哀想だなーと思ったからです。 そこで、2015年の夏休みは、多少干渉し