読者です 読者をやめる 読者になる 読者になる

ツナワタリマイライフ

日常ネタから技術ネタ、音楽ネタまで何でも書きます。

問題を設定できるまで考えること、そして考えることを考えた

はじめに

勉強の哲学を読んで、猛烈に考えることを考えた。ちょうどそのとき会った同期に「これ(勉強の哲学)面白いから読んで意見を聞かせて欲しい」と言ったところソッコーで読んでくれていろいろアドバイスをくれた。slack上のログをまとめたものです。

take-she12.hatenablog.com

以前は目標の呪いについて語り合ったT氏ですね。

take-she12.hatenablog.com


勉強のコンプレックス

(僕のブログに書かれている、自身が勉強が下手だという記述に対して)

T「最初に聞きたいんだけど,なんで勉強下手やと思うん?」

僕「客観的な根拠、数字はない、主観的な体感で、かけた時間の割に成果が小さいと感じる。「努力」は他者から認められることはあるけど、それがアウトプットにつながってない、アウトプットを褒められることはないから、インに対するアウト効率、すなわち勉強の得意度、が低いと認識してる。まぁ元々持った劣等感(コンプ)がそう言わせてるだけかもしれん、なかなかそいつとは離れられない。」

T「コンプレックスは拭えないものだからね.  俺も自分の指導教官の圧倒的すぎる数学力*1をみせつけられて,すごくコンプレックスを抱えたこと有るし.」

僕「コンプがあろうとなかろうと、自分がしたいことには抗えないから、共存するしかないね。」

T「俺が考える勉強ができる人っていうのは具体化と一般化ができる人で,そういうことができる人は自分で考えることを主軸にしてるからか,ものをわかったことにしない傾向があると思っていて.逆に器用貧乏な人に多いなと思うが,わかったことにしちゃう人かな.あるいは飲み会の小ネタにしか使えない段階で終わってしまうと言ってもいいかもしれない.へぇそうなんだ面白い.そういう考え方もあるかもねーで終わってしまうというか.言い方悪いかもしれないけど,(僕)もそういう傾向を感じときがあるかな.」

T「で,勉強にコンプレックスがあるんだったら,俺からのオススメは自分しか気にならない問題を提唱することだと思う.答えは最悪どうでもいいし,無理に答えを出す必要なんてないから問題を提唱することが大事だと思う.そうすると,自分らしさも出るし,自分が世界で一番詳しい問題を作れる.」

僕「そのとおりだね。問題を提唱は友人にはすることはあるけど、相手を選んでるかもしれない。あと、"問題"の認識がまだあってないかもしれない。」

わかったことをわかったことにしない。ここでいう「問題を作る」ということは、深く深く自分で考えた結果でしかできないことということに、このあと気づく。つまり問題を作れるようになることを目標にすれば今より勉強が得意になる可能性を示唆したようだ。

知りたいことと考えたいこと、勉強と研究

T「例えば,この本を読んだ後何を考えたいのかって具体的に何かあるん?」

僕「哲学という学問がわからないから知りたい」

T「それは,知りたいであって,考えたいじゃなくない?言い方を変えると,答えるの載ってる本を探そうという行為であって,自分の頭で考える行為じゃなくない?」

僕「ないね」

T「もちろん,哲学を知りたいという興味を持つ事自体はすごくいいことだと思う.」

僕「考えたいことは、言葉が伝わる、伝わらない、ということ。伝わったとは何を持って伝わったと言えるか、とか」

T「それはこの本を読んでさらに具体的な問いになったって感じ?」

僕「言葉の意味は環境によって変わるし、無限に変わり得るという方向の見方に刺激をもらっただけで、問いそのものは具体的になっていない。ヒントにはこれからなるかもしれない、という感触程度。」

T「なるほどね.問いに対する,解答の切り口を一つ得たって感じなわけか.」

僕「うん、だから伝わったり伝わらなかったりするよね、そりゃ、という納得はある。でもまだ、自分の問いには少し遠い気がしてる。」

T「ほうほう.そこを深められたらいいね.」

T「ちょっと話を戻すけど,具体的な問いを考えるっていうのは,勉強というよりは研究かもしれない.でも,頭のいい人は「勉強」と「研究」をうまく走らせられるんだよね.」

僕「勉強と研究の違い、言えない」

T「だから,この本を読んだときに「勉強」だけに偏重させてちゃうまくいかないだろって思った.」

T「Twitterでみたいいなと思った言葉は.勉強は既にあるものを自分の中に再構築すること,研究はまだ知らないものを自分が新しく作り出すこと、だったかな.」

僕「(自分にとって)まだ知らないものは、研究でも勉強でもありえてしまう?いわゆる新規性が絶対?世の中にとってか、自分にとってかで、線を引ける?」

T「俺が線を引くなら,勉強とそれ以外になると思う.勉強は本を含め答えをベースに理解する行為だと思っている。知らないものを,自分で考えるのは一種研究だと思う。他の人から成果としては認められないかもしれないけど」

僕「なるほど、行為ベースね」

T「うん」

僕「知るか、考えるか?(めっちゃ雑にいうと)」

T「そうね」

僕「どっちも好きだよ」

T「頭がいい人は,考えるための問題がうまい印象がある.話を循環させちゃったけど,(僕が)頭の良さみたいなものにコンプレックスを感じるなら,問題を作ってみてはいかがかと.」

僕「知ることはできる、考えることはできる、うまい問題を作ることができるかというと、??となるな。何だろう」

T「それは問題を作る能力だよ.鍛えるべきだと思う.」

T「俺が考えるんだったら,言葉 が全て同じ意味なら,必ず伝わるはずだ.でも伝わらないということは言葉には揺れが有る.一方でこの本は言葉自体に共通の意味,言語らしさ?みたいなものがあるとも言っていて、それは複数の環境を体験することで見えると言ってる.じゃあ.自分の気になる世界で,例えば自分の会社の中の常識,IT系の勉強会に来る意識高い系のエンジニアの常識,それらを比較して共通になる言葉や意味って何だろう?とかかな?」

僕「問題にするまで考え尽くせてないのかもね」

T「そうかもしれない.」

僕「さっきの例で言う飲み会のネタのくだりというか。面白いとまでは思うんだけど、考え尽くされた問題になるまで考えられてない。 まったく全部がそこで止まってるわけでもないと思うけど、そういうところは多いと思う。」

T「それが研究の第一歩だし,自分で深く考えるようになる第一歩だと思ってる.俺も全部をわかってるわけじゃないし,参考にできる範囲でやってくれたらって思う」

物事を知る、考える、勉強する。。。そういう行為は大きく、すでにあるものを自分が理解する(再構築する)=勉強と、知らないものを(自分で考えることによって)あらたに作り出す。そのためには自らなぜ?を繰り返して問題設定をする必要がある。

勉強と研究が説明できなかったように、両者を意識的に分けられていなかった。

僕は考えることが好きなはず。だとすれば、問題設定ができるまでに考えを尽くせていないのか?となり、そうして考えるとは何か?という闇にハマっていく。(笑)

深く考える

T「深く考えるってさ,具体的にどういう行為だと思う?」

僕「それがわからない戸惑いやぞ(笑)」

T「これに関しては(勉強の哲学で出てくる)アイロニーだと思ってて。例えば、第1段階はA→Bっていう関係を見つける、第2段階はAを含むさまざまなものとBを含むさまざまなものをの関係を見つける.それの繰り返しなのかなって思う.」

僕「それに気づけるとすっごい気持ちいいのよねぇ」

T「そうだよね.で,もちろん全然気づけないことが多い.」

僕「多い」

T「でも,そういうのを繰り返しながら第2段階にどうやって至るのかを試行錯誤するのが深く考える行為で一番大事だと思う」

僕「考えたいことを考える、ことにまだ慣れてないように思う。ご飯を食べたいように、ギターを弾きたいようにそうあれたらな」

T「慣れですぜ。1年ぐらいすれば慣れてくるよ.きっと」

僕「この1年で慣れるとする。意識的に考える時間をとりたいなとは、根拠なく思っていたんだ。」

僕「まだ、書くこと、アウトプットすることと、考えることがうまく分離できてない気がする」

T「それは俺も全然できないけど(笑)アウトプットは未来への投資だと思って作ってるかな。考えること,及び,消化することがメインだけど,いつか忘れるからその時のためにアウトプットを作るイメージ。」

僕「考えることの、考えた!ということがわかってないから混乱している」

T「なるほど.考えるはどういう行為なんだろうね.わかってしまえば簡単なものを,試行錯誤して見つける行為?迷路でゴールを見つけるようなものかな?」

僕「考えたいと思いつつ、何をすれば考えたといえるかがわかってないから、自分が考えていることに自信が持ててない」

僕「言葉にできた!(考えられてる?)」

T「考えるって言葉は曖昧だからな.結果も伴わないように使われるから考えたのかどうか判断しづらいし.」

僕「考えるって言葉は曖昧。考えるって行為は曖昧か、あるいは行為であるなら曖昧ではないか」

T「行為として明確にできてるなら曖昧じゃないかもね.」

わかってしまえば簡単なものを,試行錯誤して見つける行為? 迷路でゴールを見つけるようなものかな?

僕「これはわりと腑に落ちてる」

T「お,ありがとう.」

僕「考えることを考える」

T「メタ的ですね.こういうことを話してると会社休みたくなるよね.」

僕「会社休んで考えることを考えたいね。考えないで考えないでいる会社にいるより」

T「そうね.考えてもどうしようもなくて,こなしてる会社よりかな」

僕「話戻るけど、やっぱり書くことを通じて考えたい。補助輪みたいなもんだ。一時期より書く量減ってるので、またふやそう。」

T「うむうむ.俺は手書きとPCとホワイトボードをどう有効活用するか考えたいな.」

僕「のipad proもあるしね」

T「ホワイトボードを前にしゃべりながら解説するといろんなアイディアが降ってきて,答えが目の前にあるとそれを写経してしまって何も考えてないんだなって感じる」

僕「降って来て、それを表すのは、考えが意識的なところから離れてるだけで、考えてると言える気がするよ(また混乱)

僕「考えることを考える夜であった」

T「wwwwいいね」

おわりに

考えることを考えて会社を休みたくなった僕らであった。

思ったのは、「なぜ自分は勉強が下手だと思う?」と僕自身の発言へ問いかけるところから話をはじめるアプローチが上手だなと思いました。だって「ほんと勉強下手だよねいったいどんな勉強方法とってるんだい?」などと言われると(自分で言ってるとはいえ)「はぁ」ってなるわけで、相手に言わせるって大事だなと思いました。

主題としては「問題設定をする」(あるいは、問題設定ができるまで、考える、それも深く)ことをおすすめするよという内容だった。まぁこれでもよく「酒と食べ物の合うって何!?」とか「恋愛の好きと友情の好きに区別はない(持論)」とかよく同期氏に展開して突きあわせたりしてるんだけど(笑)もっともっと問題の数を増やしたい。

まだ具体的に「考える」こと「問題設定する」ことに対して、どうなれば達成なのか、これから僕はどう動けばいいのか、具体的には分からないけど(そもそも考えることや勉強することに終わりはないのでした)今回考えることを考えた、勉強することを考えたことは僕に大きな刺激をもたらし、実際に行動も変化しています。

いつもいつも仕事のこと、日常のこと、キャリアのこと、悩んだりするごとに真面目に、冷静に話を聞いてくれて、丁寧に言葉を届けてくれてありがとう。感謝します。

*1:彼は数学科卒で今もバリバリ数学やってる数学マンである

"すべての教育は「洗脳」である 21世紀の脱・学校論" を読んだ

はじめに

読んだ。

学校教育が国民に「我慢こそ美徳」を強いて、自ら行動せずブレーキを踏む教育、本書で言う「洗脳」をしてきた。その結果「したいことがあるけどできない」人間が増えている。それは全て学校の洗脳のせいだから今からでも自分のやりたいことだけをやりなさい。

これが本書の主張だと思う。

内容自体はそんなもんなんだけど、ちょっと自分とも照らし合わせて考えたいのでブログを書くことにした。

学校教育と「常識」を考える

ここで簡単に「知識」と「常識」の違いについて触れておこう。(略)常識とは「解釈」である。主観の入りまくった、その時代、その国、その組織でしか通用しない決まりごと。それが常識である。(p20)

そして学校は常識を植え付ける場所である、それが洗脳であるという主張だ。

僕はこの文章を読んで、学校が常識を植え付けるとともに国民をふにゃふにゃにして国家最高仲間最高にする、従順に何でも目上のひとに従うようにする、そういう意味で洗脳している、とまでは思わない。

ただ、「常識」という言葉については中学時代、高校時代にひどく疑ったことをよく覚えているのでここで語りたい。

「常識で考えろ」と怒られたことがあった。そのときは、何も言ってないなと思ったし、それが我々が知るべきことだとしたら、それを教えるのが教員なんじゃないの、教員の役目でないとしたら家庭なんじゃないの、そもそも常識ってなんだよ、(世の)常が識別している事柄ってなんだよ、誰が決めるんだ、誰が定義するんだ、どうやって決めるんだ、どうやって知るんだ、って。高校時代かな。怒りとともに考えた覚えがあります。

常識という言葉が僕に通じなかったし、常識という言葉に猛烈に違和感を抱いた。この感覚は今でもある。

常識を教えるときに、常識という言葉を使ってはいけないと僕は思う。

常識がなくても(あえて常識という言葉を使っています)いいとは僕も思わない。ここで使う常識は、おおよそ「マナー」に分類されるかもしれないし、「教養」と語られるかもしれない。「常識」は概念であり、おそらく都合良くしか使われていない。「常識がない!」はもう1歩踏み込んで言わないと「俺が不愉快」「みんなやってるからやれ」「いいから言うことを聞け」と言っているようにしか思えない。

「常識」は「常識」という言葉以外で説明することができるんじゃないか。マナー、法律、文化、、、そこまで落とし込めば「そうする必要性はないけれど、この社会ではこうするひとが大半で、特に何も考えずにそうしている。君がどうしても受け入れられないならそれは構わないけれど、いったん習ってみてはどうだろうか」という風に言えるだろうし、おそらく常識を課すシーンってマナーあるいは犯罪にあたるシーンなんじゃないだろうか。

「ひとが話しているときに遮る」ことを「常識がない」と言うこともできるだろうし、送ったメールに返事をしないひとに「常識がない」と言うこともできるだろう。だけどそれを常識として相手を攻めてどうなるんだろうか。

そもそも文化的に解釈が異なったりする、すなわち生活してきた社会の習慣の積み重ねが「常識」にすぎず、先の引用にある通り時代によって変わるもので、常識そのものは中身がない。

だから、「ウチの後輩常識なくてさぁ〜」という話には「どこがどうダメなの?」「そのダメなところを教えてあげなきゃ」「どうしても無理なら切るしか」の3つにしかならない。まぁ、常識を攻撃する意味は、まったくないのだ。常識がないと感じるそのポイント、あるいは共通する考え方を教えてあげないとな、と思う。

結論として、僕は学校が常識という名の「従順」を植え付けるために学校があるとまでは思わない(これは現場の教員の話も聞いてみたい)が、常識という言葉は嫌いだし、疑うべきだという点では同意しました。

学びとは没頭である

「学び」を楽しんでる人は違う。没頭している人にとっては、正解が見つからないことも、自ら動かなければ取り組むべき課題が見つからないことも、没頭する対象がある限りすべては「楽しい」ことだ。だから、彼は暗中模索を繰り返す。つまり没頭は、人を決して立ち止まらせないのだ (p89)

この章で著者は「やりたいことが見つからない」「やってはみたけど没頭できない」「収益化できない」というひとに対して、自分がやりたいことをやれと返していて、イマイチ本質的な回答になっていない、あるいは根拠に乏しいと感じる。

自身のインターネット黎明期に遊んだ経験が、楽しいと遊んだ経験があとに生きた、だから売れる売れない稼げる稼げない考えずとにかく没頭するんだ、という意見は、正しいと思う。しかし、「楽しいことやるんだよ」が、洗脳を浴びてきた「でも。。。」のひとに届くかというと、これでは届かないと思う。

僕自身はやりたいことを自覚的にやっているものの、真にやりたいこと - かどうかは自分で決めるので何とも言い難いが - というより、大きな変更を伴うことは行ってきていない。教育を受けてきた通りの、義務教育、大学、就職というコースを選んでいるので、おそらく対象読者であると思う。

そもそも、好きなことがないひとは、本当に好きなことがないのだろうか。

好きなことを探す力、何かにワクワクする感覚、好き・やりたいを自覚する力、もしそれそのものが低下しているとすれば。それがブレーキを踏んだ状態であり、本書でいう学校教育の洗脳を受けた状態だとしたら、やはり前提を文章で説いたとしても、「やりたいことをやれ」は効果的ではない。

具体的に落とすならば、「考えるより先に行動する」「publicな場所におく(公開する)」「考えたことを文章化する」あたりを届けてみたい。

行動できるならそれはもちろんしたほうがいいし、ひとの目に触れるということは、ひとの目に触れられる状態に具現化するということだし、3つめはまさに具現化すること。

おそらくやりたいことをやるにも訓練が必要なんだと思う。

自分自身が何をやりたいかなんて、なかなかわかりはしない。

そのための基礎トレーニングとして、僕なら考えたことを文章化することを勧める。文章化すれば、その時その瞬間において、そしてそのコミュニティにおいて、1つの事実として絶対化される。(解釈の余地は当然残りつつも)考えたことがある言葉として絶対化された場合、それを仮説として次の考えにいける、あるいはそれは考え終わったこととして、次の考えにいける。このプロセスが、次々に考えることができ、その結果自分が真にやりたいことを見つける確率をあげるのだと思う。

自分1人で、じっくり考える。よく、自分と向き合う、なんて言うけれど、考えていることを考える。文章にしながら考える。あれでもない、これでもない、ちょっと違うかも、うまく言えてないかも、それでもいい、そのときその瞬間の言葉として絶対化すれば、あるいは別の言葉で言えば現時点での言葉として「有限化」すれば、少しずつ整理されていくはず。

このプロセスを取らずに単にぼんやりと「ああ会社やめたい」「ああ学校行きたくない」「ああ有名になりたい」と考えるだけじゃ、何も変わりはしないと思う。

僕なら、堀江さんに変わって、自分でブレーキを踏んでいるひとには上記のことを伝えたいと思った。

おわりに

思いの外長くなってしいまった。本書の主張の批判や、解釈というよりは、本書の内容をヒントに、自分の考えを深める記事にした。

僕も常にうつりかわるやりたいことをどう捕まえて、どう自分のものにして、どう吐き出すか常に模索中で、上の言葉は自分の経験から書いた。最近あまり文章を書いたり、じっくり考え抜く時間が減ってきたので、また意識的に増やしていこうと思う。

「勉強の哲学 来たるべきバカのために」を読んだ

はじめに

読んだ。

勉強の哲学 来たるべきバカのために

勉強の哲学 来たるべきバカのために

実に面白かった。本書で学んだ勉強の仕方を、このブログでも習ってみようと思う。

読み返しながら、自分でもう一度味わって、自分の感想を言うような内容なので、本そのものの紹介にはならないかもしれないし、読んでない人が見てもあまり面白くないかもしれません。

第1章 勉強と言語 言語偏重の人になる

勉強とはかつてのノっていた自分をわざと破壊する、自己破壊である。言い換えれば、勉強とは、わざと「ノリが悪い」人になることである。(p20)

勉強は自己破壊であり、ノリが悪くなることである。それは「コード」と呼ばれる、環境特有の「こうするもんだ」から離れて、考えるから、その環境から自由になろうとするからである。

環境特有の、コードに無意識レベルで支配されているという実感はもちろん普段からなくて、でも確かに、それはあると確かに実感できる。環境が変わると、のちに出てくるように同じ言葉でも通じなかったり、例えば業界特有の言い回しがあったりする。あれもコードだ。

言葉の意味は環境のコードのなかにある (p33)

僕はこれまで言葉が持つ意味は何かを、とことん考えてきた。言葉が伝わったり、伝わらなかったりするのはなぜか。言葉には不思議がある。そこに言葉がコードに支配されているという観点はこれまでなかった。それは当然で、言葉の意味はコードによって変わる。あるいは、別のコードに支配されている人間同士であれば当然解釈は異なり、伝わったり伝わらなかったりするのだ。

もっと言えば、言葉はただのツールで、言葉の持つ意味以外をいかにして伝えるかが大事だとも思っていた。伝えるために、言葉は道具として存在するが、絶対に完全にはならない。完全に言い尽くすことはできない。だけど丁寧に言葉を選ぶ。わかったようなつもりに、いかに近づけるか。本書とは方向は違うが、僕は伝えること、伝えたいこと、そのツールとしての言葉に、昔から興味があった。そういった点で、コードに支配される言葉という観点は非常に面白い。

言語それ自体は環境から分離している。言語それ自体は、現実的に何をするかに関係ない、「他の」世界に属している。(p36)

言語の言語的性質は所詮コードによる。言語から言語的性質(目的的な、コードに支配された意味)を剥ぎ取ったあとに残る、本書でいう「言語それ自体」「器官なき言語」が存在する。究極的に言語はいつでもコードに支配された言語的意味から解放されて、バーチャルな言語世界に生きることができる。言語の言語的意味ばかりに執着して、僕はやはりコードに支配されていました。

慣れ親しんだ「こうするもんだ」から、別の「こうするもんだ」へ移ろうとする狭間における言語的な違和感を見つめる。そしてその違和感を、「言語をそれ自体として操作する意識」へと発展させる必要がある (p52)

言語の言語的な意味をいったんバラし、本書でいう言語の玩具的に捉える、この意識こそが重要だと説いていますね。

新たな環境(コード)に入った時に違和感は、確かに感じます。そこに集中したことは今までなかった。

僕は「言葉遊び」が好きだと、よく仲間に言われます。事実、そうだと思う。 それは本書で言う言語の玩具的使用だったし、後に出てくる享楽的快楽に基づいて、言語を操っていたのだと、まさに思います。

言語の言語的意味を一旦バラし、快楽と、言語的意味から一見離れた言葉を組み合わせて、あらたな「ノリ」として言葉を発し、おそらく僕自身のコードとして仲間に伝染させていく、支配していく、そういうシーンがあります。このように説明できるとは、まさか思わなかった。

第2章 アイロニー、ユーモア、ナンセンス

この章ではまず、端的に要旨を整理してみる。

  • 環境のコードは常に不確定であり、揺らいでいる(p67)
  • アイロニー - 超コード化を進めていくと、コード不在の状態に近づいていく(p86)
  • アイロニーは、「言語なき現実のナンセンス」へと突き進んでいく(p88)
  • ユーモア - コードの不確定性を最大限にまで拡張してしまえば、どんな発言をつないでもつながる、つながっていると解釈しさえすればいい、ということになる(p98)
  • ユーモアの極限は「意味飽和のナンセンス」(p99)
  • 縮減的ユーモアでは、話を細部に絞るだけではなく、意味の次元自体を縮減する(p105)
  • 縮減的ユーモアの極限は「形態のナンセンス」(p108)
  • 個々人がもつさまざまな非意味的形態への享楽的こだわりが、ユーモアの意味飽和を防ぎ、言語の世界における足場の、いわば「仮固定」を可能にする - 「形態の享楽によるユーモアの切断」(p112)
  • 非意味的形態としての言語が刻み込まれた時の痛みを享楽するというのが、言語を使う人間にとって、根本的なマゾヒズムである(p117)

これは後述する読書ノートのようなもので、引用しつつ引用と自分の考えを別にしないといけない、ということで出展を書いてみています。(とはいえ、引用部分以外でも本書の言葉に支配されたように語ってしまっていて、よくないなぁとは思います)

この章は本書にとって核な部分だと思います。個人的には、ユーモアの拡張によって言語が無限に広がっていくことはないと言っていて、それは確かにそうなんですが、それが享楽的こだわりによって仮固定されるというのは「そういう説もあるかぁ」ぐらいで、あまりしっくりは来ていません。

単純に引っ越すコード、それがリアルであろうがバーチャルであろうが、意味の拡張は個々人の人生分しか広がりようがない。それを経験を踏まえた享楽的こだわりによって仮固定と言っているのはわかる。アイロニカルな例でもそうだが、原理的に極限は考えられるが、実際には起こりえない。

後に出てくる有限化を、どうやって有限にするかを、考えたい。

第3章 決断ではなく中断

僕が言いたいことはシンプルです- 「最後の勉強」をやろうとしてはいけない。「絶対的な根拠」を求めるな、ということです。それは、究極の自分探しとしての勉強はするな、と言い換えてもいい。自分を真の姿にしてくれるベストな勉強など、ない。(p136)

勉強はきりがない、それはアイロニカルに追求していっても、ユーモアに目移りしていったとしても、終わり到達することはなく、全て学んだという状態に達することも決してないということ。

ではどうやって勉強を有限化すればいいのか。何の中で比較し、選択すればいいのか。それは信頼できる情報か、自分の享楽的こだわりで選ぶことが考えられる。

自分なりに考えて比較するというのは、信頼できる情報の比較を、ある程度のところで、享楽的に「中断」することである。(p140

そして決断について、気をつけよと主張しています。

絶対的な根拠はないのだ、だから無根拠が絶対なのだ。だから - ここで起きる論理の飛躍に注意してください - 、無根拠に決めることが、最も根拠づけられたことなのである。次のイコールが成り立つ、絶対的な無根拠=絶対的な根拠

極限までアイロニーを繰り返した末の「俺が決めたんだから決めたんだ」は、根拠がないことが根拠になっているということ。

僕は決断主義でした。

正確には、決断主義的に、中断していた。信頼できる情報から、比較するんですが、それは享楽的こだわりに支えられていたかもしれませんが、決断し、納得し、納得したことを根拠にし、振り返らないような生き方をしてきました。

本書の立場は、無根拠を根拠にすることが他者の絶対服従であり、それはコードや環境から自由になろうということと反する、ということでした。

一方で、「中断」と(無根拠を根拠とする)決断はなかなか紙一重だと感じます。

ではどうやって中断が起こるのか、比較を続けた上での、享楽的こだわりによる仮固定のような、中断の仕方が起こりうるのか。

自分自身が持つ「無意味なこだわり」によって選択し続ける。その無意味なこだわりは実は無意味でなく、自分自身の過去の、享楽的こだわりの連続によって生まれたものだ、ということはわかる。

無意味なこだわり=享楽的こだわりによって、比較時の足場を仮固定する。ではどうやって無意味なこだわりを自分自身で何度も生成することができるのか?それには自分が過去にどういう出来事があって今のこだわりが生まれたかに意識的である必要があるとし、自身の欲望年表を作ることを勧めている。

そうやって自分の享楽的こだわりを分析し、どんどん移り変わって、どんどん別のバカになりなさい。どんどん別のこだわりを持ち、比較を続け、勉強を続けなさい、そう主張している。

ここでこの章は終わってしまうんだけど、欲望年表は別の機会に作ってみようと思う。自分のこだわりはここ数年の中でもかなり変化しているように感じるので、分析したい。

そして自分の決断が、中断であるのか、自分で言えるかが、わからない。

第4章 勉強を有限化する事実

ここでついに実践的な技術について触れます。

新しいことを勉強することは、専門分野に入ることです。

「まとも」な本を読むことが、勉強の基本である(p171)

この章は唯一具体的なテクニックを述べているので、理解はしやすい。

  • 入門書から入る
  • 入門書は複数を比較する
  • 教師は有限化の装置である
  • 専門書の信頼性 - 知的な相互信頼の空間から信頼を受けているか(p188)

ここも入門書、専門書、基本書の選び方は、やはり信頼ある(比較を続けている)ひとに従うことを勧めている。

僕もよく、新しいことを学ぶときはまず本屋にいく。そこでもまた、複数の入門書を見て、リファレンス的な教科書を買って、実際にやってみて、考えてみて、書いてみて、あきらめたり、範囲を限定したり、わからない点は深く考えないようにして - それこそ「有限化」して、やっていたので、おおよそ本書の言う通りの勉強法を取っていたことになる。もちろん選択した本が信頼に値するか、までは比較は十分でなかったかもしれないし、それこそ決断主義的に決めていたかもしれない。

僕は勉強はあまりうまくないと思っているので、選ぶものが悪いのか、有限化が下手なのか、それともそのコードのテクストの読み取り方が下手なのか、どこが足りてないのかはわからない。ただ、少なくとも勉強は好きで、いろんなことに目移り的に興味を持つ性格に(幸運にも)あるので、これからも勉強は続けたい。そう思えた本だ。

その他、この投稿では残念ながら徹底はできていないが、

どこまでが他人が考えたことで、どこからが自分の考えなのかをはっきり区別して意識しなければならない。(p199)

出展を明らかにする。研究・学問では当たり前のことですよね。それも意識的にできていなかったですね。

その他、読んだときにメモを箇条書きで取って結びつけたり、kindleだとハイライトが楽なんですけど、紙の本だとつい億劫になって、というか集中したくて読みながらメモ取りたくないんですけど、ちょっとやってみます。

おわりに

僕はこの本で勉強の何を学んだのか。

  • 言語は「こういうもんだ」という環境のコードによって支配され、言語の意味的意味はコードに依存するという考えに納得した
  • 深く勉強するためには、アイロニーにもユーモアにも無限には行けず、おそらく自分の享楽的快楽に基づく「こだわり」によって有限化される ということにも納得した

一方で、

  • 勉強をし続けることと享楽的こだわりの変化の行く末、果ては何だ?(いや、だから、勉強の完成はないんだ)
  • そうであれば、本書の主張は?

とループしてしまった。(笑)

本当にこれが勉強の入り口なんだろうと思う。勉強には終わりがないからこそ、勉強をいかに有限化し、いかにこだわりにって変わり続けることができる。「それこそが究極の享楽的快楽だ」なのかもしれないし、「享楽的快楽」があるからこそ、勉強ができる、なのかもしれない。それはどちらだろうな。どちらでもあるかもしれない。

いずれにせよ、自分がこれまでぼんやりと感じていたこと、ぼんやりと興味があったこと、興味があったことを具現化してくれた、さらなる一歩に導いてくれたこの本を読めてよかった。著者の千葉先生に感謝。

バンドのHPを作成したのでやったことをまとめておく

はじめに

前回も自分のソロプロジェクトのHPをAWS上でなんやかんや作って、今回はそれと同じことをしたことになる。

take-she12.hatenablog.com

その5まであるが省略。

完全に同じことをしたわけでもないし、前回と違う部分、自分の過去の記事が不十分だった点もあるので大きな流れとしてやったことを整理しておく。

Architecture

AWS上で作った仕組みについての絵。 f:id:take_she12:20170416173649j:plain

大きく以下のセクションに分けられそうだ。

  1. S3にコンテンツをアップロードし、webホスティングをした
  2. 独自ドメインを取得し、Route53で名前解決できるようにした
  3. cloudfrontでcache設定と、cloudfront経由でしかS3バケットにアクセスできないようにし、Route53のAレコードをcloudfrontのドメイン名に変更した。
  4. circleCIからアクセスできるようIAMでユーザを作成し、githubのpushをトリガーにgithubとS3のコンテンツを同期した
  5. HPそのものをpure.cssを用いて作成した

順におさらいしていく。

S3

S3への静的コンテンツのアップロードは非常に簡単。「S3 webホスティング」で検索すれば有益な情報が山ほどでる。

注意点はバケット名をドメイン名にすることぐらいだが、cloudfrontを使うなら必須ではないのかな。

Route53

ドメインは前回と同じくムームードメインで取得。取得時にはDNSは「今は使用しない」にしておき、Route53に登録後に出てくる4つのawsのname serverをムームードメイン管理ページで登録してやる。

DNSの伝搬は結構時間がかかるイメージだが、数分で完了したから驚く。

ちなみにここでの登録はCNAMEではなくAレコードかつRoute53の独自仕様のALIESで、独自ドメイン→S3バケットへの変換を行っている。この理由としてはRFC1034でトップレベルドメインにはCNAMEが使えないからだそうだ。

サブドメイン無しでAkamaiの利用ができなかったのでCloudfrontに切り替えた件 - 日記っぽい何か

wwwのようなサブドメインを切らなくても登録できるから非常に助かる。

cloud front

今回はhttps対応を行っていないので、新規登録したあと、Route53のAレコードのALIESをS3バケットからcloud frontのアドレスに変えただけだ。

このときS3バケットのポリシーも一緒に更新するよ、と選んでおけば勝手に更新されるから楽。

cacheも前回と同じく1日。1日の遅れぐらい気にしない。今後0時ちょうどに新作リリースの発表。。。とかがあるなら別だが。

circle CI

前回と同じくcircleCIを採用。ここで少しハマって、前回登録してるからAWSへの認証は新規にしないでいいだろう、と思い込んだんですが、IAMユーザのアクセスキーとアクセスシークレットの登録はprojectごとにしないといけないみたい。

で、アクセスシークレット は発行時にしか見れないから、再度生成し、前回登録したprojectも登録しなおしました。

pure.css

前回はskeltonを採用したんですが、今回は違うものを使ってみようと思いまして、yahooのpure.cssを使ってみました。

さすがに閲覧のみの静的サイトにbootstrapみたいな重たいもの採用する気にはなれないし、S3は転送量で課金されるので軽いに越したことはない。人気も高そうだったので。

あ、遅れましたけど実際に作ったサイトが以下。

猫の休日

今時はスマホで見るのでレスポンシブ対応。まぁこれpure.cssのサンプルまんまなんですけどね(笑)自分で作ろうと思いつつ、まだcssの中身全部よみとけていないのでこれからゆっくり。。。

github

githubはこちら。

github.com

おわりに

ドメイン購入してAWSの設定、circleCIとの連携、pure.cssを使って静的コンテンツ登録まで土曜の夜と日曜の朝で計4hほどでできました。便利な世の中だー。これでドメイン年間700円、AWSの使用量月数百円って安すぎるよね。。。

余談

きになるお値段、もう1つ似たような仕組みでサイト運用しているのである月の課金を見てみましょう。

f:id:take_she12:20170416180544p:plain

数ヶ月遡ったけど0.7ドルか0.8ドルでした。route53が一番高いんですね。

とはいえroute53の課金は100万クエリを超えないと増えないので、まぁちょっとバンドの個人HPを作る程度なら心配する必要もないでしょう。

www.lancork.net

2017年1〜3月振り返りと4月目標

はじめに

見事に2月の振り返りと3月の目標設定をすっぽかしてすっかり4月です。目標を立てるという目標はとても難しいことがわかりますね!!!

実際2月〜3月は精神的に死んでたり、仕事が局所的に忙しくなったりしていたとはいえ。。。まぁあっという間に過ぎて行きましたね。

take-she12.hatenablog.com

2月目標振り返り

楽曲制作

  • [○] とけてなくなる-おかえりなさい をベース録音して公開
  • [○] とけてなくなるリリース曲にメロディを打ち込む
  • [○] とけてなくなる-シロップをmix整えて公開
  • [○] なのは ドラムRec
  • [○] なのは ベースRec
  • [○] なのは 月の光に歌うよ 作詞編曲完
  • [×] 千明さんコラボ曲のアレンジ完成

まぁ2月だけじゃなくて3月と合わせてなのでなんとも言えませんが、ほぼほぼ達成。千明さんとのコラボ曲はすっかり頓挫してしまっていますね。作詞を先にしてもらってそのあと作曲を僕がするのはいいんですが、作詞車の要望、イメージとあっているかにとても応えることができず挫折しました。

加えて、3月初旬締め切りのYAMAHAの作曲コンテストに無事応募しました。これは本当にきつかったけど応募できてよかった。

読書

  • 小説を3冊読む
  • 小説以外を5冊読む

通勤で読書の時間は微妙に増えましたね。実績だと2月は6冊。小説4冊とその他2冊ですね。3月は小説1冊、漫画2冊、技術書2冊、その他2冊。

英語

  • site reliability engeenear 1. Introduction読んでブログ書く
  • Grammer in use Unit10〜20
  • radwimpsの君の名は英語詞の聞き取りを何か1曲やってブログに書く

0ですね英語やる気ないっぽいな俺。

健康

  • 30days plank完了
  • run 月50km

2月後半かな、10km走ってたんですけど3月ぱったりやめてしまいました。

4月の目標

音楽

  • YAMAHA作曲コンテスト曲提出曲を公開
    • マスタリング、ミックスやり直し
    • ギターアレンジ仕直し
    • ドラム打ち込み微調整
  • とけてなくなるアルバムボーカル録音
  • なのはオリジナル1曲作詞作曲
  • とけてなくなる新曲2曲 作詞作曲する
  • カバー曲を1曲公開

音楽は少しずつ、進めていきたい。

技術

ちょっと技術勉強してなさすぎてやばいのでこの1冊だけはやります。

読書

  • 月10冊

ジャンルを問うことにあまり意味がない気がしてきたので。指標としてこれぐらいは目標にしたい。

健康

  • 月100kmラン

3月忙しさにかまけてカレーばっかり食べて運動全然しなくてすっかり太ったので調子を戻します。

ブログ・note

  • 月20記事

ちょっと最近記事も減ってきていて、思考の時間も減っている気がするので、毎日とは言わず、月20記事を目標に何かを書いたり考えたりする時間を意図的にとって調子を戻したいと思います。

おわりに

4月からは仕事が落ち着くと信じていますので、調子を取り戻して(本当は仕事が忙しくても自分のペースを保っていたいんだけどね)また自分のいきたい方向に進みたいと思います。

「アジャイルコーチング」を読んだ

はじめに

現在4人チームのチーム運営に取り組んでいまして、いろいろあってアジャイルプラクティスの1つ、カンバンボードを各自のタスク割りに使うようにしました。

take-she12.hatenablog.com

導入前の課題

  • あらゆる情報をGitlabに一元化しており、個人の作業状況も個人のWORK/name/README.mdに集約していた
    • 結果、報告の粒度や問題点の提起が個人任せになっており、周囲が気づきづらい
    • 頼んだ仕事が本当にそのひとに認識されているかがわかりづらい

まずはチケット化しよう。ということでgitlabのissueを導入しました。

issueを導入した結果

  • どのタスクが誰が担当しているかわかるようになった
  • タスクの状況も1日1回更新してもらうことで1日1回のペースでupdateされるようになった

課題と改善

  • タスク粒度が不適当
    • ラインをbacklog,todo,doing,review,doneとし、reviewを追加することで、「これ以上自分のやることは終わった(誰かの待ち状態)になったものをreviewにすることにした
    • 結果、タスクはreviewが入るまでが1タスクになることになった

というわけでこれからはタスクがどれだけ追加されるか、消化されるかの数値をはかって生産性を可視化しよう、ということですが、なぜこのアジャイルコーチングを手にとったかというと

  • カンバンボードを導入した結果、メンバーが指示待ち(タスクを振られるのを待つ)になってしまった
    • これは僕が最初振っていたので当たり前です。自己組織化にはほど遠い。
  • タスクの期待値がうまく伝わらない
    • 説明不足もあるんですが、タスクの完了条件、背景(なぜやる必要があるのか)を記載することでだいぶ良くなりました

というわけで、カンバンボード自体は何なくみんなに使ってもらえたんですが、チーム全体でアジャイル式にタスクをまわしていくというときに、どうやったらみんなが自分ごととして、取り組んでくれるようになるのか?そのマインド変化をもたらすために何が大事か?を考えたときにこの本に出会いました。

アジャイルコーチング

アジャイルコーチング

アジャイルコーチン

自分がスクラムマスター、アジャイルチームをリードする立場になったときの心構えの本。中でもよかったところを紹介します。

1章 コーチングの基本

コーチの役目

気づく、フィードバックする、教育する、ファシリテートする、支援する、がアジャイルコーチの役目。

今は自分がプレイヤーかつマネジメントもやっている状況だったのでとっても良くない状況。そもそも自律的にチームが動いているところにアジャイルコーチが手助けする前提ですよね。

コーチングの態度

「模範を示す」というのがありました。僕自身の経験から、ひとにやってもらうためにはまず自分がやる、ということを心がけてまして、これは間違ってなかったなと実感しました。

もうひとつ、大切だなと思ったのは「言葉に気をつける」「私が」「あなたが」「彼らが」ではなく「私たちが」「私たちの」「私たちに」と置き換える。これは全然意識がたりていませんでした。「うちのチームが」とは言っていたかもしれませんが。(笑)

とはいえ「属人化を殺す」というポリシーで仕事をしているので、特定のひとに仕事を頼むことはあれど、誰のせいとか誰がやらないといけないということはない、はず。

PrOpERサイクル

Problem,Options,Experiment,Review。

PrOpERサイクルという言葉は本書でもたくさん出てくるんですが、でてくるたびに「何の略だったっけ?」と戻ることになってました。(笑)わかりづらい。

意識こそしてなかったですが、ほぼほぼこの通りに仕事を捉えていました。

「何が問題なの?(problem)」「解決するにはどうしたらいい?複数案あるならメリットデメリットを教えて。(Options)」「じゃあやってみて。(Experimtn)」「やってみてどうだった?(Review)」の方式で問題解決に取り組んでいますし、メンバー内でも上記の対話で話を進めています。

問題はExperimentの途中であらたなproblemが発生したり、時間がたてばproblemはproblemじゃなくなったりして、それがめまぐるしいことですね。あとは時間をかけてほしいところとかけてほしくないところの認識にメンバーとギャップがあったりしました。単にこれは対話がたりてないか事前の背景共有が不足してるんでしょうが。

14章 あなたの成長

飛んで一番よかったのはこの章ですね。

情報をキャッチアップしたり、ブログでアウトプット(まさにこのことですね)したりと、自分が成長し続けるための方法がのっています。ただ、中でも一番心にきたのは「優しく」という項目。

チームで仕事をしていれば、イラっとすることもあるし、「なんであんなに時間かかるんだ?」と不信に思ったり、意思疎通がうまくとれなくて「何を言っているかわからない。。。(きっとお互いに)」となったりすることがあるでしょう。(この本でもある通り、あなたを待ち構えてる苦難、ですね)

僕自身、怒りを表面に出したり、直接誰かを批判することはしません。それでも心に刻んでおきたいのがこの"優しく"かなと思います。

自分に優しくするように、他人にも優しくしましょう。厳しく責めたりしてはいけません。誰もが最善を尽くしており、すべてのことには何らかの理由があることを常に意識しましょう。その「最善」は素晴らしいものではないかもしれません。そして、そのように振る舞う理由をあなたが理解していないのかもしれません。だから見つけるのです。推測だけで終わらせて、判断したり陰口を叩いたりしてはいけません。話し合いましょう。情報を直接もらいましょう。驚くことがあるかもしれません。

「同じ立場になるまでは、他人を批判してはいけない」という言葉もあります。人が仕事をうまくできない理由はさまざまです。私生活に困難を抱えているのかもしれませんし、仕事を失い不安を感じているのかもしれません。自分の価値観を曲げなければいけないと感じていたり、コンフォートゾーンから追い出されていると感じていたりするのかもしれません。これまでに仕事で失敗したことがなければ、それは単に運がよかっただけです。適度にストレスのかかる状況にいたことがなかったのでしょう。

これは常に、心に持っておきたいです。

幸い今の僕の職場には失敗を責めたり声を荒げるひとはいません。

おわりに

今回、アジャイルチームを見る立場にとっての心構えを学びました。自分自身についてもPrOpERサイクルをまわして、改善をはかっていきます。

「今すぐ実践!カンバンによるアジャイルプロジェクトマネジメント」を読んだ

はじめに

久しぶりの投稿です。この本読みました。

今すぐ実践!  カンバンによるアジャイルプロジェクトマネジメント

今すぐ実践! カンバンによるアジャイルプロジェクトマネジメント

今どんな仕事してるの?

今はOSS開発にCIを導入する仕事です。今時CI、ビルド自動化やテスト自動化をやってないプロジェクトなんて世の中にあるかわかりませんが、大きい会社ですので、そのあたり専門チームを作ってフォローしていくという体制になっています。

やってる仕事が多岐に渡り、単純な開発をするわけではなく、テストプログラムを書くこともあればトラブル調査をしたり、開発者に以来したり関連部署と調整したり、いろいろあります。その中でタスクが見えづらくなり、まず見える化のためにgitlab issueを使いはじめました。

そしてちょうど隣にissue boardがあったので、実践してみているところです。ベストプラクティスを学ぶためにこの本を買いました。結論、買ってよかった。

第1章 経営陣の同意を得る

もちろん、新しいプラクティスを導入する際には経営陣の同意は必要でしょうね。インターネット上のカンバンボードシステムを使うにしろ、リアルなホワイトボードと付箋を使うにしろ、お金はかかります。

幸い、私の部署では既に社内システムとしてのGitlabを使っていたのでGitlab boardが何の手続きもなく使えるということ、管理職もこういった変化や新技術導入や取り組みに関しては絶対のNoと言わないひとなので、ここの障壁は一切ありませんでした。

ただ本書にとってのこの章のいいところは、経営陣の同意を得る、というていで、読者にカンバン導入時にどれだけ時間がかかって、どんなリスクがあるのか、同時に説明できるところですね、うまいなぁと思いました。

第2章 カンバンのクリックスタートガイド

この章ではカンバンの基本的な使い方を説明してくれます。大事な部分。

手順1 チームの大まかなルーチンを把握する

これはカンバンボードのリスト(フェーズ)を割り出すために、ある程度決まった形をあぶり出しておいたほうが良いということでしょうね。うちのチームは開発チームではなく、仕事はひとと話すことから技術的解決まで幅広くあるので特に定めていません。

手順2 壁の模様替えをする

これはアナログのカンバンボードを作るという章ですね。私がgitlab boardを使ってますが、まぁアナログのほうが動かす感覚があってメンバーが乗り気になるメリットはあるのかもしれません。

手順3 混乱を抑制する

WIPの上限の設定方法について書かれています。この算出方法は普段の仕事が全て同じルーチンであるときにだけ使える方法ですね。手順1でも言った通りうちのチームでの採用は難しい。

手順4 完了を定義する

各タスクの完了基準を定めないと次のステップへ移動できない、当然のことのようにも思えますが、これはうちはできていませんでした。issueの本文に何ができたら完了か、ということを書いておくと良いと思いました。導入します。

手順5 デイリースタンドアップミーティングを行う

これも各フェーズのWIP制限が決まった上での話ですね。カードをいつ誰でも動かしていいのか、デイリースタンドアップミーティングのときだけ動かすのか、迷っています。WIP上限が決まっていれば、空いたときbacklogから必要分を移動させられる点が良いと思いました。

トラブルシューティング

充実した内容でした。フェーズごとに担当が分かれている場合は作業がブロックされることがあるようですね。そのときはその原因となるフェーズを手伝うことが有効とのこと。多分重要なのはいかにタスクを留まらせないか、だと思いました。Doingに動きがない状態が一番まずいというのは体感しています。

第3章 納期を守る

納期を守るために必要なコツが記載されています。MVP(Minimam-Viable Product)最低限顧客に渡すもの、機能を定義したり、完了予定日の追跡、それに付随するパラメータの計測。

  • TCR(Task Comletion Rate) / タスク達成率。毎日どれだけ達成しているか、もしくはタスクが移動しているか
  • CTE(Current Task Estimate)/ 現在のタスクの見積もり。
  • TAR(Task Add Rate) / タスク追加率。月初のタスク総数を月末のタスク総数から引けばどれだけ追加されたかがわかりますね。

これらをgitlab issueで簡単に取得できたらいいんですが。issueをopenした日とcloseした日がわかればいけるか。rssだとupdateした日しか取れないんですよね。。。

4章〜7章 組織ごとのカンバン導入方法

ウォーターフォール開発、スクラム、アプリケーションのデプロイメント、大規模組織、サステインドエンジニアリング(サービス継続のための欠陥対処)といったシーン、業務の種類に応じてどうカンバンを適用できるかを個別に紹介しています。徹底した現場目線がすごい。

9章 さらなる方策とカンバンを超えて

この章はカンバンがなぜうまくいくのか、その理論的解説をしています。この章めっちゃ大事ですね。

見える化はもちろんのこと、カンバンフローを運用すると自然のタスクには「完了条件」が決められます。そしてWIP制限によって、そのときそのときに最も必要なタスクが順にとられるので、最小限の作業をするようになります。

特にリーン開発の「7つの無駄」をどれも効果的に解決することに気づきます。個人的には「手持ちのムダ」が適切なスイムレーン設定によってなくなること、チケット化+チャットでの通知によって「伝搬のムダ」が大きいと感じています

おわりに

実際に導入してみて、この本を読んで、毎週使い方を改善していっています。ほぼどんなプロジェクトにも適用できるのではないでしょうか。

本書にあるプラクティスを全部実践する必要はないですが、今うちが実践してるルールはこんなところ。

  • WIP制限(Doingのところだけ制限をかけています )
  • レーンを一方通行にすること
    • うちはBacklog→TODO→Doing→Review→Doneにしています
  • 完了条件を明記すること
    • レーンを一方通行にするためには「Review」が一度くるとそのissueは終わるようにしなければなりません。
    • つまり「機能Aの開発」だとして、作業見積もり、コード作成、テスト実行のそれぞれにReviewが入るなら、その単位にissueは分割されます
  • TODO〜Review間は個人が自由に動かして良い。
  • Doneに移動するとき、BacklogからTODOへはデイリースタンドアップミーティングで実施
    • 最初と最後は優先度つけもしくは完了したかの共有のためにメンバー全員の前で実施するようにしています。

自然とタスク粒度が決まってくること、WIP制限によって今やってる仕事と残りの仕事が明になること、フローが流れることで今何に詰まっているのかがわかるようになること。自分でやれるところまでやったらすぐにReviewにすることで待ちのムダがなくなることに効果を感じています。

Gitlab issueに特化した記事をそのうち書こうと思います。物理でもソフトウェアでも、カンバンボードはあらゆるタスク管理に使えると思います!おすすめ!