ツナワタリマイライフ

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

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

はじめに

読んだ。

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

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

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

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

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

2017年1月目標振り返り&2月目標

はじめに

今年の年間目標に毎月目標を立てて振り返りする、としたわけですが。。。

take-she12.hatenablog.com

目標を立てたのが1/18っていうのが終わってますよね。(笑)この目標を立てて振り返る難しさを実感しています。とはいえ最初からうまくいきっこないので毎月頑張っていきましょう。

振り返り

楽曲制作

  • [○] とけてなくなる、消えて くなるベース録音して公開
  • [○] こりーセッション曲、1曲自自パート録音完
  • [△] 千秋さんコラボ曲、ベース、ドラム、キーボード、ガイドボーカルいれて公開
  • [×] なのは、月の光に歌うよ 作詞作曲完
  • [○] とけてなくなる、曖昧に揺れる15cm ベース録音して公開追加

とけてなくなるのモチベーションがあがっているようで、前倒しで作業できました。こういう心の変化はとても良いことだと思います。

千秋さんとのコラボはキーボード入れまでできてないのと、公開もできてないですね。この前ミーティングしたんですがまずこの1曲のアレンジを2月中に詰めることになりました。

作詞は出るとき出ないときの差があって、なかなか難しい。ただ目標にしないほうがいいかというとそういうわけでもなく、時間に迫られて出そうとする行為は意味がある。

英語

  • site reliability engeenear 1. Introduction読んでブログ書く
  • Grammer in use Unit10〜20
  • amazon english 5作品

まさかの全部×ですね。英語とまるで向き合っていない(笑)量を減らして確実に英語に向き合う時間を増やすところからやりましょう。

ソフトウェア

振り返ると今月音楽とカレーしかしてないですわ。キャパシティがそんなもんってことなんでしょうねー。どうしたもんかな。

読書

1月に読んだのは5冊ですね。

池上彰の宗教がわかれば世界が見える (文春新書)

池上彰の宗教がわかれば世界が見える (文春新書)

風の歌を聴け (講談社文庫)

風の歌を聴け (講談社文庫)

うち小説は1冊でした。最初の目標がよくなかったですね。(積ん読を読むってのが。)ジャンル別にもれなくダブりなく数字をあげよう。にしても月5だと年60冊なのでもうちょっと読みたいな。勤務地移動で電車に乗ることが増えるのでその分本を読めたらいいな。

健康

  • 30days plank完了
  • run 月50km

どっちも未達。やばい。やる気なさすぎる。ちなみに17.14kmでした。月50kmってかなりハードル下げたのになぁ。。。

振り返りと2月の目標

1月、まぁ目標立てたのが遅いというのもありますが、ほぼほぼ土日は音楽に費やしました。音楽以外の達成度が0っていうところから、今のままだとこの程度のキャパシティしかないことになります。

時間そのものを増やす必要があるので、会社の昼休み1時間はまるまる自分のことをすること、読書なんかがいいですね。(今は会社の仕事をしてしまっている)あとは朝の時間を確保しないといけない。ラン+1workできればいいですね。

平日夜は不確定要素が大きいですが、週2は自分の時間として3hほど取れるようにしようと思います。これはカレンダーにいれます。

それを踏まえて2月の目標。

楽曲制作

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

ちょっときつきつですが、なのはのレコーディングで後半はいっぱいいっぱいになりそうなので前半でとけてなくなるのほうを片付けたい。

読書

  • 小説を3冊読む
  • 小説以外を5冊読む の合計8冊を木曜に。1月よりは通勤時間が増えるのでいけるのではないかと思ってます。昼休みも読もう。

英語

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

1つ減らして、2つkeep、もう1つはやろうと思っていることです。nandemonaiyaをやろうと思ってます。

健康

  • 30days plank完了
  • run 月50km

継続。朝活やるしか道がないらしい。夜はダメだ。

おわりに

達成度はともかく、振り返りのプロセスが大事ということで、続けてみます。

「チラシ・勧誘印刷物の無断投函は一切お断り! 高耐候性ステッカー」がマジで効く

はじめに

「チラシ・勧誘印刷物の無断投函は一切お断り! 高耐候性ステッカー」がマジで効く。

以上です。

マジで効きます。

f:id:take_she12:20170204163448p:plain:w500

ゴミ箱直行だったので手間が省けます。資源も有効活用できることでしょう。

以上です。