こんにちは!
複数の億規模プロジェクトで
PLやってるやまさんです!
新プロジェクトの説明聞いたけど、分かったような分からないような…
先輩にプログラムの説明してもらったけど、なんかモヤモヤする…
IT系の資格勉強やSEの仕事って
目に見えないものを扱うことが多いので
こういうのよくありませんか?
こういう
”分かってるかはっきりしないとき”って
たいてい分かってないです^^;
重要な部分をちゃんと理解できていないと
困ったことになってしまいます…
例えば…
資格の勉強だと、受からなかったり
仕事だと、あとで大変なトラブルに
なってしまうかもしれません。
こういうときは”書く”と
分からないところが
はっきりしてきますよ!
それどころか、そういうことか!って
自分で理解できちゃったりする場合も
あるんです^^
問題部分が分かると、解決に向けて
調べたり、人に聞いたりといった
行動をおこすことができます。
逆に言うと、問題部分が分からないと
解決に向けて行動するのが難しい…
この記事では
「分かったような分からないような」を
解決する”かく”という手法について
解説していきたいと思います。
問題点をはっきりさせる力がつくと
行動力が上がるきっかけにもなります。
ぜひ読んでみてくださいね!
Contents
IT系の資格やSEの仕事はなぜ”分かったような分からないような…”が多いのか
なぜ、IT系の資格やSEの仕事で
”分かったような分からないような…”な
状態によくなるのかと言うと
扱う情報が抽象的な場合が多いからです。
Aシステム→Bシステムへデータ連携してBシステムの夜間バッチ処理で…
SEの現場だとよくあるやりとりですよね。
なぜこんな抽象的な話が
多くなってしまうのかというと
ITが情報を扱うものだからです。
”IT→情報技術”なので、
当たり前なんですが、
ITシステムで扱う情報は
目に見えないことが多いです。
例えば、このブログも
文字情報や画像情報が出力されていますが、
出力されるまでに人間の目に見えない
いろんな処理がされていますよね。
この”目に見えない部分の処理”を
作っていくのがシステム開発作業の
大半を占めます。
なので、どうしても抽象度が高い
情報のやりとりが
多くなってしまうんですよね。
試しにやってみて理解度上げる、
というのも1つの方法なんですが、
やってみたら本番環境でバグりましたー!
これでは困ることもありますよね^^;
SEの仕事は目に見えない情報を扱うことが
多いので、
いまいち理解しきれてないような
モヤモヤした状態が多く発生します。
分からない理由
ではなぜ理解しきれないのか、
その原因を解説していきたいと思います。
何かの説明を聞いて分からないとき
大きく次のどちらかの状態に
なっているんじゃないでしょうか。
- 説明に使われている単語が分からない
- 情報の関連付けができていない
順番に説明していきますね
説明に使われている単語が分からない
話をちゃんと聞いてるのに何言ってるか分からない…
説明を聞いても、何を言ってるのか
分からない場合は、
”まったく分からない”状態のはずです。
言葉が理解できないできないので
当たり前ですよね^^;
新しい現場に配属されたばかりの場合や
SEになりたての方に多いです。
ボクも経験ありますが、外国語を話されているのと変わらない…
”まったく分からない”状態を
脱出するための対処方法は
とにかく単語の意味を覚えることです。
相手が日本人であれば、
日本語で説明してくれるはず←
分からないことはちゃんと聞いて
メモを取りながら覚えましょう。
情報の関連付けができていない
1つ1つの単語は分かっているんですが、
情報をうまく関連付けできていない状態。
このようなとき
”分かったような分からないような…”が
状態が発生します。
分かるまでもう少し!
単語は理解できるので
なんとなく説明されていることは
分かります。
ですが、”AだからB、BだからCといった”
説明されていることについて
情報の関連性が整理できてない
状態なんですよね。
情報の関連付けが
うまく理解できていないときは
”分かったような分からないような…”に
なってしまいます。
何が分からないかを知る
理解しきれていない状態を脱出するには
何が分からないのかはっきりさせることが
必要があります。
何が分からないのかはっきりさせないと
自分から質問もできないですし、
説明する側も何を教えたらいいか
分からないですからね^^;
逆言うと、分からない部分が分かれば、
自分で調べたり、質問したりすることが
できます。
解決のために行動することが
できるんですよね^^
なので、
自分が何を理解できていないかを知ると、
行動力が上がります。
何を理解できていないかを知るには
かいてみることをおすすめします。
理解度を確かめるための超簡単な方法→かいてみる
ボクは何を理解できていないかを
知るために
今理解できている部分について
書いてみることを
おすすめしています。
最初はめんどく感じるかもしれませんが、
実は書いてみた方がはやいというケースは
多いですよ!
気になる書き方については
いろいろありますが、
システム開発では
次の3つのパターンがおすすめです。
- 処理や業務の流れで書く
- 時系列で書く
- 因果関係で書く
処理や業務の流れで書く
処理や業務の流れに関することは
説明の場合はフロー図を
書くのが効果的です。
こんなやつです。
またしっかり書けば、フロー図は
プロジェクト炎上の防止になるので
かなりおすすめです。
フロー図の効果について
まとめた記事はこちら。
時系列で書く
フロー図と似ているんですが、
時系列に書いていくのもおすすめです。
こんなやつ(内容はまったく関係ないです)
横に線を引き、いつ何をしたか
書いていくことで情報を整理します。
バグ分析などで多いんですが、
ログ情報からDB更新履歴を
追ったりする場合に効果絶大です。
フロー図よりも簡単に書けるという
メリットもありますね^^
因果関係で書く
なんでそうなったのか原因を
分解して書いていく方法もあります。
つまり、因果関係を整理して
書いてく方法ですね。
バグの原因分析などで役に立ちます。
原因分析を行いたい場合ときなどは
ロジックツリーで書くのが効果的です。
見たことあるかと思いますが、
こんな感じです。
(内容は関係ないです)
なお、ロジックツリーですが、
実は書き慣れるまでは難易度が高いです。
書いてみると分かるんですが、
分岐したときの抽象度が合わないとか
うまく分岐させることができないとか
慣れてないと結構難しい…
でも、ロジックツリー自体をきれいに
書くことが目的ではないはずです。
なので、ロジックツリーを書く時は
ほどほどの完成度にして
こだわりすぎないよう注意しましょう。
おまけ:かくのは電子がいい?手書きがいい??→最初は手書きがおすすめ
ボクは”分からないときは書け!”を
職場の後輩にもおすすめしてます。
そこでよく質問されるのは
エクセルなどの電子データで書くのか
手書きの方がいいのか。
結論としては、最初は手書きをおすすめします。
紹介した3つの書き方
- 処理や業務の流れで書く
- 時系列で書く
- 因果関係で書く
これらですが、電子データで書くと
図形の操作がめんどくさい…^^;
めんどくさい思いをするなら
ラフに手書きした方がいいと
やまさんは思ってます。
とにかく書くことを習慣づけるのが
大切です!
まとめ
この記事ではこんなことを紹介しました。
- 理解できたか自信がない場合、たいてい理解しきれていない
- 分かったような分からないような状態は情報を関連付けできてない状態
- 理解しきれていない部分をはっきりさせるためには”書く”のが効果的
明日からでも実践できるので、
ためしてみてくださいね!
なお、この記事の冒頭で資格試験の
勉強の話を少しました。
実は資格試験の勉強をする前に
チェックしておきたい注意点があるんです…
ということで、資格試験勉強前に
注意しておきたい点について
以下の記事でまとめてみました。
ぜひ読んでみてくださいね!
それでは!
IT系資格の勉強してるけど、理解できているのか、できてないのか分からない。