人に説明すること

学生のうちは気にしないでも何とかなるやつ。

結論から言うと、『5W1H』を意識しておけば解決する。
もちろん、相手との共通認識(例えば「私が」等の情報)は省いても大丈夫ですが、基本は『5W1H』を使う。


■『5W1H』の確認
①when <いつ> = 時間
②where <どこで> = 場所
③who <だれが> = 誰
④what <なにを> = 物/行動
⑤why <なぜ> = 理由
⑥how <どのように> = 手段


■『5W1H』を使う理由
簡潔に「相手に不要な疑問を持たせない」こと。
5W1H』を使って質問が出てくる時は、相手が話に興味を持った場合か、『5W1H』が間違っていた場合のいずれかと考えてよい。
不要な疑問を持たせないことは、無駄な質問を受ける時間を短縮できるし、わかりやすい説明は個人の信用にもつながる。


■例題
「あなたは昨日何をしていましたか?」を『5W1H』で説明しなさい。


■解答例
「18時ころに駅前のレストランで家族と食事をしていました。出かけていて食事を作る時間が無かったので外食にしようということになりました。」


■解説
前半の文章で「when/where/sho/what」、後半の文章で「why/how」。
面白いのは、いずれかの要素を抜いても文章として成立するということ。
ただしその場合は抜いた要素に対する質問が返ってくる可能性が高くなる。


■まとめ
結局最後まで『5W1H』の話になってしまった。
でも、それくらい大事なことであると考えてほしい。
説明をするときに意識することができるようになれば、話を聞くときにも意識して聞くことができるようになる。
そうすると情報の抜け漏れが無くなるようになり、お互いのためになる。

仕事のストレス源になる通勤時間

遠いとか満員電車とか朝早いとかそういうの。
11月から新しい現場に行くことになって路線図見て焦った。
片道1時間の間に乗り換え3回。しかも全部5分とか10分しか乗らないから寝られないし。
そもそも混んでるから座れないし。
どの乗り換えでも待ち時間5分くらいあるし。

引っ越すしかない。
隣の駅くらいにしようと思う。最悪電車なくなっても歩いて帰れるし。

バッチファイルの個人メモ

以下の⓵と②をそれぞれ.batファイルとして同じフォルダに保存する

中のパスが正しいものになっていることを確認した後、⓵を実行する

 

----------------------------------------------------------------------------------------------------

 

@echo off
rem 練習用バッチファイル
rem 「echo off」で以降のコマンドが全て非表示で実行される
rem ファイルの初めに「echo off」を使用しない場合、「@」でその行だけが非表示で実行される
rem 「rem」はコメント行


rem 【フォルダを開く】
rem 「start」コマンドで新しいコマンド/プログラムを起動する
rem 次の書き方だと、「C:\work\sample」フォルダを開く
start C:\work\sample


rem 【コマンドプロンプトを開く】
rem 次の書き方で新しいコマンドプロンプトを開く
rem startコマンドの一つ目の引数はコマンドプロンプトのタイトルであるため、新しいコマンドプロンプト「NEW!」が開く
start "NEW!"


rem 【アプリケーションを実行する】
rem startコマンドを実行する場合、一つ目の引数だけだとコマンドプロンプトが開いてしまう
rem 一つ目の引数は空にして、二つ目の引数に実行するアプリケーションのパスを書く
rem ※ファイアフォックスをインストールしていない場合は、何でもよいので実行できるアプリケーションのフルパスに変更してください
start "" "C:\Program Files\Mozilla Firefox\firefox.exe"

rem 同じアプリケーションを2つ書けば2つ開く
rem なのでここまで全て実行すると同じアプリケーションが3つ開いているはず
start "" "C:\Program Files\Mozilla Firefox\firefox.exe"
start "" "C:\Program Files\Mozilla Firefox\firefox.exe"


rem 【指定したURLを開く】
rem 「start URL」で指定したURLが開かれる
rem 規定のブラウザで開かれる
start https://msdn.microsoft.com/ja-jp/


rem 【他のバッチファイルを呼び出す】
rem 「Practice_Sub」という名前のコマンドプロンプトを開くバッチファイルを用意する
rem 当ファイルと同じフォルダに置いてあるなら以下の書き方で良い
rem 異なるフォルダに置いてあるならフルパスを記載する
call Practice_Sub.bat

 

----------------------------------------------------------------------------------------------------

 

----------------------------------------------------------------------------------------------------

 

start "Practice_Sub"

 

----------------------------------------------------------------------------------------------------

 

■「start」と「call」の違いについて
・start
新しいプロセスで処理する

・call
同じプロセスで処理する


処理Aを実行中に、分岐して処理Aと処理Bをそれぞれ実行するのが「start」
処理Aを実行中に、寄り道して処理A´を実行して完了したら処理Aに戻って続きを実行するのが「call」

現場が変わる

11月から現場が変わる。

今のストレス源と離れられるからちょっとは体調よくなるといいな。


同じ会社の人にどこまで症状について話すか迷うのよね。とりあえず体調不良ってことにしてた先輩から「良くなったか」って聞かれて、あーそういうのじゃないんだよなーって。


うーん、迷う。

プログラムの設計段階で失敗したこと

振り返ってみると「こうすれば良かったのかな」と思うことがあったのでメモ。

 

①設計時に今後の芯となる内容が決まっていなかった
本当の「最低限必要な機能」が決まらないまま、この機能は必要かあの機能は必要かという話が始まってしまった。
例えば「画面に入力した文字列を、別の画面に出力する」という機能を実装しようとしている時に、「出力後のデータをソートする場合がある」や「CSVに出力したい時がある」などの、使うかもしれない機能の話が始まってしまったような状況だった。
主な原因は、営業側に話の主導権を握られてしまっていたことと、設計側の責任者がいなかったこと。
前者はそのまま、あれもしたいこれもしたいを真に受けてしまっていた。後者は前者の状況を作り出す原因になっていた。
営業側が言うことに「NO」といえる人がいなかったため、営業側の立場が上になってしまった。
営業の意見を聞くことは大事だが、それをもとに仕様上の課題や画面イメージを考える段階では営業を同席させるべきではなかった。
実際は営業と開発の両方に足を突っ込んでいる人が担当だったから嫌でも同席されることになってしまっていたかもしれないが、そういった提案をすべきだったかなと。

②個人スキルの差が大きいことに対する考慮
工数を算出する時、コーディングをする時に、スキル差を考えていなかった。
正確には、考えていたが問題ない程度だろうと思っていた。
結局予定工数の2倍かかってしまってバッファを食いつぶしたり他の人が他の人がフォローに回ったり。
実はこれ、①の内容が影響してさらに悪化した。今までに使っていない言語やツールを使うだけでも差が出るのに、前述のあれもしたいこれもしたいによって実装する機能が増えたり変更されたり。
それに比例して目に見えて進捗差ができてしまった。その差はもはやチームとして成り立たないレベルに達してしまった。

 

どちらも基本的なことで、こういったところで失敗するとうまくいかないのだと実感した。