タスクの先にある目的を見失わないために

目の前にあるタスクをなんとかすることに手一杯になってしまいがちだけれども、目指すべきゴールを明確にしておけば迷いが生まれにくくなるかもしれない。

最近なんでこんなことやってんだろーって思うことが多いので、いまやっていることが自分にとってどういうメリットがあるかを家に着くまで考えます。

良いチームを作ること

生産性アップ。
チームビルディングスキルが身につく
仕事行くのあんまり嫌じゃなくなる
仕事楽になる
職場が快適になる
残業減るかも
飲み会が楽しくなる

プロジェクトを進めること

チームや個人の評価になる。ほめられる
ボーナスが増える。
休出にならない
一応会社の目標だし
達成感ある
もうかるプロジェクトだったら偉い人からもほめられる。ボーナスが増える

メンバー育成

チームの生産性アップ。
育成スキルが身につく。
育成の成果が認められたらボーナスが増える
代わりに仕事してくれる手が増える
その間に好きなことができるかも
運用してもらえるかも

リーダーや先輩をするモチベーションがほしい

人やチームの面倒を見るのは自分の成長に役立つのか?わたしのメリットってなに?なんかわたしばっかりみんなのこと考えてない?って感じて元気なくなるからやる気を出したい

最近チームとか人を見ていると、人に対する不満ばっかり目についてしまってやだ。自分を振り返りたい。ノイズを追い払って自分の至らないところに目を向けたいです。

続きを読む

チームリーダーになりたくない

って最初に言ったんですけど任されてしまいましたね。
リーダーを任されて数ヶ月、いろいろ考えた話。

そもそもチームリーダーはいないはずでは?

スクラム開発にいるのはプロダクトオーナーと、スクラムマスター、チームメンバー。
スクラム開発にはチームリーダーはいない。

が、スクラムやってるはずのうちの会社、なぜかチームリーダーがいる。
リーダーの仕事はスクラムマスターの領域が近いけれど、実際の作業もやっているのでチームメンバーでもあるかんじ。バックログはチームで出している。POは誰だかよくわかんない。

なので実際、リーダーはただのスーパーマン
要件からバックログのタスクにする。調整して、みんながタスクに集中できる環境をつくってあげられる。コード書いてタスクを燃やせる。なんでもできる。リーダーすごいよ。スクラムの全役ひとりでやってるのでは?

というわけでうちのチームリーダーはなんかすごい。

模索、チームリーダーはなにをするのか

さて、リーダーやってねって言われたけど、すごいので、なにから始めればいいのかさっぱりわからない。
迷走して、プロジェクト開始からしばらく、PO寄りのスクラムマスターをやっていました。
コード書かない。タスク出しと調整に徹する。
立場がPOになったので、チームと対立する。後から学んでみればこれ自体はスクラムの構図の通りだった。
なんだけど当時はそれを理解してなくて、やってることがPOだったくせにこっちの気持ちとしてはチームの一員だったので、チーム内でギスってる感じになってめちゃくちゃにつらかった
あとコード書かないとやっぱエンジニアとしての自分の成長はどーなんの?って悩んで憂鬱になる。*1

実際、チームリーダーはなにをするのか

今リーダーしてる人たちが思うリーダーの仕事は「プロジェクトの目的のために行動できる人になること」らしい。
当事者意識。プロジェクトを自分のこととする。

チームメンバーという役割

じゃあメンバーはそれをリーダー任せにしてていいの?ってならない?スクラムにおけるメンバーは役割のないその他ではない。チームを作るのはチームメンバーたち自身。
自分たちにそんな役割があることをメンバーは理解しているか?わたしは理解していなかった。それはわたしが働きだして3年経つのに今更こんなことを考えていることに現れていると思う。

これまで見てきたリーダーは調整もできるしコードも書いてて、自分はタスクのことだけ考えてても困らなかった。ただのコーダーであるなら快適かもしれないけれど、現状はそんなチームリーダーに甘えてきた結果。これまでの自分がリーダーに甘えていたボンクラコーダーだったことを認めるしかない。

理想、チームリーダーはいらなくなる

自立的なメンバーによって成り立つ自己組織的なチームにリーダーはいらないはず。

現実、チームリーダーはいなくなる

チームの最初期を作ってきた人たちはいなくなる。わたしはおそらく、経験も知識もなくこのチームで育ってリーダーになる最初のひとになる。
成り立ちが全く違うんだから、いままでと同じようにはできない。これまですごいリーダーたちにしてもらってたようなこと、同じようには、いまのわたしにはできない。

わたしはみんなが知っている「チームリーダー」になれない。

チームリーダーになりたくない

これからもスクラム開発をするなら、そして銀の弾丸の「チームリーダー」になれる人がいないなら、この先はチームリーダーのいらないチームをみんなで作らなきゃいけない。

「プロジェクトの目的のために行動できる人になる」のは、リーダーだけじゃいけない。プロジェクトもチームも勝手には回らない。わたしたちはチームだから、みんながその思いを持ってチームに「なる」必要がある。

だからやっぱりチームリーダーになりたくない。*2
みんなと同じメンバーのひとりとして、みんなでチームを作りたいです。

*1:いまの現場にはコードを書く以外のタスクに対する重みが少ないように感じていて、調整事にかかるコストは可視化されにくいし、ドキュメント作成のタスクが軽んじられている気がする。それは嫌

*2:最初は本当にリーダーになりたくなかったんですけど、それは「チームリーダー」に対するハードルの高さだったと思う。いや無理だからねこんなん!

「自分の得意な感覚」を知っておくと良い

vakモデル、vak理論など呼ばれる、そのいずれが正式名称かなのかはわからないのですが、そういう考え方があります。あんまり良い資料やページにあたれなかったので、詳しいことは適当にググってください。
ざっくり書くと、vakというのは視覚、聴覚、体感覚のそれぞれの頭文字を取ったものです。人にはそのみっつのうち、ひとつまたはふたつの優位な感覚があり、わたしたちは日々その得意な感覚を主に用いて認知を行っているそうです。
どれが得意でどれが不得手か、というのはその人によるみたいですが、わたしはおそらく「体感覚」派です。

時は遡って3年前、新人研修を受けていたころ、わたしは言葉が出てこなくてうまく話せない、と、講師の方に相談をしたことがあります。研修時間後の立ち話くらいの感覚で、腰を据えて話したわけではないのですが、その時に講師の方から言われたのが「もしかしたらあなたは体感覚なのかもしれない」でした。

視覚、聴覚は高次の感覚であるのに対して、触覚・味覚・嗅覚を含む低次の感覚である体感覚は、言語で表しにくい傾向があるようです。見たものや聴いたものを言い表すよりも自分が感じたことを言い表すほうが難しい気がするので、それはなんとなくわかる。
おそらくわたしは体感覚が優位、サブが視覚、聴覚が劣位です。

で、タイトルに戻る。
これがわかるとなにが良いかというと、まず、考えたり学んだりするときに得意な感覚を使う方が覚えやすい。

体感覚なわたしの場合は、なんでもまずやってみるのが一番早い。
とりあえず、手を使って書く。体感覚は言語化が難しいのですぐ喋りだすのは苦手。視覚情報は比較的頭に入りやすいので、文字や図にするのはGood。聴いたことはすぐ忘れるから絶対に書きとめておく、もしくは復唱する。喋るというのは体感覚だからわりと覚えられる。みっつ聴いても最後のひとつしか覚えてないみたいなことはよくあるから、口頭で言われたことは忘れないように工夫しておかないとダメ。

もうひとつ、うまく仕事するためのコミュニケーションの方法を周りに知ってもらうことができる。
会話ベースの場合、わたしは聴いて理解するのが苦手なので「復唱する」または「自分の言葉で言い換える」ことで理解しやすくなる。ので、よくやるけど、あんまりやりすぎると微妙かなとも思うので、「わたしはこれをすると頭に入るので、うざいかもしれないけど許してください…」と周りの理解を得ておくと仕事が進めやすくなると思う。
ちなみに今自分がこれをやってるかというとあんまりやってないんですけど。これに気づいたころにはもうチームが受け入れてくれていたので。やさしいチームメンバーでよかったなあ

たぶん人に対しても同じように得意な感覚を使えるようなアプローチをしてあげることで理解を促せるようになる、気が、する……。まだそこまではいけないけど。特に春先は人に教えることが増えてくると思うので、意識してみてもいいのかな〜、とか。*1

新人の、とくに自分の興味分野外の社会人研修ってだるいとかってめんどいとかよくわかんなかったみたいなこと結構多かった(すみません)けど、こんなふうに、意外と役立ってるな〜って内容もたまにはあったので、一概にナメてかからずに、一応聴いておくと良いことがあるかもしれないね、って思います。

*1:念のため記しておきますが、これは新人教育をしたいと言っているわけでは、決して、決して!ありませんので、上司各位におかれましては誤解なさらずによろしくお願いいたします。

わからないの理由

アホの子を教えるのは楽しかった、という増田の記事を読んだ。勉強のできない子が抱えている、放置されたままの些細なつまづきを取り除いてあげられる先生の話。はてブホッテントリに入っているので興味があればすぐ見つかると思います。
追記でかつて本人が九九を覚えていなかった話をしていて、それを読んで思い出した話。自分が似たようなつまづきをして、英語ができなかったこと。

ずっと学校の成績はわりと良い方だったので深刻にできない子というわけではなかったのだけど、中学に上がって始まった英語が苦手だった。90点以上がアタリマエだったはずの学校のテストで、中1の秋頃には英語は60点程度しか取れなくなっていた。
上はいなくても下はたくさんいるド田舎の公立中学校、なまじ勉強ができる分つまづいてることは外からはわかりにくく、ごまかしがきくから、先生から問題視されることはない。つまづきを解消できないまま授業のカリキュラムは進んでいって、そのつまづきの負債は次第に膨れ上がって、どんどん大きくなっていく。
増田を読んでふと自分に重ねて思い出したのはこういうところだった。当時、わたしはbe動詞がわからないまま中学2年生になろうとしていた。

親は英語の塾に通わせてくれた。ちょうど友達の家の近所に外国人の先生がやっている個人塾があったので、友達に連れられる形で通わせてもらうようになったのだと思う。
ド田舎なので、外国人の存在自体とても珍しかった。個人塾なので少し広めの自宅の一室を教室として使っていた。いいにおいがする綺麗なお家。白いモジャモジャ髭のおじさん先生は、最初、少しだけ怖かった。
そこで薄いワーク本を1冊とホワイトボードを使い、友達とたったふたりのごまかしのきかない教室で、ゆっくりと最初から勉強をやり直した。

そこから中学の終わりまで一杯、わかったふりでごまかしきれない授業を受けた。やり直しの過程でわかったのは、単語の意味は暗記できても、文法というものが理解できていなかったということ。S,V,O,C。特にOとC、その区別はずっと難しかった記憶がある。
本ばかり読む子だったのに、不思議なものだけど、たぶんあの頃は日本語の文法だって理解していなかった。文のつくりかたに理屈があることを知らなくても日本語は読めるし、物語を感じることはできた。それまで困らなかったらしい。

そういうわけで塾に通ってやり直していくうちに、文法をちゃんと理解し、授業にも追いつけるようになり、高校に入ってからは国語と英語が一番得意(ド文系!)になった。ゴミのような点数の数学と理科をひっさげつつも大学合格できたことを思うと、あのとき英語ができるようになってほんとうに良かった。

わかったふりで本質的な理解をしないまま進んでいくと後からしんどくなることを忘れずにいたいし、もし人がそうなっていたらそのつまづきに気づいてあげられると最高。教える側としても教わる側としてもいろいろ考えさせられる話。

今思えば、理屈のわからないものをそのまま飲み込むのが昔からすごく苦手だった。
まぁ結局、高校化学のmolでつまづいて赤点ギリギリの低空飛行だし、数学は微積以降なにもできなかった(ただ数学は受験にどうしても必要だったので、理屈がわからないまま仕方なく解き方の型だけ叩き込んだ記憶がある)。「理屈がわからないけどそのとおりにする」は未だに苦手だ。

この流れで思い出したのでvakモデルの話とかしたい。
またこんど

自由に生きるのに必要な名前

いくつ名前があるのかと問われ、彼は「自由に生きるのに必要なだけ」と答えた。

映画「ハウルの動く城」でソフィーの問いかけに答えるハウル
元々児童文学育ちなので原作小説の「魔法使いハウルと火の悪魔」が好きで、大きくストーリー改変されてしまった劇場版に思うことがないわけではないけれど、劇場版ハウルのこの台詞は好きでずっと覚えている。
児童文学における名前の扱いといえば、ハリー・ポッターの「名前を呼んではいけないあの人」や、バーティミアスの魔術師は本名を呼ばれると魔術を無効化される世界観も思い出せる。名前に対するわたしの考え方は小中学生のころに読んだ児童書、海外のファンタジー小説によって育まれたのだと思う。

名前は存在を、キャラクターを縛る。
たとえば会話をするとき、大抵の場合はすぐ目の前に聞いてくれる人がいて、口に出した瞬間にその言葉は自分自身と強く結びつく。その積み重ねによってこう考え、こう話し、こう振る舞う、「この人はこういう人である」と理解していく。その理解した形を扱うための識別子が名前である。
ハリー・ポッターの世界の魔法使いたちはヴォルデモートの名前を呼ばないことでその存在に対する理解を放棄した。バーティミアスという悪魔に本名を知られた魔術師ナサニエルは、自らのしもべとして召喚した悪魔に対する支配力を失ってしまう。魔法とファンタジーの世界において、名前は存在そのものを理解するための最も簡単な手がかりになる。
だからこそ、もし名前を変えることができるならそれはつまり、別の存在になれるということだ。
ハウルは「魔術師ジェンキン」「魔法使いペンドラゴン」「恐怖のハウル」そして「ハウエル・ジェンキンス」の名前を持った。作中で、その理由は身元を隠すためだと語られている。とかげのしっぽのように、名前を自分から切り離すことで、いつでも逃げられるように。

社会に生きるわたしたちがハウルのように「自由に生きるのに必要なだけ」の名前を持つことは難しいけれど、インターネット上においては、こうしてリアルな自分自身と一対一ではない「わたしではない個人」の名前を持つことも簡単にできる。
だからこの場所は居心地が良い。誰でもない個人として認知され、自分自身のある側面を縛られることなく表現することができる。

いま人がインターネット上で持つアカウントの数は、それがその人にとって「自由に生きるのに必要なだけ」の名前の数なのだと思う。

Sinatra + ActiveRecordでアプリ作るよ

社内勉強会でSinatra + ActiveRecord + vue.jsのタスク管理アプリを作っているので、そこで困ったことのメモ。
今回はSinatra + ActiveRecordのサーバサイド。

qiita.com

このページを参考につくる。

SQLite3::CantOpenException: unable to open database file

$ bundle exec rake db:migrate
rake aborted!
SQLite3::CantOpenException: unable to open database file
...

DBのファイルが開けない。
ぐぐったらファイルやディレクトリのパーミッション周りが怪しいとあったので変えてみるも通らない。
パスの指定がおかしいのかな?と疑い出す。

berofe models/todo.rb

ActiveRecord::Base.establish_connection('sqlite3:///todo.db')
class Todo < ActiveRecord::Base
end

after models/todo.rb

ActiveRecord::Base.establish_connection(
  adapter: 'sqlite3',
  database: 'todo.db'
)
class Todo < ActiveRecord::Base
end

establish_connectionはハッシュで書く方法とURLで書く方法がある。
establish_connection (ActiveRecord::Base) - APIdock

DBのファイル作成

$ sqlite3 todo.db

このあたりをやってみたらふと成功。

$ bundle exec rake db:migrate
== 20180201054009 CreateTodos: migrating ======================================
-- create_table(:todos)
   -> 0.0021s
== 20180201054009 CreateTodos: migrated (0.0022s) =============================

書き方変えたからなのか、DBファイルを事前に作っておかなきゃいけないのか…。
理由がわからなかったのでまた今度試してみる。

Encoding::UndefinedConversionError - "\xE7" from ASCII-8BIT to UTF-8:

sinatraのほう
文字コードの変換に失敗。paramsで受け取った値に文字コード指定すると直る。

str.force_encoding('utf-8')

でOK
force_encoding (String) - Rubyリファレンス
パラメータ受け取った時に毎回これやるのはどうなのっていう話はある。うーん

When assigning attributes, you must pass a hash as an argument

これもsinatra

エラーメッセージをちゃんと読むとハッシュで渡すようにと言っているので、変更する

todo = Todo.new(params[:name])

todo = Todo.new(name: params[:name])

エラーメッセージをぐぐるとこういう記事が出てくるので、時勢に乗り遅れていた説…
rails5.2への準備を整える - Qiita

Automatorで自動化する

「PDFファイルを一ページずつ画像ファイルに変換」
「画像のファイル名はプレフィックス+ページ番号にする」
みたいなことがやりたいときに使ったAutomatorのめも。

macOSにはAutomatorっていうめっちゃ便利なアプリがある。
ワークフローを作れるアプリらしいです。
みんな知ってましたか?わたしはこれを作るまで知りませんでした。

確か前はシェルでなんとかしてたんですが、用途的にinとoutのファイルやディレクトリの指定やらprefixの文字やら毎回変えたいというのもあり、Automator使ってみたら使いやすかった。
GUIって便利だなあと思いました

つかいかた

やりたいことを書き出す
今回はこんなかんじ

f:id:eri-twin:20180221234848p:plain

この最後の連番付きの名前にする設定がけっこう融通きく。
プレフィックスを前後どっちにつけるか、始まりの番号、区切り記号とか指定できる。
桁数指定しておくと0埋めしてくれるのがかなり良いかんじです。

で。これを実行すると

f:id:eri-twin:20180221235013p:plain

こうなる
わーい

たまにしか使わないんだけど、めっちゃ便利。
左のほうにアクションがずらずら並んでてかなり種類がある。今回の用途であればシェルでも全然できると思うんだけど、アプリの操作がいろいろできて、office系も強いので使い所によってはつよそう
自動化の選択肢の一つとして頭に入れておけたらいいなとおもいます

以上
たまにはコード書いてプログラマらしさを見せていきたい