躓くことを前提とした仕事の仕方を覚えた(ような気がする)

今までのプロジェクトには正解があったのだ、と最近、ふと思った。

僕が経験してきたプロジェクトの大半は、既存システムの改修、もしくは既存システムにつながる新規システム開発だ。
技術はレガシーで、汎用機の上にCOBOLとNATURALという言語でアプリケーションをつくりあげる。

10年以上も続いてきたプロジェクトだから、お客さんとの付き合いもほぼ完成されていた。
もちろん、僕がそうであるようにお客さんにも新人さんが入ってくることもあったようだ。
しかし、10年も続いているプロジェクトでは、新しい風が既存の文化や慣習を吹き飛ばすことはない。
新しい風も、ゆっくりと、10年間で培われた文化と慣習に取り込まれてゆく。

技術も人間関係もレガシー、枯れていたのだ。
技術でも、人間関係でも枯れている良さというものがある。

それは、正解がある、ということだ。
技術にも人間関係にも本来的に、正解はないはずだ。
しかし、長い年月はないはずの正解を作り上げる。

技術にしろ、人間関係にしろ「本質的に正しいか」ということは横においておき、慣れが生まれ、決まりきった手順や方法が確立される。
その手段が最適か否かは横において、とにかくそこに到達することはできる、という意味での正解がある。

僕は今までそうした文化に親しんできた。
こうした文化に親しむ利点はもちろんある。

それは注意深く、テストでもするかのように慎重に行動する習慣が身につく、ということだ。

汎用機の開発をしていると、早く動かして早く間違いを発見して修正する、というアプローチは取りづらい。

むしろ、最初からバグを含めないように、仕様に過剰な誤りがないように、慎重にチェックをするアプローチを取る。
良くも悪くも一発勝負、という感覚があるからだ。

なにかやるにしても「これで間違いはないだろうか」という思考が強くなる。

デバックはかなり手間なので、バグをそもそも含めないように、頭と紙の上でロジックを整えてから、プログラムを書いてゆく。
インテリセンスなど聞かないので、打ち間違えないように慎重に打ち込んでゆく。

また、ロジックもエラーから潰してゆくことを第一にプログラムを書いてゆく。
インプットで予想されるエラーをすべて潰したあとで、業務のロジックを追加してゆく。

便利なデバッガ、ユニットテストツール、構成管理ツールが存在する現在のプログラミングとは真逆なアプローチだ。

ひるがえって、今のプロジェクトは、躓くことを前提として行動することが要求される。
今まで使ったことがないアプリケーション、開発に携わっていないシステム、僕が把握できていないことがたくさんある。

こうした状況では正解、「こうすればたどりつける」という確立された方法はない。

お客さんはそうした状況に僕がいることは知らない。
そして、もし知っていたとしてもそんなことは関係ない。

だから、お客さんが要求を出すペースは変わらないし、僕は可能なかぎり応える必要がある。

お客さんの要求に対処するには、答えにたどり着ける確実な方法をつくってからとりかかろう、今までのアプローチは役に立たない。
確実な方法がわからないからできません、という応答をお客さんは期待していない。

自分としても、やったことがないことをやる前に「正解」を作りあげることは不可能だ、ということに気づく。
とりあえず、ほとんど何もわからないけど、とりあえず着手する。
もちろん、最初は何から手をつけて良いかわからないし、当然、失敗する。

どこでつまずくかわからないけど、自分がつまずくことはわかる。

だから、DBもプログラムもバックアップを取っておく。
もとに戻せることが約束されていばなんとかなる、そう思って先に進む。試してみる。

わからないことは、ネットで調べたり、人に聞いたり、知る方法はいくらでもある。
失敗したり、戸惑ったり、解決まで結論が二転三転したり、というつまずきを前提に行動しないと、結果を出すことはできない。

僕が以前、アジャイル開発の現場に行ったときに戸惑ったのは、実は、この点だったように思う。
周囲の人びとの作業が軽やかに進むのを横目に、僕の作業が進みづらかったことがある。
その原因は、事実、知識も経験も不足していたことにもある。
が、それ以上に、「つまずくことを前提に行動していなかった」点にあると思う。

おそらくあのプロジェクトのなかで、それぞれの人達にとっても、経験したことがないこと、知らないことがたくさんあったはずだ。
あのプロジェクトなかでも、チームに貢献していた人たちは、自分の知らないこと、わらかないことにも、ちゃんと挑戦していた人たちなのだと思う。

現在進行形の技術を用いながら、現在進行形のプロジェクトに携わるというとは、多くの未知な要素に関わるということだ。
そこでは確立された手法、正解をなぞることは、ほとんどできない。

むしろ、そうした方法を手探りで探してゆく、創り上げてゆくという態度と考え方が重要だ。
その根底にあるが、失敗やわからないことによるつまずきがあることを「当たり前」と考える心構えだ。

最近、新しいプロジェクトに携わるなかで、つまずきながらプロジェクトの進める心構えと方法を、僕は学んでいる。

広告

コメントを残す

以下に詳細を記入するか、アイコンをクリックしてログインしてください。

WordPress.com ロゴ

WordPress.com アカウントを使ってコメントしています。 ログアウト / 変更 )

Twitter 画像

Twitter アカウントを使ってコメントしています。 ログアウト / 変更 )

Facebook の写真

Facebook アカウントを使ってコメントしています。 ログアウト / 変更 )

Google+ フォト

Google+ アカウントを使ってコメントしています。 ログアウト / 変更 )

%s と連携中


%d人のブロガーが「いいね」をつけました。