ツナワタリマイライフ

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

チームビルディング相談会① 職場のひとの良いところが見えづらい

はじめに

ソフトウェアに絶望した私ですが、そんな"デキナイ"私が今関心ある分野がチームビルディングです。

元々、リーダーとなって場を仕切ったり、仕組みを作ってひとを動かすところは得意だと感じています。また、相手の考えを聞いて、整理して相手に伝えることが得意だという自覚もあるので、ソフトウェア・プロフェッショナルとしての道が難しいのであれば、チームビルディングの分野で活躍できないかと考え、ちょっとしばらくチームビルディングについて考えようとしています。

幸運なことに、挫折のあとの今のチームでは新しいことをやるプロジェクトで、人間関係も割とフラット。その上、そのサービスに以前から携わってたこともあり、自分は前提知識を持っているほうなので、活躍できるチャンスです。実務でもチームをどう作るかに着目したいと考えています。

きっかけ

何でも企画にして面白いことをするのが好きな私。友人が小売業の管理職をしていて、時折人間関係、というか、ひとの動かし方、指示の出し方について悩んでいるのを聞いて、「これは企画になるのでは?」と思いつきました。ひとへの指示の出し方は、まさに根元にチームビルディングがあります。そこで、悩みのネタを出してもらい、僕が考えることをブログとしてアウトプットする取り組みをしたいと提案しました。

質問

「友達の良いところはたくさん見えてくるのに、職場の人の良いところが見えづらいのはなぜでしょうか。良いひとたちだと思うのですが、友達と同じようには見れないのが不思議です。」

司会者「いきなり難しい質問ですね。」

「そうですね。いきなりの司会者登場ですが完全に音楽ライターのレジーさんのパクりです。この形式って何が良いのか、興味があったのでやってみることにしました。対話形式だと読みやすい気がするけど本当にそうなのか、とか気になっていたので。」

司会者「職場の人の良いところが見えないと」

「僕は職場の人だろうがそうじゃない人だろうか良いところ見えるので、自分自身に覚えがない感覚の相談でとても難しい。」

司会者「友達と職場のひとの違いが問題?」

「友達の良いところはたくさん見えると言っているので、おそらく相談者自身の問題でしょう。良いところを見抜くスキルはあるんだけど、なぜか職場のひとだと見えにくくなる。」

司会者「職場ではスイッチが入るとか」

「本人も職場では自分の職務というロールを演じてるだろうし、その上で職場のひとも"職場のひと"というフィルターがかかっていて、友達関係のようにまっすぐ見えなくなるんだと思います。Aさん、Bさんという風にそのひとそのものを見ているよりかは、職場のCさん、職場のDさんという風に、職務フィルターがかかっている状態になっているのでは。」

司会者「どうやったらフィルターが消えますかね?」

「相手もただの人間だよね、っていうのを意識することができたらいいと思います。例えば、その相手に"期待"してたりしないでしょうか。相手に仕事を期待する=相手にその職務を期待することになるので、結局職務を演じるロールでしか見えなくなってしまうのでは。相手に期待しないことって、結構大切だと思うんですよね。」

司会者「期待外れだと悲しかったり悔しかったりする」

「とはいえ、上司に期待されている、という事実がモチベーションをあげるのも事実。ただ、期待を伝えるのは良いところが見えたあとだと思います。まずは相手に期待するのではなく、仕事をお願いしつつも、そのフィードバックを得ることに一生懸命になるべきだと思います。この仕事をお願いする、その意味が伝わったか、できそうか、できなさそうか、難しいか、やりたいか、やりたくないか、やってどうだったか。こういったものをはかる時間はどうしても必要。そのはかる時間を経れば自然と良いところは見えてくるはず。」

司会者「じっくり観察すると」

「そうですね。私は結構ひとを見てると思います。で、相手が何を返してきても否定しないし、期待もしない。もちろん感謝はします。相手を受け入れることですね。受け入れた上で、ちゃんと対話して、じっくり向き合う。やっぱり期待しないってのが効くんじゃないかなーと思います。」

考察

"変えられるのは自分だけだ"ということに気づいたのはいつだっただろうか。他人は変えられないんですよね。

他人に期待しない、というとどうしても冷たいイメージがつきまとうんですが、冷たくないんですよ。無です。マイナスじゃないです。相手に期待しないということは自分の行動がした結果は全部自分が負うわけです。伝わらなかったのであれば、伝え方が悪かったかな?ってなるかもしれないし。嫌だな、このひとは、と思っても相手には変わらないわけですから、嫌な相手こそ笑顔で近づいてみるとか。世界を変えるには自分を変えるしかない。

職場のひととしか見えないから、良いところが見えない、本当の気持ちを理解することはできませんが、期待せずにじっくり向き合ってみる、というのが1つの答えとして提案したいですが、いかがでしょうか。

おわりに

対話形式、司会者に都合良く喋らせられるので、話の展開を作るのがとても楽ですね。この企画内では続けてみたいと思います。

今回の企画は友人にネタ出しを協力してもらっています!本当にありがとう。反面どんな質問がくるかわからない楽しさも味わいつつ、考える時間・場所としていきたいです。他に相談ネタ・考えるネタがあれば遠慮なく教えてください。では!

仕事が楽しくないので「仕事は楽しいかね?」を読んだ

はじめに

タイトルはちょっと釣りです。すみません。楽しくなくはないです。

仕事は楽しいかね?

仕事は楽しいかね?

kindle unlimitedで読めます。

明日は今日と違う自分になる。

第4章「明日は今日と違う自分になる、だよ」では、目標を立てることの危険性を指摘している。「今日の目標は明日のマンネリ」という言葉からあるが、目標を設定すると、自己管理ができているような気がするともいうし、数年後はおろか、数か月後だってどんな人間になっているか予想がつかない。それよりも大事なことは「明日は今日と違う自分になる」こと。人生を完璧に、自分の思う通りにコントロールすることは不可能と割切るかわりに、常に変わり続け、前に進見続けることだと。

目標を立てて、それを達成しようという取り組みは自分もやっていた。その数が多かったり、達成できなかったり、結局その目標って何のためにあるんだっけって思ったり、うまくいかないと思っていた。

もちろん、目標を立てることそのものはいい。やりたいことを言葉にするという意味ではとてもいい。でもよりフォーカスすべきことは、進捗管理するより、常に今大切なことは何かを考え、変わり続けることなんだと思った。

努力と偶然

第6章「必要は発明の母かもしれない。だけど、偶然は発明の父なんだ。」も、過去の成功者たちの事例をうまくつかんでいる。成功者は10回のうち9回は失敗しているし、なんならもともとしたかったことと違うことがきっかけで大成功をつなげている。これはもちろん偶然であるが、毎日変わり続けようとする姿勢が生んだものだ。

人生はコントロールできないし、成功は偶然から生まれる。だからやるんだよ。少しずつ変えて試すんだよ、なんども試すんだよ、それしかないんだよ。

そう聞こえる。

ホーソーン効果

「あらゆるものを変えて、さらにもう一度変えること」

一般的に、実験は関係している要素を抽出するために、変数を1つにする。同時に変数をいくつも変えては何が効果的だったかがわからないからだ。

しかし完璧な実験ではなかった当時の実験は、結果的にひとが注目されることでどのやりかたをとっても生産性が30%あがる結果となった。つまり完璧なリサーチをしようすればするほど、物事の相互作用を見落としてしまうことを言っている。この文章だけでは説明が不十分だが、この場合でも変化が強いということが主張にあると思う。

成功者がやってきたこと

11章「だれだって、後からだったら、何だって言える。革新というのは簡単そうに見えるものなんだ、後から見ればね」

ここが一番どーんと落ちましたし、自己啓発本のもっとも大きい罠はこれだと思う。

成功者の語る言葉は、とってもストレートな道に見える。そしてそれができるのは特別な人間だからと思い込んだり、運がよかったんだと言う。チャンスはきっと自分とまったく変わらないはずなのに。

困難が与えてくれること

第12章「覚えておいてくれ。"試すことは簡単だが、変えるのは難しい"ということを。」で、とても好きな一節があるので紹介したい。

「困難というのは、一つひとつが実施演習を始める合図だ。試すことは、一つひとつが世の中への問いかけだ。答えというのは、一つひとつが旅だ。旅程の計画は人生に任せておけばいい。きみの仕事は、光を集めることとカメラを持っていくことなんだから:

後半にグァァァってきますね。旅程の計画ばっかり書いて、旅を一切しない。それが自分だな、って思った。

おわりに

仕事をしているひと、誰もが読んで何かを感じるであろうお話です。特に僕みたいに何かになりたい気持ちだけはあって何もできてないひとが読むといいと思います。

試そう。変わろう。大切なヒントを教えてくれた本です。続編の2も出ているのでそちらも読みます。

ソフトウェアプログラミングは不安との戦いだ

はじめに

エッセイ的な記事なのでnoteに書こうか迷ったんですが、プログラミングの話なのでこちらに書きます。

ソフトウェアプログラミングのつらみ

僕はソフトウェアエンジニアです。名乗れる程度には。新卒入社して3年目も中頃が過ぎ、「言われたことはやる」から「言われなくてもやる」への転換期と言ったところでしょうか。それなりに自分のやれること、得意なこと、わかりながら仕事に関わっています。

ただね。

ソフトウェアプログラミングって絶望的につらいんですよね。

え?何?好きなんじゃないの?めっちゃ勉強してるし、仕事も楽勝とか言ってるやん?って?うん、そうなんやけどさ、そうよ、たいていはそうなんやけど、基本的には自分は絶望的にソフトウェアプログラミングが苦手やと思ってるし、自分のセンス、才能の無さに定期的に絶望してます。絶望しすぎて方言でとるわ。

つらみを淡々と語りますので分からなくてもいいのでやさしくしてください。

ソースコードを読むつらみ

いやね、オープンソースの時代ですから、実際OSS使ってビジネスしてますし、仕様書がない!クソだ!分かるか!なんてさすがの僕も言いません。(1年目のときは本気で思ってました。OSSじゃなくて自社製品だったけど。)

それにソースコードを読めてこそエンジニア的なところあるじゃないですか。分かる、分かるよ。正解はソースにしかないってのはね、いいんだけどね、それでもつらい。

何がつらいってソースコード読むこと自体はいいんですよ。あーこうなってんだーって学びもあるしさ。こんな書き方するかよwwwってなったり楽しみはあるのさ。問題はしぬほど大規模なソフトに対して初見で障害対応するとき。 無理なのでは????????

このへんはもう経験が圧倒的に足りてないとは思っていて、だからこそ見当のつかない闇の世界に見えるわけですね。つまりソースコードの対局的な見方や、こういうふうに作られることが多いっていうデザインパターンを知らないんだと思う。きっとできるひとはおおまかな概要と掴んで、この処理はこのへんで閉じててこうされる、みたいなのが分かるんだと思う。でもそのへんがまったく自信持てなくて不安で死ぬ

動かしてみてデバッグログ仕込むとか、原始的な方法はあるにはあるけど、大規模環境で容易にソースいじれない場合はこれも難しい。専有環境をそもそも持つべきっていう論はあると思うけど。誰か「この処理はここだよ」って教えてほしい。そして呼び出し関係全部静的解析してほしい。甘えでいい。おねがい。

問題切り分けのつらみ

ソフトウェアはバグと切っては切れない関係にあります。というかバグとの戦いがソフトウェア開発の9割をしめるといっても過言です。

ちなみにプログラミング的なバグか、環境の一時的要因かはさておき、何か起きたときは問題を切り分けなければなりません。

まったく見たことないのに「~番のトラブル対応、よろしゃす」とリーダーに振られるわけですが、いやまってそもそもこれは何の機能のコンポーネントなの?ログはどこに出るの?ログ何個かあるけど何が違うの?内部でコンポーネントいくつかあるけどそれぞれの役割は何なの?このコンポはどのコンポとどうやって通信して連携してるの?まったく分からないところから切り分けスタートです

ビル・ゲイツも問題を切り分けよと言ってますが、それができりゃ苦労しないよと言わせておいてほしい。もちろん仮説のもと試行してこの時に起きる、このときは起きない、とやってだんだん範囲を狭めていったり、もしくは時系列に並べて関連するidなりなんなりで並べて どこまでは通信はいっててここで消えてる、としたりして切り分けするのは分かってます。切り分けは、前提知識がない以上、仮説思考の上の試行錯誤をするしかないと思っていて、これがとても苦しい。知らないものに対する仮説を立てるのが難しい。つらい。

影響調査のつらみ

ではここにバグがあったので修正しましょう。はい。これで起きなくなりました。よかったよかった。で終わらない

そう、デグレートの危険性があります。その修正をしたことによって、該当箇所はよくなったかもしれませんが、それによって他の機能が動かなくなる可能性があります。これを見極めるのが難しい。つらい。

いやいや今時全部自動テスト書いてるからリグレッションテストできるし安心でしょっていう世界に僕は行きたい。お願いします。行きたい。

テストで担保せずとも(もちろんテストで担保は必要だが)論理的にこのメソッドはここからしか通らないって言い切りたい。grepしただけじゃ不安だ。

再現テストのつらみ

なるほどこんな障害が起きたんですね。まずは再現しましょう、そのぐらいは僕も分かってますよ。でもね、再現させるのって超難しい。

まずそもそも同じ操作をするのが難しい。操作って難しいんですよ。API打つのかCLI打つのかいろいろありますけど、製品によっては前準備とか環境を整えてあげないといけなかったり、そのために手続きが必要だったりしてそもそもめんどくさい。その上でオペレーションをする、まずそのやり方を知らないから調べるところからだったりする。そして再現できてるっぽいけどこれで本当に再現になっているのか不安になる。だって再現しないから。再現しないといっても自分のやり方が正しい自信がない。

再現したら儲けなもんで、あとはいくらでも網をしかけられるんだけど、再現しないことにはなかなか正体を暴けない。

おわりに

僕がいかに低レベルなプログラマで常に不安と戦っているかを愚痴る記事になったこと、反省してます。たまには許してほしい。

そしてこの不安を消すためにこれからも努力を続けます。

UNISON SQUARE GARDEN - mixjuiceの言うとおり 耳コピギター編

はじめに

バンドの次回課題曲なので耳コピしました。ユニゾンやるの久しぶりだけど歌える気がまったくしません。

www.youtube.com

前回はベースを取りました。

take-she12.hatenablog.com

Bメロ

MVではAメロ斎藤くんギター弾いてる気がするけど聴こえないので無視しますね。

E|                                                          |
B|10 10 10  8 10  5 5 5 3 5  10 10 10 8  10  11 11 11 10  8 |
G|10 10 10 10 10  5 5 5 5 5  10 10 10 10 10  10 10 10 10 10 |
D|                                                          |
A|                                                          |
E|                                                          |

E|                                            8  8  8       |
B|10 10 10  8 10  5 5 5 3 5  10 10 10 8  10  11 11 11 11 10 |
G|10 10 10 10 10  5 5 5 5 5  10 10 10 10 10           10 10 |
D|                                                          |
A|                                                          |
E|                                                          |

最後、2弦13フレットが遠いので1弦8フレットにしたんですが、和音が正確じゃないかもしれない。

その後はGm → Am → C# → C

最後は

E|                   |
B|                   |
G|                   |
D|                   |
A| 3 0 1   0 1  3  3 |
E|       3           |

www.youtube.com

サビ

|F    |Asus4 A  |Dm   |C   F      |
|B♭ C |Am7   Dm |B♭   |B♭m C B♭AGF|
            *2→ |Gm C |B♭  F      |

www.youtube.com

1周目終わるところがちょっとあやしい気もする。

ギターソロ

E|           |
B|           |
G|           |
D| 6  6      | ×2
A| 8↑ 8 6 6  |
E|         8 |

E|16 15 13   16 15 13    16 16 |
B|        13          13 15 15 |
G|                             |
D|                             | 
A|                             |
E|                             |

E|13  15  17   |
B|16↑ 19↑ 21↑  |
G|             |
D|             | 
A|             |
E|             |

E|15 15 15 15 15 18 18 18 17 15  20 20 20 20 18 18 18 19 20 |
B|15 15 15 15 15 15 15 15 15 15  17 17 17 17 17 17 17 17 17 |
G|                                                          |
D|                                                          |
A|                                                          |
E|                                                          |

演奏動画はこちら。

www.youtube.com

シュビドゥバッバ

B♭→C→Dm | B♭→C

www.youtube.com

ラスサビ

一番最後の全世界のスケールで〜のところだけ足しました。

Gm → C → Fを適当にアルペジオ

E|      1   1 |
B|    1  1  1 |
G|  2       2 |
D|3         3 | 
A|            |
E|            |

www.youtube.com

アウトロ

一番むずかしい。

オクターブは省略。5弦の13,12,10,8あたりをあげさげしてください。

E|13 13 13 13 12 13  15 15 15 15 13 15  17 17 17 17 18 17  20 20 20 20 20|
B|13 13 13 13 13 13  13 13 13 13 13 13  15 15 15 15 15 15  17 17 17 17 17|
G|                                                                       |
D|                                                                       |
A|                                                                       |
E|                                                                       |

E|20↑ 20 18 17 18 20                 17 17 20 20 18 17 13 13 |
B|                   18  18 18 20 20 17 17 17 17 17 17 13 13 |
G|                       17 17 19 19                         |
D|                                                           |
A|                                                           |
E|                                                           |

www.youtube.com

おわりに

100%正解ではないとは思いますがとりあえず通して楽しい!ぐらいにはこれました。コードに関してはうちのピアニストが取ったのが95%正解でしたので自分でできておりません。。。今後もギターの耳コピ練習してできるようになりたい。続けるぞー!

「たとえる技術」を読んで考える、たとえることと伝えることの関係

はじめに

面白そうな本を書店で見つけた。

たとえる技術

たとえる技術

たとえることは自分にとって作詞スキルに関係する程度しかない。小説を書くわけでもない。

本書は「たとえる」ことだけにフォーカスを当て、たとえるテクニックと、たとえる効果が語られている。これを読んだからと言って比喩表現がすぐにあがるわけではない。ただ、この「たとえる」こととは何なのか、を考える機会が欲しかったので読んでみた。

本書では冒頭に「たとえたほうが良い理由」、「たとえを作るために必要な視点の紹介」、「実際にたとえを使う例」という流れで構成されている。最後のたとえを使った2ページの文章が想像力を掻き立てられ、たとえることの効果を証明しながら書かれていて二度美味しい。

たとえることは、より鮮明に伝えること

たとえることは、伝えること。僕はこの本を読んで感じました。

伝えることはコミュニケーションの根幹であり、我々が生きる上で避けてはいけない問題です。今も僕はブログを通じて、言葉を使って、この本を読んで考えたことを伝えています。

なんのためにたとえるのか。それはより「鮮明」に伝えることです。「正確」に伝えることではないことに注意しましょう。何もたとえないよりも真実に近づき、イメージを共有しやすくなり、より正確に近づくかもしれませんが、絶対に正確にはなりません。イメージといった通り、より「鮮明」になる。聞き手が描きやすくなることから、鮮明という言葉を使いました。

正確性を求められる技術文章とは、かけ離れた存在でしょう。しかし、会話するとき、自分の体験をより鮮明に相手に伝えるためにはたとえることが助けになります。

たとえることは、より鮮明に伝えること。これに気づけたことがこの本を読んで一番大きな収穫です。

日常会話における「たとえ」

日常生活ではどんな場面でたとえる必要性があるでしょうか。事実の報告が求められる仕事には向かないでしょう。「夏休みが終わるのに宿題一切手をつけてない小学生の心境ぐらい進捗やばいです」なんて言っても確かに解決の困難さは伝わりますが、「で、どれぐらいやれば終わるんだ」を知りたいに決まってます。

やはり、体験の共有をする場面でしょうか。「駅前に新しくできた定食屋さんに行ったんだ。「どんな店?」「定食の種類が8種類あって充実していたよ。味はよくあるチェーン店の定食屋と同じぐらい。店の雰囲気が地元の商店街にポツンとあっておばちゃんがやってる定食屋のようで落ち着いたよ。」なんていうと(それぞれの体験における)商店街の定食屋を浮かべながらその店を解釈するでしょう。

文章で何かを伝えるときもたとえは必要です。「ブログを書くととても良いですよ。」「どういいの?」「考えついたことを文章化すると、今まで曖昧なままぐるぐるまわっていたことが明確になる。そのことでまた新しいことを考えられるようになる。常に溜まりっぱなしの食器を見ると次に洗う気がなくなるから、毎回片付けたほうが気持ち良いのと似ているよ」なんていうと「あぁあの感覚か」と伝わる。

お互い知らないフィールドで働いているとき、どんな仕事をしているかを伝えるには、相手が知っていることで例えるとイメージしやすくなる。看護士に対してソフトウェア開発を伝えるときに患者の記録をパソコンに入力するでしょう、と言ったり、もっと一般的に銀行のATMを使うときに金額を計算する何かが裏にいてね、なんて言うことができる。

本書で登場するたとえにはくどいものもあるし、小説の表現みたいに日常会話でする必要はないかもしれない。だけど少しオリジナリティを足すことで自分の言葉になるって素敵でしょう?

おわりに

表現力、説得力に「たとえる技術」を使うことが有効だということに気づくことができました。これからも何か物事を伝えるときにたとえることができないかを考えたい。

今年の読んでよかった候補です。

「エッセンシャル思考」から考える、人生で大切なものへの選択と集中

はじめに

きっかけはマイクロソフトのテクニカルエバンジェリスト、牛尾さんの公演で「エッセンシャル思考」に触れられたことです。日米間におけるソフトウェア開発生産性の違いに、日本は余計なことをしすぎているという指摘をしています。このくだりで、エッセンシャル思考という言葉が出てきました。

エッセンシャル思考 最少の時間で成果を最大にする

エッセンシャル思考 最少の時間で成果を最大にする

simplearchitect.hatenablog.com

エッセンシャル思考

エッセンシャル思考とは、大切なものだけを実行する思考法のこと。とてもシンプルですね。エッセンシャル思考の効果、導入方法、継続方法が書かれていて、読みやすい良書です。

なんでこの本を手に取ったかというと、私は何でもやってしまう人間で、自分の人生でやりたいことを成し遂げられてないからです。何でもやってしまう気質はこのブログを見ればわかりますね。(笑)「やろう」と思ったことはやる、気分が乗らないことはやらないと、はっきりしていることは良いと思います。しかし、その「やろう」ということが多すぎて、自分の大切なものを見定めることはできていません。

自分の大切なものを考える

「自分がしたいことなんて、30までに見つかればラッキーです。」とジャーナリストの津田大介氏が言っていた。

講演で、好きなことを見つけるコツはありますか?と津田氏に質問したときに帰ってきた答えが「好きなことの近くに身を置き続けることです。」そうしているうちに、好きなことの組み合わせで自分だけのやりたいことが見つかります、と言っていました。

大学時代の後期から新卒入社した今にかけて、興味があることはまずやってみる、というメンタルモデルを確立した。これはこれで、価値があることだと思う。何をやらないよりはマシ。ただ、その興味があることの中で、本当にやりたいことを選定するフェーズに入っているんだと思う。

自分が好きなこと

  • IT(プログラミング、サーバ、ネットワーク、クラウドコンピューティング)
  • 音楽(バンド演奏、楽器演奏、音楽鑑賞、作詞・作曲・編曲、DTMDAW)
  • 言葉(作詞、読書、思考)
  • ブログ(書く、読む、発信する)
  • カレー(食べる、作る、スパイス、欧風カレー、インドカレー)
  • 酒(ビール、日本酒、ウイスキー、カクテル、飲む、飲みに行く)
  • ひと(ひとと話す、価値観を話す、議論する)
  • 旅行(ひとに会う、食べる、移動する、移動しながら考える)
  • 登山

思いつく限りでもこんな感じ。多い。多すぎる。

例えば今年の目標は以下の記事で書いた。10個。到達状況の振り返りは別途するが、音楽について欲張りすぎて、わけの分からない状態になっている。

take-she12.hatenablog.com

選択と集中をどう進めるか

今年の切れ目あたりでそろそろ何でもやってみるメンタルから、大切なものだけに注力し、確実に成果を出すメンタルに変化していきたい。興味ごとにどう変化していくべきかを考えてみる。

ブログ

例えば今年はブログをはじめた年でもある。(正確には去年)それが約1年続いたことは大きな進歩だ。アウトプットが習慣化した。次は質への転換を考えてもいいかもしれない。(ブログのPVはあるレベルを越すと収益化できる)

音楽

音楽は大好きで、音楽なしの人生は考えられない。大好きだからこそ興味が無限大に広がって、何も成し遂げられていない。耳コピに挑戦してできるようになったことはとても良かった。今度はやらないことも決めたほうが良さそうだ。音楽こそ一番選択と集中が必要。

ものを書くこと

最近自分の中で興味があがってきたことがWebメディアや、ライターという分野。文章を書くということの楽しみがブログの延長で見えてきた。書籍をいつか出してみたいという思いもある。この抽象的な思いをもう少し具体化する必要がある。

カレー

今ハマっていることにカレーがある。意識的にカレーを好きになった2年間だ。今は一人暮らしをはじめスパイスから作っている。このカレーに対する情熱は消えそうにない。

ソフトウェアエンジニアリング

最後にソフトウェアエンジニアリング。1日8hを費やす仕事なので、興味がないよりあるほうがいい。こちらもブログに「触ってみた」系が多く、ちょっと手を出してそのあとそのままということばかりだ。とても成長が遅いと思う。ただし、IT技術はいつまで経っても手段でしかない。このバックグラウンドを活かして、その先のやりたいことが見つかれば自ずと集中する分野は見えてくる気がする。

好きなことと得意なこと

上記では自分の興味があること、つまり好きなことをあげた。しかし友人に以下の記事を勸められ、「好きなことより得意なことを探すべきかもね。」というコメントをいただいた。

www.4gamer.net

該当箇所である3ページ目にリンクしてますが、経営者と技術者の話や、ゲーム開発とWeb開発の話と内容盛り沢山なので全部見てください。

岩田社長もおっしゃるように、得意なことは「手間のわりにまわりがありがたがってくれること」である。そして直前に語られている、アウトプットされるものの質はそのひとが日頃考えていることに左右される、という発言も興味深い。これは「好き」の話だ。

得意なことを自覚することは、好きなことを自覚するより数段難しい。しいて言うならタイピング速度(に転じる文章を書くスピード)と他者を説得すること(根拠はあまりない)だろうか。あとはチームビルディングとチームマネジメント(コーディネート)が得意なような気もする。これは今後も継続して考えていきたい。「さっさと得意なことを見つけて」楽になりたいものです。

おわりに

このように各分野ごとでも興味が発散していて集中を進める必要がある。その上でさらに絞る作業が必要になってくるかもしれない。このあたりは今年度の振り返りと来年度の目標設定で明確化していきたい。

今回はエッセンシャル思考という本を読んだことをきっかけに、興味の選択可能性について考えました。今の考えを続けていてはまずく、転換期だとこいうことを意識できたことは大きいです。

頭でっかちにならないように、口だけにならないように、ちゃんと成果出していこうね。

スマートPythonプログラミングその2

はじめに

引き続きスマートPythonプログラミングをやっていきます。

take-she12.hatenablog.com

落とし穴を避ける

Pythonの落とし穴を避ける方法についての章です。

Pylint

文法の静的チェックとしてpylintをオススメしています。pipでいれてみましょう。

[vagrant@smartpython ~]$ sudo pip install pylint
You are using pip version 7.1.0, however version 8.1.2 is available.
You should consider upgrading via the 'pip install --upgrade pip' command.
Collecting pylint
/usr/lib/python2.7/site-packages/pip/_vendor/requests/packages/urllib3/util/ssl_.py:90: InsecurePlatformWarning: A true SSLContext object is not available. This prevents urllib3 from configuring SSL appropriately and may cause certain SSL connections to fail. For more information, see https://urllib3.readthedocs.org/en/latest/security.html#insecureplatformwarning.
  InsecurePlatformWarning
  Downloading pylint-1.6.4-py2.py3-none-any.whl (569kB)
    100% |████████████████████████████████| 569kB 494kB/s
Collecting six (from pylint)
  Downloading six-1.10.0-py2.py3-none-any.whl
Collecting backports.functools-lru-cache (from pylint)
  Downloading backports.functools_lru_cache-1.3-py2.py3-none-any.whl
Collecting configparser (from pylint)
  Downloading configparser-3.5.0.tar.gz
Collecting isort>=4.2.5 (from pylint)
  Downloading isort-4.2.5-py2.py3-none-any.whl (40kB)
    100% |████████████████████████████████| 40kB 631kB/s
Collecting mccabe (from pylint)
  Downloading mccabe-0.5.2-py2.py3-none-any.whl
Collecting astroid<1.5.0,>=1.4.5 (from pylint)
  Downloading astroid-1.4.8-py2.py3-none-any.whl (213kB)
    100% |████████████████████████████████| 217kB 807kB/s
Collecting lazy-object-proxy (from astroid<1.5.0,>=1.4.5->pylint)
  Downloading lazy-object-proxy-1.2.2.tar.gz
Collecting wrapt (from astroid<1.5.0,>=1.4.5->pylint)
  Downloading wrapt-1.10.8.tar.gz
Installing collected packages: six, backports.functools-lru-cache, configparser, isort, mccabe, lazy-object-proxy, wrapt, astroid, pylint
  Running setup.py install for configparser
  Running setup.py install for lazy-object-proxy
  Running setup.py install for wrapt
Successfully installed astroid-1.4.8 backports.functools-lru-cache-1.3 configparser-3.5.0 isort-4.2.5 lazy-object-proxy-1.2.2 mccabe-0.5.2 pylint-1.6.4 six-1.10.0 wrapt-1.10.8

以下のコードがテスト対象です、

[vagrant@smartpython ~]$ cat test.py
#!/usr/bin/env python
# -*- coding: utf-8 -*-

def main():

    foo = 'Hello, world!'
    print(foo)

    unused = 1

    return

    print(foo)

if __name__ == '__main__':
    main()

めっちゃ分析してくれますね。

[vagrant@smartpython ~]$ pylint test.py
No config file found, using default configuration
************* Module test
C:  7, 0: Unnecessary parens after u'print' keyword (superfluous-parens)
C: 13, 0: Unnecessary parens after u'print' keyword (superfluous-parens)
C: 18, 0: Trailing newlines (trailing-newlines)
C:  1, 0: Missing module docstring (missing-docstring)
C:  4, 0: Missing function docstring (missing-docstring)
C:  6, 4: Black listed name "foo" (blacklisted-name)
W: 13, 4: Unreachable code (unreachable)
W:  9, 4: Unused variable 'unused' (unused-variable)


Report
======
8 statements analysed.

Statistics by type
------------------

+---------+-------+-----------+-----------+------------+---------+
|type     |number |old number |difference |%documented |%badname |
+=========+=======+===========+===========+============+=========+
|module   |1      |NC         |NC         |0.00        |0.00     |
+---------+-------+-----------+-----------+------------+---------+
|class    |0      |NC         |NC         |0           |0        |
+---------+-------+-----------+-----------+------------+---------+
|method   |0      |NC         |NC         |0           |0        |
+---------+-------+-----------+-----------+------------+---------+
|function |1      |NC         |NC         |0.00        |0.00     |
+---------+-------+-----------+-----------+------------+---------+



Raw metrics
-----------

+----------+-------+------+---------+-----------+
|type      |number |%     |previous |difference |
+==========+=======+======+=========+===========+
|code      |9      |47.37 |NC       |NC         |
+----------+-------+------+---------+-----------+
|docstring |0      |0.00  |NC       |NC         |
+----------+-------+------+---------+-----------+
|comment   |2      |10.53 |NC       |NC         |
+----------+-------+------+---------+-----------+
|empty     |8      |42.11 |NC       |NC         |
+----------+-------+------+---------+-----------+



Duplication
-----------

+-------------------------+------+---------+-----------+
|                         |now   |previous |difference |
+=========================+======+=========+===========+
|nb duplicated lines      |0     |NC       |NC         |
+-------------------------+------+---------+-----------+
|percent duplicated lines |0.000 |NC       |NC         |
+-------------------------+------+---------+-----------+



Messages by category
--------------------

+-----------+-------+---------+-----------+
|type       |number |previous |difference |
+===========+=======+=========+===========+
|convention |6      |NC       |NC         |
+-----------+-------+---------+-----------+
|refactor   |0      |NC       |NC         |
+-----------+-------+---------+-----------+
|warning    |2      |NC       |NC         |
+-----------+-------+---------+-----------+
|error      |0      |NC       |NC         |
+-----------+-------+---------+-----------+



Messages
--------

+-------------------+------------+
|message id         |occurrences |
+===================+============+
|superfluous-parens |2           |
+-------------------+------------+
|missing-docstring  |2           |
+-------------------+------------+
|unused-variable    |1           |
+-------------------+------------+
|unreachable        |1           |
+-------------------+------------+
|trailing-newlines  |1           |
+-------------------+------------+
|blacklisted-name   |1           |
+-------------------+------------+



Global evaluation
-----------------
Your code has been rated at 0.00/10

ほとんどがコーディングスタイル違反を意味するCのようです。

しかし細かく分析してくれるのはうれしいですね。今思えばrubyで静的解析使ったことないなぁ。

条件分岐と真偽値

どの言語でも何がTrueかFalseかは注目されますね。boolメソッドを使えば真偽値が分かるということですね。空文字や空配列がfalseになるようです。

非推奨のモジュール

importすれば使えるpython標準モジュールのことでしょうか。rubyでいうところのSetとかそのあたりかな。Deprecatedになってないか注意して使いましょうということですね。

紹介されていますが、そもそもの知識がないのでskip。

Pythonらしく書く

ここから急に難しくなりますね。Python初心者にはつらいところ。

イテレータとコンテナ

イテレータrubyにもあるのでわかりますよ。

[vagrant@smartpython ~]$ cat iter.py
iter = [1,2,3]
for i in iter:
    print(i)

実行するとこうなる。

[vagrant@smartpython ~]$ python iter.py
1
2
3

辞書、リスト、集合などをイテラブルなオブジェクトと呼びます。

なるほど、これらのイテラブルなオブジェクトの内部でイテレータオブジェクトは使われていて、このイテレータはnextで次に渡されたら中の要素は消えてしまうということですね。

そしてその間に存在するのがコンテナオブジェクト。イテラブルなオブジェクトは中身を一度コンテナオブジェクトに渡して、そこからイテレータオブジェクトを生成するといったイメージでしょうか。

内包表記

例えばリストでいえば、[]の中身にリストの要素を返却するロジックを記述すれば行数を少なくできる、という感じでしょうか。

確かにこれは楽ですね。横着している気分。

デコレータ

これ、仕事中に出てきてわからなかったやつですね。Pythonできる同期に聞いたんでした。

関数をデコレートして、付加価値をつける仕組みですね。例えばこの関数を呼び出す前にかならず行いたい処理を足したりできます。

これは面白い仕組みだと思います。コードを読む立場は大変だと思いますが、いろいろなことができる可能性がある。Pythonらしさのために必要なんだろうなと思いますね。

コンテキストマネージャ

ある処理の前後に何かをするときに使われるという。

with句のことをコンテキストマネージャと言うんですね。

おわりに

ちょっとPythonを一通り触っているひとでないと理解が難しい領域になってきました。想定読者は入門書終わったひとって言ってるんですから当たり前ですけれども。今回一周しておいて、また戻ってこれるような本だと思います!

次回で残り2章をやって終えたいと思います!