本格的な家族の引っ越しは実は未体験で、学生時分や社会人一人暮らしをしていた頃にわりと住所を転々としていたので、一人で引っ越すのは何度となくやっていましたが、私が生まれて実家を引っ越す、という経験をしたのは今回で3度目、1回目はまだ子供の頃、2回目は一人暮らしをしていたアパートからの引っ越しと実家の引っ越しを同じタイミングで行ったため、実家側の引っ越しについてはノータッチ、そして今回の引っ越しで3回目なので、私主導での家族全体での引っ越しはよく考えてみたら初めて、ということになるんです。
ゴミの量がハンパない
今回の引っ越し、戸建て(賃貸)から戸建て(自己|ヨメ所有)への引っ越しなんですが、土地面積・建坪だけで言うと、旧居より新居の方が若干狭いんです。収納スペースも豊富にあるわけではないですし、引っ越しをするにあたって「いらないモノは捨てよう」「新居に持っていくものは現在あるものの2割、8割は捨てよう」と家族で相談し、本当に必要なモノだけを持って引っ越しをしようと話をしました。
その結果として、
- 引っ越しにとても時間がかかってしまった
- 捨てたモノの量がとても多くなった
という副作用が発生しました。というよりは、時間がかかった理由がモノの取捨選択のためであり、そして結果として捨てるものが多いため*1、とにかく毎日少しずつ時間を取って、「モノ」を捨てる｜捨てないを判断、捨てる場合は更に分別をし、捨てられるタイミングでひたすら捨てていく、という作業を続けていきました。
捨て方の方法論はともかく*2、とにかく「これは捨てるべきか」という判断を下すのには労力が必要です。かなり強い意志が必要です。逆に、これは処分しないと判断するのは簡単で、労力も要りません。若干スピリチュアルな話になって恐縮ですが、日本の(宗教的)文化の中で「つくも(付喪)神」という、道具やモノに神が宿るという考え方があって、目の前にモノがあると、それにはなにがしかの思い出であったり感情であったり、という「神」がいるわけです。そう。この「神」の呪縛がモノを捨てられなくする要因の一つで、解放されるためには何らかの「言い訳」、神との契約解除のための儀礼が必要になるわけです。
個人的には好きではない考え方*3ですが、「こんまりメソッド」はまさにモノの呪縛をどのように解くか、というのを逆説的に、つまり呪縛されたままでよい(＝ときめく)かどうかで判断をするように教えています。「ときめかない」というのはモノを捨てる＝呪縛から解放されるための「言い訳」になり得ますからね。
ただ、いずれにせよ、捨てるためには意思を表出する必要があって、「ときめかない」と最初思ったとしても、なんでときめかないのか、と思わず考えてしまうのが「付喪神」のなせる業で、何らかの理由があって手に入れたモノが『なぜ不要だ(ときめかない)のか』と考えさせてしまうわけです。「ここにモノがあるのは必然(理由がある)」なので、手放さない場合はその必然を思い出せば済むのですが、手放す場合はその理由を上回る「手放す理由」を考える必要があり、それを生み出すのには時間も労力もかかります。
プログラミング講師という仕事と「事前研修」
そんな引っ越しをしながら考えたのが、プログラミング講師の副業をしたときに受講した「事前研修」のことでした。私自身は普段Javaを使わないので、Javaのプログラムを基本にした講師の仕事を受託するにあたって、単純に言語仕様のキャッチアップでもしておけばいいかな、と最初は高を括っていましたが、テキストを読み進めていくと、「プログラミングの基本」についての知識をあまり持っていないことを思い知らされました。私は教育を受けてプログラマの道に入ったわけではなく、独学で少し、現場でほとんどのプログラム技術を学んでいるので、講義で自分が教えなくてはいけない体系だった学習内容を研修でサラッと学習し、ずいぶんと目から鱗が落ちるような経験をしました。
でも、事前研修自体はそれほど苦痛でもなく、むしろすでに理解している断片的な知識を体系的に紐づける作業でしかないわけで、仕事の合間に受講していたこともあって楽しい研修だったなぁ、と記憶をしています。
そして、実際に現場に赴き、「教える」という作業を始めると、受講する立場と講義をする立場では圧倒的に講義をするほうが大変だ、ということに気が付きます*4。理由は簡単で、「知識を伝える」ために、どうやって伝えなければいけないかをその場で考えないといけないからです。知識をただ伝えるだけであれば、「講義」という形式をとって、講師が受講者に対して説明をする必要はないわけです。テキストがあるのだからそれを読めばいいんです。講師、メンターだの先生だのと呼び方はいろいろありますが、いわゆる「教える人」は「教えらえる人(受講者)」に、ただ知識を伝えるだけでなく、その知識を理解できるように説明をしなくてはいけないわけです。その説明も、あらかじめ「こうやって説明しようかな」と思っていたことが、現場の雰囲気で「あれ？この説明の仕方だとわかってもらえないかもしれないな」と判断して、その場で説明方法を変えたりする臨機応変さも必要だったりします。
覚える：インプット / 教える：アウトプット
「講師」という仕事は、アウトプットをしてなんぼ、という仕事です。もっとも、プログラマという仕事(SEという仕事)もプログラムを書いたり仕様を作ったりと、アウトプットをしてなんぼ、なんですが、いずれにしても、成果物を継続的にアウトプットしなくてはいけません。下世話な言い方をすれば、「アウトプットを出すことで稼げる」わけです。
逆に、「受講者」という立場は、その受講内容にもよるとは思いますが、基本的には何かを学ぶために講義を受講しています。覚えなくてはいけないことがあれば、それを、その場でするかどうかは別にして覚える必要があるわけです。講師の「アウトプット」を自分の「インプット」として取り込む、ということです。
ただ、仕事関係のいろいろなセミナーだったりカンファレンスに参加したりして私が思うことは、「あれ？このセミナー、俺には必要ないかも」と感じたりすることです。できるだけそうならないように事前にセミナー内容を吟味して参加することにしてはいますが、オープンカンファレンスで、ちょっと気になる講演に参加することもあったりします。そんな時に、「必要ないな」と判断したらその場で席を立ち、別の会場に入ったり「サボったり」することもしばしばあります。基本的には、自分の知っていることに対して、他者の知見で得られるものがあるかどうか、という観点で講演なりを聞き始め、得られるものがなければ去る、というのが私のスタイルです。
自分で講義を行う人間がこのようなことを言うのは矛盾しているようにも思いますが、学ぶべきことがないのにずっとセミナー会場で勉強している「フリ」をするのは時間の無駄だと思っています。そして、逆説的になりますが、セミナー会場で登壇する人間(＝講師)は、そんなことを受講者に思わせないように、圧倒的に高品質なアウトプットを出力することで、受講者の学びの機会に対して「学んでよかった」「聞いててよかった」と思ってもらわなければいけないはずなんです。
プログラムを書くことももちろん、高品質なモノを書く必要があります。よく議論される「よいコードとは？」という命題の答えには少し遠いのですが、少なくともよいコードの必要条件の一つとして、「品質が高いこと」はあるはずです。何をもって「品質が高い」のか、の議論はあると思いますがそれはまた別の機会に。
会議(ミーティング)
さて、余談ですが私は昔から「会議」が好きではありません。
その理由の一つが、『会議がある情報の「一方的な伝達手段」である(そうなりがちである)こと』です。こういう言い方は語弊があるかもしれませんが、「会議」と称して一方的に会議主催者の持っている情報を伝えるだけの場を作ることで、主催者は「アウトプットを行った」、仕事をした、という気分になっている人たちがかなり多いと考えています。
同様に、そして好きではない理由のもう一つとして、会議参加者もその主催者の「アウトプット」をただ聞いて、インプットを得られた、と満足している人たちが多いとも思っています*5。それでも、会議は開催されますし、召集されますし、参加したらしたで後悔するか目を付けられるかのいずれかの結果が待っていて、それでもまた会議が開催され、召集され、というループが続くわけです。
会議の場は誰か特定の人がアウトプットをし、誰か特定の人はインプットしかしない、という場ではなく、お互いに議論をする場、つまりアウトプットとインプットが参加者すべてに発生する場だと思っています。
品質の高いアウトプットを出すために
コードの品質、という話ではなく、一般的なアウトプットの品質を高めるためにしなくてはいけない事は、とにかくアウトプットを出してみることに尽きるように思っています。
私も昔は、質の高いインプットを得られればおのずとアウトプットも高品質になる、と勘違いをしていたのですが、インプットの質とアウトプットの質は比例しません。言葉を言い換えると理解しやすいかと思います。
インプット＝知識
アウトプット＝成果・結果（≠知識）
知識があろうがなかろうが、成果を出すことがアウトプットなんです。
引越しの例で言えば、一軒家からアパートに引っ越す場合には、「知識」として床面積が減少することはわかるし、数値化すれば床面積の比率も分かるはずですが、だからと言ってその知識が「何を引っ越し先に持っていき、何を捨てるか」という結果(成果)には何ら影響を及ぼさないわけです。プログラミング講義に関しても同じで、知識を「覚える」ことだけをすればいい講義になるか、と言えばそれは違うわけです。ただの「知識のひけらかし」でしかない。
よく「自分の言葉で講義をすること」と言われます。講義の内容を自分のモノにせよ、とも。ただの知識として覚えるのではなく、知識を「自分でやってみる」＝アウトプットを出すことで、そのアウトプットを自分のインプットとして置き換えて考えてみると、「あれ？これでは説明が足らないな」とか「この部分は自分の理解が足りてないな」とか、アウトプット自体の品質をセルフテストすることができるようになります*6。
もちろんインプットがなければアウトプットを出すこともできません。成果・結果は知識に裏打ちされたものです。先ほどの引越しの例だと、床面積が50%減少することが分かっているのに荷物の絶対量が10%しか減っていない(という結果)となれば、当然荷物は引越し先では入りきらないわけですし、そもそも床面積が減少するかどうかわからない状態で荷物を減らすことはできないわけです。知識以上のアウトプットは出せません。となれば、知識も積極的にインプットとして取り込まなければいけません。ただ、インプットを得ることは今の世の中ではそれほど難しいことではないわけです。ネットを見れば情報はあるし、本を読まなくても音声や動画で情報を得ることだってできる。いわゆるスキマ時間でインプットを得ることはできるのですが、アウトプットを出すためにはスキマ時間で何とかなるレベルではありません。きちんと時間を取ってアウトプットを出さなくてはいけません。だから、とにかくアウトプットを出しまくる、出してみて、情報が不足しているようであればインプットを得て、更にアウトプットの質を高めていく。そうすることでアウトプットの質が高まっていくんだと私は考えています。
*1:捨てるモノが果たして所持品の8割であったかどうかは検証をしていませんし、家人の個々の判断ですのでわかりません。私自身、目指したのは8割減ですが、実際に捨てたのは半分ちょっととかそれくらいではないのかと分析をしています。特に捨てた/処分したのは衣類と書籍・メディア類。メディアについては「自炊」してデータ化できているモノについては処分しようと当初から考えていました。
*2:「断捨離」とか「ミニマリズム」とかいろいろありますが、私自身はミニマリズム的な考え方で持ち物を減らしていきました。一番特徴的なのは、「押し入れにずっと眠っていたモノは問答無用で捨てる」です。押し入れに眠っていたモノは、時期によっては前回の、つまり今回の移転元に引っ越してきたときからずっとそこにいたモノもありました。20年近く経つでしょうか。20年必要としていなかったモノを、例えば明後日必要とするか、と考えました。もちろん、ごくごく少ない確率で必要とするかもしれませんが、まぁ9分9厘＝99.9%いらないはずなんです。だとしたら処分しても問題ない、と判断できるわけです。
*3:考え方だけじゃないですが、キライなのは。
*4:正直に言えば、プログラミング講師の前に別の、マーケティング系の講師としての登壇経験があるので、講義をするのが大変であることは身をもって知っていましたが、実際にやるとやっぱり「大変だなぁ」と感じるわけです。
*5:会議での発言を一切行わず、会議終了後に休憩室で「いやぁあの会議退屈だったよね」と愚痴るような人は間違いなくその手の人たちです。退屈だと思うなら「そんな上意下達のためだけの会議は即刻辞めて欲しい」と会議の場で発言するか、会議の場を立ち去るかした方がいい。私は立ち去ったことはないですが、会議の運営について文句を言ったことはあります。
