コードが神様ならエンジニアは創造主になり得るか

on

モブプログラミングでは、タイプするエンジニアに周りのモブが憑依しつつコードを書いていく様はまるで神が降りてコードを創造しているのではないかと思わなくもないけれど、コードが神であるという考え方はモブプログラミングに陽の目が当たる歴史以前の、ドキュメントがコードの仕様と同期されていないような石器時代に作られたシステムではずっとコードが神様だったのです。

 

それは動いているコードを信じるほか選択肢がないということであり、信じられるオブジェクトとしての対象がコードしかないから。動いているコードとコードと違う仕様が書いてある仕様書を並べてどちらを選ぶかをエンジニアに踏み絵させれば、誰ひとりとしてコードと違う仕様書を選ぶことはないのです。誰もがコードを選ぶ。動いていないドキュメントを信じるエンジニアはいないのです。

 

じゃあ、その神であるコードは誰が書いたのか。

 

エンジニアが書いたことは歴然としているのに、その動くコードを創造しながらエンジニアはコードの創造過程である仕様書についてはいい加減だった。つまり、コードの創造主である神はズボラであった。

 

コードは動く動かないが明確に誰がみてもはっきりと結果を確認できるためにコードの創造主であるエンジニアは心底リソースを投下し熱心にコードを創造するのに、コードの素材となる仕様については記録を残すことさえ煩わしいと思っている。

 

挙げ句の果てには、素材を手に入れることさえ煩わしいと口を開けてパクパクしているだけだ。

 

このようなエンジニアがモブプログラミングをしたらどうなるか。契約のあるシステム開発で。ディスプレイの前で、タイプするエンジニアに憑依しようとしても仕様となる素材を自身で手に入れることもできないから結局、何もコードを創造することもできずモブプログラミングはダメだと一方的な態度をとるのではいか。

 

新しいことを取り込むことは、現状の文化を変えていくということに結びつく。何かを変えたいから外から今ここにないものを持ち込むのだから。

 

難しく考えずにやってみる方が得られるものは多いけれど、そうした新しいものを取り入れ、許容し、現状の文化に混ぜて使うための労力を厭わないだけの腹づもりは必要で。

 

モブプログラミングは一つのツールであり、システム開発のある一部分の置き換えであるということを踏まえ、そのパーツを嵌めたときにどこに影響するかまで見極め、変えていくくらいは頭の片隅に置いておくと良いのではないか。

 

プログラミングではないが、モブでディスプレイを共有しながらコンテンツをモブで作ったときに感じたことは、モブは教育、技術移転、コンテンツの背景の共有、コンテンツの考え方の同期、コンテンツを割り振るときの完了定義、スケジュール共有までその場でできてしまう。

 

これはとても強力なツールであることを確信した瞬間だ。

 

確信した瞬間だけれども、たぶん、モブの技量的な関係が1:Nの1が強すぎるとNが従ってしまい一方通行になってしまう嫌いがあるのでNとなるモブなのか1となるモブのマインドが鍵なのかもしれない。