制作にもアジャイル思想は有効かも
技術畑の人には既に市民権を得た感じのある『アジャイル』ですが
クリエイティブな仕事全般的に結構使えるんじゃないかと思っています。
アジャイルとは(WikiPediaより)
ソフトウェア工学において迅速かつ適応的にソフトウェア開発を行う軽量な開発手法群の総称
てことで手法にばかり目が行きがちなんですが、要は素早くかつ柔軟に対応して合理的に
開発しましょうというやり方。
ちょっと昔の人にとっては仕様決めて設計書書いてその通りに作らなければ怒られて
一部機能に手直しが入れば不具合でない限りは「仕様変更」扱いでお金と工数を延々
絞りとるSIerの常套手段でした。
ま、それはさておきこの思想、いろんなやり方があっていわゆる「ベストプラクティス(経験則)」
を用いて最適な開発物を作っていくのですが、これをどう適用するのかというと幾つかある中で
この3つが最適ではないかなと。各イテレーションではそんなに作りこまなくて形になる一纏まりで一旦やめておくのが重要。
1)反復(イテレーション)
短いスパンで制作を進めて、そこで一つのサイクルにする。その上でレビューして修正が必要なところを決めていく。
2)ペアプログラミング
同じ画面を見ながらハンズオンでああでもないこうでもないとしながら制作を進めてみる。開発ではプログラミングだけど、デザイニングとか言っておくのが正なのかな?
3)レビュー(スプリントレビュー)
イテレーションの最後は必ず制作物のレビューを行い、次のイテレーションへの方針ぎめをする。
てな感じです。逆にアジャイルのベストプラクティスで合わないだろうなーと思うのが、スクラム会議です。一所懸命作って毎日行うスクラム会議(朝会的なもの?)で否定されたら制作意欲失うかも(笑)。

クリエイティブな仕事全般的に結構使えるんじゃないかと思っています。
アジャイルとは(WikiPediaより)
ソフトウェア工学において迅速かつ適応的にソフトウェア開発を行う軽量な開発手法群の総称
てことで手法にばかり目が行きがちなんですが、要は素早くかつ柔軟に対応して合理的に
開発しましょうというやり方。
ちょっと昔の人にとっては仕様決めて設計書書いてその通りに作らなければ怒られて
一部機能に手直しが入れば不具合でない限りは「仕様変更」扱いでお金と工数を延々
絞りとるSIerの常套手段でした。
ま、それはさておきこの思想、いろんなやり方があっていわゆる「ベストプラクティス(経験則)」
を用いて最適な開発物を作っていくのですが、これをどう適用するのかというと幾つかある中で
この3つが最適ではないかなと。各イテレーションではそんなに作りこまなくて形になる一纏まりで一旦やめておくのが重要。
1)反復(イテレーション)
短いスパンで制作を進めて、そこで一つのサイクルにする。その上でレビューして修正が必要なところを決めていく。
2)ペアプログラミング
同じ画面を見ながらハンズオンでああでもないこうでもないとしながら制作を進めてみる。開発ではプログラミングだけど、デザイニングとか言っておくのが正なのかな?
3)レビュー(スプリントレビュー)
イテレーションの最後は必ず制作物のレビューを行い、次のイテレーションへの方針ぎめをする。
てな感じです。逆にアジャイルのベストプラクティスで合わないだろうなーと思うのが、スクラム会議です。一所懸命作って毎日行うスクラム会議(朝会的なもの?)で否定されたら制作意欲失うかも(笑)。

地味であることを恥じてはいけない

ウチの会社では月末になると締め会なる会合があり
そこで各種表彰が行われます。
その月で目覚ましい成果を上げた個人やチームに対する
ものなのですが、正直わかりやすい功績のある人・チームも
あれば、地味だけど重要な役割を果たしているものもあったりします。
この地味な方はなかなか表彰で取り上げてもらうのは難しいのですが
どんな価値を出しているのかを自分なりに考えていることは
大事なんじゃないかと思います。
ルーチンワークの中にも当然価値はあります。
というか価値のない仕事をしている時点で、自分の仕事を
見なおさないとダメです。言われたからやっているのは
ハッキリ言って二流、いや三流かも。その仕事を正しく咀嚼して
意味づけできて二流。付加価値出して一流の仕事だと考えています。
昔コンサルタントのブログかなんかで読んだのですが、あるチームが
あってそれぞれのチームでの貢献率を%で出してもらった時に
チーム合計が100%を超えないところはヤバイって話。
主体的に取り組んでこそ、人生の大事な時間を削ってやる価値のある
仕事なんでしょうね。
てことで地味な仕事に付加価値を出して表彰されたらメデタシですが
表彰がゴールじゃないので、選に漏れても自信を持てる仕事を
したいものです。








