調べ物した結果

現役SEが仕事と直接関係ないことを調べた結果とか感想とか

抽象化するとはいったんなんということか。思考整理


abstract（抽象）なクラスの説明がうまくできなかったんだ。

目次

辞書

とりあえず辞書。
www.weblio.jp

抽象的とは、共通した要素を抜き出して一般化していること、または具体性に欠けていて実態が明確ではないことである。

おおよそあってる気がする。だけどプログラム、設計関連ではここに別のニュアンスがもたらされている気がする。
抽象の概念そのものよりプログラムの本質の話か。

なんでプログラムがいるんだ。

楽をしたいから。とかまーいろいろあるけど「問題を解決するため」にあるとおもう。
抽象的には「問題を解決するため」具体的には業務によるね。

プログラムは「問題解決のため」が前提なので、
（問題解決のための）抽象化。ということになる。
ということで問題を解決しようとしたら「抽象化」が必要になる場面があって、そのために抽象的なクラスがあるんだね。

抽象表現がもたらすメリットとはなんぞや。

先ほどの引用の通り「具体性に欠けていて実態が明確ではない」のが抽象だ。
字面だけおうとマイナス面が漂うが、具体的でないことによって「柔軟性」が確保できる。
抽象表現によって解決できる課題は「プログラム」の「柔軟性」

個別、固有の完全実体にしてしまうと融通が利かない。
多種多様の業務一つ一つ。それぞれをすべてプログラムで記述するのは非効率で現実的ではない。
また、業務は移ろうのでせっかくつくっても変更が発生する。
ということである程度の柔軟性を確保する必要がある。あった。

ということで。

抽象クラスとは：プログラムの柔軟性を保つためにあえて具体性を排除して実態を持たない。
となる。
abstractは実体みたいなのがあるので怪しいんだけれど。
実際のところがっつり保守なんかをしないとただただ具体的ではない不安定なものにしかみえないかもしれない。
たぶん恩恵なりメリットは実感する訓練が必要な気がする。

Java + Selenium + chrome をちょっと触ってみるまでがつまずき放題だった。


放題。好きなように躓けばいいんだ。

むかーしむかしにpythonで遊んで以来さわってなかったselenium。
windows10 + STS(Java)でSelenium動かしてみたかったんだけどなかなかたどりつけなかった。
qiita.com
を参考にさせてもらっていたんだけど。
・そもそも記事はたぶんMac環境
・3年以上前の記事でいまとだいぶ勝手が違うきがする。
というようなことが要因でうまくいかず。
とはいえ記事のおかげで300倍ぐらい解決が早かった気がするので感謝の意を示しつつ、
30分ぐらいかなーってのが２時間かからないぐらいでたどり着けたので記録としてのこす。

目次

libないんじゃが・・・

とりあえずseleniumが必要。ということでダウンロードサイトで拾ってくる。
Downloads | Selenium
が、想定よりもライブラリが少なかった。なんでや。
ぶっ飛ばして手順どおりやったけどコードが全然ライブラリ足りなくてビルドができなかった。

"Stable"って安定版ってことだとおもったのに。こんなかんじ。
gyazo.com
そのあとMavenで引っ張り出したのがこんな感じ。
gyazo.com
なのでだいぶ足りない様子。
記事内サンプルコードは@TestもついてるのでJUnitもいるっぽいが。現状はMavenでも搭載されてないんじゃないかな。

Mavenがんばれ。

ということで公式からダウンロードしてきてもライブラリが足りてないっぽいので（読めてないだけ説が濃厚なんですが）Mavenプロジェクトに切り替えてMavenで落とすことにした。
こちらを参考に。とくに困ることはなく。
qiita.com
Maven Repositoly か公式からDependencyは取ってくればいいと思うけど。

公式からとってくるときはバージョンちうい。
こんな感じでバージョンのところが不定になっている。

<dependency>
  <groupId>org.seleniumhq.selenium</groupId>
  <artifactId>selenium-java</artifactId>
  <version>4.X</version>
</dependency>
引用元：[https://www.selenium.dev/documentation/getting_started/installing_selenium_libraries/:title]

pom.xmlつくったことないぜ。な人はdependencyそのままはっつけてエラーになって混乱すると思う（混乱した）。
dependenciesで囲むことも忘れないようにちうい。こんな感じになるＹＯ

<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 https://maven.apache.org/xsd/maven-4.0.0.xsd">
  <modelVersion>4.0.0</modelVersion>
  <groupId>selenium.practice</groupId>
  <artifactId>seleniumPractice</artifactId>
  <version>0.0.1-SNAPSHOT</version>
  <dependencies>
	<!-- https://mvnrepository.com/artifact/org.seleniumhq.selenium/selenium-java -->
	<dependency>
	    <groupId>org.seleniumhq.selenium</groupId>
	    <artifactId>selenium-java</artifactId>
	    <version>3.141.59</version>
	</dependency>
  </dependencies>
</project>

ということで無事ライブラリゲットした。

サンプル実装コード

公式の実装コードはこちら。

import org.openqa.selenium.By;
import org.openqa.selenium.Keys;
import org.openqa.selenium.WebDriver;
import org.openqa.selenium.WebElement;
import org.openqa.selenium.firefox.FirefoxDriver;
import org.openqa.selenium.support.ui.WebDriverWait;
import static org.openqa.selenium.support.ui.ExpectedConditions.presenceOfElementLocated;
import java.time.Duration;

public class HelloSelenium {

    public static void main(String[] args) {
        WebDriver driver = new FirefoxDriver();
        WebDriverWait wait = new WebDriverWait(driver, Duration.ofSeconds(10));
        try {
            driver.get("https://google.com/ncr");
            driver.findElement(By.name("q")).sendKeys("cheese" + Keys.ENTER);
            WebElement firstResult = wait.until(presenceOfElementLocated(By.cssSelector("h3")));
            System.out.println(firstResult.getAttribute("textContent"));
        } finally {
            driver.quit();
        }
    }
}
引用元：
[https://www.selenium.dev/documentation/]

java15でさわっていたけど、WebDriverWaitの第2引数がDuration対応してなくてlongっぽいのでそこはなおした。
コードはfirefoxのドライバなので、chromeように直すと以下のようになる。

        WebDriver driver = new ChromeDriver();
        WebDriverWait wait = new WebDriverWait(driver, 10L);
        try {
            driver.get("https://google.com/ncr");
            driver.findElement(By.name("q")).sendKeys("cheese" + Keys.ENTER);
            WebElement firstResult = wait.until(presenceOfElementLocated(By.cssSelector("h3")));
            System.out.println(firstResult.getAttribute("textContent"));
        } finally {
            driver.quit();
        }

これだけだとchromedriverのパスがわからなくてエラーになる。
仕組みはいまいち理解していないがChromeDriverのインスタンスを生成する前にパスを指定する必要がある。
System.setProperty("webdriver.chrome.driver", "driver/chromedriver92.exe");
こんな感じで。上だと実行環境にdriverフォルダほってそこに置いてるイメージになる。
gyazo.com
これね。ドライバが２つあるのはChromeのバージョンとあってなくて別のバージョン用のをもってきたから。１つでOK。

全部足すとこんな感じに。

import org.openqa.selenium.By;
import org.openqa.selenium.Keys;
import org.openqa.selenium.WebDriver;
import org.openqa.selenium.WebElement;
import org.openqa.selenium.chrome.ChromeDriver;
import org.openqa.selenium.support.ui.WebDriverWait;
import static org.openqa.selenium.support.ui.ExpectedConditions.presenceOfElementLocated;

public class HelloSelenium {

    public static void main(String[] args) {
    	System.setProperty("webdriver.chrome.driver", "driver/chromedriver92.exe");
        WebDriver driver = new ChromeDriver();
        WebDriverWait wait = new WebDriverWait(driver, 10L);
        try {
            driver.get("https://google.com/ncr");
            driver.findElement(By.name("q")).sendKeys("cheese" + Keys.ENTER);
            WebElement firstResult = wait.until(presenceOfElementLocated(By.cssSelector("h3")));
            System.out.println(firstResult.getAttribute("textContent"));
        } finally {
            driver.quit();
        }
    }
}

これで実行したらとりあえず動いたっぽい。hellow selen. cheese!

おわり。

おわり。楽勝だと思ったら楽勝じゃなかった。ぱわぁが足りない。
先人の知恵は偉大だなぁ。非常に助かる。ありがたや。

DX-Ready事業所ってなんやねん。というあれで


DXがよくわからない。よくわからないけど飛び交ってるしいろいろつらい。
なんかふわっとしていて怪しい雰囲気も感じるんだけど怪しいと断ずることもできないレベルでよく見えてないからちょっとだけ調べた。

目次

DX認定制度。とかあるらしいぞ。

引用元
www.ipa.go.jp


びゃーん。しらなかったぜ。

gyazo.com

引用元：https://www.ipa.go.jp/files/000086670.pdf

DX-Excellent
DX-Emerging
DX-Ready　←ココを認定するよ、
DX-Ready 以前

Readyってことで「準備できてんぜ」って話にはなるかな。
Emergingは「振興、独立」とかなのでとりあえずやり始めたぜ。ぐらいだろうか。
ExcellentはExcellentなんだろう。うん。

しれーっと安全確保支援士とかぶち込んでるとこ見るとIPAらしいなぁ。という感じもしなくもない。

でもととか。

情報促進法（正式名称：「情報処理の促進に関する法律」） にもとづくものらしい。
推し進めたい感はわかったけど詳しいことはちゃんと中見ないとだめだね。

どうやって認定するんや。

デジタルガバナンス・コードなるもののうち、基本的事項が対応するらしい。
デジタルガバナンスコードは以下。
www.meti.go.jp

そのまま文章をとってくると

① IT システムとビジネスを一体的に捉え、新たな価値創造に向けた
戦略を描いていくこと
② ビジネスの持続性確保のため、IT システムについて技術的負債と
なることを防ぎ、計画的なパフォーマンス向上を図っていくこと
③ 必要な変革を行うため、IT 部門、DX 部門、事業部門、経営企画
部門など組織横断的に取り組むこと
が重要であり、企業全体の組織構造や文化の改革、中長期的な投資を行
う観点から、経営者の関与が不可欠なものである。

積極的に、ビジョンをもってIT活用していけ。いくのだ。
いかんと遅れるで（ITを使っている場合と比べて）というような解釈でいいとはおもうんだ。

認定に対応する基本的事項には柱となる考え方として以下のようにある。

企業は、ビジネスと IT システムを一体的に捉え、デジタル技術による
社会及び競争環境の変化が自社にもたらす影響（リスク・機会）を踏ま
えた、経営ビジョンの策定及び経営ビジョンの実現に向けたビジネス
モデルの設計を行い、価値創造ストーリーとして、ステークホルダーに
示していくべきである。

なんだろうな。もともとITで効率化やー。みたいな感じで経費削減のお供みたいな感覚が
あったんじゃなかろうか。ではなくて、そもそもビジネスと切り離せない状態にきている。ので、
がんばれ。そーゆー感じだろうか。なんでどう頑張るか。を明確にできれば認定いけるのかね。

やくにたつんかいな・・・

こればっかりはちょっと。お客様次第な感じもないでもない。
DX-Readyといってどれぐらい伝わるんだろうか。
まーでも少なくとも「ITがビジネスと切り離せない状態にきている」みたいなところはわかってるし、
そのつもりでやれる準備はできますよ。という証明にはなるんだろうから（経産省のお墨付きという形にはなるが）
逆に言うとやって見て認定おりないってことは考えが甘かったり認識が連れてるって話だろうからちょっと頑張って
取得めざしてみるのもいいかもしれない。費用に対する効果が図れなくて進言しづらいのだけれども。

引用まとめ

DX認定制度 Web申請受付開始のご案内：IPA 独立行政法人 情報処理推進機構
Society5.0時代のデジタル・ガバナンス検討会 （METI/経済産業省）

Java（Spring）のプロジェクトにぶちこまれて数ヵ月たったから振り替える。

ポエミオス。別プロジェクトから派兵されて数ヵ月経過した。
主にメンバーの教育について思うところ。知見。単なる感想がたまってきたので吐き出しておく。
あとあんまりJavaもSpringも関係ない。

目次

lombokこのやろう。

こういったものがあるのは知っていたけど、いまのプロジェクトではじめて出会いましたよlombok。
詳しい説明は他にまかせますが、GettetSetterなどだれが組んでもだいたい同じになるお作法的な部分を省略してくれる
便利なアノテーションを提供してくれます。

@Getter
private String id;

みたいにしとけば勝手に public String getId(); メソッドが生えてくれます。

お陰で？スコープやらカプセル化がどうとか。そういったことをから思考を放棄して、
情報量の少ないしゃべらないクラスをごりごりと生産してくれるので嫌いになりかけてました。
悪いのはlombokではなさそうなことに気づいてからは良好な関係を気づけてます。
いいとか悪いとかではないんだけど。そもそもわからないところを「呪文」として処理する文化があるので、
アノテーションはちょっとその「呪文」を信仰している層と合体するとえぐいんだ。
DelegateとかSuperBuilderとか場面はあるけどほしいときにいるとすごく頼りになるんだけどね。lombok。
ちょっと封印したい気持ちになったよ。
どこからそうなったのか、あるいは１側面ではそうなのかもしれないけど、
「オブジェクト指向⇒カプセル化⇒privateにしてgetterSetter 」みたいなのがそこらを歩き回っている。
この思想とlombokは合体しやすい。大変危険。とりあえず新人は救えたと思うけどほかの方は。

Mybatis is God

神。レジェンド。こっちも詳しい説明は他に譲る。
RDBがそもそも適切に設計はされていない。を前提によく練られていて素晴らしいと思う。
いわゆるO/Rマッパーのような使い方もできるだろうけど、もうちょっと柔軟性を持ち込めてなおかつ余計なものを書かなくてすむので、
ある意味前述のlombokとにたようなもんかな。
そもそもDBちゃんと設計し直せよ・・・見たいな不自由と戦うには必要かもしれない。
そもそもちゃんと直してほしい。リレーショナルなDBが関係性を明示できてないってどんなやねん。
ところが一度作られたDBはいろんな。本当にいろんな（Excel管理されてるとか。）理由で開発中であっても変更が難しく、
違うところがダメージを吸収してる。歴史的にそうやってインフラ層、DBの設計の外側で頑張り過ぎてるせいで知見がたまらず、まともにDBを設計できる人が育たなかったんじゃないかと推測しているが。
えぐいRDBはそこらじゅうにある。今なら思考を放棄してKeyValueストアにでも放り込んだ方がましと思えるような設計も多々ある。結局同じ闇を生むので放棄されたらこまるのだけれど。
MybatisとDB設計を主戦場にしたいぐらい気に入ってる。所属の会社的にはなかなかここをいじれる機会がないので、これはプライベートでちまちま積むしかないのが惜しいところだ。

コピペとのたたかい

２Outぐらいから考えたいが。一般的には３Outからだろうか。３度同じコードを書くのではない。
おい。Ctrl＋C、Vしろって意味じゃないんだちくしょう。
これとひたすらレビューで戦ってた基本的に敗北してた。勝てない。
コピペも呪文信仰と相性がいいらしい。ある意味オブジェクト志向らしいというか、再利用してるんだけど「違う。そうじゃない。」

思想レベルでのインプットはしんどい

思想とはいかに。仕事に思想を持ち込んではいけないのかもしれないが。
コードは設計書に書いてる風味でクラスはデータの入れ物で、あとはなんか適当な場所（書きたくなったタイミングでその当時さわっているクラスファイルに）メソッド開く。見たいなコーディングスタイルが身に付いてる人に別のものをぶちこむのは非常に大変だった。いまもぶちこめてない。あんまり思想に染まってない新人だけ引き込めたけど。

「納期　＞　品質」
これは仕事でやってるわけなのでその通りだとも思うんだけど。
品質を測る方法が曖昧なのをいいことにとりあえず納品するケースは多々あると思う。これは業界全体的によくないことだと
おもっている。最低限の品質が人によっててしかも測定しないってのはずいぶんだとおもう。
主に保守性に関する品質はガンガン犠牲になる。品質を犠牲に時間を生成することを覚えたプロジェクトは次第に「バグの密度」とかどうとか。そもそも納品してはいけないレベル、ものの品質を犠牲にしはじめる。
口を開けば時間がない。やむを得ない。ねぇのは「時間」じゃなくて「（私を含む）技術」だ。
といった具合でプログラムや設計の範疇から「自責他責」なんかの話までしなくちゃいけなさそうで、
なかなかである。いってることはわかるし全然理解できるけどね。
コーチするのはやってみたいけど、corachableなところまでもっていくのはなかなか大変ですね。ちょっと一人でやってると辛くなるからさすがに仲間がほしいなと思う。

レビューでなんとかするんなら覚悟しとけよ

そういったもの「品質」全般をレビューで確保するのは無理筋（範囲と責任が広すぎるぜ）
Lombokについても、コピペについても。基本的にはコードレビューで私が相手をすることになっていた。
相手にならん。私の全面敗北。つまり指示通りパンチしてた勢とやりあうにはレビューのタイミングでは遅すぎる。
先のカプセル化もそうだけどそもそも設計の知識なり経験も乏しかったりするんだ。そうなるともっと基本的な教育も必要になる。
OJTとかいうのりでコードレビューなんかで教育しだすとなかなかコミットされないしひたすら指摘が返却される地獄が生まれた。地獄になってたので基準を緩めたらお察しである。レビューで教育してはいけない。戒め。
覚悟とは地獄が生まれる覚悟でそれでも「品質」を維持する覚悟。上記のとおり「納期」が優先なので地獄が生まれただけになってしまった。
そもそも一定基準までレベルをあげる必要がある。教育の時間は別途とろう。IPAのプロマネ問題でもだいたいそうやって解決してる。そんな時間も予算も権限も俺にはないんだ。
Springの話は前半に時間とってやったのはよかった。ただ層や責任の分離はちょこっとやっただけでは理解できないしどうしようもないなぁ。

呪文使いのトラブルシュート

たぶんドリルかなんかだと思われてるのでだいたいに問題解決にぶちこまれる（割りと火力がないので弱点見つけてつるはしでえっちらおっちらやるタイプなんだが・・・あとは壁から逃げる。）
不明点を不明のまま「呪文」として処理する呪文使いは問題の切り分けも呪文であるがゆえに苦手としている場合も多い。
よって解決困難な問題がでてくるのだが報告も曖昧で（まぁ、正確に問題がとらえられるならそもそも相談になんか来ないんだろうけど）きつい。呪文使いのトラブルシュートはまずはこの呪文使いがその呪文をどうやって理解してたり解釈してるのかを想像したりする必要がある。こちらの言語も一部伝わらないので日本語なのに日本語が使えなかったりする（残念なことにこちらのいっていることも一部呪文なんだ。あちらから見れば私も十分に呪文使いである）
もちろん謎の呪文をつかって解決したことになっているので応用は聞かず。ほげぇってなる。なるけど頑張るよ。その人が悪いわけではないしね。

おわり

なんか辛い感じなったけど多人数プロジェクトは楽しいと思うし基本は楽しく仕事させてもらってます。
無力感もあるが学びもある。やってきてよかったなーと思うこともあればもっとやっとけばよかったなーなど。
設計スキル、保守の経験は貴重。もうちょいまともに人と一緒に成長する手段は確立しないときついなぁ。
Springすごく楽。手が足りねぇ。

参考にしている本とか

1. 現場で役立つシステム設計の原則 〜変更を楽で安全にするオブジェクト指向の実践技法 増田 亨 https://www.amazon.co.jp/dp/B073GSDBGT/ref=cm_sw_r_tw_dp_W1WHSR4TZNKRW0FRYNH9
2. この1冊ですべてわかる 新版 コーチングの基本 コーチ・エィ　 https://www.amazon.co.jp/dp/4534056591/ref=cm_sw_r_tw_dp_BNR5PMY03HSPSQAKTFRE
3. 松岡さんの質問箱（ドメイン駆動回りとか。あれこれ回答してる。） https://peing.net/ja/little_hands

「伝票テーブル」ってあるべきなのか。という話。

ちょっとお仕事で「伝票」を取り扱うことになったのだけれど。どうにもテーブル構造が決まらず。（正確にはきまってるけど）
もしやということでちょっとだけ書いてみる。

目次

ひとまず前提

まー大体。世の中依頼と受注が発生する業務には「伝票」がついて回ってくる。
依頼時の情報と受注情報。あとは受入なりするから検収なり受入なりの伝票がつく。
依頼者「これこれこういったものをお願いしますね。」
受注者「ハイ了解。これででゲスね」
依頼者「うけとったで。おけまる！完璧！」
というわけで、その取り交わしの記録として伝票が発行されて、こと細かな部分は「明細」という単位でくっついていく。

gyazo.com

こんなもんよ。

これ自体は大きく間違っていないし側面的にはあっている気がする。
IPAの過去問でもこの類のもんはたびたび出てくるし、大体以下の様子。
gyazo.com

引用元：IPA 独立行政法人 情報処理推進機構：問題冊子・配点割合・解答例・採点講評（2020、令和2年10月）
https://www.jitec.ipa.go.jp/1_04hanni_sukiru/mondai_kaitou_2020r02_oct/2020r02o_db_pm1_qs.pdf


はて、しかしこれ本当にいいのか？というのが今回の前提。
「伝票」は契約における一時的な記録のスナップショットでしかなく、永続化に値しないのでは？
ということ。

なにが問題なの

いや。いまのままでも特に問題はないんだけど。柔軟性が失われているような気がしている。
それどころか「記録」としていつでも取り出せる状態ではあるべきなんだけど。ただ伝票を取り扱うサービスとしては
コアではない。そんな感じ。あくまでもスナップショット。データから生成できればよい。
間違ってもそのままの形でつかっちゃいけないんじゃないの？ということ。
やつらはあくまで「発注依頼時」であったり「受注時」の状態。事実を記録するのはいいんだけど。
情報が増えたり、減ったり。形式が変わったことに対して非常に脆い。

じゃぁどうもつべきだろう。

やはりここは「だれが」「なにを」といった「記録」のみに着目していくべきだとおもう。
具体的にはこんなノリで。
gyazo.com

依頼に紐づくスター型というか。そもそもそこに対する記録を種別に応じて記録すべきだろうと。
結局各種「伝票」はここから用意に生成できるだろうし、よくてviewとして持つぐらいだろう。わざわざ実体を持つ必要はないはず。
この構成の強みは
・情報が増えた場合にテーブルを追加するだけで対応ができそうなところ。（できそう。）
・ＲＤＢじゃなくてもいいかもしれない。key-value型とも相性もそこまで悪くないように思う。
・ユーザーの目に触れる「伝票」の部分を「view」に落とし込むので見ための影響を受けにくい。
やったことはないのだけれども。だいたい構成はきまってるし紙もとに起こされたデータベースを眺めるぐらいしかないのだけれど。
過去のある点をとるのは若干めんどうではある。要件に応じて永続化用のテーブルがあるのはよいと思う。

なんでこんなことになってるのだろうか

おそらく元々紙だったものをそのままデータ化する形で設計をしてしまったから。
長いこと電子カルテと戦っていたけど、あっちも診療録という元々もは紙の情報をそのままデータベースに押し込んでいる。
結果的に非常に取り扱いの面倒なデータベースができあがってる。たぶん記録としての紙をそのままデータベースに落とし込むのは
多くの場合誤りだと思われる。
データベースは記録を残すものではあるが、例えば合計金額のような計算で出力可能な項目を保持するのは基本的によくない設計。
であれば「伝票」なんてものはまさしくその集合のようなもので、基本的にはデータベースに保持しないほうがいい。
いつしか紙ではないデータベースにお目にかかれるといいなぁ。その時は「紙をベースにしなきゃだめだ！！！」とか言ってるような気がするけど。


いじょう。

自己解決能力が高いってどういうことだろう

僕は自己解決能力が高いらしい。そのように上長に言われた。
特出してどう高いと判断してるのかわからないし、そもそもよくわからない能力。
高いとか低いだから数値化できるんだろうか。できてる気がしないけど。数値化できたら楽しそう。
おそらく課題に当たった時の対応能力を指すんだろうけど。はたして。

目次

まずはぐぐって定義する。

TOPにできてたのはこちら。
lifecoordinate.com

一部を抜粋すると。

自己解決能力が高い人の場合は、マニュアルがなかったり、上司が教える余裕がない時は、自分で仮説を考え調べ、まずは行動に出して挑戦してみます。そして、上手くいかない場合は、再度調べて解決に近づこうとします。

引用元：https://lifecoordinate.com/skill/1832

いろいろワードがでてきましたが。
自己解決ということは
・自分で仮説を考える。
・自分で調べる。
・行動する
・上記を繰り返して解決に近づける。
ということかとおもいます。の能力なので上記の能力ってことになりますね。

doi.org
別の視点から上記の論文では以下のしるされており、こちらには「問題の発見」「定式化」というようなワードもでてきます。

仕事上 起 こ る 問 題や 問題事態 を
想定 し，問題 を発見 し，問 題 が起 こ っ た背景 を明確 に
し，問題 を定式化 し，その 解決案 を複数個考 え出す と
い っ た，い わ ゆ る問題解 決能 力の育成の 必要性 か ら，
こ れ らの 能力の 育成 をめ ざ した教材 （ワーク ブ ッ ク）
を作成 し

引用元：https://doi.org/10.20694/jjsei.20.2_15

ということは「問題そのものを発見して明確にする」ということも「自己解決」のプロセスの一つともいえそうです。
だいぶ輪郭が見えてきました。

能力とはいかに。

当たり前と言えば当たり前ですが。自分で調べて解決するまで行動する。的なことを自己解決としました。
ではその能力（高いとか低いといえるもの）は何なのか。

せっかくなので前述の論文を読んでみるとよさげなシートがありました。

gyazo.com

引用元:https://doi.org/10.20694/jjsei.20.2_15

これでなんとか数値化できそうです。自己評価にはなってしまいますが。

おわり。

おおむね自己解決の能力。が何を指してるのが大体わかった気がします。だいたい。
おそらく私の場合上記のシートの
①「感度 の よ さ」 が特出しています。なにせ不満だらけですからね。
②「識別力」 は長いこと運用保守で不具合の対応ばかりしていたので、鍛えられているような気がします。
④「やる気・やる気の持続力」はない。ないけどお仕事だしね。やりますよ。という感じはある。
上のようなことが重なって上長は「君は問題解決能力があるね」と判断したんだろうと思います。
視野、ひらめきは日ごろの学習で積む必要があり、まだまだ伸ばせる余地がありそうです。識別力は経験値が必要かなーといった感じ。

明言はされていませんが、WEBサイトの方も、論文も
「実際に解決できたかどうか」はそこまで重要ではないように見えますね。
解決しようとする姿勢、とかそんな感じの力っぽいですね。できるかどうかはその後らしい。

縄跳び３重飛びできるようになったから記録にのこす


掲題の通り。ひとまず室内で連続3回達成したので記録に残す。

目次

きっかけ

2020/09頃。日頃の運動不足解消を目的に縄跳びに取り組み始める。
とりあえず2重飛びはできたが、3重飛びはできず。そういえばギネス的にはどんなんや？
としらべて「7重飛び」とか言っている様子なので3重ぐらいならなんとかなるんじゃないかと思って始めた。
30を超えた身体はそこらじゅうが柔軟性を失っており。とくにふくらはぎ、足首のあたりが致命的だった。
10代のころはまったく動作の意図すら意味が分からないといったようすのアキレス腱のばし（両足を前後に開いて後ろ脚の筋を伸ばす）がすごく効く。
これ効果あるじゃん。やべーじゃん。といった状況であった。数回飛ぶと息切れするし、10分も連続で運動し続けることはできない身体になっていた。

練習方法

どこぞのサイトをあさって「低速2重飛び」「高速2重飛び」をひたすら繰り返した。上記の通り、柔軟性が終わっていたので
一回トライして、足首伸ばしてもう一回トライして伸ばす。みたいにつど柔軟も取り組んだ。
いけそうかなーってときにはついでに3重飛びもトライしてみて３か月ほどたってようやく飛べるようになった。

今の状態

最初にも書いたが「3重飛び」連続3回。がいまのマックス記録。2重飛びは60回ぐらいなら連続で行ける。
息切れもほとんどしなくなった。

おすすめの縄とか

ダイソー100円縄がサイコーによい。
rocketnews24.com
ちょっと重いので最初はもっとよくあるふっつーの縄が良い。ただしそっちは大人の力で振り回すと余裕でキャップが抜けるので、
ガムテなどで補強したほうが良い。よくあーる、ふっつーの縄だとなんかねじれたり手元でたわんでうまく回せないなーとか思い出したら交換する。みたいなタイミングでよいと思う。

次

4重飛び挑戦する。おそらく低速3重飛びと高速3重飛びを繰り返す形になると思う。ということでしばらくは3重飛びの精度を上げるところからになる。