冒険とホントの勇気とロマンティックと

あんたにも今あらためて振り返ってみると違う光景が広がる曲ってあるかい？

特にガキンチョの頃に聞いていた曲ってのは、今味わい直すと本当に違う光景が広がったりするもんだよな。
いやあ、歌は良いね。リリンの生み出した文化の極みだよ。

で、実際になんで違う光景が広がっているのかって考えると、ちっと妥当な言葉がすんなり出てこない。
経験とか世の中に対する理解だとかってジャンルの言葉にはなるんだろうが、なんか微妙に違う香りがそこに混ざっている気もするんだ。

今回は、この香りの正体について考えてみる回だ。

ちっと一緒に記憶のタイムカプセル開きに行ってみようぜ。

ロマンティックをもらうために必要なもの

今回このことを書こうと思ったきっかけをくれたnoteがあるんだ。

川口さんはドラゴンボールのアニメ初期のエンディングテーマである「ロマンティックあげるよ」を振り返ってくれている。

まあ、読んでみてよ。エモいぞ。えらく。

読ませてもらって強く感じたのが、今の世界は「冒険よりも計画を求めている」と自分が感じていることだった。

かつての俺たちは世界のことをなにも知らないで、そのことを知りたくて冒険したくてウズウズしていた。
ところが、世の中がヒトとの約束で成り立っている以上は、俺たちの行動には結果を当然のように求められる。

そらそうだ。俺の作業結果が得られる前提で俺の仕事相手はまた別の誰かとの約束を守ろうとしているんだから。

その事実を理解した俺たちは、冒険に対して「ウズウズ」ではなく「畏れ」を感じるようになる。

「ウズウズ」という感情のままに動くエゴを突き通すだけの理由を見いだせなくなっているって言い換えても良いのかもしれない。

つまり経験という言葉に混ざっていた香り。
そいつは「約束」ってことになるのかもな。

システム開発と冒険

で、俺の場合はシステム屋なので、システム開発って現場での計画と冒険について考えてみようと思う。

今の世の中は変化の速度が上がってきているとは言え、依然としてウォーターフォール型の開発が主流なのは間違いない。

ウォーターフォールってのは、要するに業務分析をして、どんな機能が必要かを決定し、その設計を作成し、その設計通りにプログラムを作り、設計通りに動いているかテストしてリリースするって言う、文字通り水が上流から下流へと流れるがごとくに進んでいく開発手法だ。

当然、そこには綿密な計画があり、その計画との差異を開発し続ける中で常に監視し、異常値が見つかったならば原因を調べ、対策をうち、その効果を再度測定する、という実に「仕事っぽい」作り方だ。

ところが、このウォーターフォールには弱点がある。
時間がかかりすぎるってのもその一つだけれども、俺の中で最もでかい弱点は「そもそも何をシステムとして作れば良いのかを判断できるヒトはこの世にいない」ってことだ。

システムづくりってのは工数を突っ込んだなりにものが出来るので、机上で考えるだけだと「あれも欲しい」「これも欲しい」となってしまって、全然使われない機能がてんこ盛りになるってのはよくある話だ。

つまりさ。
誰もシステム開発の入口である「欲しい機能」ってものを選定するにあたって「冒険」してないんだよ。

でも何を機能として作ればいいかの答えを誰も持っていない以上は、「冒険」は絶対にいるんだよ。

じゃあ、どうするのか？
そこで現れてくるのがアジャイル開発ってスタイルだ。
本当に最低限動くためだけのものを作って、実際にそれを運用で使ってみて、改善ポイントを現場から吸い上げて継続的に開発していくってやり方だ。

やってみるとわかるけれども、このやり方だとメチャクチャ日々が冒険の連続になる。
システムを使うヒトが言ってきたものを作るだけじゃなくて、それをどうすれば効率的に進められるのか、はたまたその使うヒトが言っていることが本質を捉えているのか。
そんなことを喧々諤々になって進めていく日々だ。

しかも時がたつに連れ、その冒険の日々に関わる人はどんどん増えていく。
ホントの勇気を試される日々に巻き込まれるヒトがどんどん増えていく。

なあ、あんたはどう思う？

俺たちはこの冒険の日々に身を投じる「ホントの勇気」を見せることでロマンティックを手に入れられるんだろうか？