284.基準を持つ
初回：2022/11/9
Kyonさんの『持論を持つこと』に触発されて、テニス理論について、考察したいと思います。
P子「仕事に関係があるの？」※1
以前にも『030.テニスと将棋とシステム開発』で説明したように、これらは『同一の考え方』が可能です。というか、人間の行動というものは、どのような事であっても、基本的には同じ考え方が適用できると思っています。
1.持論を持つ → 基準を持つ
まず、少し言い換えたいと思います。持論では話を進めにくいので、基準に言い換えます。
テニスでグリップを決めたとします。このグリップの持ち方を『基準』とします。
P子「グリップの持ち方を『持論』とは言いにくいわよね」
なぜ基準を決めるのかというと、試合(実践)で思い通りに行かない場合やしっくりこない場合、その『基準』が自分には合っていなかったという事です。そこで『基準』を変更します。
この時、基準がない状態で試合(実践)に臨んだとして、違和感を覚えた場合に、何が悪かったのか、どう改善すればよいのかが判りません。また、それで上手くいった場合でも上手くいった理由を知らないままでは、それ以上の向上は見込めませんし、何か調子がおかしくなった場合に立て直しが出来なくなります。
そういう意味で『基準を持つ』事は非常に重要になります。
P子「そんなに簡単に『基準』を変更してもいいの？」
そのあたりは非常に難しい問題です。
試合でうまくいかなかった場合、単なる経験(練習)不足なのか、本当にグリップが合わないのか、グリップに合った打ち方が出来ていないのか、はたまた、ラケットが合っていないのか？
グリップを変えるべきか、打ち方を変えるべきか、ラケットを変えるべきか...それとも練習量を増やすべきか...
これを、システム開発に置き換えて考えてみます。
顧客の要求に対して、上手く対応できなかった場合、単なるメンバーの経験不足なのか、使用した言語(javaやPython)が合わなかったのか、それらの言語に合った開発手法(ウォーターフォールやアジャイルなど)が合わなかったのか、はたまた、採用したフレームワーク(SpringやStruts、DjangoやFlaskなど)が合わなかったのか。
そんな場合に、簡単に使用言語を変えるわけにはいかないでしょう。フレームワークの学習にも結構時間がかかりますから、変更するとなっても大事です。多くのケースで、ずるずると何も変えられないまま、時間ばかり過ぎていくのでしょう。
2.基準は簡単に変えられない
『基準』を簡単に変更できない理由として、もう一つあります。
P子「一つだけ？」
まあ、いくつもあるんですが、実は皆さんが気付いていない事があります。
例えば、テニスのグリップを変えるとします。
テニスのグリップには、コンチネンタルグリップ(ラケットを立てて上から握る、俗にいう包丁握り)とウエスタングリップ(ラケットを地面に置いて、真上から持つ)があります。それらの中間的な位置づけとして、イースタングリップやセミウエスタングリップというのがあります。よく言われる『握りが薄い』順に、コンチネンタル→イースタン→セミウエスタン→ウエスタンで『握りが厚い』となります。
ここで問題となるのが、グリップだけ変えても全然上手くなりません。逆に言うと、試合で上手くいかなかった場合にグリップを変えて練習してみると、前より上手くいかないから元に戻す...というケースがあるかもしれませんが、それはグリップだけ変えたことが原因です。
≪参考1≫
https://tennis.j-treasure.com/gurippu/
テニスのグリップが厚い・薄いの違いと選び方 ストローク編
≪参考2≫
https://lond-jnl.me/2020/07/contact-point/
グリップや打点の位置でこれだけ移動距離、時間の確保が変わるといった話 (テニス)
グリップを変えると、打ち方(スピン系かフラット系か)とか打点が変わる(厚い握りの場合は少し前方、薄い場合は体の横)とか、ボールと体との距離が変わるとか、色々と付随するパラメータも合わせて変更する必要があるという事です。
つまり、グリップを変えようとする場合、それ以外の多くの事を変える必要が出てきますが、同時にそれだけの事を変えるとなると相当な覚悟が必要になってきます。ジュニアなどフォームがなにも固まっていない場合ならともかく、社会人になって週末テニスプレイヤーとなり楽しくテニスしている人達にすれば、グリップの変更は相当なリスクを伴います。
この時、本人はグリップを変えただけなのにフォームも打点もスタンスも気付かないうちに変わっています。そうしないと窮屈な打ち方になったりするからです。実はこれが大問題で『基準』をきちんと把握していないと、改善が出来ないのです。知らない間に基準が変わっているので問題点も正確に把握できなくなります。
上手く打てない原因がグリップを変えたことなのか、知らない間に変わっている他の要因に起因する事なのかすら判らなくなってしまいます。
これがシステム開発の場合では、言語を変えると、開発手法やフレームワークも同時に変更する必要もあり、当然開発メンバーへの教育も必要ですし、納品済みのシステムの保守などで旧環境の知識も継続して残しておく必要があります。
フレームワークは知らない間に変わるという事はありませんが、開発手法は言語やフレームワークに合わせて変更するというより、昔ながらの企業文化で、ずるずると継続することがあり得ます。そんな場合、上手くいかない時に、何が原因か判らなくなったりします。
3.変更する時は目的を明確にする
テニスの例でいうと、グリップを変えるのは目的ではなく手段です。というのはスピン系でバンバン攻めたいという人が、グリップを厚くする...というのがセオリーで、グリップを厚くしたから、スピン系でバンバン攻めるぞ！という人はいないでしょう。
つまり、スピン系でバンバン攻めたい人が、どうすればよいかという事を考えた結果、グリップを厚くするという理論にたどり着きます。グリップを厚くすると、ボールを手前で捉える必要があり、体からの距離を近くする必要があるというのも理論です。それらを意識して実践します。そのうえで、理論通りに出来ているのかを検証して修正していきます。
そこまでして初めて、上達のスパイラルに乗ることができます。
どれか一つでも『無意識に変更』していた場合、改善が後回しになったり手つかずになったりして上達に時間がかかったり成長が止まることもあります。
これをシステム開発に置き換えると、言語や開発手法の変更が目的ではなく、あくまで手段という事です。
ただ、顧客の要求毎に言語や手法の変更なんてできませんから、自然と自分たちの得意分野で勝負する事になります。そうすると、言語や開発手法を変更する目的は、顧客の要求ではなく、業界の流れというか世界の情勢というかそういうものに合わせる必要があり、変えざるを得ないというケースでしょう。
早く変えると流れを読み違えるリスクがありますし、変更が遅いと業界の流れに置いて行かれることになるので、なかなか判断が難しいと思います。
4.まとめ
ここまで述べたように、変更するのは非常に難しい事です。
しかし、行き詰って将来が見えなくなってきたり、変更することでしか解決できないような場合、覚悟を決めて変更すべきです。
P子「追い込まれてから着手するのは、すでに手遅れのような気がするけど...」
基準を変更する場合に重要となるのは、下記の 3点です。
1.変更すべき目的を明確にしておく
2.変更に伴い、他にも多くの事を変更する必要があることを意識する。
3.変更したそれぞれの項目についての基準を明確にしておく
一つの事を変更しようとした場合、実に多くの事の変更を一気に行う必要があります。それらの変更を無意識に行うのではなく、基準を設けて、その基準を少しづつ変更する事で、改善していくという取り組みが必要です。
一つだけを変更して終わり...とか、他の項目を無意識に変更するとかをしていると、改善のスパイラルに乗ることができないので、折角の変更が非効率になったり無駄になったり、変更したこと自体が間違いだったと勘違いしたりすることになりますので、ご注意ください。
ほな、さいなら
======= <<注釈>>=======
※1 P子「仕事に関係があるの？」
P子とは、私があこがれているツンデレPythonの仮想女性の心の声です。