僕もいい歳してオタクなのでオタクな絵をSNSで眺めてたりしてるんだけど、そういうオタク界隈でよく絵師さん(イラストレーターさん)が描きかけで没になった自作の絵を「供養」と称してTwitterに晒していることがよくある。
で、このブログ記事も趣旨は割とそれに近いもので、僕の昔の仕事を供養するためのものだ。
といっても大昔で、2002年頃、社会人3年目に自分が書いた資料が最近部屋の中を整理してたら出てきた。僕は当時東芝の研究所にソフトウェア工学の研究者として勤めていたのだけど、それは東芝の社内に適用するために考えた独自のソフトウェア開発方法論の提案だった。
んでそれを見たら、めちゃくちゃびっくりしてしまった。
まぁ20年前に没になったものなんで公開しても問題なかろうと思うので公開してしまうが、タイトルは「確認を取るソフトウェア開発」というものだった。
で、その提案内容なんだけども、
- 開発プロセスのどの工程かに関わらず、session(インタビューや話し合い、報告)とwork(作業)を繰り返す
- 開発項目や課題はカードに書いて、カードごとのステータスで進捗を管理。ステータスはsession時に更新して、「確認」になったらその項目は終了
とある。
それで今、僕は業務でスクラムマスターをしているのだけど、その視点で見ればこれはびっくりするほど今どきのスクラムをやってるのである。
1つめは原始的なスプリントぽい何かだし、2つめは今見るとプロダクトバックログをカンバンで管理するのと事実上変わらない事を言ってて、今どきのアジャイルで採用されている各手法とエッセンスとしては大して違いはない。もちろん細部は違うけど。
スクラムとの大きな違いはウォーターフォール型の開発を念頭に置いていたことだ。だって当時はアジャイルといえばXPが出てきたばっかりで、東芝のような大企業が採用するようなものとはみなされていなかった。東芝が社内でアジャイルを採用し始めるのはこの10年くらい後の話である。
で、アジャイルは基本的に反復型開発を前提にしていて、1スプリント内で設計も実装もテストもやってしまうことを想定しているけれど、僕のこの提案手法はそうではなかった。ただ、設計やって実装やってテストやって、という長大なプロセスを何ヶ月もかけてやったとしても、設計工程も実装工程もテスト工程もブチブチに短く切ってしまって、短い間隔でsessionとworkを交互に繰り返すことで管理すれば良いと考えた、ようだ。当時の僕は。
長いプロセスをかけて作った場合の要求とと成果物に大きな意識のずれが生じるのが問題だと僕は考えていたので、間を細切れにして、その都度話し合いをして齟齬を修正してなくしてやればいいのでは、って考えた、ようだ。資料を見返すと。
当時バックログもカンバンも知らなかった(てか、バックログって当時なかったかも?)のに、ワイやるやん。筋は全然悪くなかったやん。
……などとつい自画自賛してしまうと同時に、自分みたいなのが独立して考えても同じような思想に行き着いたのだから、結局ソフトウェア開発は、同じ問題意識を持つ人間が真面目に考えたら誰でも今どきのスクラムのような形になったのかもしれない。
そういう意味では、現代のスクラムはそうなるべくしてなっているのかも。
僕はこの発想は当時出てきたばかりのアジャイル開発ではなく、梅棹忠夫氏の京大カードをソフトウェア開発に応用できないか、という辺りから着想したようだ。ソフトウェア開発で発生する課題とそれを解決するためのコミュニケーションを円滑にするために使える、と当時の僕は思ったらしい。
というので、関連書籍として京大カードの本を置いておく。
あと京大カードは直接関係なかったかもしれないが、一緒に当時読んでたカードに関する本。部屋を整理したときに一緒に出てきた。
でもボロボロだったので、捨ててさっきKindleで買い直した。