本を読めるかどうか、という人生の指標
- 作者:窪 美澄
- 発売日: 2017/05/25
- メディア: 文庫
最近は、窪美澄と連城三紀彦の小説を読み漁っている。通勤時間には小説を、仕事中は仕事を早く終わらせて技術書や論文を、それぞれ時間を割り振って週に4〜5冊のペースで本を読んでいる。連城三紀彦『恋文』、窪美澄の『水やりはいつも深夜だけど』この二冊は限りなく完璧に近い小説だった。間違いなくオススメできる。僕の友人であったり、僕が書く文章を少しでも気に入ってくれている人がいるのならば、絶対に読んだ方がいいと断言できる小説だ。
そんなペースで本や論文を読む僕を見て、彼女は「活字に飢えてるね。もはや猟奇的だよ」と言う。確かにその通りだ。僕はストレスが溜まると狂ったように本や映画、漫画やアニメを消化し何かを補給しようとする。それは彼女の言う通り、まさしく猟奇的な程の衝動で、飢えという表現も相応しい。
きっと、現実逃避なんだ。何か活字や物語を消化して自分の中に取り込まないとこの物語性のない平坦な毎日に埋もれてしまうような、そんな焦燥感を僕は覚えている。意外にも、挫けそうになったり、挫けてしまった時にはそのような飢えは襲ってこない。自分でもそんなものを未だ残していたことに驚いてしまうんだけれど、辛い時や疲れた時にだけやたらと責任感や使命感のようなものが出張ってきて、辛さや疲れから離れることを許してくれない。僕はどうやら、辛くなる前や疲れていない時、つまり余裕が少しでもある内に出来るだけ現実逃避をするようにしているらしい。
転職面談の際「一番最近に読んだ本は何ですか」と問われ、僕は「銀河鉄道の夜です」と答えた。それが原因かどうかはわからないが、その会社の選考は落ちた。エンジニアとしては、技術書や自己啓発本を挙げるのが正解だったと思うし、一応の補足として技術書のタイトルもいくつか挙げた。相応しくない答えだったとは理解している。しかし、当時僕が最後に読了したのは宮沢賢治の銀河鉄道の夜であったし、そう告げることは僕にとって、企業に対する宣戦布告の意思表示でもあったのだ。
僕は、本を読めない程忙しかったり追い詰められたりする会社には絶対に入らない。今の会社は業務の役に立つ技術書ならば業務時間に読んでも構わないし、コアタイム外の時間に何をしようが成果さえ出せば構わない、なんならコアタイムの間にどこにいようが構わない、喫煙所でタバコを吸いながら作業をしてもいいとさえ言ってくれている。僕の上司や僕の同僚達は、僕にとってこの環境こそが給与や待遇よりもずっと価値のあるものであることをきっと知らない。何なら今の僕にとって、仕事先として重要なのは本を読めるかどうかの一点のみと言ってもいい。たとえ給与が多少下がったとして、自由に本が読める時間が増えるならば一向に構わない。それはまさしく僕のエゴであり、読書をすることでアウトプットの質が高まるなどとは決して約束出来ない。
このような環境が与えられ、僕がそれを本当に実行し始めたのはごく最近のことだ。別にそれでいいよ、と言われてはいたがいざ実行に移すとなるとどうせ批判が飛んでくるのだろうと悲観的に考えていた。だからこそ最近まで本気で転職を考えていたのだが、実際に業務時間内に本を読み、使える知識があればそれを共有するということをしていたら、その共有が批判されるどころか褒められるようになってきた。具体的にはこのブログに投稿した記事(下掲)を共有したり、すごいエンジニアの安井さんという方が発案されていたスクラム体験ワークショップ(下掲)をお昼休みに開催したりteam geekの宣伝をしている内に、なんとなくチームが上手く回り始めるようになってきた。そしてそんなことをしていたら会社全体に僕の存在が段々と認知されるようになってきた。
僕がソフトウェア開発について学んでいること - ここはクソみたいなインターネッツですね
まあ「あいつは何をやってるんだ?」というまなざしも多少はあるんだろうけれど、今のところ褒められることの方が多いので最早僕が今の会社を辞める理由も無くなった。こうなると転職活動もただの時間の浪費でしかなくなるので一旦ストップすることにした。
本を好きな時に読めて、またそれが認められるかどうか。僕はクオリティオブライフの重要な柱として、この指標を大切にしていきたい。そしてまた、そうしたことで気持ちに余裕を作り、大切な人との時間を優しさに満ちたものに保ちたいと、心から思う。
バグって言うな問題は構造の問題なんじゃないか
先日から友人のエンジニア達と、はてな界隈でバズっていた記事について話している。
提案:エンジニアに気軽に「バグ」というのはやめませんか? - worker experienceの日記
バズっていた記事とは上記のもので、簡単に言うと「エンジニアに"バグ"と気軽に言わないでほしい」という提案を投げかける内容だ。
ある友人は上記記事を「エンジニアのエゴだ」と断じ、ある友人は「バグって言われるとウッとなるから共感出来る」と言う。僕はどちらの気持ちもわかる。
たしかに、ユーザーや顧客からすれば正しくないデータを表示したり望んでいない挙動をするプログラムにはバグがあると思って当然である。それが仕様だとしても、そんなことはユーザーにとっては知らないし関係のないことだ。
要求の履き違えであったりビジネス要件認識のズレであったり仕様通りであったり仕様漏れであったり普通にバグであったり、システムがユーザーの思った通りに動かない原因は色々ある。でも、原因なんてことはユーザーには関係のないことなのだ。思った通りのものが得られない。それが何より重要なことなのだ。思った通りのものが得られないシステムに対し、それをバグや不具合と呼んでしまうことに罪はない。ほかに相応しい言葉を知らないのだし、それこそシステム面か仕様に踏み込める人間でないとそれがバグなのかどうかなんて分からないのだ。システムをわからない人に仕様を調べて指摘しろというのはエンジニアのエゴであるし、単に"バグ"という言葉を嫌うのならばそれこそ"ドラゴン"と呼ばせてみればいい。結局ドラゴン=バグなのだから、呼び方を変えたところで根本的な問題は解決などしないと思う。
しかし一方で、バグという言葉がいかにエンジニアを傷つけるかということも僕はよく分かる。痛いほど分かる。
バグを起こしたエンジニアのリアルな感情の流れ - ここはクソみたいなインターネッツですね
バグじゃないものをバグだと呼ばれることで、エンジニアは不要なストレスを感じる。またバグという言葉が横行することで本当に直すべきバグが隠れてしまうという話も納得がいく。どちらの気持ちもわかるエンジニアとしては、この問題の根本的な構造を改めて解きほぐしていきたい。
友人達との結論
面白いのは、何度か違う場所で違うエンジニアとこの話をしたけれど、出てきた結論が同じであったという点だ。
結局「エンジニアとその他」という認識か、あるいはそう認識させてしまう構造の問題じゃない?
僕らはいつもこの結論に至った。
例えばシステムとドメイン領域両方の理解をしたディレクター、あるいはプロダクトオーナーのような人間が居れば、エンジニアに"バグ"という言葉が伝わる前に一度咀嚼してもらえるはずだ。更に言えば、例えそういった役職がなくともビジネスサイドの人間とシステムサイドの人間にしっかりとしたチーム意識があれば、エンジニアではない人間もプロダクトに対してプライドや"自分ごと"意識が生まれているはずである。その場合「バグでないものをバグと呼ばれてムッとする」のはエンジニアだけではないのが自然だ。ビジネスサイドの人間とシステムサイドの人間がしっかりとパートナーシップを結べていないからこそ、此岸と彼岸というようにエンジニアとそれ以外を断ずることが出来てしまう。一つのプロダクトに対し、ビジネスとシステム双方を織り交ぜた強いチームが存在していれば、そもそも「エンジニアにバグと言うのをやめてほしい」というような話は出てこないはずなのだ。ネガティブに言っても「プロダクトのことをよく分かっていないのにバグと言わないでほしい」となるか、普通ならば「このプロダクトにはバグだと思われてしまう問題があるんだな」というポジティブな受け取り方になるはずなのだ。
こうした論理から、僕と友人のエンジニア達は、結局この問題は認識か構造の問題であると結論した。
僕の感想
けれども実際問題、そんなに強いチームが出来ていることなど稀だし、バグだー不具合だーと直接エンジニアに言ってくる人は少なくない。でもやはり僕は、それはその人のリテラシーや気遣いの不足が悪いというわけではなくて、そう思わせてしまうシステムに原因がある場合がほとんどだと思う。そしてシステムのことはシステムの人間にしか分からないこともあるのだから、柔らかく「どんなバグですかー?」とこちらから歩み寄る姿勢こそが必要なんだと思う。
殆どの人はエンジニアを傷付けるつもりでバグという言葉を使っているわけではないのだし、エンジニアがバグという言葉で傷付くかどうかを想像しろなんて酷だ。逆にわからないものをバグと呼んでいるんだという想像は容易なのだから、まずは余裕を持てる方が歩み寄り、最終的には互いの歩み寄りが行える構造を目指すべきだ。
全人類がTeam Geekを読めばいいのに
Team Geek ―Googleのギークたちはいかにしてチームを作るのか
- 作者:Brian W. Fitzpatrick,Ben Collins-Sussman
- 発売日: 2013/07/20
- メディア: 単行本(ソフトカバー)
僕はエンジニア二年目だか三年目だかの時に、先輩に勧められて一度この本を読んだことがある。その後しばらくして僕はリーダーと呼ばれるような立場となり、チーム開発や自分の仕事、世界そのものと自分自身をとても嫌いになるようなひどい経験をした。僕は鬱を理由にそれらのことから逃げ出して、逃げられるだけ逃げようと決めた。社会から、自分自身から遠ざかってしまいたい。当時はただその一心だった。そんな僕は、なんの奇縁か今再び似たような業界で、まさしく嫌悪していたはずのチーム開発をしている。
僕がこの本を改めて今読んだ理由は、チーム開発に対するトラウマを克服するため、また何故僕はあの時失敗し身も心もバラバラに散ってしまったのか、それを知りたかったからだ。そして僕は今それ以上のことを知った。この本が最高の本だということ。そして、死ぬほど苦しんだあの時期にこそ読むべき本だったということ。
当時は、一緒に働く人を信頼し、尊敬し、そして自身は謙虚であるべきだというこの本の願いや、その重要性を真の意味では理解できていなかった。断言する。Team Geekは単なる自己啓発本などではなく、地獄とクソをミックスして焼き上げたようなこの社会から自身を守り、また少しでもその地獄を歩きやすくする方法をまとめたガイドブックのようなものだ。僕はそれを知らずに、足裏を糜爛させながらトボトボと焼けた地面を歩いていた。少しすると当然脚は使い物にならなくなって、四肢を使い果たした頃にはもう手遅れだった。身体も心も社会や人間との摩擦で削られて、僕は僕の半分くらいを失ってしまっていた。
僕は元来、自己啓発本と呼ばれるような本はあまり好きではない。どうしても偉そうに講釈を垂れられている気がしてしまって、反発してしまう。それこそ流行の自己啓発本をいくらか読んで出て来た感想は「わかってるよ、うるせえな」という程度のものだった。それは今でも変わらない。偉そうに自己啓発本を読めと言ってくる人間も大抵嫌いだ。そういう奴らが彼らのいう大切ないくつかの習慣を本当に習慣付けているところを見たことはないし、何かを引き寄せているところも見たことはない。彼らは嫌われる勇気を持つのではなく、もともと自分のことしか考えていないから嫌われてもなんとも思わない。これからの正義の話をするのではなく、自分自身が正義であることを主張する。ああ、悲しい哉。本自体は偉大な本であっても、君はその本ではないし、その本を書いた人間でもない。その本を君から勧められたとして、何故僕が読む気になると思うのか。何故そんなにも無自覚に正しさを押し付けられるのか。というか大体あいつらは、一体いくつの習慣を身につければ気が済むんだ。何か自分が成長しているっぽいエビデンスとして自己啓発本を読んでいることなんて、君が無自覚だとしても、みんなが気付いているよ。それらしいものを消費できれば、もはやなんでもいいのだろう。
話が逸れた。信頼と尊敬の重要性を語るこの本を紹介するにはふさわしくない吐露だった。ごめんなさい。
ではなぜ僕がこのTeam Geekについてだけは自己啓発本ではなく(しつこいようだが地獄とクソとゴミと嘘を捏ねて叩いて整形せず焼き上げたようなこの恨めしい社会の)ガイドブックだと称し、わざわざ日記まで書いているのか。それは偏にこの本が人々に寄り添うものだからだ。上からものを言うでもなく、正しさを押し付けることもない。この本に書いてあることは、著者らの痛み、こうしたらなんとなく上手くいったという経験、痛みを繰り返さないように気をつけていること。基本的にこの三つに終始する。それを主張や説教などという強いスタンスに乗せるのではなく、読者に対する親しみを込めた語りかけという優しさに乗せている。寄り添うというのはこういうことだ。不思議な世界に連れて行ってくれる本や、ドラマティックな日常に巻き込んでくれるような本、正しい道を歩ませようとする本、反骨精神を呼び起こしてくれる本。たくさんの本を読んだけれど、僕はこんなにも友人と話しているような気分にさせてくれる本に出会ったことはない。
この本が多くの人に読まれ、皆が皆生きやすい社会を作る一員となってくれると僕は嬉しい。そして僕も、その社会の中で車輪となるのであれば本望だ。
僕がソフトウェア開発について学んでいること
はじめに
たまにはエンジニアらしいことを書こうとしてまとめていたことが、あまりに長くなったのでqiitaに投稿することにした。
マルチポストになってしまうが、本来の目的であるここにもそれをまとめておこうと思う。
おわりに、に書くつもりではあるけれど、僕はコンピュータサイエンスを学んできたわけでもなく、文系出身であり、勉強も不十分なのです。
間違いなどがあればご指摘ください。
目次
1. 前提知識
1-1. ソフトウェア工学の概略
ノイマン式コンピュータが生まれた1940年代から、ソフトウェアに対する社会的な需要は爆発的に拡大した。しかしそれまで存在していなかった「ソフトウェア開発」というものに対する経験や知識は当然成熟しておらず、需要に対する開発速度及び品質の低さが問題となった。その歴史的文脈から1960年代にソフトウェア工学という工学が生まれ、ソフトウェア開発に関する技術が研究され始めた。
ソフトウェア工学の中で、様々なソフトウェア開発方法論(SDM)が発明/定義されていった。構造化プログラミング、オブジェクト指向プログラミングなどの考え方及び技法がこれに当たる。
SDMの研究と共に(正確には相互的に内包された研究として)、システム開発ライフサイクル(SDLC)という概念が生まれた。これは開発計画から設計実装運用保守、そして廃棄までの過程を標準的なモデルとして示したものである。
以下、条件付けせずにライフサイクルモデルと記載した場合、SDLCについて言及したものであるとする。
参考資料
1-2. ライフサイクルモデル
以下、代表的なライフサイクルモデルを列挙する。
ウォーターフォールモデル
システム開発における各工程を、水が流れるように順序立てて進めていく開発手法である。
基本的に工程を後戻りさせることはせず、下記のような流れでシステム開発を進行させていく。
(引用元:http://sysdev.sakura.ne.jp/development/169)
また、昨今ではウォーターフォールはV字型の図で解説されることが増えた。
内容としては同一で、どの工程がどの工程へ対応しているかを強調する目的で表現を変えているだけのものである。
(引用元:http://sysdev.sakura.ne.jp/development/169)
メリット
- プロジェクト計画の見通しを立てやすい
- 要求定義/要件定義及び設計が先に完了するため、開発者の迷いを減らせる
- 適用開発例が多く、参考になるプロジェクトが多い
- 各工程での成果が明確になる
- 進捗管理がしやすい
デメリット
- 全工程を予め定義/作成しなければならないため、プロジェクト計画立案自体にコストがかかる
- 工程を後戻りさせることを想定させていないため、仕様変更があった際に多大なコストが生まれる
どのようなプロジェクトに向いているか
- 要求/要件/目標が固定されており、途中変更のないプロジェクト
- 予め全ての要求/要件/条件/期間/工程/責任を定義しなければならないプロジェクト
- 発注/受注案件など。
- 何が出来ていれば成約か、特に相互の責任を明確にすべき場合
- 発注/受注案件など。
- 期間的制約の強いプロジェクト
プロトタイプモデル(反復型)
プロトタイプモデルと呼ばれる開発モデルは、しばしば手法としてのプロトタイピングと混同される。
ここでは一般にプロトタイプモデルと呼ばれる開発モデルと、プロトタイピングを利用した開発を分けて考える。
まず、一般にプロトタイプモデルと呼ばれる開発手法の例を挙げる。
一般的なプロトタイプモデル
- 立ち上がり期に機能を制限した実際の製品のプロトタイプを開発し、ユーザによる評価を受け機能追加/修正していくという手法
- 純粋なプロトタイプモデル(反復型)といえる
(引用元:https://thinkit.co.jp/article/914/1)
純粋プロトタイプモデルのメリット
- 計画立案時に全ての要件を作成するコストが発生せず済む
- ユーザとの認識のズレを最小限に留めることが出来るため、手戻りの際のコストが(ウォーターフォールモデルに比べて)低い
- ユーザ自身が当初想定していなかった要求に気づく機会がある
- ユーザがコア機能を早期に利用できるようになる
純粋プロトタイプモデルのデメリット
- 画面数や機能が多いプロダクトの場合、プロトタイピング工数自体がコストとなる
- 当初に要求/要件を明確にしないため、ユーザが満足するまでプロジェクトが完了しないリスクがある
- 付随して、プロジェクト全体の見通しが立てづらい
- 評価者(ユーザ,ステークホルダ)の人数により、評価工程のコストが大きくなってしまう場合がある
- 評価者の選定が難しい
どのようなプロジェクトに向いているか
- 比較的小規模なプロジェクトに向いている
- 期間的制約の弱いプロジェクト
- 対象ユーザの課題が深刻であり、すぐさま改善を進めていきたい場合
- ユーザ自身が課題をどう解決していけば良いのか見通しが立っていない場合
- 評価者(ユーザ,ステークホルダ)が少ない場合
プロトタイピングを開発工程に取り込む例
- 上と同様、機能を制限したプロトタイプを作成するが、要求/要件定義をする目的としてプロトタイプ利用し、その後本設計を開始するという手法。他の手法と併用される場合。
要件定義のためのプロトタイピング利用手法
要求に対する提案のためのプロトタイピング利用手法
(引用元:http://f.hatena.ne.jp/teeeeeeemo/20180220175918)
プロトタイピングの目的
- ユーザとベンダの間に想定のズレがないか早期に検知する
- 要求/要件の妥当性の検証
- 技術的実現可能性の検証
スパイラルモデル(反復型)
ウォーターフォールモデルとプロトタイプモデルを併せた開発手法であると言われる。
しばしばプロトタイプモデル、インクリメンタルモデル(後述)と混同して語られることがあり、それらとの違いは理解が難しい。
特徴としては、システムを複数のサブシステムに分割し、サブシステム毎にウォーターフォールモデルで開発を進めていくという点。
サブシステム毎にプロトタイプを作成し、その後ウォーターフォールモデルで開発を行うという形。
また、サブシステムの要求定義から評価(テスト)までを反復する点にも注目しておきたい(後のインクリメンタルモデルとの大きな違い)。
(引用元:http://webpg014.hotcom-web.com/page6.html)
メリット
- 計画立案時に全ての要件を作成するコストが発生せず済む
- 一つ一つの機能(サブシステム)について、ユーザの満足度を高くできる
- ユーザが機能を早期に利用できるようになる
デメリット
- 計画立案時に全ての要件を作成する必要はないが、完成システムのイメージはステークホルダ間で共有されていなければならない
- ウォーターフォールモデルと比較すると、スケジュール/工程管理が複雑になる
- システムの分割が困難な場合がある
- それぞれのサブシステムが高い独立性を持つ場合にしか利用できない
- 評価者の選定を慎重に行わなければならない
どのようなプロジェクトに向いているか
- 作りたいものの大凡のイメージはできており、しかし全体要件を定義出来るほど要求が明確でない場合
- システムをサブシステムに上手く分割できる場合(機能の独立性が高い場合)
- 期間的制約の弱いプロジェクト
インクリメンタルモデル
個人的な見解としては、ウォーターフォールの変化系モデルであると考えている。
スパイラルモデルと同様に、システムを複数のサブシステムに分割し、サブシステム毎に開発していく手法。
スパイラルモデルと違い、全体の要求定義は先に完了させ、反復は行わない。
ウォーターフォールモデルの工程を並行で走らせるイメージ。
(引用元:http://www.itmedia.co.jp/im/articles/0310/08/news001.html)
メリット
- ユーザが機能を早期に利用できるようになる(スパイラルモデルと同様)
- スパイラルモデルやプロトタイプモデルと比較すると、工程管理が容易
- 要求定義が完了しているため、開発者の迷いを減らせる(ウォーターフォールモデルと同様)
- サブシステム毎の開発を行うため、ウォーターフォールモデルよりは手戻りコストが低い
デメリット
- 要求を予め定義しなければならないため、プロジェクト計画立案自体にコストがかかる(ウォーターフォールモデルと類似)
- 並行して開発を進行させていくため、開発内容が重複してしまう場合がある
- ウォーターフォールモデルと比較すると、スケジュール/工程管理が複雑になる(スパイラルモデルよりは容易)
- システムの分割が困難な場合がある(スパイラルモデルと同様)
- それぞれのサブシステムが高い独立性を持つ場合にしか利用できない
どのようなプロジェクトに向いているか
- 要求/要件/目標が固定されており、途中変更のないプロジェクト(ウォーターフォールと同様)
- 予め全ての要求/要件/条件/期間/工程/責任を定義しなければならないプロジェクト(ウォーターフォールと同様)
- 発注/受注案件など。
- 何が出来ていれば成約か、特に相互の責任を明確にすべき場合
- 発注/受注案件など。
- 機能を随時リリースし利用していきたいプロジェクト
- 期間的制約の強いプロジェクト
1-3. アジャイル開発
1-3-1. agileとは?
agileとは
(動きが)機敏な、はしっこい、(…に)機敏で、はしっこくて、頭の回転の早い、機敏な、明敏な
(引用元:https://ejje.weblio.jp/content/agile)
(引用元:https://ec-orange.jp/ec-media/?p=18702)
アジャイル開発をライフサイクルモデルと別項としたのには理由がある。
これまで紹介したライフサイクルモデルは、ソフトウェア工学の研究から生まれた、システム開発を効率的に進めるための経験則的ソフトウェアプロセスの集合、いわばフレームワークのようなものであった。これらはソフトウェアプロセスを定型化/評価し、いかに効率的な開発/保守を行っていくかという目的で考案されたと言える。
一方で、アジャイル開発という考え方はそれらとは少し違った見地から生まれたものである。
プロセスやツールよりも個人と対話を、
包括的なドキュメントよりも動くソフトウェアを、
契約交渉よりも顧客との協調を、
計画に従うことよりも変化への対応を、
価値とする。すなわち、左記のことがらに価値があることを
認めながらも、私たちは右記のことがらにより価値をおく。
(引用元:アジャイルソフトウェア開発宣言)
私たちは以下の原則に従う:
価値のあるソフトウェアを早く継続的に提供します。
要求の変更はたとえ開発の後期であっても歓迎します。
動くソフトウェアを、2-3週間から2-3ヶ月という
できるだけ短い時間間隔でリリースします。
ビジネス側の人と開発者は、プロジェクトを通して
日々一緒に働かなければなりません。
動くソフトウェアこそが進捗の最も重要な尺度です。
チームがもっと効率を高めることができるかを定期的に振り返り、
それに基づいて自分たちのやり方を最適に調整します。
(引用元(一部抜粋):アジャイル宣言の背後にある原則)
これまでソフトウェア工学で行われていたソフトウェアプロセスの定型化という研究とは逆に、ソフトウェアプロセスを柔軟かつ漸進的な非定型のものとして扱おうとしていることが読み取れる。
こうした思想が生まれた背景には、いくつかの理由が考えられる。
第一に、ソフトウェアプロセスの複雑化に伴う責任の明確化によって、副次的な成果物(要件定義書、仕様書、詳細設計書、テストエビデンス等)が増大し、「プロダクトを作る」という本質的な目的を達成するため道のりが遠くなってしまった側面があること。
第二に、webが発展したことによりソフトウェア開発に求められるものが変化したこと。ソフトウェアの利用される速度/頻度と改善要求の頻度は少なくとも相関、比例しているといってしまってもいい。少なくないソフトウェアが24h絶え間なく利用されるようになり、これまでの定型化されたプロセスを用いていては変化の速度に対応できない場合が出てきたのではないかと私は考えている。
第三に、ソフトウェア工学がある程度成熟してきたことで、基礎的な研究を応用できるタームに至ったのではないかと考えられる。前掲のアジャイルソフトウェア開発宣言の通り、アジャイル開発の理念は決してこれまでのソフトウェア工学で培われた経験則を否定/軽視するようなものではなく、それらの価値を認めた上でより現代にふさわしい価値を重視するというものである。既存のモデルを適宜最適な形で取り入れつつ、プロジェクトやチームによりふさわしい形の新しいモデルを追求していく、という姿勢こそがアジャイル開発の根幹であると言える。
以下に、約15年前、2003年時点での玉井による論を引用抜粋しておく。
開発/保守環境と運用環境の境界が喪失しつつあることにも,注目すべきであろう(中略)これまでのようにまず開発/保守環境でプログラムを作成し検証して,その後,運用環境へ移行するという段階を踏んだ作業は現実的でなくなってくる
引用元:玉井(再再掲) 144頁
1-3-2. アジャイル開発の手法
アジャイル開発と一言で言っても、スクラムやエクストリームプログラミング(XP)、リーンソフトウェア開発など様々な手法がある。
アジャイルの基本的な考え方は上述し、アジャイル開発に内包される様々な手法には細部の違いはあれ一定の共通した特徴がある。
そのため、ここではアジャイル開発手法の一つであるスクラムを紹介するに留める。
1-3-3. スクラム
Ken Schwaber/Jeff Sutherland両名によって開発されたアジャイル開発手法の一つ。
細かい手法やルールについては公式ガイドがあるのでそちらを参照の程。
(引用元:http://www.nec-solutioninnovators.co.jp/column/01_agile.html)
スクラムの特徴は公式ガイドにあるように以下の三点が挙げられる。
- 軽量
- 理解が容易
- 習得は困難
私も実際の業務にこのスクラムを浅い知識のまま取り入れたことがある。その経験から言っても上記三点は納得できる内容である。特に二点目の"理解が容易"と三点目の"習得は困難"という点は注目すべき特徴である。開発手法の自体の理解は容易だが、理解するのと実践するのとでは違いも多い。実際には数多くの問題が発生する。
公式ガイドにあるように、スクラムという開発手法は常にチーム構築/システム開発プロセスの改善を行っていく手法である。このことを軽視し、上辺だけスクラムを取り入れてしまうと私のように「なんちゃってスクラム」状態に苦しむことになる。実際、スクラムを取り入れ失敗するプロジェクトは数多く存在している。スクラム体制のコーチングのみで価値を認められるエンジニアも存在するほどに、スクラムの習得は困難である。
では、スクラムの実際の取り組み方を公式ガイドから抜粋し紹介する。
スクラムの理論
スクラムは、経験的プロセス制御の理論(経験主義)を基本にしている。
経験的プロセス制御の実現は、透明性・検査・適応の 3 本柱に支えられている。
- 透明性
- プロセスの用語を参加者全員で共有している。
- 作業する人とそのインクリメントを検査する人が「完成」の定義を共有している。
- 検査
- 適応
- プロセスの不備が許容値を超え、成果となるプロダクトを受け入れられないと検査担当者が判断し た場合は、プロセスやその構成要素を調整する必要がある。調整はできるだけ早く行い、これ以上の逸脱を防がなければいけない。
スクラムチーム
スクラムチームは以下の三つの役割で成立する。
- スクラムマスター
- プロダクトオーナー
- 開発チーム
スクラムマスター
- スクラムの促進と支援責務
- 開発チームへの支援
- プロダクトオーナーへの支援
- 組織への支援
- 上記促進支援によるスクラムチームが創造する価値の最大化
- スクラムを成立させ続けるためのサーバントリーダー(奉仕/支援型リーダー)
プロダクトオーナー
- プロダクト価値の最大化責務
- プロダクトバックログの管理・透明化
- プロダクトバックログ:プロダクトに必要だと把握しているものをすべて順番に並べた一覧
- 開発チームの作業価値最適化
- プロダクトバックログアイテムの周知
開発チーム
- 自己組織化責務
- サブチームはない
- 並列したプロフェッショナルであり上下関係はない
- スプリント毎のリリース責務
スクラムイベント
スクラムは規則的なイベントを規定している。時間制限のあるイベントのみが存在でき、不要な時間的コストは削減されなければならない。
スプリント
スクラムのコアといっていい機能である。
- リリース判断可能なプロダクトインクリメントを作るための、1か月以下のタイムボックス(規定する)
- スプリントゴールに悪影響を及ぼすような変更を加えない。
- 品質目標を下げない。
- プロダクトオーナーのみがスプリントを中止できる。
- とはいえ、スプリントを中止すべきことはほとんどない
スプリントに内包されるイベントは以下の4つである
- スプリントプランニング
- デイリースクラム
- スプリントレビュー
- スプリントレトロスペクティブ
1.スプリントプランニング
以下の問いに答えを出す会議である。先に挙げた三本柱の内、透明性の部分に関連の強い場。
- スプリントの成果であるインクリメントで何を届けることができるか?
- インクリメントを届けるために必要な作業をどのように成し遂げるか?
2.デイリースクラム
主に開発チーム作業計画をする場。日々の開発に関する検査、適応の機能を備える。
3.スプリントレビュー
スプリント自体の検査の場。
注意:一部のみ抜粋している。
- スプリントの終了時にインクリメントの検査と、必要であればプロダクトバック ログの適応を行うものである。
- 参加者は、スクラムチームとプロダクトオーナーが招待した重要なステークホルダーである。
- プロダクトオーナーは、プロダクトバックログアイテムの「完成」したものと「完成」していないも のについて説明する。
- プロダクトオーナーは、現在のプロダクトバックログの状況を説明する。(必要であれば)現在 の進捗から、可能性のある目標とデリバリーの日程を予測する。
- 開発チームは、スプリントでうまくいったこと、直面した問題点、それをどのように解決したかを 議論する。
- 開発チームは、「完成」したものをデモして、インクリメントに対する質問に答える。「完成」の定 義にプロダクト機能のリリースが含まれていれば、それらを表示してレビューしてもらう。
- グループ全体で次に何をするべきかを議論し、次のスプリントプランニングに価値のあるイン プットを提供できるようにする。
- 市場やプロダクトの利用状況によって、次に行うべき最も価値の高いことが変更される可能性 をレビューする。
スプリントレトロスペクティブ
スプリントに対する適応の場。
- スクラムチームの検査と次のスプリントの改善計画を作成する機会 である。
- スプリントレトロスペクティブは、スプリントレビューが終わって、次のスプリントプランニングが始まる前に行う。
- スクラムマスターは、このミーティングがポジティブで生産的になるようにする。
- 人・関係・プロセス・ツールの観点から今回のスプリントを検査する。
- うまくいった項目や今後の改善が必要な項目を特定・整理する。
- スクラムチームの作業の改善実施計画を作成する。
以上がスクラムという手法の規定である。
より詳細/正確な規定、実践的な内容については以下を参照。
- スクラムガイド - 日本語訳
- Scrum基本のキ - 西村直人
- スクラム概論 - Ryutaro "Ryuzee" YOSHIBA
- Agile-development-course-advanced - Miho Nagase
2. 要求工学
ソフトウェア工学とそれがもたらしたライフサイクルモデル、及びアジャイル開発についての説明は終えた。
どのライフサイクルモデルにも必ず存在するのが「要求定義/要件定義」というプロセスだ。私にとって、いやおそらく多くのエンジニアにとって、これはプログラムを書くこと自体よりも非常に難しいプロセスである。
例えば顧客が「ごはんを食べたい」と言った時、私たちは何を明らかにし、何を考え、何をすべきなのか。
顧客が求めているものは"ごはんを食べる"という行為なのか、"お腹をいっぱいにしたい"ということなのか、それとも"外食に行きたい"、"ごはんでも食べながら人と話したい"ということなのか。また、求められているごはんとは何か。お米を炊いたものか、それともごはんはお米という意味ではなくてパスタかラーメンか、そのどれでもいいのか、どれでもダメなのか。今どれくらいごはんを食べたくて、いつまでにごはんを食べたいのか。また、いつまでごはんを食べたい状態は続きそうか。我々はごはんを作れば良いのか、ごはんを食べれる場所を作れば良いのか、ごはんを食べられるお店を紹介すれば良いのか、ごはんを一緒に食べてくれる人を紹介すればいいのか。そして、それはどこまでが顧客の決めるべきことで、どこから我々のすべきことなのか。
このような問いは書ききれないほどある。要求/要件定義がいかに奥深く難解な問題であるかということが、この例でわかってもらえるかと思う。
要求工学とは
要求工学とは、要望、要求について、あるいはそれを仕様化するプロセスについての研究と言える。
プロジェクトの失敗原因の多くは要求に起因する
要求工学知識体系(REBOK)概説 - 独立行政法人情報処理推進機構
システム開発において、手戻りやスケジュールの遅延、重大なバグが発生した時点で少なからず開発プロセスに失敗、欠陥があったと言える。
そして上記引用の通り、IPAはプロジェクト失敗の多くの原因は要求/要件定義にあるとしている。
これは私を含む多くのエンジニアが肌で感じ取っていることでもある。
要求定義/要件定義に関する書物は現在確認できるだけで100冊を超えており、それは要求/要件定義の難しさを多くの人間が感じている証左である。
上掲IPA資料、ソフトウェア工学(再掲)にも要求獲得、要件定義の難しさやそれに対するアプローチ技術の重要性が説かれており、これらは昨今ソフトウェア開発における一つの大きな課題として工学と呼ばれるにまで至っている領域である。
要求獲得、要求定義、要件定義、仕様化のプロセスについてはまだ未成熟な領域である。つまり、ベストプラクティスは未だ確立されていない難解な課題であるということは前提として認識してもらいたい。
2-1. 要望、要求、要件の違い
重要:この三つはそもそも人によって解釈が違うものである
- 要望:demands
- 要求:requirements
- 要件:requirements
“requirement”は,通常“要求”又は“要件”と訳される。
(引用元:JIS規格X0166)
今回は、抽象度の違いという観点から特に要望/要求について定義し、要件定義に至る前段階に必要なプロセスを明らかにしたい。
抽象度の高い順に並べると要望>要求>要件(>仕様)であるという前提で話を進める。
2-2. 要望と要求の関係
通常、要望は英語でDemandsという。要求はRequirementsということから、この二つには明確な違いがありそうだということがわかる。
その前提の上で、まずは私なりの要望と要求の関係を定義したい。
- 要望 = 顕在化してない要求(潜在的要求)
- 要求 = 顕在化し、具体性を得た要望
私はこのように要望と要求を区別し、またその関係性を定義する。
そして、要求工学の力を借りつつ、私自身の経験から要求をさらに細分化していく。
システム開発にまつわる"要求"というものは、下記のような段階的プロセスを経て獲得されるものであると私は考える。
- 要望の発露
- 要求の認識
- 要求の分析
- 要求の定義
- 要求分析結果の合意
- 要求の検証
まず、要望が何らかのプロセスを経て1.顕在化(発露)する。そして、それは要望保持者と要求獲得者(要求定義をしたい者)の両名に"未成熟な要求"として2.認識される。次に、認識された"未成熟な要求"を"成熟した要求"へと進化させるプロセスを経る。このプロセスを3.要求分析と呼ぶ。最後に、成熟した要求を文書化して明示(4.要求の定義)し、要望保持者と要求獲得者の間で5.要求分析結果の合意を得る。そして、成熟した要求が両者に共有された後、6.要求の検証を行う。
IPAのREBOKに基づく定義に当てはめると、1,2が要求獲得、3が要求分析、4,5が要求の仕様化、6が要求の検証・妥当性確認・評価に当たる。
同IPA資料にもあるように、このプロセスは決して直線的なものではなく、上で紹介したいくつかの反復型ソフトウェア開発ライフサイクルモデル、アジャイル開発の思想のように反復による改善を必要とするものである。
2-2-1. 要望の発露(顕在化)プロセス
先ほど"要求 = 顕在化し、具体性を得た要望"と定義した。
では、どういった経緯を経て要望は顕在化するのか。
要望が顕在化し"未成熟な要求"へと変化するプロセスには少なくとも2つの種類がある。
- コミュニケーション型要求発露
- 自己完結型要求発露
これらはあくまで私個人が名付けたものであり、一般的な用語ではない。それぞれ図を用いて説明する。
2-2-1-1. コミュニケーション型要求発露
上図に示したように、要望は要求獲得者(例えば要求獲得をしようとしているSIer)と顧客(ユーザ)間のコミュニケーションによって顕在化し、まず"未成熟な要求"へと変化する。
この場合、作業を楽にしたい、しかし"どうすればできるのかわからない"というわからなさや、そもそもこれは課題なのかというわからなさがコミュニケーションによって解消されたことにより要望が顕在化される。その"わからなさ"が要望を要望として留まらせていた原因と言える。
このプロセスを要求獲得者側として行う際に注意するべき点は正にそこであり、医療現場や社会学、心理学などにおけるインタビューの手法を取り入れるなどして、"わからなさ"の障壁と原因を理解した上で可能な限り適切にコミュニケーションを図る必要がある。適切でないコミュニケーションがもたらす結果は、要求獲得者のバイアスによる誘導、つまり"本当に顧客が要望していること"からの乖離といえる。
妻木によれば、この段階で具体的に取られる調査手法には以下のようなものがある。
- 情報の収集
- ステークホルダ分析
- 構造化インタビュー
- 観察
- 文献調査
- プロトタイピング
- 問題の定義
- 情報の整理
- 合意形成
- モデリング
2-2-1-2. 自己完結型要求発露
一方で、要望の顕在化までは顧客自身が行なっている場合がある。
顧客が要望を顕在化している状態では、SIerやソフトウェア開発をする側はほとんどの場合その要求を聞き取ることしか行わない。
上に挙げた妻木による調査をすでに顧客側が済ませており、ある程度整理された要求が提示されるという期待からである。しかし要求を獲得するという本質的な目的に対しては、この期待は危険を孕んでいる。
自己完結型要求発露によって顕在化した要求は"最も未成熟な要求"である可能性が高い。顧客自身が行った要望の健在化は(顧客が社内調査をした結果だとしても)第三者とのやりとりを介して発露した要求ではない。提示される要求はコミュニケーション型要求発露プロセスを経た場合よりもあいまいさが強く、主観によるバイアスの影響も多大に受けている可能性がある。
しかし一方で、自己完結型要求発露によって顕在化された要求は、コミュニケーション型要求発露にはない当事者であるからこその業務知識、背景、課題感が含まれている可能性も高い。後のプロセスである"要求の分析"、"要求の検証"プロセスを経る際に鍵となる何かしらの要素がこの段階で露見することもある。
2-2-2. 要求の認識プロセス
要望の顕在化プロセスを経て、要求は初めて両者に認識される。
時には、顧客本人にとってもこの段階で初めて発見される要求及び要望がある。
(例) 「この作業を楽にしたい」 -> 「こういうシステムがあれば楽になるんだ」 -> 「じゃあそれが欲しい」
(例)「気づいていなかったけれど、実はこんなことにも困っていたんだ」 -> 「じゃあそれもどうにかしたい」
特にコミュニケーション型要求発露においてこの発見は顕著である。この場合においては、顧客自身も要求獲得を為したと言え、顧客ベンダ双方が要求獲得者としての性質を得る。
要望の発露と要求の認識プロセスを分けた理由はここにある。要望が発露した時点で要求として認識されたと捉えることもできる。しかし顧客自身が気づいていない要望/要求の発見という要求獲得における重要な課題の鍵を握るのはこのプロセスであると私は考える。
2-2-3. 要求の分析
2-2-1,2-2-2のプロセスを経ることで"未成熟な要求"を獲得した。
次の要求の分析というプロセスは、獲得した要求を成熟させる重要なプロセスである。
要求工学の領域ではない一般的な「要求定義」と呼ばれる工程で行われることとほぼ同様である。
分析の手法は多々ある。この分析こそが要求定義のコアであり、シナリオベースモデル、領域分割モデル、ゴール指向モデルなど様々な分析フレームワークが開発され、この難題をいかに解決するか日々研究がなされている。
ここでは、私の経験から最低限分析しておきたい3つの項目を挙げる。
- 要求の背景調査
- なぜその要求が生まれたのか?
- 誰が
- いつ
- どこで
- どのように
- なぜ、その要求は"今"要求として顕在化したのか
- なぜその要求が生まれたのか?
- 要求の正当性を明確化
- その要求は本当に必要とされている要求なのか?
- 誰に、どのくらい必要とされているのか
- その要求は何を解決し、何をもたらすのか
- 例えば業務効率の改善に関する要求であった場合、解決により何が顧客にもたらされるのか
- 新しい価値の創造リソース
- 人員コストの削減
- etc...
- もたらされるものは、本当に求められているものと同じなのか?
- 例えば業務効率の改善に関する要求であった場合、解決により何が顧客にもたらされるのか
- システムやツールが欲しい、という要求は正当なものなのか?
- 要望保持者、要求獲得者の適切でないバイアスが含まれていないか?
- それは「本当に欲しい」のか?
- "楽になるシステム"ではなく"楽になるオペレーションフロー"では解決できないのか?
- ここで、オペレーションフローを変更できない等の背景が発見されることもある
- システムと併用してより効率的な解決ができる方策はないか?
- システム利用権限保持者を拡大すれば、より効率が上がるのではないか?
- システム導入と同時に保守/運用が別途必要になるのか?
- 要望保持者、要求獲得者の適切でないバイアスが含まれていないか?
- その要求は本当に必要とされている要求なのか?
- 要求の具体化
- 要求が解決されるとは、どういうことなのか
- 先の図の例で言えば"楽になる"、"使いやすい"とはどういうことか
- 何が解消されていれば要求の解決に至れるのか
- 要求が解決されるとは、どういうことなのか
問いの例として、いくつか具体的な問いを掲載した。要求分析というプロセスは、何度も何度も立ち返り問いを発することで改めて要求の意義、要求の本質と詳細を明らかにしていくことが目的である為、重複した問いも時には必要であると私は考えている。
より根本的な課題背景を知ることで、必要とされているシステムが変わってくることはザラにある。 そもそも要求が正当でなく、作った後に「使ってない」と言われることもまたザラであると言える。1990年代に行われたスタンディッシュ・グループのレポートによれば、システムに搭載した6割以上の機能が使われていないという。
(参考:アジャイル開発とスクラム 顧客・技術・経営をつなぐ協調的ソフトウェア開発マネジメント 2013 平鍋健児、野中郁次郎)
1990年代の調査が現代に通用するのかどうかは別として、そうした非効率的な状況を回避するために、背景の認識、正当性の検証、具体化というこのプロセスが必要なのである。
要求の分析は決して開発者のみに利益があるものではなく、両者にとって利益のあるプロセスである。
要求の分析プロセスを経ることによって、顧客にとっても開発者にとっても気づきが与えられる。本当に必要とされている解決は何か、それはどれくらい致命的な問題で、解決することで何が起こるのか。
しかし一方で、開発側が敢えてこの要求の分析プロセスを回避している場合もある。例えば開発会社にとっては顧客にとって無駄なものであったとしても、案件として受注をして言われた通り納品してしまえば報酬がもらえる。この問題は受注/発注双方の課題でもあり、システムインテグレーション、システムコンサルティングの領域に波及する。
2-2-4. 要求の定義
前プロセスである"要求の分析"で明らかになった"要求の本質と詳細"を書面化するプロセスが本プロセスである。
一般的には、この時点で要求仕様書という要求をシステム仕様にまで落とし込んだ書面を作成する場合もある。
しかし今回は先述した通り、要求と要件を明確に区別し話を進める。その上で、要求の分析プロセスで明らかにしたものはビジネスの要件であり、決してシステム要件ではないということを断言しておく必要がある。
即ち、このプロセスで作るべき書面は、"ビジネス要件"を明示したものである。
2-2-5. 要求の合意
2-2-4. 要求の定義で作成したビジネス要件をまとめた書面は、両者によって分析結果に齟齬がないか検証合意される必要がある。
このプロセスでは分析の結果の正当性を問う。ここで注意しなくてはならない点は、そもそもの要求の正当性ではなく分析の結果の正当性を合意するという点である。
要求の正当性を問うプロセスは別にある。次のプロセス要求の検証である。
2-2-6. 要求の検証
ここまでで、ある程度成熟した要求が定義された。要求の分析結果は書面化され、ビジネス要件の具体的な姿が見えるところまできた。
その要求は本当に必要なものだったか、本質的な問題は別のものではなかったか、当初持っていた要望とは別の要望が生まれてはこなかったか。ここでようやく、顧客と要求分析者の間で要求の正当性を改めて問うことができるようになる。
2-2-7. 反復
先述した通り、これらのプロセスは反復型ライフサイクルモデルやアジャイル開発の思想のように、反復して行わなければならない。
その理由は以下2点である。
- 分析結果を受けて、要求が変化し得ること
- これまでのプロセスで得た"気づき"による新たな要求がまだ一連のプロセスを経ていないこと
例えば先の図で"本当は別のものが欲しいのかも"という新たな要求が顕在化した。その原因は何か。それは潜在的な要望が新たに発見されたことに他ならない。
はじめに、要望を以下のように定義した。
要望 = 顕在化してない要求(潜在的要求)
要望が潜在的な要求であるように、要望にもまた顕在化しているものとしていないものがある。顕在化した要望は新たな要求となり、再度一連のプロセスを経てその正当性、必要性が議論されて然るべきものである。また、要望は一度洗い出したらそれが全てというものではない。常に新しい要望が生まれ、それは潜在的であることもあるし、顕在化している場合もある。
この流動性、複雑性こそが要求工学という技術を生んだ要因であると私は思う。
おわりに
僕は現在webエンジニアとしてご飯を食べているが、高校や大学で情報系のことは一切と言っていいほど学んでこなかった。所謂「ちゃんと勉強してきた」エンジニアではないのだ。大学は社会学部社会学科というゴリゴリの文系学科を出ているし、卒業研究のテーマなんて「若者と自殺について」というような感じで、もう本当に全然プログラミングのプの字も知らずに生きていたのだ。
僕がエンジニアになったのは4年前くらいのことになる。最初に入った会社の配属先発表で「システム開発室ね」と言われたその瞬間、僕の車輪はエンジニアというレールの上を回り始めた。それなりにプログラムを書けるようになって、それを楽しいと思うようになってきて。ちょっとハードワークすぎてうつ病になったりもしたけれど、それでも僕はエンジニアリングというものが今も好きだ。
僕がボランティアで大学生にプログラミングを教えているのも、自分がエンジニアリングという仕事を好きだというところが根底にはあって、もし僕の知識を彼らに提供することで彼らがより幸せな人生を送れるのだったら素晴らしいし、彼らがエンジニアになるにせよならないにせよ、この楽しさというものを理解してくれたらとっても嬉しいなあという思いからだ。
しかしいつからか、「ちゃんとコンピュータサイエンスを勉強している奴には勝てないなあ」ということに気づいてしまった。多分それは本当のことなんだろう。僕は昔から算数や数学が苦手で、高校入試の自己採点をした時なんて、数学は0点だった。国語と英語の点数のみでどうにか受かった。本が好きで、純粋経験とか唯我論とかそういう哲学を知るのが好きで、理屈が好きで、小説家になりたいと思っていて、この上ないくらいに文系の極みのような人間だ。
一般的にエンジニアというと理系の仕事だと思われる。僕もそう思う。でも僕は今でも、シグマと言われるとウッという拒否感が出てしまう。for文というシグマと似たようなプログラムの構文があって、それを日常的に使っているのに、やはり数学には苦手意識があるのだ。
そんな僕は、「エンジニアとして何をしたらいいのかな」と漠然とした悩みを持っている。webエンジニアの一般的なキャリアパスとしては、エキスパートとしてプログラミングを極めていく道と、マネジメントの方に進む道がある。僕はなんだか、どうなりたいのかよくわからない状態になっている。
もっとプログラミングを勉強していきたいし、でもちゃんと勉強してきた人たちからすると僕なんてにわかエンジニアというか、そういうような存在になってしまうよなあと。業務ではPHPを使っていて、それだけじゃあダメだと思ってrubyやjavascript、C++なんかも触ってみたけれども、なんだかそれもちょっと違うような気がしている。
そこで立ち返って、僕に出来ることはなんだろうと考えることにした。
僕に出来ることは、何かを入れて、何かを出すこと。
本や論文、人が書いた文章を読むこと。
そして、それを自分なりに解釈して、書くこと。
インプットとアウトプット、多分僕にはそれしかできないんだと思う。
息を吸うのと同じだ。僕には多分、これしかできないんだと思う。
だからいっぱい本を読んで、いっぱい日記や記事を書こう。
もっと本を読みたい、もっと文章を書きたい。
昔から、物語を読んだり観たり聴いたりすることが好きだった。というより、僕にはそれしか熱中できることがなかった。それにもかかわらず、最近では本を読むことがめっきり減ってしまった。精々週に一度か二度、長い通勤時間を利用して青空文庫をペラペラとめくるくらいだ。
最も好きな作家は坂口安吾で、次がゲーテ、並んで森鴎外とヘッセ、中島敦、山田詠美。この並びを見ればわかる通り、僕の好きな物語に確固たる系統はない。敢えて言うのであれば、あまりに情熱的な、魂から溢れ出たような文章が好きなのだ。それが織り交ぜられた物語に、心から圧倒されることが好きなのだ。話自体が面白いとかつまらないとか、設定が面白いとかそんなことは関係ない。デカダンだろうがフェチズムだろうがナルシシズムだろうが諦念だろうがフェミニズムだろうが、どんな姿勢でどんなメッセージを発していてもかまわない。一文一文に込められた熱量、魂、そのあまりの迫力に打ちのめされるあの感覚に取り憑かれてしまって、たまらないんだ。僕は文章と物語に、憧れていたい。
中学生頃から、友人と過ごさない時間の大半を読書に費やした。大学では、映画を撮りたいという友人に脚本を書いた。今思えばあの稚拙な短編物語を短編映画にまでしてくれた彼には感謝の言葉もない。僕の物語への執着は、ずっと続いた。それどころか、年々その激しさを増していった。初めてオズの魔法使いの絵本を読んだその時から、一度たりとも物語から離れたことなんてなかった。
それなのに、仕事が、生きるためにお金を稼ぐということが。僕が一番大切に思っていたものを奪ってしまった。あるいは、僕が一番大切にすべきだったものは、生きるために働くなんてことではなくて、この思いそのものだったのかもしれない。
それでも今、僕は欲しい本がたくさんある。ほしい物リストにはたくさんの本が入っている。
どれもこれも、仕事をうまくやるための本、自分の能力を磨くための本ばかりだ。僕はそれが悲しい。昔は本に実利なんて求めていなかった。僕が好きだったのは教科書ではなく、物語だったはずなんだ。いつからだろう、本が何かを与えてくれるものだと勘違いし始めたのは。本は、読み手が何かを感じ取るもので、あちらからは何もしてくれないものだって、ずっと思ってきたのに。
僕は、物語をもう一度取り戻したい。仕事や、嫌な人間関係や、茫漠と横たわる人生の不安は絶えず僕を苦しめている。生活に追われ、本を読む時間だってほとんどない。それでも僕はこれから、たくさんの本を読もうと思う。たくさんの文章を書こうと思う。そうして僕は物語を、僕なんかでは敵いっこない尊い魂に圧倒されるあの快感を、この手に取り戻そうと思う。
アーリータイムズ
僕は今、フレックス制度を利用して早帰りをしている。嬉しい。早帰りといってもそこまで早いわけでもない。コアタイムが10-16時と決められていて、そして僕の家と会社は遠い。どれだけ急いでも帰宅出来るのは結局18〜19時になってしまう。それでも、普段0時くらいに帰っているのを考えれば十分に嬉しい。 体調が優れない為やむを得ずとった強行ではあるが、僕は今嬉しいのだ。
イイ話
昨日友人が言っていた。お金は高いところから低いところに流してしかるべきで、低いところから高いところに流すのはヤクザのシステムだと。そしてこれは優しさや余裕においても同じことだと。なるほど言い得て妙である。そう言われるとそんなような気がしてくる。もしかすると、早帰りをしたことで僕も余裕を感じているのかもしれない。バラバラに座ろうとする親子に席を譲ることが普段よりスムーズに出来た気がする。
余裕のあるやつが余裕のないやつを助ければいいんじゃない?と彼は言った。素晴らしい考えだ。僕も本当にそう思う。僕自身もそうありたいと思うし、人にもそうで居てほしいと思う。できれば、余裕のある側でありたい。
これを書きながら昨日の友人との会話をだんだん思い出してきた。確か僕らはそのイイ話の前に、お互いにブチ切れたことがあったよねという話をしていたんだ。こんなにイイ話ができる人間でも、やはり余裕がないと怒ったりしてしまうことはあるのだ。10年近く付き合った友人らが、お互いにムカついた話をした後で大人みたいな話をする。とても人間らしくて気に入っている。素直で素朴で素敵な話の流れだった。
大学生の頃、別の友人と似たような話をしたことがある。その友人と僕はバンドを組んでいた。彼は非常に時間に寛容だった。バンド練習の際に誰かが遅刻をしてきても、本当に何とも思わず仕切り直すことができる人間だった。そして彼は他人に対してと同様に、自分の時間にもあまり執着をしていなかった。僕の知らないところではあるが、彼自身が何かの待ち合わせに遅刻することが少なからずあったようだ。ある日彼は何の気なしにこう言った。
遅刻したら怒られるじゃん。でも、みんなが怒る意味が正直あんまりわからないんだ。
僕は彼の言葉に共感を覚えた。僕らは二人でじっくりと、その分からなさの原因を探ることにした。おそらく何ヶ月、すくなくとも何週間かこの話題は続いた。結論を言えば、彼と僕は暇だから怒らないんじゃないかという話になった。今思えばなんて結論なんだろう。文系大学生が二人集まって真剣に議論した結果とは思えない。
でも確かに、当時僕らのカレンダーは基本的に真っ白だったし、そもそもカレンダーを埋めるものだなんてこれっぽっちも思っていなかった。だから何か面白いことがあれば飽きるまでやっていたし、納得のいかないことがあれば納得いくまで考えたり話したりした。それから好きな女の子の話なんかもずっとしていた。
他の人たちのカレンダーはきっと真っ黒になっていて、決められた時間で決められたことをやれないと他の予定に支障が出ちゃうから怒るんじゃないかな。
当たり前のことだ。そんな当たり前の結論が、当時の僕らには想像もつかない新たな発見だった。想像が出来なかったから、ゼロから仮説を立てて、こうなんじゃないか、ああなんじゃないかと今思えばよくわからない推理をしていた。
でも、その想像のつかなさが、それこそが僕らの純真だったと思うよ。今では僕らはカレンダーを"埋める"とは言わず、スケジュールを"空ける"と言うようになってしまった。なんで、いつこうなったんだろうね。自分達とは違う人のことを想像していたはずなのに、今はもう違う人ではなくなってしまったね。このことについて、また話し合いたいね。
かなわねえな
かなわない、僕は善い人間には、かなわない。
僕は、世界には善い人間がいることを知っている。そしてその少なさと尊さもまたよく知っている。
善い人間はいつも僕を助けてくれる。悩みごとがあれば一緒になって考えてくれて、放っておいて欲しい時は放っておいてくれる。何かをお願いすれば快く引き受けてくれるし、僕が何かをお願いしたことを喜んでくれたりもする。少し時が経てば、最近どうだと不意の連絡を寄越してくれ、正にそれが欲しいというタイミングに僕の心配をしてくれていたりする。そして、僕に心配をさせてくれることもある。
善い人間は、きっと僕以外の人間も助けている。彼等はいつも誰かの為に考え、行動し、一緒になって喜んでいる。少なくとも僕にはそう見える。本当にかなわないよ。仕事をして生活をして、彼等にも僕と同じような暮らしがある。彼らも僕と同じように悩むことだってあるはずなのだ。しかし彼等は僕と違い、いつだって優しく善い人間でいることが出来る。どうしていつも、凪いでいられるのだろう。なんでそんなに、静謐であれるのだろう。
僕はといえば、根っこの部分からもう善くない人間だ。善悪の二元論で語るならば、当然僕は悪人に近い側にいる。私欲が喉の渇きのように付き纏い、呼吸をする度に厭忌の粘りは増す。これぞ嫌な人間というような行動を取ってしまうこともあり、本当に嫌になるよ。こんなことばかりの時間と、こんなことばかりの自分が。そしてどこか善い人を羨んでしまうこの浅ましさも。
それでも僕は今、仕事や生活、この暮らしにそれなりに向き合った形で日々を費やせている。僕が思うに、その少しの前向きさの源泉になっているのはやはり、今や今までに一緒に居てくれた善い人達の存在であると思う。これからくる過去も、これまで見た未来も、全部が全部彼等のお陰であって、それが心から分かってしまう。本当にかなわないと何度も思い知らされるよ。
僕はやはり、彼等のように穏やかでありたい。病める時も健やかなる時も、そうありたい。ただ生きているだけで苛烈さは寒風の如く吹き荒ぶけれど、もうそれに慣れるのも嫌なんだよ。もう彼や彼女にかなわないと思い知らされるのは、嫌なんだよ。
善い人間って奴は、ほんと参っちゃうよな。