エンターテイメント!!

遊戯王好きのJavaエンジニアのブログ。バーニングソウルを会得する特訓中。

インポスター症候群の調査とまとめ

きっかけ

自分がインポスター症候群の可能性が高そうだと気づいたので、いろいろ調べたようと思った。

インポスター症候群とは

wiki引用

インポスター症候群(インポスターしょうこうぐん、英: Impostor syndrome、インポスター・シンドローム)は、自分の達成を内面的に肯定できず、自分は詐欺師であると感じる傾向であり、一般的には、社会的に成功した人たちの中に多く見られる。ペテン師症候群(ペテンししょうこうぐん)、もしくはインポスター体験(インポスターたいけん、impostor experience)、詐欺師症候群(さぎししょうこうぐん、fraud syndrome)とも呼ばれる。

個人的解釈

他のサイトの内容を見て、統合的に察すると、「自分の能力や実績を認められない傾向、成功ではなく失敗の方に関心が向かう」もののようだ。
詐欺師症候群って和名は、その症状がある人に追い打ちをかけるような感じがするのだが、直訳しただけなのかな?
この和名を考えた人は、センス無いと思いました。

日本人が陥りやすいのかと思ったが、研究の発症はアメリカらしい。
日本人だと、チーム戦として仕事を考えた際に、他人の成果でも自分のせいかとして考える思考があるから、研究対象にならなかったのだと予想。
最近は、個人主義が強くなってきたら、この症状になる人が増えたのではないかと思われる。

インポスター症候群の特徴

  1. 自信がない
  2. 周りの評価の過大評価に恐れる(自信の能力を過小評価している)
  3. 自分の実力が無いと思っている
  4. 実績を受け入れられない

ヤバい。。。
ほとんど思い当たる節がある。。。
自信なんてない。逆に、どうやったら自信がつくのか教えて欲しいくらい。
過大評価というか、他人の評価を素直に受け入れられないんだよね。。。
褒められても、それは俺を煽てて操るつもりでは?って思ってしまう。
実績を受け入れられないのも、分かる。誰でもできるだろって思ってしまうのよね。。。

対策方法

サイトを横断的に見ての対策方法のサマリ

聡明な人々の近くにいる

知恵があるだけでなく、人格者であるってのがポイント。
知識不足を補うことに対して、劣等感が生まれにくいはず。

全知全能などいない

すごい開発者に見える人は、実はそんなにすごくないことはザラにある。
実績があるのは、実績を重ねられるような環境が作られているからかも知れない。

非の打ちどころのない人であろうと努力することで、生産性を低下させ、創造性も低下することもある。
完璧を求めすぎて完璧から遠ざかることはよくあるので、あまり気負いすぎてはいけない。

実績を記録に残す

日記をつけたりして、客観的に実績が見えるようにする。
そうすることで、実績を受け入れられないことをなくし、自信を取り戻す。

一流から学ぶ

一流の人のルーチンを真似る。
結果が出ているのだから、真似れば何らかの効果があるはず。

俺が考えた対策方法

何かを作るしかない。
ちゃんと目に見えるものが出来てしまえば、自然と自信に繋がり、他社の評価を受け入れられるのではないかと思う。
エンジニアであれば、特に、ね。
芸術家とか、クリエイターなら、モノを作るしか解消方法がないと思う。

何かを作りきるまで辛抱強くいられるかが、克服の難関な気がする。

関連リンク

インポスター症候群を克服する13の方法 | ライフハッカー[日本版]

インポスター症候群を克服する方法

エンジニアの混乱と成長について|Kamata Masahiro|note

Impostor Syndrome(詐欺師症候群)とQiitaについて - Qiita

もっと優れた開発者になりたければ、いますぐコーディングをやめなさい – WPJ

2020/10/05週 気づきと振り返り 初心に返る

業務こなしての問題・気づき

ドキュメント

ファイルサーバー管理はやめるべき

ファイルサーバーにファイルを直置きして編集するのはやめるべき。

やってて不便だと思ったことを列挙

  • 複数人同時編集した場合、ファイル破損のリスクが高い
    • Excelとかだと特に
    • VM環境からファイルサーバーアクセスしている場合は、更にその危険性が上がる
      • 意図しないファイルロックがかかったりして、作業が滞る
  • 読み取り専用とかにして意図しない編集を避けようとすると、今度は編集した内容を保存し忘れる。。。
    • 僕が何度かやらかして、酷く怒られましたわ。。。
  • 編集の競合で待ちが発生する。

打開方法

VCSでドキュメント管理する。
これ以上の方法は、今のところ、思いつかない。

ファイルサーバー管理で、リスクの順位は下記のとおりだと思ってる。 1. ファイル消失 2. ファイル破損 3. 更新忘れ 4. 競合による待ち

1, 2 は、VCS管理なら起きないはず。
起きたとしても、問題はローカル内に閉じているはずだから、影響範囲を小さくできると思う。
VCSリポジトリ格納しているサーバーが飛んだというのもあるけど、それはファイルサーバーでも同じ。
そもそも、そのケースは起きづらいと思う。
3, 4 リスクはあるが、回避可能なので、そこまで大きな問題はないと思う。
更新忘れは、VCSだとコミット忘れとかだと思うので、日常的に確認する作業に含まれるため、多発はしづらいと思う。

VCSとかで管理しない場合、やることが多かったり、注意することが増える気がするんだよね。
それで負荷かかって、いろいろ忘れて問題になると思う。
環境を変えることでなんとかできるものを、個人の責任になることが多いのが日本のIT現場の現状だと思う。
個人の責任にするのはいいけど、同時に環境を変えることで効率化できないか考えないとダメではなかろうかと思う。

雑記

最近、技術動向追えてないな。。。

あんまり関心のないシステム開発系のことばかり書いてしまう。。。

WEB-DBとかを購読してるから、たまには、雑誌の中から小ネタ探して調査してもいいかもね。
昔はそうしてた気がする。。。

なんか、最近、モヤモヤすることが続いてしまった。
精神的に弱っているせいか、尖ったことを書いてしまったこともあった気がする。
初心に返って、ちゃんとしたスキルを身につけるための行動をしていくように心がけよう。

2020/09/21週 気づきと振り返り デザインは偉大

業務こなしての問題・気づき

レビュー

指摘が多いからって罵倒していいわけじゃないよね?

今やっているドキュメントが、死ぬほど読みづらい上に、何か一つを修正すると連動して複数の箇所の修正が必要になる。
芋づる式に修正箇所が増えてて、レビュー時にも修正漏れとか大量に指摘されるのだが、だからって、「あほ」とか罵倒していいわけないと思うのだが、俺が違うのか?

海より広い俺の心も、ここらが我慢の限界だと思ったよ。。。
※これの元ネタ、知っている人とは仲良くなれそう。

こういうリーダーには成りたくないと思いましたわ。
それに、指摘事項の意味が分からないときに、すごく聴きに行きづらい。
すでに、俺はこの人と会話したいと思わない。
あと、あんたのレビューが通ったら、エンドユーザーのところに行くのだが、いいの?って感じた。
その指摘を設計書にコメントで書く神経が分からない。
消し忘れたりしたらどうするんだろうって思った。

尋常なないくらいハゲになりそうな予感がしました。

デザイン

最近、強く思うのだが、UI/UXって、むちゃくちゃ重要だなって思う。

今、改修している画面が、項目をてんこ盛りしている画面で、ドキュメントは分かりづらい・画面が汚くて操作しづらくて、辛い。
なんと言えば伝わるだろうか。。。
なんか、プログラマーが考えた画面って感じの画面。
伝わるかな?
もう、隙間なく入力項目が配置されている感じ。

良いUI/UXは、読みやすいドキュメントを生み、メンテしやすい画面になると感じる。
今までシステム開発してきたけど、デザイン会社に画面デザインを依頼していたところは、比較的、残業は少なかった気がする。
逆に、システム会社(SIerとか)が作るような画面は、項目をてんこ盛りにするので、かなり辛い。
何か条件が変わると、画面のどこかが変わるとか、項目が多すぎて変化が分からないってことがある。
視力悪化のためのストレス試験を受けている感じすらする。

長期的に見て、デザイン会社にちゃんと発注するほうが、コスト安くなる気がする。
デザイン会社にもよるのだろうが、いままでの経験から考えると、そういう結論になる。

この考え、ユーザー側に理解してもらえるのか、かなり疑問。
目先のコストを安く済ませようとして、長期的に損をするパターンがありそう。

東証の会見

見てたけど、記者のレベル低すぎないか?
嫌味だけ言ってきたやつとか、頭おかしいんじゃねーの?って思った。
あと、すでに回答されている内容を引き出す質問をする意味が分からん。
その質問したら、前と同じこと言うよね?って思ったのだが、違うのだろうか?

質問してる記者は、システム開発とかに携わったことがない。。?
定時点の意味がわからないって感じの質問を聞いたときは、「まじかよ。。。」って思った。
東証の回答者は、かなり親切に対応していると感じた。

なんか、質問聞いてたら、そもそも株取引したことないんじゃないの?って感じの記者もいたな。。
最後の方は、もうシステム関係ないじゃんって思ったのだが、記者の人は何を聞きに来たのだろうか?
それ聞いてどうすんの?って感じの質問が多すぎ。

「ステータスが難しい言い方」ってのが、すごくジワる。
俺も、回答する側だと、そういうかも。
だって、記者の人たち、システムの考え方とか、全然分からなそうだったからな。

改めて確認が多すぎるな。。。
本当に記者なの?
同じような質問を何回するんだ?

「横文字使わず優しく教えて下さい」って言ってたのを聞いたときは、さすがに吹いたな。。。
それ、聞いたことをそのまま流すつもりだろ。。。
聞いた記者は、フェイルオーバーとか、ディスクとかも分からないのだろうな。
記者なら情報を咀嚼して、分かりやすく伝えるのが仕事だと思うのだが、それを放棄してる?
伝言ゲームでいいのなら、この会見に来なくて良かったのでは?って思った。
呆れると同時に、腹立たしさを感じる。
こんなのにも対応しなきゃいけないから、東証の会見をしていた人たちには同情するよ。

これは、もしかしたら、システム開発の上流工程で同じようなことが起こってる??
ユーザ側が不勉強すぎて、話がまとまらず、しわ寄せが俺たちのところに来ているとかないよね?
急に怖くなってきたわ。。。

雑記

もう、疲れたよ。。。
毎日かけられる会議の精神負荷、視力悪化のためのドキュメント、すべてがストレスを与えてくる。
ストレス社会でどうやって生き抜くか、なかなか答えがでない。
もう、クラゲになって、流れに身を任せて末永く生きたい気分。
このポエム、もしかして病んでる??

動物なら癒やしてくれるだろうか?

2020/09/21週 気づきと振り返り フォルダ構成は大切

業務こなしての問題・気づき

設計・ドキュメント

ファイルを無駄に増やすな!!怒!!

なんか無駄にファイルが分割されているせいで、レビュー時に指摘されてイラッとするのだが。。。
ファイルが少なくて、近くにあるのなら気づくけど、大量にある上に、場所が離れているという。。。
それに、各ファイルの説明もないし、気づけって言う方が無理だろ。。。

なんか、それでスゲー嫌味っぽく言われて、腹立たしい。

あと、フォルダ構成も最悪だった。
大枠からだんだんと範囲が特定されるようなフォルダ構成が基本だと思うのだが、そうなってないんだよね。。。。
全然別のフォルダ下に全く同じフォルダ構成があるから、たまに分からなくなる。
これは、フォルダの迷路でも作っているのか?って思う。

フォルダ構成って、意外と大切だと思う。

雑記

最近、精神的に追い込まれてる気がする。。。
何やっても上手くいかないんじゃないか?って常に心の中で思ってしまうんだよね。。。

温泉街に旅行に行っていたが、精神的な疲れは取れなかったよ。。。
月曜から仕事だと思うと、結構、憂鬱。
これを解消する方法は、ないのだろうか?

2020/07/27週 気づきと振り返り 精神崩壊してない俺はカミーユ以上

業務こなしての問題・気づき

設計・ドキュメント

印刷時のヘッダー・フッターにこだわる

エクセルのヘッダー・フッターって、そんなに重要か?
レビュー出した際に、そこの部分のダメ出しをされたのだが、まさか、最終的に紙に出して管理しているのだろうか?

紙で管理するのはいいけど、情報の扱いが難しくなるから、絶対にやめたほうがいいと思う。
紙1枚でも紛失したら、情報漏えいだし、シュレッダーかけないのはNGになるだろうね。
こっそり持ち出しもしやすいってのもある。
無駄に労力かける割には、セキュリティリスクは減ってない。むしろ増えてる。
ペーパーレス化して欲しいのだが、力関係が面倒くさい。
日本の仕事場って、なんで政治的な要因が絡んでくるのが多いんだ?

仕様以外のところでビクビクしながらドキュメント直すの、正直しんどいのだが。。。

そこまで書く?

ウォータフォールで開発しているのだが、概要・要件フェーズで、詳細な処理内容の記述を求められているのだが、そこまでする必要あるんですかね?

むちゃくちゃ細かく書いているせいで、DB変更が甚大じゃないレベルで影響があるのだが。。。
概要だと、まだDB周りがブレるのだが、そのブレの影響をモロに食らって死にそう。。。

ケツは決まってて、やることがだるま式に増えるのは、マジで精神的にキツイ。
俺じゃなかったら、精神崩壊してると思うよ?

セルフチェック

5~6個くらいならわかるんだけど、20個以上をセルフチェックさせるのは、無理がある。

しかも、書いてあることは、基本的に仕様に関わらないことだし。

どうでもいいところにこだわるの、マジでやめて欲しいわ。。。
レビューで何か指摘しなきゃっていう強迫観念でも抱えているのだろうか?
あら捜しで、どうでもいいところが指摘され、それがセルフチェックに入り、開発者の負担をドンドン増やしている認識がないのだろうという理解を最近するようになった。
これは、どう考えても負の連鎖だろ。。。
いくらやっても、あら捜しがある以上、タスクが減ることはないという。。。
現代版の拷問ではなかろうかとすら思えてくる。

もう、終わりが見えなくて辛いわぁ。。。

総括

硬い現場ほど、どうでもいいところにこだわる印象がある。
「それって、必要なん?」って指摘されてて思ってるけど、いざ言うと、ルールだからの一点張りだからな。。。
そのルール見直せやって思う。

これで精神崩壊起こしてない俺は、カミーユより強いと思っていいだろうか?
今風だと、エミリアより強いと思っていいだろうか?

Java15

リリースされましたな。
9月のリリースは、俺の誕生日と近いから、否が応でも年齢を意識しちゃうんだよね。
そういうシビアなお年頃なの。

リリース前にまとめた記事を列挙しておく。

suzaku-tec.hatenadiary.jp

suzaku-tec.hatenadiary.jp

suzaku-tec.hatenadiary.jp

suzaku-tec.hatenadiary.jp

直近の目標

情報処理技術者試験でDBスペシャリストを受けるのだが、受かる気がしない。。。。
業務で精神ズタボロにされてるのに、試験の勉強なんかする気起きねぇよ。。。
現実逃避のために、だいたいポケモンのランクマやってる。
最近、安定して4桁台にいけるようになった。やる時間がとれてれば、たぶん3桁行けるんじゃなかろうか?

【Java】Java15先取り調査 JEP 375: Pattern Matching for instanceof (Second Preview)

JEP

JEP 375: Pattern Matching for instanceof (Second Preview)

内容

大元であるJEP305との違いがよく分からんかった。。。
第二プレビューみたいな感じに捉えたけど、あってるのかな?
英語は、Google翻訳に一任しているから、あってるか、若干不安がある。。。

suzaku-tec.hatenadiary.jp

追加調査

さすがに、これだけだと中身なさすぎるので、以前調べはしたけど、記載してなかった内容を書いておく

ブロック外でキャストした値を参照できるか?

とりあえず、テストコード
やってることは、オブジェクト型にStringを突っ込んで、それをinstanceofで判定&キャストしている。

public class JEP375 {
  
  public static void main(String[] args) {
    Object obj = "JEP375";
    
    if (obj instanceof String s) {
      // (a)
      System.out.println(s);
    } else {
      // (b)
      System.out.println(s);
    }
  }
}

たぶん、(b)でコンパイルエラーになると思う。
そう思った理由は、参照できちゃ不味い箇所だから。

そして、緊張のコンパイル

$  javac --enable-preview -source 15 JEP375.java 
JEP375.java:11: エラー: シンボルを見つけられません
      System.out.println(s);

恥をさらさずに助かった。。。
やはり、参照範囲は、ifのブロック内のみで、elseは対象外だったね。
この参照範囲になっていることで、安全にアクセスできるというわけですね。

感想

はやく入れて欲しい。
実装しているときに、意外と出くわす問題なので、この記述ができるようになるのは、読む方も実装する方も楽だと思う。
特に、基盤とかFW作っている人は、キャストのために変数作ったりするケースは多いんじゃないかな?

変数追加するだけってのを、軽視している人が意外と多いんだよね。
作る側は、そうだろうけど、読む方は、意図を理解するのに苦戦する。
あったほうが可読性上がるケースもあるから、一概には言えないけど、できることなら、変数はなるべく作らないほうがいい。

リーダブルコードに、なんか書いてあった気がする。
読んでるときにものすごい納得したのだが、どう書いてあったのか思い出せない。。。
たまに、読み返してみようかな?

suzaku-tec.hatenadiary.jp

【Java】Java15先取り調査 JEP 360: Sealed Classes (Preview)

JEP

JEP 360: Sealed Classes (Preview)

内容

簡単に言うと、継承先を限定することができるクラスやインタフェースを作れるらしい。

これができる背景には、目的にそぐわない継承やインタフェースの実装が乱立していた事実があるのかもしれない。※個人の予想です。

コード的には、下記のような記載になる。

sealed class Shape permits Circle, Rectangle, Square { }

目新しい違いは、sealedとpermits。
sealedで、今回の機能を使うことを宣言している。
そして、継承を許可するクラスは、permitsで宣言。
例の内容だと、Circle, Rectangle, Squareが継承を許可されたことになる。

調査

まずは、載ってるサンプルを試す。

sealed class Shape permits Circle, Rectangle, Square { }

class Circle    extends Shape { }
class Rectangle extends Shape { }
class Square    extends Shape { }

javaファイル作ったので、コンパイル
preview版なので、--enable-previewをつける。
※本当はコンパイルしようとしたら指摘されて気づいた。。。

$ javac --enable-preview -source 15 JEP360.java 
JEP360.java:3: エラー: sealed、non-sealedまたはfinal修飾子が必要です
class Circle    extends Shape { }
^
JEP360.java:4: エラー: sealed、non-sealedまたはfinal修飾子が必要です
class Rectangle extends Shape { }
^
JEP360.java:5: エラー: sealed、non-sealedまたはfinal修飾子が必要です
class Square    extends Shape { }

なんか、final句つけないとダメらしい。。。
つまり、1世代しか生き残れない親クラスってわけか。
継承できる先を指定しているので、たしかに、そうだなって、思った。

final句つけて、再コンパイル

sealed class Shape permits Circle, Rectangle, Square { }

final class Circle    extends Shape { }
final class Rectangle extends Shape { }
final class Square    extends Shape { }
$ javac --enable-preview -source 15 JEP360.java 

通った。。。
でも、動作を確認できないから、動作確認ようのクラスを追加しないとダメだね。。。

とりあえず作ったサンプルコード!

sealed class Shape permits Circle, Rectangle, Square { }

final class Circle    extends Shape {
  public int center() {
    return 0;
  }
}
final class Rectangle extends Shape {
  public int length() {
    return 1;
  }
}
final class Square    extends Shape {
  public int side() {
    return 2;
  }
}

public class JEP360 {
  public static void main(String[] args) {
    Shape s = new Circle();
    System.out.println(JEP360.getCenter(s));
  }
  
  public static int getCenter(Shape shape) {
    if (shape instanceof Circle c) {
      return c.center();
    } else if (shape instanceof Rectangle r) {
        return r.length();
    } else if (shape instanceof Square s) {
        return s.side();
    }
    
    return -1;
  }
}

そんでもって実行。
期待値としては、Circleクラスを渡しているので、0が返ってきて欲しい。

$ javac --enable-preview -source 15 JEP360.java 
$ java --enable-preview JEP360
0

ちゃんと返ってきたね。

指定以外のクラスで継承するとどうなるのか?

とりあえずサンプルコード

sealed class Shape permits Circle, Rectangle, Square { }

final class Circle    extends Shape {
  public int center() {
    return 0;
  }
}
final class Rectangle extends Shape {
  public int length() {
    return 1;
  }
}
final class Square    extends Shape {
  public int side() {
    return 2;
  }
}

final class Test extends Shape {
  
}

あらたにTestというクラスを追加した。
このクラスは、Shapeを継承しているけど、Shape側のpermitsには含まれていない。

たぶん、コンパイル時にエラーで弾かれると思う。

$ javac --enable-preview -source 15 JEP360.java 
JEP360.java:19: エラー: クラスはシール・クラスShapeを拡張できません
final class Test extends Shape {
      ^

当たり!!
やっぱり、コンパイル時に弾かれるよね。
正解したから、何かご褒美が欲しい。

permitsに存在しないクラスを指定するとどうなるのか?

とりあえず、サンプルコード

sealed class Shape permits Circle, Rectangle, Square, Unknown { }

final class Circle    extends Shape {
  public int center() {
    return 0;
  }
}
final class Rectangle extends Shape {
  public int length() {
    return 1;
  }
}
final class Square    extends Shape {
  public int side() {
    return 2;
  }
}

Unknown が存在しないクラス。
その他は定義済み。

期待値としては、そのままビルド通っていいのでは?って思ってる。

$ javac --enable-preview -source 15 JEP360.java 
JEP360.java:1: エラー: シンボルを見つけられません
sealed class Shape permits Circle, Rectangle, Square, Unknown { }
                                                      ^
  シンボル: クラス Unknown
JEP360.java:1: エラー: 無効なpermits句
sealed class Shape permits Circle, Rectangle, Square, Unknown { }
                           ^
  (スーパータイプUnknownへの参照が不正です)

なんだと。。。
ビルド時にクラスの存在も確認しているのか。。。

感想

クラスをグルーピングできるようになるって理解でよいだろうか?
使う側で不用意な拡張とかされないようになるから、FW側を安全に使うようになる理解でいるが、どうだろう?

若干、疑問に思っているのは、オープン・クローズドの原則と相反する気がするのだが、気のせいだろうか?
なぜ入ったのか、経緯をよく理解できてないせいか、どうにも腑に落ちない。

今年はイベントがほとんどないから、理解があっているのか確かめる場が無いのが痛い。。。