プロジェクトの成功とは？

先日、社内で

プロジェクト成功の定義は？

という議論をしました。

アジャイルやリーンとしては「価値提供」かと思います。

素早く、価値を提供出来る事が成功かと。

これをもっと具体化した目標値が達成出来れば、

成功かと思います。

議論では、

問題があっても対応出来ていれば成功

イテレーションが回せていれば成功

などなど。

どれも成功だと思いますが、

議論になるという事は、

成功基準をプロジェクト開始前に決めていない証明でもありますね…

しかし、プロジェクトとしては成功しても、

エンジニアとしては納得行かない点も多くありそうですね。

あそこは、あーしておけばよかったー

とかとか

設計視点や、コード視点など、

それぞれ視点を変えると、後悔が無い事の方が少ない気もします。

プロジェクトとしての成功

個人としての成功

などなど、複数の定義はあってイイ気がしますね！

しかししかし、改めて考えると目標達成と後悔は違いそうですね。

目標は達成しても後悔する事はありそうです。

目標値はあくまで目標値で

完璧な仕事というか、完璧な業務というか、

後悔のない仕事というか、後悔のない業務

は難しいですね。

改めて、

目標以外の視点で「ふりかえる」事も大事ですね。

身近なものからハカる

最近、お気に入りの言葉です。
「身近なものからハカる」

昨今のソフトウェア開発では、静的解析ツールがだいぶ進化し、
ツールの種類も選べる状況にありますが、
そんな状況でも、あまりハカる習慣は無い気がします。

日々の業務において、身近な事、物をお手軽にハカる事で
当たり前ですが、現状が見える化できます。

そして、もう一つの鍵は「量」です。
「質」をハカるのは難しいので、まずは「量」からハカる。

しかしながら、量も細かくなっていくと、質に近くなります。

例えば、ドキュメントの量を測るとして、
最初は、大まかなページ数から宣言し
徐々に、ページ内の記載項目数や表や図などと
細かく宣言していけば、
1ページ内の項目数が分かると、1項目の大まかな粒度が分かります。
粒度は質に関係します。

正式なドキュメント以外でも、ちょっとした調査でも
メモ程度は残す事が多いと思います。
すると、それはドキュメント同様にハカれます。

メモを残さない場合でも、何をどのくらい調査するかは
ハカれると思います。


更に、それを宣言すると、より多くの気づきを得らると思っています。

身近な事、物の量を宣言して結果を比べる。

今日は何をどのくらい作成する
と宣言し、結果、どのくらい作成出来た　
とふりかえり、結果を検証するのではなく、次の宣言に生かす。

これを繰り返すと「量」の意識が徐々に「質」になっていくと考えています。

質を意識する為にも、
身近なものから量を宣言する！

勘の見える化

先月のSWEST19にて大収穫がありました。

失敗プロジェクトのほとんどが開始時に失敗しそうな事がなんとなく分かる
という議論の中で、
「なぜ、分かるのか？」
「それは経験と勘」という事になるのですが、

議論はここで終わるのではなく、ここからヒートアップします。
勘は、経験に基づく根拠が必ずある筈。
そして、失敗しそうと感じる、きっかけや違和感が必ずあった筈。
そのきっかけや違和感を感じた後どーした？

それを放置したから失敗したのでは？！
しかも、違和感を感じるのは1度では無い筈、
ヤバイと気づいた時にはリカバリー出来ない状態だったのでは？！
と、大先輩から突っ込みが...

ぐうの音も出ません....

育成の為とか、なんとか理由をつけたりしますが、
放置していた事には変わりなく....

そして、クライマックスは、

違和感を感じたら、何か勘が働いたら、
それをそのまま放置せず、
それを追求して伝える事、見える化する事がベテランの役目では！

と、大先輩からお叱りを受けました...

しかし、しかし、これは大収穫です。

勘をキチンと伝える。
つまり、伝えられるように考えて行動する。

改めて、具体化し、見える化して、数値化して伝えていく事が
大事だと感じた瞬間であり、今も考え続けています。

その結果、今の2週間毎のふりかえり活動においても、
勘を仮説として数値化する事が可能だ！
という事に気づき、具体化を進めています。