【読書メモ】論点思考

まとめ

  • 問題を正しく解く前に、「解くべき問題」を正しく設定することが重要
  • 与えられた論点をそのまま解き始めず、「本当にこれを解くべきか」と疑い、見直す
  • 事実や事象そのものは論点ではない。目的に照らして「何を明らかにし、判断すべきか」という問いにする
  • 誰の立場で、何を実現したいかによって、論点は変わる
  • その論点を解くことで得られるインパクトを考え、取り組む優先順位を決める
  • 部下には論点を設定させるか、論点を選択させる質問で仮説を含んだ問題解決力を向上させる

区分 検索の例
事象 検索からの離脱率が高い
論点(オープンな論点) 離脱を減らすために、何を改善すべきか?
論点(白黒はっきりさせる論点) 離脱を減らすために、検索速度・検索精度どちらを改善すべきか?
仮説 検索速度が遅いことが、離脱の主な原因ではないか
検証 応答時間と離脱率の関係を調べ、速度改善で離脱が減るか確かめる
打ち手 原因に応じて、インデックス最適化やキャッシュ導入などを行う

メモ

解くべき問題のことを論点と呼ぶ

1章

問題を解き始める前に、問題のように見えるものから真の問題を発見すること。解くべき問題を決めること。

問題解決力が優れていても、間違った問題を解いていたら何にもならない。解くべき問題を間違えると、いくら優れた答えを出したところで、ビジネスには何の役にも立たないし、不利益を被ることさえある。

与えられた問題は正しいとは限らない。

与えられた問題をそのまま解いても、正解にはつながらない可能性がある。 大して成果が上がらない可能性もある。

問題を与えられた時に、本当に正しいか、つまり論点の設定は間違っていないかという視点を常に持つことにする。

上司から論点を与えられたときには、つまり何か命令を受けたときには、まず与えられた問題を疑うことから始めるべきだ。

論点思考の稚拙というのは、経験が大きく物を言う点にある。したがって、若いうちから論点、それも重要な大論点を見つけ出す訓練をしておかないと、マネジメントになった時に問題解決がうまくできない。

2章

顧客の論点や上司の論点は、疑ってかかった方が早く答えにたどり着く。

現象や観察事実を論点と間違えないことが大切だ。一般的に問題点と呼ばれるものの多くは、現象や観察事実であって、論点ではないことが多い。

何を論点にするかで打ち手が変わるということだ。

問題は人によって変わる。誰にとっての問題を解くかによって、問題は全く変わる。

論点を見つけるには、本当にそれは論点かと常に疑問を持つ。なぜを繰り返す。 なぜを繰り返して課題の真因に迫っていくことができる。

3章

筋の良し悪しを見極める判断基準は、どれぐらいのインパクトがあるかを想定する。 そういう視点で考えてみると、実は問題だと騒いでいても、解決後のインパクトがなく、実は大した論点ではないとわかることも多い。

最悪なのは、すべての論点をある程度までやるというやり方だ。

仕事でも、プライベート同様に直感を大切にした方がいいということだ。直感を重視し、後からそれを論理的に説明するように考えたり、あるいはどうやったら検証できるか考えるということがあっていい。

5章

大切なのは、最初に与えられた論点を鵜呑みにしないこと。

6章

大論点を求めるという姿勢の有無によって、思考の方法は随分違ってくる。課題を何かと常に考えている人と、ただ与えられた課題の答えを探している人とでは、考え方そのものが大きく違うのだ。

優秀なビジネスパーソンは、二つ上の立場で物事を考えている。

引き出しは意図的に増やさなくてもよく、自分が気になったものに対してレ点を打っていく

【読書メモ】良い戦略、悪い戦略

まとめ

  • 決定的に重要な課題・領域を見極め、そこにリソースと行動を集中する
  • 競合の強み・弱みを理解し、自社の強みをぶつけて持続的な競争優位をつくる
  • 変化の兆候を早期に捉え、他者より先に行動する

抜粋

こちらの打つ手の効果が一気に高まるようなポイントを見極め、そこに狙いを絞り、手持ちのリソースと行動を集中すること 直面する状況の中から死活的に重要な要素を見つける。そして、企業であればそこに経営資源、すなわち人、物、金、そして行動を集中させる方法を考えることである。

良い戦略は、目標やビジョンの実現以上のことを促す。良い戦略は、直面する難局から目を逸らさず、それを乗り越えるためのアプローチを提示する。 状況が困難であるほど、行動の調和と集中を図り、問題解決や競争優位へと導くのが良い戦略である。

良い戦略には、取るべき行動の指針が既に含まれている。細かい実行手順が示されているわけではないが、やるべきことが明確になっている。 戦略とは、組織が前に進むにはどうしたらよいかを示すものである。戦略を立てるには、組織にとってよいこと、好ましいことをどうやって実現するかを考えることである。

いい戦略には論理構造がある。これをカーネルと呼ぶ。 カーネルは、診断、基本方針、行動の3つの要素で構成される。状況を診断して問題点を明らかにし、それにどう対処するかを基本方針として示す。

1章

戦略の基本は、最も弱いところにこちらの最大の強みをぶつけることである。別の言い方をするなら、最も効果の上がりそうなところに最強の武器を投じることである。

良い戦略におのずと備わっている卓越した価値の第一は、新たな強みを生み出すことである。 良い戦略に必要なのは、様々な要求にNoといえるリーダーである。戦略を立てる時には、何をするかと同じくらい、何をしないかが重要なのである。

2章

相手がこちらより弱いところに、こちらの強いところをぶつけるのが戦略の定石とされる。 相手が持っていないもの、気づいていないものをどうやって見抜くか、そしてこちらの強みをどこに言い出し、どう活用するか。その強みは私たちの視界の外れの方に存在し、かすかにきらめくだけで、よほど注意を集中しないと見えてこない。

戦略を考えるときは、常に競争を考慮しなければならないことを学ぶのである。 自社の強みと弱みを見極め、状況のチャンスとリスク、あるいは敵の弱みと強みを評価し、自社の強みを最大限に生かす。

3章

悪い戦略の4つの特徴は、空疎であること、重大な問題に取り組まないこと、目標を戦略と取り違えていること、間違った戦略目標を掲げていること。

悪い戦略とは、戦略が何も立てられていないという意味ではなく、また失敗した戦略を意味するのでもない。悪い戦略では、目標が多すぎる一方で、行動に結びつく方針が少なすぎるか全くないのである。

悪い戦略の特徴は、わかりきったことを必要以上に複雑に見せかける、中身のないことを厚化粧で覆い隠しているのである。

重大な問題を無視し、分析をしようともしなかったら、戦略を立てることなどできない。重大な問題と無関係の目標や予算は戦略とは呼べない。

頑張ることは人生において大事ではあるが、最後の一踏ん張りをひたすら要求するだけのリーダーは能がない。リーダーの仕事は、効果的に頑張れるような状況を作り出すことであり、努力する価値のある戦略を立てることである。

リーダーになるということは、誰かが自分の目標を決めてくれるポジションから、組織の目標を自分で決めるポジションに移ることを意味する。

良い戦略は、一つか二つの決定的な目標にエネルギーとリソースを集中投下し、それを達成することによって、次々と新しい展開へとつなげていく。これに対して、悪い戦略では、いろいろなことを詰め込みすぎて、ごった煮状態の目標が掲げられていることが多い。

4章

選ぶという困難な作業を避け、どの意見も捨てず、誰の体面も傷つけないようにしていたら、良い戦略は生まれない。

的を絞り込んだ戦略では、明確な目標にリソースを集中させる。そのためには、戦略目標以外からリソースを引き上げて、戦略目標に回さなければならない。これは選択と集中の必然的な結果である。

戦略策定の第一歩は、持続的な競争優位となる何かを見つけ出すこと。言い換えれば、どうすれば勝てるかを見極めることだ。

成功すると考えたら成功する。逆に失敗すると考えたら、失敗することになる。成功するためには、失敗という観念を完全に排除しなければならない。成功するためには、幸福のことだけを考えていなければならない。そうすれば、前向きになり、不安や憂鬱は消し去られる。

5章

戦略を立てるときは、診断、基本方針、行動からなる。

診断について、戦略を立てる作業の多くは、何が起きているのかを洗い出すことにある。 事実を客観的に観察して問題点を把握しておかないと、現実的な戦略を立てることはできない。

いい基本方針は、難局に立ち向かう方法を固め、他の選択肢を排除するのが基本方針である。 よい戦略とは、何をやるかを示すだけではなく、なぜやるのか、どうやるのかを示すものであるべきだ。 重要なのは、既往方針を定めることによって、無数にあった手段の中から方針に沿った行動を選び、一貫性をもって取り組めるようになることである。

行動の必要性こそが、戦略をより的確に、より明確にするのである。 戦略が単なる願望にとどまっている限りにおいて、組織内の価値観の対立は容認される。

だが、行動しなければならない時には、苦渋の選択をしなければならない。 そして、戦略で最も重要なのはそこである。 戦略の極意は、本当に重要な問題を見極め、そこにリソースや行動を集中することにある。何かに集中すれば、それ以外を捨てることになるからだ。

戦略は、結局のところ、コーディネートされた行動があるシステムに強制されるという形で具現化するのである。

6章

最も効き目のあるところに力を集中することが、戦略的テコ入れの要諦である。

顧客の反応よりさらに重要なのは、競争相手や敵の反応を予測することである。

ニーズは高まっているのに、それに応える製品やサービスが提供されていないとすれば、それは一つの不均衡である。

集中が大きな見返りをもたらすもう一つの理由は、閾値効果が現れるからである。

閾値効果とは、あるレベルを超えるまではほとんど変化が現れないが、そのレベルを超えれば一気に大きな変化が現れることを指す。 このようなケースでは、ターゲットを慎重に選び、手持ちのエネルギーやリソースを集中することが望ましい。

7章

リーダーが戦略実行に使える強力な手段の一つは、近い目標を定めることである。近い目標とは、手の届く距離にあって十分に実現可能な目標を意味する。 高い目標であってよいが、達成不可能ではいけない。

最後の責任は自分が取るというだけではなく、近い目標を設定してチームが動けるようにすることがリーダーの大切な使命である。

自分のコマの動く選択肢を増やして、相手のコマの動く範囲を狭めるという目的がある。

あることだけに集中する。すなわち、最重要課題に優先的に取り組むためには、他の重要なことがクリアできていなければならない。 近い目標とは、はしごを上るようなものと考えることができる。最初の段にしっかり足をかけなければ、次の段に上がることはできない。

8章

どこかに弱い環がある場合、いくら他の環を強化しても鎖全体は強くはならない。

どこかに劣るところ、弱いところがあったら、全体がダメになってしまう。

まずはボトルネックを見つける。 そして、短期的な損失は覚悟で、将来に投資する覚悟を決める。

最終目標を掲げつつ、近い目標からクリアしていったことが成功につながったのである。

12章

どんな時、どんなところで優位に立てるのかを理解することが、それを活用する秘訣と言える。 こちらが優位なところでは存分に力を発揮し、そうでないところは巧みに回避する。 さらに、ライバルの弱みを突き、こちらの弱みは握られないよう注意する。

競争相手より低いコストで生産できるとき、競争相手より高い価値を提供できるとき、あるいはその両方ができるとき、競争優位があるという。

競争相手に容易に真似されないこと、模範困難性が条件になる。より正確に言えば、優位性を生み出すリソースを真似されないことが重要だ。

価値を高めるために重要なのは、コモディティ化しないようにすることだ。

ビジネスの世界では、競争優位の必要性が声高に叫ばれているが、競争優位を持っているだけでは、 高収益に直結するとは期待できない。 つまり、競争優位と富の関係は固定的ではなく、変動する。

希少なリソースを持つ場合には、それに対する需要をうまく高めることこそ、戦略の基本といえよう。

13章

変化のうねりが過ぎてしまうと、その影響は誰の目にもはっきりするが、変化を生かすにせよ、影響を免れるにせよ、その時ではもう遅すぎる。 したがって、変化のうねりが形成される早い段階で、気づいて手を打たなければならない。 大事なのは、予測することではなく、過去と現在に目を凝らすことである。

14章

ライバルの慣性を理解していくことは、自社の強みを理解するのと同じくらい重要である。

旧来の慣行が染みついている人や、変化に抵抗する人には退場してもらわなければならない。 それと並行して、新しい流れに沿って組織を再編することが必要になる。

17章

戦略的になるということは、近視眼的な見方をなくすということである。 逆に言えば、ライバルより広い視野を持つことである。同業者や競争相手が何をしているか、何をしていないか、常に認識していなければならない。

ある分野で戦略を立てるには、その分野について十分な知識を持っていなければならない。 これに関しては、現場の実地経験に勝るものはないと言えよう。 経験を積むと、この状況ではこれがうまくいくとか、この状況ではこういうことが起こりうるといった判断がつくようになる。 寒気がしたら風邪薬を飲むように、多くの人がパターンに従って行動している。

18章

どうしたらいいかわからないとき、他の人のやり方をまねたことは誰にでもあるだろう。 だが、全員がそれをしたら、誰もがまったく根拠のない行動をとることになる。 本当のことは誰かが知っているとみんなが考えているが、実際には誰も知らない。

群れの圧力は、みんなが大丈夫だと言っているのだから絶対大丈夫なのだと考えることを強要する。 内部者の視点は、自分たち、自分の会社、自分の国、自分の時代は特別なのだから、他の時代や他の国の教訓は当てはまらないと考えることを強要する。 こうした圧力は断固はねのければならない。現実を蓄積し、群れの大合唱を否定するデータに目を向ければ、また歴史や他国の教訓から学べば、それは十分に可能である。

【読書メモ】イシューから始めよ

【前提】バリューのある仕事とは

生産性はどれだけのインプットでアウトプットを生み出せたかを示している。 具体的には以下の式の値が大きければ生産性が高いと言える。

筆者は生産性が高い仕事はバリューのある仕事と定義しており、その中身はイシュー度と解の質が高い仕事

イシュー度

自分の置かれた局面でこの問題に答えを出す必要性の高さ

解の質

そのイシューに対してどこまで明確に答えを出せているかの度合い

どれだけ解の質を高めても、イシュー度の低い仕事は価値がゼロに等しいため。

生産性の高め方

イシュー度の高い仕事からはじめ、解の質を上げていくこと これを繰り返していくうちに解の質が高まっていき右上に近づいていく

アンチパターンは逆のアプローチで解の質から高めること(犬の道)。いわゆる努力と根性でがんばっても疲弊していくだけのため。

イシューを見極めること

まず何に答えを出す必要があるのかを考える必要がある。そのためイシューの見極めから始める。

仮説を立てる

仮説である「xxxはxxxではないか」と問いを立てることで答えを出すことができ、その仮説が正しいかどうかの検証ができる。

イシューにするポイント

  • 主語と動詞を入れることで曖昧さが仮説の精度が高まる
  • WhyよりWhere,What,Howにすると答えを出す必要がある問いになる

よいイシューの条件

  • 本質的な選択肢である
    答えがでるとそこから先の方向性に大きく影響を与えること。つまりその答えによって方針・優先順位・行動が変わるため。

  • 深い仮説がある
    検証方法が具体化し、そのイシューに答えを出せるかどうかも見極めやすくなるため。

  • 答えを出せる
    現実的に検証でき、答えを出せる問いでなければ、解くことができないため。

イシューを特定するために

  • 一次情報に触れる
    現場の情報は誰の手でも加工されていない切り取られていない情報のため。

  • 基本情報をスキャンする
    数字、問題意識(前提)、フレームワーク(構造)を把握し課題の知識を抑えるため。

  • 集め過ぎない・知りすぎない
    情報を集めすぎると使える情報が頭打ちになりそれ以上の知恵がでなくなるため。

イシューの解き方

イシューを見極めた後は解の質を高める必要がある。 そのために必要な作業が以下の2つがありこれをイシュー分析と呼ぶ。

  • ストーリーラインづくり
  • 絵コンテづくり

ストーリーラインづくり

これは、イシューとそれに対する仮説が正しい場合、どんな論理と分析によって検証できるかを前倒しで考える作業。 最終的な結論から逆に考えることで答えに直結する作業に絞ることができる。

そのためには以下が必要になる。

  • イシューの分解
  • 分解したイシューに基づいてストーリーラインを組み立てる

イシューの分解

いきなり大きなイシューに答えを出すのは難しいため、答えを出せるサイズまで分解する。

イシューを分解することで以下の効果がある

  • 課題の全体像が見えやすくなり、何をどこまで検討すべきかが把握できる
  • サブイシューのうち、優先順位の高いものが見えやすくなり、解くべきイシューの順番が分かる

分解の基本はMECEに行うこと。MECEに分解することで、検討漏れや重複を防ぎ、元のイシューに答えるために必要な論点を整理できる。 ただし、最初からMECEに分解するのが難しい場合は、「最後にどんな判断・結論がほしいのか」から逆算し、その結論を出すために必要な論点に分解する。

分解したイシューに基づいてストーリーラインを組み立てる

イシューを分解するだけでは相手を納得させることはできない。 そのため、論理展開となるストーリーが必要になる。どういう順番、流れで話をすれば相手が納得してもらえるかを考える。 このとき、分析や検証が完了していない状態で、仮説がすべて正しいとすればという前提で作る。そのストーリーを成立させるために必要な分析だけをすればいいため。

ストーリーラインの型

以下2つの型があるが、どちらも結論を支えるピラミッド構造にして構造化して伝える。

  1. WHYの並び立て
    最終的なメッセージについて、理由を並列に立てる。 この際、論点がMECTになるようにすることで評価者からの攻撃に備える。

  2. 空・雨・傘
    事象、問題、対応によりストーリーを伝える。 雨でどらだけ問題の深堀り(イシューの特定)ができているかが勝負になる。

絵コンテづくり

絵コンテとは具体的なデータのイメージをビジュアルとして組み合わせることを指す。 どんなデータが取れそうかではなく、どんな分析結果がほしいのかを起点にイメージを作る。 イシューから始めるの考えで、「どんなデータがあればストリーラインの個々の仮説=サブイシューを検証できるのか」という視点でデザインする。

以下3つのステップで押さえる。

  • 1)軸の整理
    分析は比較のため、比較の軸を決める必要がある。比較の表現方法は比較、構成、変化から決める。 軸は基本的に結果と原因の軸で考える。

  • 2) イメージの具体化
    イメージには数値を入れることで客観的な比較結果が分かるようにする。 またその数値から意味合いを加えることで、最終的に欲しい結果を表現する。 典型的なパターンは、差がある、変化がある、パターンがあるの3つ。

  • 3) 方法の明示
    説明するためのデータを取るための方法をがなければ、これまでの仮説を立証するストーリーラインや絵コンテの根拠がなくなってしまうため。

アウトプットドリブン

ここからは実際に分析やチャートをまとめていく工程となる。

注意点として、いきなり手を付けるのではなく、最も影響を持つ部分から取り掛かる。 これが覆るとこれまでのストリーラインや絵コンテづくりが無駄になってしまうため。

またイシューに対してはフェアに検証する。 イシューを正当化するためだけの検証のような、結果ありきの考えになると本当にほしい分析ができなくなるため。

実際に進めていく中で重視することは以下

  • トラブルをさばく
  • 軽快に答えを出す

トラブルをさばく

  • 欲しい数字や証明がでない
    もし当初の想定から外れてしまった場合、構造化した推定により、欲しい結果を出すためにはどんな構造・組み合わせが必要かを考える。 また自分の足で規模感を把握することや、複数のアプローチから数値を出すなど別の視点から推定する。

  • 自分の知識や技では埒が明かない
    自分だけで進められなくなった場合は他力を活用する。 またもしそれでも解決の目処が立たないならその手法に見切りをつけ、別のアプローチを考える。

軽快に答えを出す

  • いくつもの手法を持つ
    自分の手札や手法の豊かさがバリューを出す人の資質に関わる。 なるべく広い分野の経験やスキルを持っておく。

  • 回転率とスピードを重視する
    丁寧にやりすぎても完成度は高めにくくなる。 それよりも完成度よりも取り組む回数(回転数)を大切にする。 答えを出すためにはエレガントさよりもスピードを重視する。

メッセージドリブン

これまでやってきたことをアプトプットを通じて受け手に以下の状態になってもらうように成果物をまとめる。

  • 意味のある課題を扱っていることを理解してもらう
  • 最終的なメッセージを理解してもらう
  • メッセージに納得して、行動に移してもらう

このとき、聞き手は完全に無知であり、高度の知性を持つと想定する。 つまり的確な伝え方をすれば必ず理解してくれると考える。

ストリーラインの磨き込み

  • 論理構造を確認する
    WHYの並び立てのピラミッド型か空・雨・傘に沿っているかを確認する。

  • 流れを磨く
    紙芝居方式の荒磨きや実際の人を想定した説明をして補強が必要なことがないかを見直す。

  • エレベーターテストに備える
    要点を抑えて説明できるレベルになっているかを確認する。 特に構造で把握することで、相手に合わせて何をどのレベルまで説明すべきかが判断できるようにする。

静的型付け言語・動的型付け言語

(会社のLT会で発表したものの転記。)

TypeScriptのメリットを紹介するつもりでしたが、型がある言語全般に言えることなので、もう少し広い意味で静的型付け言語・動的型付け言語の紹介をします。

データ型

データ型・プログラムを実行するときのデータの入れも(コンピュータのメモリの確保する量)

データ型を定義する→プロダクトの実行前に入れ物の大きさが分かる→データに対して最適なメモリ使用量で済む

データ型を定義しない→プログラム実行前に入れ物の大きさが分からない→実行するまでにどんなデータが来るか分からないため、余分にメモリを確保する必要がある

※メモリ=一時的にデータを記憶する場所、作業机のイメージ

机のスペースが広い=メモリの使用量が少ない→実行速度が速い
机のスペースが狭い=メモリの使用量が多い→実行速度が遅い

特徴

静的型付け言語

変数・関数にデータ型の宣言が必要な言語

  • メリット
    • データ型に関するエラーが事前に分かる
    • 実行速度が速い
  • メリット
    • コードの記述量が多い
    • 開発スピードが遅い

言語

動的型付け言語

変数・関数にデータ型の宣言が不要な言語

  • メリット
    • コードの記述量が多い
    • 開発スピードが遅い
  • メリット
    • データ型に関するエラーはプログラムを実行しないと分からない
    • 実行速度が遅い

言語

利用ケース(個人的な意見)

静的型付け言語が向いているケース

  • 大規模・大人数
  • スケールする可能性が高いサービス(自社サービス)
  • 安全性・パフォーマンス重視(金融・ゲーム)

動的型付け言語が向いているケース

  • 小規模・小人数
  • スケールする可能性が低いサービス(受託など)
  • 開発スピード重視(スタートアップ)

所感

最初に開発した言語がJavaだったり、今はC#を使っていることもあり静的型付け言語の方が贔屓目な書き方になってしまった。

ただ世間的にも最近JavaScript→TypeScript、Ruby→Goに移行している事例を割と見るので、型があるほうが安心して開発できると感じる。

参考

フロントエンドエンジニアのロードマップ(2021)読解

はじめに

結論から書くと、今後はフロントエンドに注力していこうと思います。

現状フロントエンド・バックエンド両方担当していますが、下記理由からフロントエンドに注力しロードマップを参考に学んでいこうと思います。

なぜフロントエンド?

会社で受講したWebのセキュリティ研修がきっかけです。
IPAのAppGoatとFlatt SecurityのKENROを受講しましたが、似たような内容でもKENROの方が使いやすかったです。(IPAさんごめんなさい)

どうして使いやすかったのかはうまく説明できませんが、色を使いすぎていない、スペースが適度に空いているなどデザインの面が良かったからだとは考えています。

もともとユーザーも自分も使いやすいと思えるサービスを開発したいと考えていましたが、「使いやすい」の定義が曖昧でした。

ただ2つのサービスを使ってみた経験から、使いやすさは目に見える画面に影響されることが多いと考えたため、目に見える部分を担当するフロントエンドを専門にしたいと思うようになりました。(レスポンスが遅い、すぐエラーになるなど正常に動作することはクリアしている前提の話ですが)

デザイナーでもよくない?

画面を担当するのであればデザイナーでもよくないかと思いましたが、過去にデザイン系の案件を担当してデザインを考えているときよりもコードを考えてたり、書くことの方が好きなためエンジニアとして働きたいと思っています。

過去に担当した案件から、デザインは客観的に説明することが難しい(主観的になってしまう)ことが多いイメージです。色のコントラスト比や黄金比など数値にできるものならまだしも、レイアウトやUIの使いやすさは個人の感覚に左右されることが多く、自分が納得してデザインを決めることができませんでした。(私が知らないだけで、そういったものの理論ややり方もあるかもしれませんが)

デザインに対し、プログラムは客観的に説明できることが多く、自分も納得感を持って仕事ができていました。(同じ処理は繰り返し処理にしてコード量を減らす、複数箇所から参照される値は変数・定数にして改修時に直す箇所を少なくするなど)

なぜロードマップ?

フロントエンドを専門にしていくにあたり、何を学べがいいか分からないため、全体像を知ることができるものを探していました。

今回参考にするのはroadmap.shのFrontendDeveloperのロードマップです。Zennなど技術系サイトに掲載されたり、テック系のYouTuberが紹介していました。

何を学ぶ必要があるかを知るためにロードマップを読解し、その中から今後学んでいく領域について書いていこうと思います。

ロードマップ

FrontendDeveloper roadmap

画像の中心の1本の線でつながっているブロックごとにどういった内容か書いていきます。

マークの意味

画像左上のマークの意味です、上にあるものほどおすすめな選択肢になっています。

  1. Personal Recommendation / Opinion
    おすすめな選択肢

  2. Alternative Option - Pick this or purple
    代わりの選択肢、選ぶならこれか上記のもの

  3. Order in roadmap not strict(Learn anytime)
    いつでも学んでいい、順番は守らなくていいもの

  4. I wouldn't recommend
    非推奨、やらなくてもいい

項目

項目内のトピックについて箇条書きしていきます。太字は優先度が高い選択肢です。(マークの意味の上から2項目の選択肢)

Internet

インターネット、HTTP、ブラウザなどそもそもの基礎となる技術。
フロントエンドはパフォーマンス向上のために特にブラウザの知識は持っておく必要がありそう。

  • How does the internet work?
  • What is HTTP?
  • Browers and they work?
  • DNS and how it works?
  • What is Domain Name?
  • What is hosting?

HTML

HTMLの基礎、フォーム・バリデーション、ベストプラクティス 。
基本的には書けるけど、何が良い書き方なのかは知っておいた方がよさそう。

  • Learn the basics
  • Writing Semantic HTML
  • Forms and Validations
  • Conventions and Best Practices

Semanctic HTMLは要素に目的・役割を持たせること。検索エンジンがページの検索のランキングを上げる、目の不自由なユーザー向けの読み上げソフトのページ移動を補助するなどの利点がある。

CSS

CSSの基礎、FloatsやFlexなどのレイアウト、端末ごとによって表示が異なるレスポンシブデザイン。

  • Accesibility
  • SEO Basics
  • Learn th basics
  • Making Layouts
  • Responsive design and Media Queries

Accesibilityはフォントサイズを上げる、行間を空けるなど、ユーザーがより快適になるようにデザインすること。

SEO検索エンジンで自社のページが検索時に上位表示されるように最適化する戦略。toC向けのサービスはこの知識も求められそう。(toB向けサービスでも広告記事は同様に必要かも?)

JavaScript

JavaScript基礎、DOM操作、非同期通信、ES6・JavaScriptモジュール、バブリングやスコープなど概念。

  • Syntax and Basic Constructs
  • Learn DOM Manipulation
  • Learn Fetch API / Ajax(XHR)
  • ES6 + and modular JavaScript
  • Understand the concepts Hosting, Event Bubbling, Scope, Prototype, Shadow DOM, strict

普段ES5で書いているので、ES6は改めて学ぶ必要がありそう。バブリングやスコープなどJavaScript固有の概念も理解しておく。

Version Control Systems

バージョン管理システム、Gitの基本操作。

  • Basic Usage of Git

Repo hosting services

GitのWebサービスにあたるもの。GitHubを覚えればOK。(BitBucketを使ったことあるけど、UIが違うだけでほぼ同じだったので、GitHubだけでよさそう)

Web Security Knowlwdge

最低限覚えておくセキュリティの知識。

  • HTTPS
  • Contents Security Policy
  • CORS
  • OWASP Security Risks

Package Manager

主にJavaScriptで開発されたモジュールを管理するためのシステム。
手動でそれらモジュールの設定ファイルや更新を行うのは手間が掛かるため、簡単なコマンド入力でそれらの作業ができるようになる。
- npm - yarn

CSS Architecture

  • BEM
  • OOCSS
  • SMACSS

モダンなフレームワークCSS-in-JSがある場合は、CSS設計は優先度は低い。
ただBEMには精通していることは推奨。

CSS Preprocessors

  • Sass
  • PostCSS
  • Less

CSS設計と同じくフレームワークCSS-in-JSが主流になっているので、こちらも優先度は低い。
ただ余力があれば知識を付けておくとよい。

Build Tools

Task Runner

ファイルの更新を監視しコンパイルするなどのタスクを自動化してくれるツール。

  • npm scripts
  • Gulp

Linters and Formatters

  • Prettier
  • ESLint
  • StandardJS

静的解析ツール、コードを整形してくれたり、策定したルールに沿っていない箇所を教えてくれたりするもの。

Module Bundlers

  • Webpack
  • Rollup
  • Parcel

複数のファイル(モジュール)を1つの最適化されたファイルにバンドル(まとめる)するツール。

Pick a Framework

フロントエンド開発のフレームワークと状態管理ライブラリ

  • React.js
    • Reduc
    • MobX
  • Angular
    • RxJS
    • NgRx
  • Vue.js
    • Vux

Modern CSS

CSS in JSと呼ばれるJavaScript内にスタイルを記述することで、スタイルをコンポーネント単位に指定する技術

  • Styled Components
  • CSS Modules
  • Styled JSX
  • Emotion
  • Radium
  • Glamorous

Web Components

再利用なカスタム要素で、他のコードから独立してカプセル化する機能を持つ

  • HTML Templates
  • Custom Elements
  • Shadow DOM

CSS Frameworks

JS based

JavaScriptフレームワークと共に利用することが推奨とされているもの

  • Reactstrap
  • Material UI
  • Tailwind CSS
  • Chakra UI

CSS first

デフォルトでJavaScriptコンポーネントが付属していないCSSファーストなもの

  • Bootstrap
  • Materialize CSS
  • Bulma

Testing your Apps

単体、結合、機能テストの違いとツールを使ってそれらを作成する方法を学ぶ

  • Jest
  • react-testing-library
  • Cypress
  • Enzyme

Type Checkers

静的型チェッカー、実行前に型が正しく定義されているか検証する

  • TypeScript
  • Flow

Progressive Web Apps

先進的なWebアプリで使われる様々なWebAPIを学ぶ。

  • Storage
  • Web Sockets
  • Service Workers
  • Location
  • Notifications
  • Device Orientation
  • Payments
  • Credentials

パフォーマンスの計算、測定、改善をする

  • PRPL Pattern
  • RAIL Model
  • Performance Metrics
  • Using Lighthouse
  • Using Dev Tools

Server Side Rendering(SSR)

サーバーサイドでレンダリング(HTMLを生成)し、ブラウザはレンダリングされたファイルを表示する。Node.jsの実行サーバーが必要、サーバー側の負荷が増加するが、SPAよりも表示速度が速い。

  • React.js
    • Next.js
    • After.js
  • Angular
    • Universal
  • Vue.js
    • Nust.js

GraphQL

API向けに作られたクエリ言語及びランタイム。クライアントが必要なデータ構造を定義することで、サーバーから必要以上のデータを返されることを防止でき効率がよいとされる。

Static Site Generators

静的サイトジェネレータ、WebサイトのHTMLファイルを生成するツール。
CMSと異なり、すべてのHTMLファイルを作成するため、レスポンスが速い・サーバー代が掛からないなどのメリットがある。

  • Next.js
  • GatsbyJS
  • Nuxt.js
  • Vuepress
  • Jekyll
  • Hugo

Mobile Application

モバイルアプリ、iOSAndroid両方を開発できるクロスプラットフォームフレームワークが推奨。

  • React Native
  • NativeScript
  • Flutter
  • Ionic

Desktop Applications

VSCodeやslackなどPCにインストールして利用するアプリ

  • Electron
  • Carlo
  • Proton Native

Web Assembly

ブラウザ上で動作するバイナリコード。JavaScriptより高速で主要ブラウザでは対応している。2019年にW3C(Webの標準化団体)は公式水準として受け入れている。

これから学ぶ領域

まずはTypeScriptとSPAを勉強しようと思います。上記2点が、現在フロントエンドエンジニアでの必須要件になっている求人が多いためです。

このこと自体は初めから求人だけ見れば良かったかもしれません。 ただロードマップを読解したことで何を学ぶべきかの全体像を把握することができました。ロードマップを参考に今自分が勉強している場所を確認しながら、今後も学習を進めていきたいと思います。

参考

【C#/NUnit/Moq】単体テストについて

背景

業務で利用しているNUnit・Moqを学習するにあたり、そもそも単体テストについての知識がないので単体テストの目的、手法、ライブラリの使い方などついて自分用にまとめます。

なお、単体テストは自動化されたテストを前提に記載しています。分類としての単体テストでは自動テストを必ずしも意味していないため。(手動の単体テストはマイナーだと思いますが)

単体テスト

比較的小さなプログラムのテスト。テスト対象は主にクラスやメソッドなどテスト可能な最小単位な部品(ユニット)。

メリット

  • バグの早期発見
    単体テストはコードの開発直後にテストするため、バグがあった場合にすぐに発見できる。
    またテスト対象の粒度が小さいため、問題があった箇所を特定しやすい。

  • 品質の維持
    リファクタリングや影響箇所の修正などで既存コードを改修した際に、テストコードがあれば改修による問題を発見・修正しやすくなるため品質を維持しやすい。

デメリット

  • 開発者の工数増加
    単体テストはテストコードだけではなく、テストコードを呼び出すドライバやテストコードから呼び出されるスタブなどの準備が必要となる。
    開発者は稼働するコード以外にも開発する必要があるため、開発工数が増加してしまう。

  • 後回しにされやすい
    開発者の負担増加によるスケジュールの関係で、網羅的ではなく簡易的なテストだけで済まされてしまう場合がある。またテストコードのメンテナンス漏れやテスト実行されなくなってしまう可能性もある。

他のテスト

単体テスト以外にも以下のテストがある。

  • 結合テスト
    単体テストの次に行うテストで複数のプログラムを組み合わせて正常に動作するか確認するテスト。
    部品ごとの動作を確認する単体テストは完了しているため、主にデータの受け渡しや流れを確認する。

  • システムテスト
    結合テストの次に行うテストで、ユーザーが使用する環境を想定して確認するテスト。
    1つの機能を確認する結合テストは完了しているため、外部のシステムや他の機能に影響がないかシステム全体を確認する。

単体テストの手法

ホワイトボックステスト

プログラムの内部構造(関数や条件分岐など)に関するテストで、テスト対象のソースコードが正常に動作するか確認するテスト。

網羅手法

  • 命令網羅
    全ての処理を最低1回でも通す。

  • 分岐網羅
    全ての分岐の処理を通す。(分岐先に注目したテスト)

  • 条件網羅
    全ての分岐条件の真/偽条件の場合の処理を通す。(分岐条件に注目したテスト)

ブラックボックステスト

プログラムの内部構造は意識せず、入力に対して期待される結果が仕様通りか確認するテスト。

分割法

  • 同値分割法
    有効な値、無効な値を入力して想定となる結果になるか。

  • 境界値分割法
    有効な値と無効な値の境界となる値を入力して想定となる結果になるか。

NUnit/Moq

NUnit

C#Visual Basicなど.NET言語の単体テストフレームワークJava単体テストフレームワークであるJUnitから派生して開発された。

Moq

.NETのための唯一のモックライブラリ、予め作成しておいたインターフェースに対して、テストする際の振る舞いを設定することができる。

以下Microsoftチュートリアルや業務でよく見かけるキーワードについて記載。

属性

テスト用のクラスやメソッドなどに付与する属性

  • Test
    TestFixtureクラス内のメソッドをテストとしてマーキングする。パラメーターを利用しない単純なテストに使われることが多い。

  • TestFixture
    テストとオプションでsetup, teardownメソッドを含むクラスをマーキングする。

  • Setup
    TestFixtureの内側で使われ、各Testメソッドの前に実行される共通処理を書くことが出来る。

  • TearDown
    TestFixtureの内側で使われ、各Testメソッドの後に実行される共通処理を書くことが出来る。

  • Ignore
    何らかの理由でテストを実行すべきではないときに、TestFixtureTestの属性に加えることで、付与したテストを無視できる。

  • TestCase
    テストメソッドにパラメータを渡し、渡したデータでテストが実行される。

アサーション

テスト結果を判定するための機能、テスト結果によって成功・失敗と判定される。

  • Assert.AreEqual
    2つの引数が同一か判定する

  • Assert.NotEqual
    2つの値が異なるか判定する

  • Assert.Throws
    特定の例外がthrowされることを確認する

  • Assert.DoesNotThrow
    特定の例外がthrowされないことを確認する

  • Assert.Fail
    失敗を生成する、またプロジェクトに合わせて失敗時のメッセージやパラメーターを設定できる。

モック

データベースアクセスやネットワーク通信など外部通信が行われるテストにおいて、テスト用の結果を返す代わりのオブジェクト。

注意点
事前にテストするクラス・メソッドのインターフェースを定義する必要がある。また本物のクラスもそのインターフェースを実装する。

  • Setup
    特定のメソッドが呼ばれた際の戻り値や例外などの指定ができる。 このメソッドでテスト時のオブジェクトの振る舞いを決定する。

検証用アプリ

参考

【JavaScript】call・apply

  • 関数のthisを置き換える
    call・apply共に関数を呼び出し、呼び出した関数のthisを第1引数に指定したオブジェクトに置き換える。
var func  = function(){
    console.log(this);
}

func();
func.call({hoge: 1});
func.apply({hoge: 2});
//出力
//func()はwindowオブジェクトが出力される(長すぎるため省略)
{
  hoge: 1
}
{
  hoge: 2
}

違い

  • 第2引数の値
    callは第2引数以降に値を複数受け取る。applyは第2引数に1つの配列を受け取る。
var func  = function(a1, a2){
    console.log(this);
    console.log(a1);
    console.log(a2);
}

func.call({hoge: 1}, "c1", "c2");
func.apply({hoge: 2}, ["a1", "a2"]);
//出力
{
  hoge: 1
}
"c1"
"c2"
{
  hoge: 2
}
"a1"
"a2"

使用例

  • なりすまし
    callやapplyを利用すると本来は利用できない機能が、利用可能なオブジェクトになりすまして利用できるようになる。
<ul>
  <li>1</li>
  <li>2</li>
  <li>3</li>
  <li>4</li>
  <li>5</li>
  <li>6</li>
  <li>7</li>
  <li>8</li>
  <li>9</li>
  <li>10</li>
</ul>   
var liText1 = ( document.querySelectorAll( "li" ) ).map( function (e) {
    return e.textContent;
});
console.log(liText1)


var liText2 = Array.prototype.map.call( document.querySelectorAll( "li" ), function (e) {
  return e.textContent;
});
console.log(liText2)
//liText1 はmap()を持っていないため実行できずエラー
Uncaught TypeError: document.querySelectorAll(...).map is not a function

//liText2 はmap()を持っているArrayオブジェクトになりすますことで実行できる
["1", "2", "3", "4", "5", "6", "7", "8", "9", "10"]

参考