や、当たり前のことではあります。しかしながら、プロセス定義書やPFDを作っていると案外はまってしまう点なのかもしれないと感じました。プロセス定義書やPFDを作る時は「プロセス」を中心に記載するため、頭の中も「どうプロセスを組み立てよう」という状態になってしまいがちです。作るモノも一緒に考えながらプロセスを組み立てるのであれば尚更です。プロセスを定義する時は、プロセスが完了した結果、産み出されるモノ・成果物を強く意識した方が良いと考えます。

作るモノのフローを考えるのだから、PFDは「Process Flow Diagram」というより、ひょっとしたら「Product Flow Diagram」または「Production Flow Diagram」でもいいのかな、と思ったりしました。

これは計画や見積もりにも同じことが言えると思うのです。また、機会があればこれも考えてみたいと思います。

2014-07-02

達成できなかったTRY

Project Management 日記

プロジェクトでKPTによる振り返りを実施した時に、TRYの一部が達成できていない時はどうするか（続けるべきか）という課題に最近触れた。

アジャイルサムライのふりかえりに関する下記のような記述にもある通り、ふりかえりはできなかったことをつるし上げても価値は生まれにくい。

ふりかえりは魔女狩りじゃない

むしろ振り返ろうとする心を削いでしまうことが多い。
従って結論としては以下のような方針でやるのが良いのでは、という結論に至った。

できなかったものも含めてKPTして、TRYをもう1度出す
続けるかどうかはTRY次第
同じ目的でも別の方法でTRY

また、次のイテレーションではTRYのまず達成するアクションを決めてもらった。何も成果がない、という状態を防ぐためだ。アクション出せないなら、話し合おう、というのも伝えた。これもある意味でTRYだったかもしれない。
同じような課題にぶち当たった方々はどうしているのか聞いてみたい。

2014-06-26

組込みの現場とアジャイルの狭間で

アジャイル開発 Project Management

現在の僕の最大の課題は、どのように組込みシステムを、どのように組込みソフトウェア（F/W）を作り上げるか、という領域だと考えています。全ての組込みシステム開発が同様に作られているはずはないので、正確には現在関わっている組込みシステムをどのように作るか、かもしれません。

現在関わっているシステム開発方法も、水が下方に流れ落ちるように、様々な試行錯誤の結果としてあるわけで、過去から見ればきっと最善な方法であると信じています。しかし、まだまだ問題山積みであることと、なぜか悪化する方向に流れているような気がしてならない事があります。

アジャイル開発の一切の無駄を排除するような考え方やプラクティスを試行して、少しでも頑張らずに、楽しく開発できることを目指して活動しています。

2014-06-18

ふりかえりと信頼と

Project Management

「ふりかえり」に関して以下のような状況になったことがある。

「ふりかえり」に参加しているのだけれどメンバーがあまり積極的でない
アクションは決めたけれどまだできていないし「ふりかえり」またやるの？
形式的になってしまっていて良い意見を出す方向にならない

自分はメンバーの場合が多いのだけれど、司会でもそういう状態になったことがある。こういう時、多くの場合はそのチームに対してメンバーが不信感のようなものを持っていることが多いのではないかと感じている。このような場合、皆さんはどうしているのだろう。今まで体験したのは以下のような感じかな。

信頼おける外部メンバーにファシリテートしてもらう
人数が多い場合はグループ分けしてみる

また、上記は応急処置として効果があるとしても、信頼を厚くするにはどんなことをしているのだろう。ふりかえりの小さなアクションを共同で成し遂げる、とかかなぁ。

2014-06-14

アジャイルと自由、制約

Project Management

僕の妻は学校の成績は良くなかったらしい、が、新しいものへの抵抗感や知識を学習することに対する積極性はかなりある方だと思う。そして、なぜか今日は（少し前にも）アジャイルサムライの話になった。妻の職場の業界はSIとかなり離れているもののマネジメントで苦労しているらしい。そんな話を少し出力しておく。

「アジャイルサムライって前に話してたよね」
「そうだっけ、ソフトウェア開発の話だけれど他の仕事でも得るものが多いと思うよ」
「読んでみたい」

暫く他の話もしつつ…（ドラッカーとか）

「…自分の利益は何かを冷静に考えることができるのならば、社会にルールのような制約、ルールは必要ないものが多いように思うんだよね。例えば、道路の制限速度があるのは、本来事故を起こしたい人はいないはずなんだけど、人が本当は望んでいないのにも関わらず、速度を超えて走ろうとするから必要になってる」
「自動運転なんかもそうだよね、事故を起こさない技術がまだないから必要になる」
「社会が豊かになれば本来ルールは減ると思うんだけどなぁ」

のような流れ。（全て記憶していないのでだいたいの流れ）

そして話して思ったのは、プロジェクトもそうで、誰も望んでいないゴールへ向かうということが多々あるということ。そしてこの望まない流れを修正する方法として、流れを強制する考え方がプロセスをガチガチに固めるプロセス定義手法、「開発者も顧客もゴールへ向かわざるを得ない状態」にするのがアジャイルの手法なのかなぁ、と考えながら帰宅した。

それでは今日もおやすみなさい。

Thought about system by Hiroyasu Ishikawa

We are uncovering better ways of developing system.

タブ（インデント）を半角スペースに変換

Ruby 2.1.2 install on Ubuntu Linux

インストールの環境作り

rbenvのインストール

rubyのインストール

プロセスと成果物

達成できなかったTRY

組込みの現場とアジャイルの狭間で

ふりかえりと信頼と

アジャイルと自由、制約