「AI分析でわかった トップ5%社員の習慣」を読んだ
以前以下の記事を書きました。
時間術に続いてこちらもAmazonPrimeで無料だったので読んでみました。
中身は時間術と同じような内容もありましたが、こちらでも勉強になることがありましたので紹介してみたいと思います。
週に1回15分間の内省タイムを持つ
以前の記事でもフィードバックをもらうことは言及しました。
本書でもフィードバックの重要さを謳っており、内省タイムを設けることを推奨していました。
内省タイムでは、まず1週間で行った仕事について成果に繋がった仕事、繋がらなかった仕事を切り分けます。
そして繋がらなかった仕事をしてしまったとき、なぜ自分はこういう判断をして、この結果を招いたのか、そして次はどうすればよいのかを考えます。
この内省タイムによって、次の仕事に活かすことができるのだそうです。
ただ、私のやっている仕事の性質上、すぐには結果が出ず、成果に繋がったのか繋がらなかったのかよくわからないことがあります。
例えば商談の場合、発注を頂ければ成果に繋がったと判断できますが、それがわかるのは数カ月先だったりして、週の内省タイムでは判断できないのです。
そのため、効果がわからず最初の数週間でやめてしまいました。
今思うと、週に1回にこだわる必要もなかったのでは、という気がしています。
とにかく何か失敗をしてしまったときに、内省タイムを設ければよいのではないかと思います。
まとめ
人に合ったやり方で内省タイムを設けることが重要だと思います。
このブログでも、私の内省を綴ってみたいですね。
※公開するかどうかは別として…🤔
「Re:vision: タスクリストとアウトライン」を読んだ
タスクの整理術について模索していた時に本書に出会った。
AmazonPrimeで無料だったので読んでみることにした。
最初に触れておくが、タスクに関して本書ではあくまで1日のタスクをどう決めるかについて言及していた。
エンジニアがやるWBS的なプロジェクト全体のタスクリストとはまた毛色が異なることを最初に申し上げておく。
私が本書から学んだデイリータスクリストと、現在どのような運用をしているのかについて記す。
デイリータスクリスト
デイリータスクリストとは、今日一日のタスクを書き出したリスクのことだ。
今日やるべきこと、やりたいこと、できればやっておきたいことを書き出す。
書き方として、まずは、とりあえずタスクを並べてみることから始める。
優先度や包含関係などは関係なくとりあえず洗い出す。
次に包含関係を考え、大タスクの中に小タスクをインデントして記入する。
この点は実際にOneNoteやNotionを使って書いてみたが、OneNoteのほうが書きやすかった。
タブキーを押すだけでインデントされるし、大タスクをダブルクリックするとトグルリストのように閉じたり開いたりできる。
Notionでもトグルリストの機能はあるのだが、何ステップか操作を踏まないといけない。この点が私は煩わしく感じた。
とはいえNotionのほうが見やすく整理できるし何より多機能なので、結局OneNoteはあまり使っていないのだが…
話を戻すと、一通りタスクを洗い出し、包含関係を持つように整理できたら、優先順位を決める。
私は、マストでやること・できればやりたいことの2つに分け、その中で優先度が高い順に上から並べるようにしている。
最後に今日一日どんな風に過ごしたいかをデイリーサマリーと称して、タスクリストの一番上に書く。
サマリーは結構重要で、書いたからには今日一日その指針からブレないようにする。
これが私のデイリータスクリストの運用である。
しかしながら、実際に運用してみるとサマリーからはブレる。
また、1日で終わるだろうと思って書き出したタスクが、夕方見ると全然終わっていないことに気づく。
そのため、果たしてこのままで本当に良いのかは一度考える必要がある。
確か本書でもこのことについては書かれていた気がするので、また再読してみたいと思う。
まとめ
本書ではデイリータスクリストについて学んだ。
しかし、現状ではうまく運用できていない。
うまく運用できていない要因について、また本書を読み込み、記事にしたいと思う。
「AI分析でわかった トップ5％社員の時間術」を読んだ
仕事に忙殺される日々、自分はいつからこんなに残業しているのだろうということで、
今の状態を抜け出すべく本書を手に取りました。
※AmazonPrimeで無料だったこともあり💦
本記事では本書から学んだことを3つ紹介してみたいと思います。
有限の時間をポジティブに捉える
AI分析によると、トップ5%社員は忙しさをネガティブに捉えるのではなく、
「やるべき仕事が多いのは周りから認められている証拠だ」と、ポジティブに捉えているそうです。
この言葉だけで救われるような感覚がありました。
効率主義から効果主義になる
表紙にも書いてありますが、
「やらなくても良い仕事を効率的にこなしても、成果にはつながらない」
と理解することが重要です。
大切なのは、何をすると一番良い成果が出るかということです。
そのために不要な仕事はどんどん周りに投げたり、やらないことにしているようです。
では、仕事の取捨選択はどのようにしたらよいのでしょうか。
それは後述するフィードバックを受けることで、何をすべきかがわかるようになります。
フィードバックを受けて足りないところを埋める
成果を待つ人は上司であったり顧客であったり様々です。
その人たちに最大限の成果を提供するために、アウトプットを早くしているそうです。
そしてフィードバックを受け、相手が何を待っているのか情報を収集し、
ノウハウをためているから、必要な仕事の選択ができるのだそうです。
まとめ
大事なことは、ポジティブなマインド、効果主義、フィードバックということがわかりました。
これを普段の仕事でも意識して取り組みたいと思います。
「良いコード/悪いコードで学ぶ設計入門」を読んだ
kintoneでやや複雑なJavaScriptカスタマイズが必要になったため、
よい設計方法を学びたいと思い、本書を読みました。
本記事では本書から学んだ内容を3つ紹介してみたいと思います。
データクラスは多数の悪魔を呼び寄せる
データを保持するだけのクラスを一般的には「データクラス」と呼び、そして悪いコードのパターンを本書では「悪魔」と呼んでいます。
データクラスがなぜ悪魔を呼び寄せるかというと、そのデータを使用した処理が色々な箇所で実装される可能性があるからです。
このような構造は重複コードを量産し、修正が入ったときに修正漏れ、可読性低下などを招きます。
関連するデータやロジック同士が分散し、バラバラになっていることを「低凝集（ていぎょうしゅう）」と呼びます。
※今までずっと「ていぎしゅう」と読んでいました💦
staticメソッドは低凝集になりがち
staticメソッドはインスタンス変数が使えないため、上記と同様に関連するデータが分散し、低凝集に陥ります。
そうなるとstaticメソッドの使いどころはどこになるのでしょうか。
本書ではstaticにしてもよいのは横断的関心ごとと紹介されています。
例外処理、ログ出力処理、同期処理などは、staticメソッドとして定義してもよいでしょう。
型判定が必要な場面ではインターフェースを使う
インターフェースを使わずに型判定を行う場合、instanceofを使用したif文が大量生産されます。
型が増えるたびにif文が増えていく構造になり、これが複数個所に実装されていると、修正が必要になった際地獄を見ることになります。
インターフェースであればポリモーフィズムによってこうした事態を防ぐことができます。
JavaScriptだとインターフェースの概念が存在しませんが、classを使ってポリモーフィズムっぽい実装することができるようです。
まとめ
以上、３点紹介しました。
上記以外にも参考になることが多く書かれているので、ぜひ一読することをお勧めします。
「人工知能は人間を超えるか」を読んだ
はじめに
G検定の試験対策として、「人工知能は人間を超えるか」を読んだ。
人工知能とは
人工知能の定義
人工知能の定義は明確に定まっていないが、本の筆者は「人工的に作られた人間のような知能」と定義している。
単純な制御を行うプログラムであっても「人工知能」と称してしまえばそれは人工知能である。
人工知能ブームはこれまでに3度到来しており、現在は第3次AIブームの真っ只中である。
それまでには技術的な問題によって冬の時代を越してきた。
第1次AIブーム
第1次AIブームは1950年代後半～1960年代である。
この時代は「推論・探索」の時代と呼ばれた。
推論とは人間の思考過程を記号によって表現し実行するものであるが、処理としては探索に近い。
探索のやり方として、探索木と呼ばれるものがある。
これは、場合分けを木の枝のように表すものである。
探索木を実際に探索していくには、幅優先探索と深さ優先探索がある。
幅優先の場合、ゴールまで最短距離でたどり着く解が必ず見つかるが、探索の途中過程をすべて記憶していかなければならないので、メモリが多く必要になる。
深さ優先の場合、必要なメモリは少なく済むが、必ずしも最短距離が見つからない。
探索木や迷路問題などであればよいが、将棋や囲碁の場合パターンが非常に多く存在するため、通用しない。
この時代のAIは簡単な問題「トイ・プロブレム」しか解けないとして、冬の時代を迎えることになる。
第2次AIブーム
第2次AIブームは1980年代～1995年代である。
この時代は「知識」の時代と呼ばれた。
専門知識を取り込ませ、推論を行うことで、専門家のように振る舞うことができる。
これを「エキスパート・システム」と呼ぶ。
知識を取り込ませる方法として「意味ネットワーク」がある。
これは概念をノードで表し、関連する概念をノード同士で結び、ネットワーク化するのである。
しかし人間の持つ一般常識を取り込むには膨大で非常に時間がかかる。
知識を取り込むこと自体が難しいことがわかると、それ自体を研究する動きが生まれた。
これを「オントロジー研究」と呼ぶ。
オントロジー研究には、ヘビーウェイト・オントロジーとライトウェイト・オントロジーに分けられる。
ヘビーはしっかり取り込み、ライトはとにかく使えればよいという考え方である。
しかし結局意味まではAIが理解することができず、壁にぶつかることになる。
これは「知識獲得のボトルネック」と呼ばれる。
「フレーム問題」という問題も発見された。
これは問題を解くために必要な条件の要不要を切り分けることができない問題である。
さらに「シンボルグラウンディング問題」という問題もある。
これは「シマシマ」などといったシンボルを表す言葉を理解できない問題である。
結局これらの問題の解決には膨大な時間を必要とし、再び冬の時代を迎えるのである。
第3次AIブーム
ディープラーニングが生まれるまで
第3次AIブームは2010年代～現在である。
この時代は「機械学習」という研究が進められた。
機械学習とは、「分け方」を自動的に習得する技術である。
機械学習には教師あり学習と教師なし学習、強化学習に大別される。
教師あり学習とはその名の通り、入力値とその目標値が与えられ、その関係を学習する。
教師なし学習とは、入力値のみが与えられ、学習をしながらその値の中に存在する一定のパターンを抽出する。
強化学習は試行を繰り返し、より価値の高い行動を学習する。
しかし何を特徴量とするかは人間が決めないといけなかった。
ディープラーニングが生まれたあと
ニューラルネットワークという技術が生まれた。
これは人間の脳神経を信号が伝わっていく様子を数学的に模したものである。
このニューラルネットワークを使用した機械学習をディープラーニングと呼ぶ。
ディープラーニングによって、画像分類や時系列データから特徴を抽出することも可能になった。
ディープラーニングはデータを基に、人間が特徴を決めるのではなく、コンピュータが特徴量を作り出す。
コンピュータはデータの相関関係を見ることで、勝手に特徴量を生成することができるようになった。
今後の進展
専門家の間では、２つの意見がある。
・一時的な流行に過ぎない
・特徴を表現できるようになったことで、人工知能の限界を凌駕した
本の筆者は後者の立場をとっている。
私も後者であってほしいと思っている。
まとめ
人工知能は私が生まれる前から、ブームと冬の時代を交互に発展してきた。
現在はディープラーニングが生まれ、より高度な実装ができるようになり、
人工知能が社会に溶け込み始めている。
引き続き、私も人工知能が今後どのように発展をしていくのか注目していきたい。
【育児中でも合格できる！】AZ-900に合格するためにやったこと
自己紹介
- 4か月の息子を持つ、1児の父親です
- SIer系の企業でエンジニアをしています。わりとコードを書く機会も多いです。
普段の生活
- 平日は9時～18時まで仕事をし、その後育児に参加します
- 休日はフルタイムで育児に参加しています
やったこと
試験の3か月前~
- 「Microsoft Virtual Training Days」に参加し、無料で試験が受けられる特典をもらう
- 他の人の合格体験記を見て勉強法を学ぶ
試験の2か月前~
- 「徹底攻略 Microsoft Azure Fundamentals教科書[AZ-900]対応*1」（以下、黒本）を購入し、流し読みつつ、2周問題を解く
※効率を考え2週目は間違えた問題だけを解いた - 勉強時間をtoggl*2に登録
- Todoist*3に毎日やるタスクを登録
試験の1.5か月前~
- Udemyの問題集*4を購入し、ここからはこの問題集ベースで進めた
※購入に至った理由は、黒本は少し内容が古いことに気づいたため - Udemyの問題集は3周した
※黒本と同様に間違えた問題だけ2週目、3周目と学習 - Azure技術資料インデックス*5を発見し、不明点をこちらの資料で確認
試験の1週間前~
- ankiアプリ*6を購入し、Udemyの間違えた問題だけを登録して毎日学習
※購入に至った理由は、この時点でUdemyの模擬試験の正答率が60～70%であり、かなり焦ったため - 忘れそうな事柄はNotion*7にまとめた
試験の1日前~
- ちょうど日曜日だったため、育児をお休みし、1日勉強させてもらった
当日
- Notionにまとめた内容を見返す ※結果865点で合格
工夫したこと
基本的に全部スマホに集約
育児中はとにかくまとまった時間が取れないため、スキマ時間で勉強する必要がありました。
食事中、歯磨き中、トイレ中...etc
そのためにいちいち本を開いたり、勉強道具を用意している時間がもったいなかったですし、
勉強の手軽さはモチベーションにも直結すると思いました。
そのため、問題集やメモ等すべてスマホだけで完結するようにしました。
使用したもの/役に立ったもの
| 使用したもの | 役立ち度 | コメント |
|---|---|---|
| 黒本 | ★★☆☆☆ | 内容が古いため、後半は少し見返す程度 |
| Udemy | ★★★★★ | この問題集をベースに学習すれば合格できると思います |
| toggl | ★★★★★ | 習慣化や勉強時間の把握に必須 |
| Todoist | ★★★☆☆ | タスク管理に使用したが、正直後半は見なくてもやるので役に立っていない |
| Notion | ★★★★☆ | 学んだことのまとめ用 |
| anki | ★★★★★ | 忘れたところを効率的に学習できる |
| Azure技術資料インデックス | ★★★★☆ | 概念や考え方を学ぶのに役立った |
| Microsoft Learn | ★★☆☆☆ | 日本語が独特すぎて頭にスッと入ってこない |
まとめ
トータルの勉強時間は51時間で、基本的にはUdemyだけで十分だと思いました。
必要に応じて、他のアプリも取り入れてみると良いと思います。
最後に、協力してくれた妻や義母に大変感謝しています。
SEが見積もりレビューを受けるときの準備
上司の見積もりレビューを受けたところ、説明の順番がバラバラでなんとも伝わっておらず、
先輩社員の方にフォローされる始末だったので、どこに気を付けるべきなのかをまとめる。
※この記事には主観が多く含まれる
新規顧客の場合
- 会社情報
- その会社の業務
既存顧客の場合
- 現在の業務
再見積もりの場合
- 前回との変更点
共通
- システム化する範囲 ※再見積もりの場合はカットしてもよい
- 見積もりの根拠
- 確認したいこと
質問の想定
いじわるな質問*1を特に想定しておく
準備の仕方
上記はレビュー当日に考えず、もっと前の日に考えておく。
１日寝かして、もっとよい伝え方がないか見直す。
もっとよい伝え方とはネガティブなワードを使っていないか、ポジティブなワードに変換できないかという観点。
まとめ
説明するのが苦手な人は、説明の時間を短くする。
質問の時間を多くする。
意地悪な質問が来ないように質問を想定しておく。
参考
伝える準備 著者：藤井貴彦氏
