>>「エンジニアなら勉強して当たり前」の雰囲気をしんどく感じる人<<

SEの勉強にも役立つ?!分からないを解決するためのアウトプット術

空に物を投げる赤い服を着た女性

こんにちは!
複数の億規模プロジェクトで
PLやってるやまさんです!

Aくん

IT系資格の勉強してるけど、理解できているのか、できてないのか分からない。

Bさん

新プロジェクトの説明聞いたけど、分かったような分からないような…

Cさん

先輩にプログラムの説明してもらったけど、なんかモヤモヤする…

IT系の資格勉強やSEの仕事って
目に見えないものを扱うことが多いので
こういうのよくありませんか?

こういう
”分かってるかはっきりしないとき”って
たいてい分かってないです^^;

重要な部分をちゃんと理解できていないと
困ったことになってしまいます…

例えば…

資格の勉強だと、受からなかったり

仕事だと、あとで大変なトラブルに
なってしまうかもしれません。

こういうときは”書く”と
分からないところが
はっきりしてきますよ!

それどころか、そういうことか!って
自分で理解できちゃったりする場合も
あるんです^^

問題部分が分かると、解決に向けて
調べたり、人に聞いたりといった
行動をおこすことができます。

逆に言うと、問題部分が分からないと
解決に向けて行動するのが難しい

この記事では
「分かったような分からないような」を
解決する”かく”という手法について
解説していきたいと思います。

問題点をはっきりさせる力がつくと
行動力が上がる
きっかけにもなります。

ぜひ読んでみてくださいね!

IT系の資格やSEの仕事はなぜ”分かったような分からないような…”が多いのか

うつむきながらベンチに座り悩む女の子

なぜ、IT系の資格やSEの仕事で
”分かったような分からないような…”な
状態によくなるのかと言うと
扱う情報が抽象的な場合が多い
からです。

Dさん

Aシステム→Bシステムへデータ連携してBシステムの夜間バッチ処理で…

SEの現場だとよくあるやりとりですよね。

なぜこんな抽象的な話が
多くなってしまうのかというと
ITが情報を扱うものだからです。

”IT→情報技術”なので、
当たり前なんですが、
ITシステムで扱う情報は
目に見えないことが多い
です。

例えば、このブログも
文字情報や画像情報が出力されていますが、
出力されるまでに人間の目に見えない
いろんな処理がされていますよね。

この”目に見えない部分の処理”を
作っていくのがシステム開発作業の
大半を占めます。

なので、どうしても抽象度が高い
情報のやりとりが
多くなってしまうんですよね。

試しにやってみて理解度上げる、
というのも1つの方法なんですが、

Aくん

やってみたら本番環境でバグりましたー!

これでは困ることもありますよね^^;

SEの仕事は目に見えない情報を扱うことが
多いので、
いまいち理解しきれてないような
モヤモヤした状態が多く発生
します。

分からない理由

赤い文字で書かれた分析の文字

ではなぜ理解しきれないのか、
その原因を解説していきたいと思います。

何かの説明を聞いて分からないとき
大きく次のどちらかの状態に
なっている
んじゃないでしょうか。

  • 説明に使われている単語が分からない
  • 情報の関連付けができていない
やまさん

順番に説明していきますね

説明に使われている単語が分からない

Bさん

話をちゃんと聞いてるのに何言ってるか分からない…

説明を聞いても、何を言ってるのか
分からない場合は、
”まったく分からない”状態のはずです。

言葉が理解できないできないので
当たり前ですよね^^;

新しい現場に配属されたばかりの場合や
SEになりたての方に多いです。

やまさん

ボクも経験ありますが、外国語を話されているのと変わらない…

”まったく分からない”状態を
脱出するための対処方法は
とにかく単語の意味を覚える
ことです。

相手が日本人であれば、
日本語で説明してくれるはず←

分からないことはちゃんと聞いて
メモを取りながら覚えましょう。

情報の関連付けができていない

1つ1つの単語は分かっているんですが、
情報をうまく関連付けできていない状態

このようなとき
”分かったような分からないような…”が
状態が発生
します。

やまさん

分かるまでもう少し!

単語は理解できるので
なんとなく説明されていることは
分かります。

ですが、”AだからB、BだからCといった”
説明されていることについて
情報の関連性が整理できてない
状態なんですよね。

情報の関連付けが
うまく理解できていないときは
”分かったような分からないような…”に
なってしまいます

何が分からないかを知る

グラフを指さす人

理解しきれていない状態を脱出するには
何が分からないのかはっきりさせることが
必要があります

何が分からないのかはっきりさせないと
自分から質問もできないですし、
説明する側も何を教えたらいいか
分からないですからね^^;

逆言うと、分からない部分が分かれば、
自分で調べたり、質問したりすることが
できます

解決のために行動することが
できるんですよね^^

なので、
自分が何を理解できていないかを知ると、
行動力が上がります。

何を理解できていないかを知るには
かいてみることをおすすめします。

理解度を確かめるための超簡単な方法→かいてみる

カラフルなメモ用紙にボールペンでメモする情勢

ボクは何を理解できていないかを
知るために
今理解できている部分について
書いてみることを
おすすめしています。

最初はめんどく感じるかもしれませんが、
実は書いてみた方がはやいというケースは
多いですよ!

気になる書き方については
いろいろありますが、
システム開発では
次の3つのパターンがおすすめです。

  • 処理や業務の流れで書く
  • 時系列で書く
  • 因果関係で書く

処理や業務の流れで書く

処理や業務の流れに関することは
説明の場合はフロー図を
書くのが効果的です。


こんなやつです。

システムと業務フロー図
引用元:https://pm-rasinban.com/wp-content/uploads/2019/06/business-flow.jpg

またしっかり書けば、フロー図は
プロジェクト炎上の防止になる
ので
かなりおすすめです。

フロー図の効果について
まとめた記事はこちら。

青空の下の赤いSTOPの看板

時系列で書く

フロー図と似ているんですが、
時系列に書いていくのもおすすめです。

こんなやつ(内容はまったく関係ないです)

時系列の図
引用元:https://juken-mikata.net/how-to/english/sequence-of-tenses.html

横に線を引き、いつ何をしたか
書いていくことで情報を整理
します。

バグ分析などで多いんですが、
ログ情報からDB更新履歴を
追ったりする場合に効果絶大
です。

フロー図よりも簡単に書けるという
メリットもありますね^^

因果関係で書く

なんでそうなったのか原因を
分解して書いていく方法もあります。

つまり、因果関係を整理して
書いてく方法
ですね。

バグの原因分析などで役に立ちます。

原因分析を行いたい場合ときなどは
ロジックツリーで書くのが効果的
です。

見たことあるかと思いますが、
こんな感じです。
(内容は関係ないです)

ダイエットのロジックツリー
引用元:https://infinity-agent.co.jp/lab/logic-tree/

なお、ロジックツリーですが、
実は書き慣れるまでは難易度が高いです。

書いてみると分かるんですが、
分岐したときの抽象度が合わないとか
うまく分岐させることができないとか
慣れてないと結構難しい…

でも、ロジックツリー自体をきれいに
書くことが目的ではない
はずです。

なので、ロジックツリーを書く時は
ほどほどの完成度にして
こだわりすぎないよう注意
しましょう。

おまけ:かくのは電子がいい?手書きがいい??→最初は手書きがおすすめ

パソコン画面をみて喜ぶ男の子と女の子

ボクは”分からないときは書け!”を
職場の後輩にもおすすめしてます。

そこでよく質問されるのは
エクセルなどの電子データで書くのか
手書きの方がいいのか。

やまさん

結論としては、最初は手書きをおすすめします。

紹介した3つの書き方

  • 処理や業務の流れで書く
  • 時系列で書く
  • 因果関係で書く

これらですが、電子データで書くと
図形の操作がめんどくさい…^^;

めんどくさい思いをするなら
ラフに手書きした方がいいと
やまさんは思ってます。

とにかく書くことを習慣づけるのが
大切
です!

まとめ

問題が問題ではなくなる

この記事ではこんなことを紹介しました。

  • 理解できたか自信がない場合、たいてい理解しきれていない
  • 分かったような分からないような状態は情報を関連付けできてない状態
  • 理解しきれていない部分をはっきりさせるためには”書く”のが効果的

明日からでも実践できるので、
ためしてみてくださいね!

なお、この記事の冒頭で資格試験の
勉強の話を少しました。

実は資格試験の勉強をする前に
チェックしておきた
注意点
があるんです…

ということで、資格試験勉強前に
注意しておきたい点について
以下の記事でまとめてみました。

ぜひ読んでみてくださいね!

驚く男性の白黒写真

それでは!

最後に(おまけ)

プロフィール記事やまさん_アイキャッチ

 

ボクは新人の頃、部署内でも有名なポンコツエンジニアでした^^;

 

プログラミングなど、ITに関するスキルが壊滅的だったのです。

 

ですが、今となっては社内で最短昇格を達成し、ボーナスも6回連続最高評価を達成しました。

 

 

こう言うと、なかなかの怪しさですよね(苦笑)

ということで、やまさんのエンジニア人生をプロフィールとしてまとめてみました。

 

ITスキル壊滅だったボクがどうやってエンジニアとしての活路を見つけたのか、気になる人は見てみてくださいね^^

>>やまさんの詳しいプロフィールを見てみる

 

プロフィールを読んでもらえれば察してもらえると思いますが、ボクはITスキル平凡な凡人SE。

めちゃくちゃプログラミングができるなど、特別なITスキルは持っていないです。

 

そのためか、昔は

  • エンジニアになったはいいものの、IT技術に関して興味を持てない…
  • 平凡なITスキルしかもってないのにエンジニアとしてやっていけるのだろうか…
  • IT技術を身につけていくだけでエンジニアとして食べていけるのかな…
  • 移り変わりの早いITの世界で永遠とIT技術の勉強を続けられる自信が…

 

このような悩みを抱えていました。

 

おかげさまで、プロフィールに書いたあるきっかけから↑のような悩みは解決してます。

 

 

ですが、実はバリバリのエンジニアの方でも「ITの勉強しない→エンジニア失格」という空気感にしんどさを感じてる人は多いみたいなんですよ…

 

というのも、「勉強しない→エンジニア失格」の空気感について、こちらの記事でまとめてみたところ、かなり人気なんですよね。

 

このブログの中でも人気の記事なので、気になった方は一度見てみてください^^

 

 

最後まで読んでいただきありがとうございました!!

コメントを残す

メールアドレスが公開されることはありません。 が付いている欄は必須項目です