プログラミング言語雑感 2017春

まえおき

kyon_mm のスキルでは。。。っていうだけで、皆さんがどうなのかはしりません。

Groovy

こまったらまずこれで検討するやつ。(.NETと比較して)どこでも動いてよい。IntelliJ IDEA + Gradleでつかっておけば問題ないやつ。

GrabやGradleの恩恵がすさまじく、可搬性の高いスクリプトやアプリケーションの開発にもってこいですね。くわえて、Spockっていうすばらしいテスティングフレームワークがあるだけで採用したくなる。Groovy自体も漸進的型付きなかんじがあって、そこそこに静的な型検査ができるのもいいなーとか。

WebアプリケーションつくるときはさいきんはRatpackっていうフレームワークでつくることがおおいですが、ガチな運用したことがないので結局はGrailsがいいっていう場面はあるのかもなーっていう見解。

C#

Visual Studioと.NET Frameworkから離れなければとりあえず安定している。いつも不満なのは、Visual Studioで出来る操作をMSBuildでやるにはどうしたらいいのか調べるのに苦労しています。誰かサクサク知る方法を教えてください。

async/awaitの変換回りはかなり気色悪い(褒めている)とかあるんですが、(LangExt っていうライブラリをつかえば)そこそこつかえるかなぁとはおもっています。 いつも不満なのは、ASP.NETとかADO.NETとかそういうやつですよ。(あれー)

F#

.NET Frameworkでアプリケーションつくるときの第一候補とする言語。C# とかいう言語では最近REPLができたそうですが、F# は古来からありますよ! みんなでレッツF# !

F# はアクティブパターンがつかいやすくてマヂ神! ってかんじですかね。タイププロバイダーとかいうおもしろ機能はいろいろ使いこみたいんですが、まだ使いこなせていないです。 あ、あと弊社? で開発している FQC っていうコンパイラの後ろ部分(IL生成部分)があるので、こいつへのPullReqとかおまちしております。

ほかの言語

よくわからん。とりあえず、言語仕様書とGetting Startよめばなんとかなるだろという雑な扱い。 Javaは最新の言語仕様書読めていないし、C++はそもそもたいしてしらないです。言語仕様書がうすい言語は勉強しやすくてよいですね。(そうだろうか。。。)

Erlang

最近勉強しているのは、CoqからErlangの生成とかできるのではーと妄想して調べていたら、PPLでそんな話があったとかで、やっぱりそうなるよねー!っていう話をステーキたべながらしていた。 Erlangカッコイイなーってあこがれこそあれど、なかなかたくさんのコードを書こうとすると、なれがたりていないです。。。(静的型検査がないやつで、たくさんのコードを書くことにそもそもなれていないってだけです)

JavaScript

JavaScriptは僕にはむずかしいので、Vue.js でいいかんじにやっておしまいです。Vuejsの日本語ドキュメントすばらしい。課金したい。 一時期は、AltJSで生成すればなんとかなるとかおもっていましたが、JavaScript書くほうが楽な場面そこそこあるなーっておもっていました。 それもWebAssemblyでなんとかなるのかもーっていう夢がひろがってよいですね。

Java

Groovyを実行する基盤のやつ。ヴァルハラ〜。各プログラミング言語とかビルドツールがJava9にスムーズに対応できるのか不安。

OCaml

なごやで公用語のやつ。プログラミングの基礎っていう書籍でつかわれているしね。

いまだに自分はプロダクトにしろツールにしろ仕事でつかったことがないので、いつかつかってみたいとおもって幾年ってかんじです。 Emacs以外でいいかんじにつかえるIDEがほしいです。JetBrainsさんつくってくれませんかね。

Scala

東京で定番化?流行?しているらしい。個人的にはGatlingつかわないWeb企業ほぼないとおもっているので、Scala書いたことないWeb系の人いるほうが希少なのではーくらいにおもっている。

VDM++

形式的な仕様に憧れてさわってみたりしているものの、「おれがつくったほうがもっといいDSLつくれそう」というサイクルをとおして振り出しにもどる系の言語です。もう最近はVDM++でいいんじゃないだろうか。。。っていう気がしなくもないですが、B-Methodとどっちにすればいいんだーってなやんじゃいます。

ふりかえり

JetBrainsさんがいないと生きていけないです。

Java女子部でSpockの入門ハンズオン講師しました。 #javajo

Java女子部というコミュニティで2017/03/25に半日間のハンズオンでSpockというテスティングフレームワークの使い方を教えてきました。 Javaはだいたい書けるけど、Groovyとかよくわかりません！みたいな人に最低限のGroovyの使い方とSpockを教えるみたいな感じです。

javajo.doorkeeper.jp

すすめかたはだいたい次のような感じです。

1. GitHubからソースコードをダウンロードしてもらう
2. kyon_mmがスライドで概要をつたえる
3. kyon_mmがIDEでサンプルコードをひらきながら解説する
4. 参加者がサンプルコードのテストが失敗している部分を通るように直す
5. kyon_mmがテストが通るようにコードを記述するのデモする
6. Groovy/Spockの基本については2 - 5を繰り返す
7. 解説がおわったらペアプロでTDDライクにSpockをつかいながらコードをかいてもらう

いわゆるKoan形式とか4clojureみたいなかんじといいますか、テストが通るように修正することで機能を学んでいくっていう感じです。

speakerdeck.com

github.com

スライドに誤解をまねくような表現がないように配慮したつもりですが、もし違っていたらツッコミもらえるとうれしいです。 Groovyの解説はJava8のまま書いても動かないところを中心にしました。

また、当日サンプルコードがいくつか間違っていたので修正したものをGitHubにあげています。

正規表現のところに // によってエスケープがなんたらというテストを最初書いてしまっていて、 動かなかったのは、文字列としてであって正規表現でのテストではなかったためです。現在のGitHubのmasterでは文字列のテストに移してあります。すみませんでしたー＞＜

全体的には自分の知識が再整理されたとか、TDDとはなんだーとか、自動テストの考えかたとかいろいろ興味をもってもらえたのがとても勉強になりました。 呼んでいただいたJava女子部の皆様には感謝です。特に声をかけていただいた、あやさんありがとう！ Java女子部はもっと怖い人のいるところだとおもっていましたが、みなさん優しかったですし、楽しい人達でした。 参加者のみなさまからも楽しかったと言ってもらえたので、やってよかったなーっておもえました。

今後も関わるのであれば、Java女子部でF#をつっこむのは難しいでしょうし、GatlingとかBetamaxとかGebでしょうか。

GroovyとかSpockまぢべんりな子なので、ぜひ使ってみていただけると嬉しいです。 また、スライドやGitHubはご自由に使っていただいて構いません。みなさまでSpockを愛でる方向で。

Enjoy Spock!

うさみみが2016年に読んだオススメ書籍と振り返り

仕事

社内他チームをマネジメントしたり、Breaking Scrumしたりと挑戦しました。たのしかったです。 セミナーや新卒研修などにも携わり。ヴァル研究所様とお仕事できたのは素晴しい経験になりました。 また、 enPiT という文科省と各大学の連携でやっている「（僕から見ると）イケてるITエンジニアの卵つくろうぜプロジェクト」に関わらせていただきました。大学院生の教育に関われる日が来てよかった。これからも積極的にかかわりたいです。 株式会社オンザロードというか、僕へのお仕事の依頼はいつでもWelcomeなので kyon.mm あっとまーく gmail.com まで。

講演

1月に「15分単位でメトリクスとってるスクラムチームあるんだけど、質問ある？」っていう発表をしてから、ちょこちょこ発表をしました。

• 2016/1 Regional Scrum Gathering Tokyo 2016 Scrum,Test,Metrics #sgt2016
• 2016/3 九州ソフトウェアテスト勉強会 Startup.Retrospective
• 2016/4 NL名古屋 NAGOYA SCRUM LEARNING #nlnagoya // Speaker Deck
• 2016/5 アジャイルジャパン 2016 まだテスト期間とかつくっているの？ ～アジャイルな開発におけるテストとの付き合い方～ AgileJapan2016
• 2016/9 Hacker Tackle 2016 アジャイル開発のテスト -自動化でしょうか。いいえ、戦略勝ちです。- // Speaker Deck
• 2016/10 Scrum現場ガイド MeetUp スクラム現場ガイド第1部で大切だと思うこと #nagoya_scrum // Speaker Deck
• 2016/11 JJUG CCC 2016 Fall Featherweight JavaやGroovyの漸進的型付けについて
• 2016/12 Nagoya.Testing in Tokyo アジャイルテスティング -バグ埋め込みを年間1件にまで減らした戦略- #NagoyaTesting // Speaker Deck

(意外と発表してた)

セミナー

3ヶ月に1度くらいのペースで、Git Boot Camp Premiumというセミナーを翔泳社で開催しています。ちなみにオンサイトでも開催できるのでいつでも依頼してください。(他のものでも) 2017年からはもっと他のセミナーも増やそうかと計画中です。

私生活

幸せでした。家族に感謝ですね。

その他いろんなこと

すみませんでしたああああああ＞＜

2017年にやりたいこと

1. きょんくんがいないチームにBreaking Scrumを導入したい。（きょんくん流 Breaking Scrumの導入事例になってみたいチーム募集しています）
2. F# かOCamlかGroovyで仕事したいので、仕事ください。
3. 形式手法導入したい。

読んだオススメなやつ

ここから下は基本的にどれも素敵な書籍なんですが、そこから更に好きなやつを選ぶなら、

• Joy, Inc
• SOFT SKILLS
• なぜ人と組織は変われないのか ― ハーバード流 自己変革の理論と実践
• グッド・マス ギークのための数・論理・計算機科学

ですね。まぁ、好みも問題かも。

IT系にいるならよんでほしいやつ

SOFT SKILLS ソフトウェア開発者の人生マニュアル

組織とかチーム

ジョイ・インク 役職も部署もない全員主役のマネジメント

なぜ人と組織は変われないのか ― ハーバード流 自己変革の理論と実践

スクラム現場ガイド -スクラムを始めてみたけどうまくいかない時に読む本-

カンバン仕事術

トヨタのカタ 驚異の業績を支える思考と行動のルーティン

ザ・トヨタウェイ(上)

ザ・トヨタウェイ(下)

チームワークの心理学: エビデンスに基づいた実践へのヒント

自衛隊メンタル教官が教える 心の疲れをとる技術 (朝日新書)

数学的な

圏論の歩き方

グッド・マス ギークのための数・論理・計算機科学

記号論理学: 一般化と記号化

アルゴリズムとかデータ構造とか

Purely Functional Data Structures

教育

幼児教育の経済学

「学力」の経済学

ネットワーク

擬人化でまなぼ! ネットワークのしくみ

さいごに

みなさまありがとうございました。ほんとうに。来年はもっとブログ書きます。

Gitを5年間教える側にまわって気付いたこと

Git Advent Calendar 2016 - Qiita の記事になります。 本記事では自分がGitを教えたことで気付いたことをまとめます。 ゆえに「Gitに入門したい人」に向けたものではありません。が、多少のエントリーポイントは示しますので参考になるかとは思います。 コミュニティ、有償セミナーで5年間Gitを中心としたバージョン管理システムを教えてきた経験の話です。 ただ、Git, GitHubなどのデベロッパーではないので、彼等の思想とは異なるかもしれませんが、そこは一人のGitの講師として見てもらえれば。

命名の混乱とユーザー層

Gitのコマンドは名前から理解しにくいことで有名です。 git rebase --intractive などは典型です。 例えば、branch という単語が示す内容はあまりにも違っています。 VCS毎に branch の意味が違うことも難しくしていますが、加えてGitの場合には branch (枝)というメタファーと実態の乖離が大きく、理解するまで時間がかかったという人もいるようです。 (ちなみにMercurialでは同等機能は bookmark となっており、Mercurialはbranch(枝)とbookmark(しおり)の両方で管理することができます)

そして、ユーザー層?スキーム?が様々であるため、GUIツールではあまり対応がとれないような言葉になっていることもあります。 GUIツールで困ったときに違う単語で調べる必要があり、加えてGitのコアユーザーはコマンドラインで使うため、GUIツールのトラブルシューティング情報は少なめになっています。 もちろんこれらを乗り越える人もいますが、自分の経験ではあまりいませんでした。 乗り越えないままに使うことはできるけど。。。という感じでしょうか。 ので、トラブルが起きたときにはGitで解決をせずに別の方法(ファイルのバックアップをどこかからもってきたり、新しくリポジトリをcloneしなおしてから、コピペしたりすること)で解決している人もたくさんいます。 別にそれ自体は悪くないですが、Gitの学習という意味では大きな壁になっています。

そういった意味で、自分が大切にしているのは Git公式の Pro Git というページです。 Git - Book

このページを読んで理解できるのであれば、それなりにプログラミングや、VCSに精通しているとおもいます。 ですが、なんとなくで使える程度の人や、パパっとワークフローがわかればいい人にはちんぷんかんぷんなページだと思います。 ここにある概念を大切にしながらGitを使う開発プロセスのトレードオフを伝えることが大切だと思っています。

Gitの概念を日本語でうまく表現している書籍は次の2冊だと思います。出版時期は少々古いのですが、あまり古びた内容でもありません。

入門Git

実用Git

バージョン管理、統合の戦略が広まっていない

Gitを教えていていつもぶつかるのは、そもそもSCM(Software Configuration Management)の戦略が知識としてもあまり広まっていないということです。 GitはSCMを支える重要な要素ですし、様々な戦略を取れるようにGit自身は多数の機能を提供しています。 この何年かで、「ローカルでGitを使うときの作法」「Pull Requestによるレビュープロセスの確立」「Infrastructure as a Code」といった知見は広まってきましたが、バージョン管理を活用したチームやプロダクトのプロセス品質を上げるという方向についての議論はあまりされていません。 というよりは、ずっと課題だと思う(ソフトウェア構成管理という単語がずっと使われている事情からそう思う)わけですが、流れとしては「SCMの戦略」よりも「SCMを中心として少しでもよくなってきている開発の改善力を中心にもっと範囲を広げよう」という感じだと見ています。 大切だと思いますし、そうすることで無駄が減る(部分最適をする前に全体を見ることが出来ることによって余計なことをしないで済む)こともあります。 ですが、Gitを活用したSCMの戦略が貧困なままでは、ビジネスのボトルネックになるばかりです。

一例としては、 Jenkins + GitによるIntegrated Workflow + Gateway CheckInを実践することができます。

JenkinsとGitで実装するGatewayCheckIn Pattern #AsianAA from kyon mm

www.slideshare.net

また、SCMという広い意味では次も参考になります。

qiita.com

「何を編集しやすく、何を実行しやすく、何を統合しやすく、何をレビューしやすく、何を組合せやすく、何をスケールアウトしやすく」それぞれのトレードオフや理想を達成するためにGitを利用することは多くの場面で大切です。

ただ、そういったSCMの戦略がわかっていない、関心がない人もたくさんいますし、必要ではない人もいます。 (もちろんわかっている人もたくさんいますが、割合の話ですね)

まとめ

• Gitの概念、コマンドを覚えるのは苦労しやすいポイントであり、反復練習か、Gitを使わないという選択肢を見つける必要がありそう。そして、それに耐えられない人がGitをなかなか使い始められなかったり、Git使っています() みたいな状態になってしまっている。
• Gitを使うことで、どのような理想的な開発プロセスにしたいのか。というSCMの戦略に関心がない人や、そもそも知識が共有されていない現状があることを踏まえて、Gitの使い方を教える必要がある。

自分の教えかたを2,3年毎に大きく変化させることでいくつか気付きがありましたが、大きいこの2つについて紹介しました。 では、これらをどうするのか? という話ですが、前者は Gitカルタ という形でコマンドをさわらずにGitの操作をイメージで掴めるようなゲームとして教えています。

codezine.jp

後者については、事例をはさみながら教えていますが、いまのところGit Boot Camp Premiumというセミナーでは最初のほうだけを教えるに留まっています。 ので、更に拡充して2017年はコミュニティ、有償セミナーを開催しようと思います。おそらく別枠で開催する感じがいいかなぁと。

おまけ

弊社、基盤チームではGitからの脱却を目指して新しいVCSの設計を始めています。いつ完成するのかはわかりません。いろいろ不満なのでね。。。

組織（チーム）を成長させるための参考書籍

概要

マネジメントやプロセスの方法論自体をどのように適用、変化させるのか。 というのは、方法論自体を知る必要があるのはもちろんのこと、どんな組織にしたくて、どうすれば成立できるのかということを考える必要があります。 それらを引っ張るものが、理想や価値観であり、それらを明確につくる能力も大切です。

というのをあるTweetの具体例から入って話しているうちに、参考書籍を紹介しておこうという流れになりました。 ので、ある程度抽象的なやり方っていうんですかね。組織に変化をもたらす方法っていう感じですかね。

Twitterの流れ

togetter.com

参考書籍

ザ・トヨタウェイ(上)

ザ・トヨタウェイ(下)

トヨタのカタ 驚異の業績を支える思考と行動のルーティン

「タレント」の時代 世界で勝ち続ける企業の人材戦略論 (講談社現代新書)

トヨタの強さの秘密 日本人の知らない日本最大のグローバル企業 (講談社現代新書)

エクストリームプログラミング

クリティカルチェーン―なぜ、プロジェクトは予定どおりに進まないのか?

IMPACT MAPPING インパクトのあるソフトウェアを作る

アメリカ海軍に学ぶ「最強のチーム」のつくり方: 一人ひとりの能力を100%高めるマネジメント術 (知的生きかた文庫)

Team Geek ―Googleのギークたちはいかにしてチームを作るのか

HARD THINGS

ワーク・ルールズ！―君の生き方とリーダーシップを変える

蛇足 : 方法の反対は目的ではない

最近勉強していて当たり前？のことを知ったのですが、方法の反対を意味する語は目的ではないという。 目的のために方法があるだけであって、反対という意味ではないというか。 ロランバルトという思想家？の著書をいくつか読んでいるのですが、彼の考え方は非常に刺激的ですので、興味がある方は読んでみてはどうでしょうか。 （ちなみにこのような解釈における方法の反対は教養になります。方法は目的を価値とするけど、教養は縛られるものがないという意味）

というのをこういった方法論とか組織論とか価値とかビジョンを勉強して、自分で考えているときにそういったことを考えていないとまさしく無縄自縛っていう感じになってしまってよくないなぁと。 っていうのを考えるためには哲学とか言語の勉強が役に立っています！

Hacker Tackleでアジャイルテストにおけるアンチパターンについて講演しました。 #hackt

3行まとめ

• Hacker Tackleっていう激熱なITデベロッパー向けのイベントで「アジャイルテスト」について講演しました。
• みなさんがつらいのはわかるけど、解決したいなら本気で取り組む必要があるので、参考になれば幸いです。
• あと、アジャイルにテストしている人達といろいろ議論したいです。

Hacker Tackleとはなにか

hackertackle.github.io

HackerTackleは、プログラマのための総合技術イベントです。 「ハッカー・タックル/博多・来る」の意味を持つイベント名には、多くのハッカーが博多に来て、さまざまな議論をぶつけあう場になればという思いがこめられています。 イマのプログラマにとって必要な知識を切り取った、さまざまな技術に関するセッションを用意しています。 ぜひ博多に来て、新しい技術を吸収し、議論をぶつけあってみませんか？

なんかMMA感がありますが、まさしく登壇者の多様性と豪華さはすごかったです。 主催者と登壇者のみなさまほんとうにありがとうございました。 僕はホクホクして帰りました。

名前の由来はハッカータックル、ハカタクル、博多来る というかんじです。 今年で2回目ということでして、昨年に引き続き参加させてもらいました。

どんな講演をしたのか

speakerdeck.com

50分間の講演だったので、30分はスライドの内容をかいつまんではなし、20分は会場と意見交換をしました。

スライドでは次の3つのアンチパターンを紹介しました。

1. 過剰自動化
2. モック酔い
3. TDD不要論

で、時間の都合上2番目のモック酔いは軽くだけふれて、1と3を中心的に話しました。 これら3つはまぁ私のまわりではよくあったので、その状況における原因とか自分なりの対策をまとめました。

ちなみに1の話ではかの「自動化ハイ」についても口頭で言及しました。 @関西のテスト自動化コミュニティ

また、アンチパターンだけはなしても「こいつうさんくさい」とおもわれるかなぁとおもったので、 一部ではありますが、自分達のチームがどのようにテストにとりくんでいるかも紹介しました。

いまは少しずつですが、手動テストもテスティングフレームワークで書くような下地をつくりはじめているところ。ってかんじですかね。

会場との意見交換では、いろんな質問がでておもしろかったです。 きょんくんの現場ではこういったことは困っていないのか？といったものから、参加者さまの現場で困っていることについての方針相談などなど。

まとめ

アジャイルって「素早く順応する」ってことが大切だとおもうので、みなさんも自身含めてどんどん変化していくとよいのでは！！！とおもっています。

改めてになりますが、Hacker Tackleの運営のみなさまによって素晴しい会になったとおもいます。本当にありがとうございました。 また、来年も参加させてもらえると非常にうれしいです。

Specification by Example: How Successful Teams Deliver the Right Software

スクラム現場ガイド -スクラムを始めてみたけどうまくいかない時に読む本-

「アジャイルコーチの道具箱 - #見える化実例集 -」を読みました。 by mari

kyon_mmさんの友人のmariです。今回はkyon_mmさんのブログを借りて、「アジャイルコーチの道具箱 -見える化実例集-」の書評を書かせていただきました。

本書はすごく楽しんで読めた一冊でした。著者、翻訳者のみなさまありがとうございます！

leanpub.com

付箋愛

まず感じたのは、「溢れんばかりの付箋愛！」です。 私も会社でガンガン使っています。 すぐかけて、貼りたいところに貼れて、 誰かに渡すことも簡単で、すぐ共有できる！

付箋がもたらす情報共有力、見える化力ってすごいですよね。 私も好きです、付箋。

肝心の本書の内容について。

基本的に説明が書いていないので、好き嫌いは分かれる本なのかもしれないなぁと思います。 どういう理由でそれをやるのか、を誰かに教えてほしい人には読みづらく感じそうです。 説明がないと物足りない！って人は、別の本を読んだ方がいいと思います。 私はどちらかというと感覚でものをとらえるタイプなので、 非常に好きなタイプの本でした。

Exampleが基本1頁に1つの構成になっていて非常に読みやすいです。 読むというより、観るって感じが近いかもしれません。 長い文章が一切なく、半分以上が図となっており、感覚的に脳に入ってきます。 本書で取り扱うExampleの中にも、図や表を利用するExampleが多く出てきますが、 それらの効果を本書をもって証明しているように思います。 すぐにできそうなシンプルなExampleばかりで、すぐにでもTryできそうです。

見えるようになるとそもそも何が嬉しいのか。

1. 気づかなかったことに気づくようになり、今まで考えなかったことを考えるようになる。
2. コミュニケーションが増える。
3. 知らなかったことを知ることができる。
4. 成長できる。
5. 楽しいと思える機会が増える(ここは人によりそうですね。)

楽しんでチームと仕事をする、という部分に特化しすぎているように思える部分もありますが、 「楽しむ→やる気がでる→効率よく仕事ができる」 とつながっていくので、仕事をするうえで楽しむって必要なことなんじゃないかな、と自分は思います。 「仕事に楽しさは求めていない」という人もいますが、 私は楽しむことで、自分の人生が金銭的にもメンタル的にも豊かになると信じています。 本書には、楽しんで仕事をする、チームうまくやる、ための工夫がたくさん詰まっています。

下記に、特に自分の心に響いた部分をいくつか引用し、レビューの締めとします。

シンプルに。

更新されなくなると信用されなくなり、どんどん使われなくなっていく。

どんな情報もツールも同じだし、よくあることだと思います。 メンテナンスされない膨大な利用ガイドや、設計書を含め、 身に覚えがある人も多いのではないでしょうか。 始めは凝ったつくりにするものの、結果として自己満足になっていて、 他の人からすると、情報や装飾が多すぎて使いつらいとか、読みづらいとか、 そういう使えないものになり、更新されなくなっていく。 作った人は、せっかく作ったのに、とイライラし、結果としてチームの雰囲気が悪くなる。

私は身に覚えがありすぎて、「本当それ！」と叫びそうになりました。 言うのは簡単ですが、実行するのは難しい。 「シンプルに」考える、「シンプルな」ものをつくる、 このあたりの考え方は、人生をより楽しく生きるためにも必要な要素だと思います。

自信のニコニコマーク！

これならひとりひとりの感覚が可視化できるし、 毎日、進捗や達成可能か？と考えることができます。 そして達成できるためにできることはないだろうか、と考えるきっかけとなると思います。 なんとなくバーンダウンを見て、「はい、見た！終わり。」ってなっているチームや、 そもそもバーンダウンなんて見てません！ってチームに取り入れると意識が変わりそうですね。

情けない話、自分のチームではそういうことがありました。 こういう工夫をしていたら、もっとよいチームになれたような気がします。

評価しよう。改善、調整をしよう。必要ないなら、使うのをやめよう。

やめ際がわからなくて、ずるずると必要のないことをやってしまったり、 引き際がわからなくて、余計なことを言ってしまったり… たくさん思い当たるふしがあります。 ずっとやってるからといって、必要かどうかを考えずにやり続けている レガシー的な何かとか。 常に物事は変わっていくのだから、常に評価して 必要がないのであればやめるというのはよく考えたら当然のことですね。 全然できていないけど、それは頭を使っていないってことなんだなぁと思いました。