いろんな意味でこれからは「自分モード」で考えたほうが良い

 この本を読んだ。いくつも示唆があった。

直感と論理をつなぐ思考法 VISION DRIVEN

４つの思考サイクル

まず、思考サイクルを４つに分けていて、特徴的な比喩で表現している。

1. カイゼン思考
2. 戦略思考
3. デザイン思考
4. ビジョン思考

これが自分のこれまでの思考に対する姿勢とリンクをしていて面白いと思った。社会人になって、長いこと、カイゼン思考で、まさに改善するには？、KPIを達成するには？という思考でやってきた。あるタイミングで、これではいけない。もっと仕事ができるようになりたいと思って、論理的思考法などのビジネス本を読んだり、ビジネススクール行ったりして戦略思考に足を踏み入れてみた。コンサルに転職したのもこのころ。ビジネスモデルとは、事業とは、マネジメントとは、みたいな、テクニックの話よりやや本質っぽいことにも興味を持ちだした時期。しなければならない、とか、すべきだという思考で走ってきて、それ以外のやり方は試してこなかった。地に足がついてないことを提案されると、うーんと腰が引けたり、あまり乗り気でなかったり。そういうやり方でよいと思っていた。まあ、悪くはないのだけど、仕事というものはそれが全てと思っていた。

自分モードと他人モード

ここに書かれている「他人モード」（市場や他者）中心で考えてきたと思う。「自分モード」は必要がないものと考えていた。まさに、この引用の状態。人に喜んでもらえて、評価をしてもらえるから、だからいいじゃんと思い、自分がなくなっていることに対して、さほど問題と思わなくなる。

他人が抱える問題の解決ばかりに夢中になっていると、「誰の役にも立たないけれど、自分にとって大切なこと」が視界から消えていく。人の役に立つのが楽しいと思って続けていると、いつのまにか「自分がなくなっている」ことに気づく。

でも、変化が激しく不確実性が増える未来の予測自体が難しいなかで、これまでのように、ある意味まじめに「他人モード」でだけ考えてても、成功できるとは限らなくなってきている。たしかに。さらに、「自分モード」のほうが楽しそう。

他人モードの思考で、お金と信頼残高を稼ぎ、自分モードの思考で妄想を叶えることをできたら、仕事というか生活がより面白みが増すと思う。

 

手を使い耳を使い目を使う思考

言葉にたよらず、手で書いたり、組み立てたり、絵をかいて視覚化したり、頭で考えて言語で論理を積み上げるやり方ではない思考の仕方がいろいろ紹介されている。手書きで視覚化してみるということはやってこなかったことなので、ちょっとやってみようかと思う。

やりたい仕事と人から求められる仕事

　「自分がやりたい仕事」と「人からやってほしいと求められる仕事」のどちらを選ぶだろうか。前者は喜んで仕事をするだろうし、後者は人から喜ばれる。悩ましい。たいていの場合、両方を満たすオーダーは来ない。

　先日、手掛けている仕事が終了する見通しのため、次の仕事というか役割の打診を受けた。これが「自分がやりたい仕事ではないけれど、たぶんできる」かつ、「今の会社のビジネスにとって自分がやりたい仕事よりも大事」で「やれる人が少ない」仕事だった。内心、ちょっとちがうなーとは思ったものの、肯定的な返事をした。これまで自分のやりたいことに対するこだわりはあるほうだったので、自分としては意外な対応だった。

　自分なりに掘り下げてみたところ、信頼残高のほうが大事とか、喜んでもらって次の仕事は自分のやりたいことを、みたいな下心はあるけど、一番大きいのは、自分がやりたいことってそんなにこだわる必要あるんだっけ？と思えるようになったたこと。明らかに自分として駄目なこと苦手すぎることじゃない限り、話に乗ってもいいのでは、と思うようになった。

いいことなのかどうなのか。いったん、話に乗ってみることにする。どうなることやら。

KPTは繰り返すこととテーマ設定が大事

今の現場で、「ふりかえり」や「KPT」が推奨されている。ほぼ強制的にチームや個人ごとにふりかえりを行うことになっている。自分はふりかえり賛成派というわけでもないけど、まあやったほうがよいよね、という消極派である。けれども、これまでのふりかえりをしたときに、例えば以下のような点で、うまくできないなと感じていた。

• チームの雰囲気が悪い、疲れている状況でおこなうと人を責めるようなProblemが出てきて険悪になる
• 組織のルールでふりかえりをやると決められているから、やらされ感でとりあえず実施し、上司に報告しやすいTryを作り出すことに終始する
• 個人でふりかえりすると、全然Keepがでてこない
• 個人でも、チームでも、カイゼンのサイクルが継続して回せない

ちょうど、今、ふりかえりの準備をしている中で、「Problemしかでてこないけど、そもそも、このやり方で会ってるんだっけ？」とおもい、手に取ったのがこの本である。

何人かの人からおすすめされていたので、興味を持っていたけど、必要に迫られなかったので、これまで読めていなかった。

これだけ! KPT

KPTの考え方やふりかえりMTGの運営の仕方が体系立てて整理されていて、頭の整理になった。

中でも、「KPTは繰り返して行うことでその効果がより大きくなる」ということ、「ふりかえり会はテーマに向かって振り返ることが前提」ということが自分には印象に残った。これまでの自分のふりかえりではできていなかったことだった。

まず、「KPTは繰り返して行うことでその効果がより大きくなる」ということについては、「KPTのサイクル」として図にまとまっている。これが自分にしっくり来た。Tryの導き出し方が特にこういう経路なのか、と腹落ちした。

1. よかったこと・今後も続けることをKeepへ
2. 困ったこと、問題点をProblemへ
3. Problemに聞きそうな改善策をTryへ
4. Keepを強化する改善策をTryへ
5. 試してみたいことをTryへ
6. Tryの中から試すことを選択
7. 試してみてうまくいったこと、続けたいことをKeepへ

主なカイゼンのサイクルはこのようなもの。Keepで終わるのがポイント。Problemからはじまるものはなじみがあるけど、Try、Keepから始まるものは考えたことがあまりない気がする。あっても、Problemより優先度が下がる感じ

• Problem⇒Try⇒Keep
• Try⇒Keep
• Keep⇒Try⇒Keep

テーマ設定に関しては、

• チームの現状とマッチしている
• 継続性のある
• 簡単には到達できない

という例をあげている。例として、「業務をよりシンプルにより素早く行うには～

」というテーマがあげられている。最初に挙げた自分の失敗談で、険悪な雰囲気になるとか、やらされ感でおこなうとかは、テーマ設定が、「残業時間を今より減らすには」とか「お客さんのクレームを減らすには」とかメンバーが何とかしたいと思っているテーマ設定だったらうまく意見が出たかもしれないと思った。

その他、KPTを通してチームを育てるということやKPTを生かすテクニックなど、ためになることが色々書かれている。目標管理面談で使えそうな「KPT話法」は自分も使ってみよう。

ふりかえりについては、今は現場のルールとしてやることになっているのだけど、せっかくなので何か実りある時間にしたい。まずは個人でふりかえりするときに、テーマ設定して、ライトな内容でもいいから、繰り返してサイクルを回すようにしてみようと思った。ルールも意図を理解して、自分の意志で運用すれば、やらされ感は薄まるはず。

不確実さに向き合おう。個人も組織も。

「変化が激しい時代」「変化に適応しよう」と会社でもよく言われています。自分もメンバーに訳知り顔に語ったりしています。でも、実際に何をしたらいいのか、個人・チーム・組織レベルで何をポイントにすればいいのか、を語ろうとすると、精神論になってしまったり、抽象的な話になってしまいます。

エンジニアリング組織論への招待 ~不確実性に向き合う思考と組織のリファクタリング

この本は、「エンジニアリングというものはあいまいなもの、つまり不確実性を具体化していくことで、何かを実現することである」という解釈の下で、不確実性に向き合うための方法を紹介しています。面白いのは、いきなり組織論に入らずに、まず「思考のリファクタリング」ということで、個人の思考での無駄なプロセスの削減について語り、続いて、1対1のメンタリング、チーム、組織と、範囲を広げて解説していっているということ。やっぱり個人の活動が肝になるということと理解。いろんな順番で読む人もいると思うけど、私は「思考のリファクタリング」から読むことをお勧めしたい。

ここで言っているのは、不確実性とは「未来」「他人」によるもの。情報を生み出し、不確実性を下げていくには、次の３つの考え方が大事であるといっています。

• 論理的思考の盲点
• 経験主義・仮説思考
• システム思考

特に、論理的思考の盲点は、我々は非論理的になることもあるということを自覚しようということを言っていて、本当にその通り、なのですが、一方で仕事で感情の話とか持ち込んでもいいんだ。知らなかったよと感慨深い気持ちになりました。どんな人でも認知のゆがみやそのほか論理的ではない思考をしてしまうときがある、むしろ非論理的なモードのほうが多いかもということを知ったうえで、判断したり、人と話したりをしたほうがいいなと思いました。非論理的になる自分を駄目だなと責めずに、織り込んで考えればいい。

その他、メンタリングの章では、他の人の思考のリファクタリングをするための方法についても紹介されています。私はどちらかというと、1対多より、1対1のコミュニケーションのほうが得意というか緊張しないので、参考にしてみたいと思います。自分の中で、これまでちがいがよくわからなかった2つの言葉が整理できたのがよかった。「共感」これならできそうな気がする。

• 共感＝相手がそのような気持になった理由を理解すること
• 同感＝相手と同じ気持ちになること

自分にとっては、エンジニアリングというもの、不確実性というもの、を頭の中で整理することができる本でした。チーム、組織論の話も興味深いポイントが書いてあるので、別で深堀してみたい。

まずは、自分の思考のリファクタリングからだなと思いました。自分が変わってみせたほうが、なんだかんだで周りを巻き込みやすいし。

この本を40分で読んで、ブログに40分くらいでまとめているけど、やればできるということがわかった。でも、もうちょっと内容に深みが欲しい。言語化は難しい。

JSTQB TMに合格した

先日、受験したJSTQB　AL（Test Manager）に合格した。せっかくなので、勉強法というか、やったことを備忘のために書いておくことにする。Test Analystはまだ持っていないというか、前回不合格だったので、Analystの勉強時の参考にしたいと思う。

勉強期間

2か月～1か月半。2，3日に1時間程度の勉強時間。

勉強法

色々なサイトを調べたり、経験者に聞いたりして、情報収集した結果、まずはシラバスをしっかり理解する必要があるのではないか、と思った。時間も限られていたため、シラバスだけをひたすら学習することにした。

学習の優先度

時間も限られていて、シラバスの最後までできるか不安だったので、シラバスの最初から順番に学習するのではなく、優先度をつけて順番に進めていった。全ての章の中で、以下のものから順番に学習をしていった。

（理解に時間がかかりそう、ボリュームがあるところは出題が多そうと考えたため）

• 各章の学習時間が多いもの
• 各章のページ数が多いもの
• 自分が苦手なところ

学習方法

章ごとに以下を行った。章によっては、1章が多いので、その場合は程よい量に分割した。

理解をするということを、実際の例を挙げながら人に説明をできるレベルになると決めたので、以下のようなことを行った。

1. シラバスを読みながら、マインドマップにキーワードを書きだして、頭を整理
2. シラバスを読んでも、よくわからないことがあれば、ネットなどで調べる
3. 書き出したキーワードを眺めつつ、人に説明する感じで説明を考えてみる
4. 自分が経験した現場でいうと、どう説明できるか、考えてみる

実務で人に説明することが多かったので、上記の３，４は実際に説明する人を思い浮かべつつ考えることができた。

最初に決めた優先順位に従い、全ての章について、1～４を行い、心配な部分は３⇒４を繰り返し行った。

試験本番の解き方

前回、TestAnalystのときは、試験時の時間配分に失敗してしまったので、今回はきちんと考えようと思った。

それぞれの問いは、同じ形式ではなく、用語を問うシンプルなものがあれば、数ページにわたる実践的なものがあったり、と種類に分かれている。

Analystの時に身をもって知ったが、試験時間は3時間と長丁場になり、試験も後半になると集中力も落ちて疲れてくる。簡単な問題も解くのがしんどいときもあった。

今回は、元気なうちに確実に正解できる問題を解いていくというやり方にした。

具体的には、問題の種類を1⇒４にざっくりわけて、1週目で１のカテゴリのものを解き、2週目で2のカテゴリのものを解くというやり方をした。

1. シンプルに用語を問うもの
2. 1ページに収まっている実践問題
3. 2ページ以上にわたる実践問題
4. 計算を含む問題

4を最後にしているのは、自分がもともと苦手な分野なので、元気でもうまく解けるか怪しいので、最後に回した。

最後に

Analystの時より色々考えて臨んだものの、やはり試験は疲れた。合格してよかったと思う。

ローカルにCI環境構築して、Jasmineを動かす

JenkinsでJasmineで作ったテストコードを実行するところまでできたので、忘れないうちにメモしとく。

やったこと

• Jenkinsをローカル環境へ環境構築
• Jasmineで作ったテストコードを動かす

Jenkinsインストール

1.homebrewインストール

↓を参考にインストール

macOS 用パッケージマネージャー — macOS 用パッケージマネージャー

2.Jenkinsインストール

brew install jenkins

3.Jenkins起動

java -jar /usr/local/opt/jenkins/libexec/jenkins.war

Jasmineを動かす

1.npmインストール

https://nodejs.org/en/

2.Jasmine-Nodeインストール

npm install jasmine-node -g

3.テスト対象コード、テストコードの修正

テスト対象コード

• exportsを指定する。
• ファイル名を「～Spec」に変更する。

テストコード

• requireにテスト対象コードの相対パスを設定する。

4.テスト実行

jasmine-node テストコードファイル名

JenkinsでJasmineを動かす

1.Jenkins設定

• 新規ジョブ作成
• 「フリースタイル・プロジェクトのビルド」選択

2.Jenkinsのworkspaceフォルダ配下にファイル格納

workspaceフォルダ配下にテスト対象コードとテストコード一式を格納。

3.ジョブの設定と実行

• ビルドの「ビルドの手順」
• 「シェルの実行」
• コマンド記入 

jasmine-node テストコードファイル名

• 保存＆実行

気づき

• Jasmine-nodeで動かす前にテスト対象コードを修正しないといけないらしい。
• テストコードのファイル名は「～Spec」でないといけないのか、もっと調べる
• workspaceにファイルそのものを置くのはいけてない、gitにコミットしたタイミングでJenkinsで動かしたい。

 

Jasmineを使ってTDDをやってみる

はじめに

テスト駆動開発（TDD）が実際にどんな感じか知りたくて、実際にやってみることにした。仕事では直接やっていないし、コード書いてたのもだいぶ昔なので、イチから調べつつ、やってみる。まだコードが未完成だけど、忘れないようにメモしておこう。

言語とかFWとか

• 言語はJavaScript。
• テスティングフレームワークは、Jasmine。なんとなく。
• せっかくなので、Githubにてコード管理。

やったこと

1. Github登録
2. Jasmineインストール
3. Gitインストール
4. ２つFunctionを作ってみる（題材：オセロ、Function：オセロを置く、ひっくりかえす（途中））

わかったこと

まだ１つのファンクションしか作ってないけど、一連のテストコード書いて、テスト実行して、実装して、ということをやってみたので、所感を書こうと思う。

結論として、実際に試してよかったと思う。書籍やサイトに情報はあるけど、実際いやってみたほうがどんなものかを理解するのが早いと思う。

環境準備系はググれば何とかなる

• 1～３は、ネットでやり方がたくさんでてるので、簡単にできた。最近は、プログラミング始めるまでの障壁がだいぶ低いな～と実感。

言語と題材選定間違えたかも

• 今回の趣旨はTDDをやってみるだったのだが、JavaScriptをやったことがなかったので、言語の調査で時間がとられている気がする。
• 題材も、雰囲気でオセロにしてみたけど、今回の趣旨からすると、UIがない、もうちょっとシンプルなものでもよかった。

もう少し考えればよかったところはあったけど、今回の目的は達成したし、個人でやっていることだからこれでよしとする。

テストコードを先に考えるということ

• 先にテストコードを考えるという思考になかなか慣れない。テストコードというか、実際は「そのファンクションに何の値を入れたら、どういう結果が返ってくるはず？」ということを先に考えるということなのだけど。本来なら決められないはずがないのだけど、考え込んでしまう。ファンクションの役割や設計がふわっとしているということなのだろうと思う。
• 重複排除と新規機能追加を同時にやりたくなる。本当ならば、重複排除⇒既存のテストコード実行（OK）⇒新規機能のテストコード書く⇒テストコード実行（NG）⇒新規機能の実装⇒テストコードの実行（OK）というようにテストコードが先に書かれるプロセスなのだろうと思うが、ソースをいじっていると、一気に直したくなる。
• 実装書く前に考え込む時間が少ない気がする。キチンとテストコードを書いてからこのテストコードが通る実装をしようと思えば、実装するコードは単純になる。この処理は外だししたほうが良いかも、とか、重複してるからまとめないと、とか、コードを書く前に考え込むことが少なくなる。この辺はリファクタリングでやればよい、という整理ができる。
• 早く動くものを作ろう、ということなのだなと思った。作っている側も、精神衛生上、小さい達成感が得られるので、気分が安定する。
• テストコード書く⇒テスト実行する⇒実装する⇒テスト実行するを早く回したくなる。リズムがうまれる。

テストコード自体の品質

• テストコードのメンテ（特にテストデータの部分）は気を付けないと、煩雑になりそう。ただ、それもテスト対象の作りによるかもしれない。
• これは、実務ではそんなことはないと思うが、開発する人がテストコードを書くときに、「テストをする」という意識で考えるのは難しいかもしれないと思った。プログラミングの一環として、仕様としてこうなるはずということは書ける。ただ、さらに踏み込んで、プログラム構造を意識したテストとか、ブラックボックステストの中でも境界値のテストみたいなところは、ちゃんとそういうテストが必要だと思ってないと、意識から抜けてしまうかもしれない。まあ、そういうテストを開発のフェーズでやるかどうかということも、ポイントではあるけど。

次やること

• ローカル環境にCI環境を作って、Jasmineを自動実行してみる
• UIテストの自動実行をしてみる

CI環境の構築は絶対やります。UIテストはちょっと時間かかりそうだけど、やりたいな。