00:06
7月17日、日曜日です。
今日は17分です。
今日は、朝寝坊してしまいました。
おはようございます。ひめみのきーすかとくわはらです。
本日も遅れましたが、朝活を始めていきたいと思います。
今回は17分なので、今から30分、45分過ぎまでやっていこうと思います。
今日は、先日、昨日宣告した通りですが、
タイトルがあると、ソフトウェア・エンジニアリング・ザ・ソフトパーツという記事を読んでいきたいなと思います。
今日は長い記事ですので、2日、ないし3日は渡るかもしれませんが、ゆるーく読んでいこうかなと思っております。
タイトルの通り、今回はソフトスキルについて注目をしている記事を読んでいこうかなと思っています。
ソフトスキルは僕は大好きなテーマなので、1回読んでいこうかなと思います。
タイトルのある通り、ソフトエンジニアリング・ザ・ソフトパーツというのを読んでいこうかなと思っております。
ご参加ありがとうございます。では読んでいきましょう。
今日はGoogle Chromeでシニアスタッフ・エンジニアリング・マネージャーを務めてから10年間私が学んだソフトエンジニアリングのソフトスキルについてご紹介をしようと思います。
10周年を記念して私の心に残っている教訓を振り返ってみたいと思います。皆さんのキャリアに役立つことを願っております。
良いエンジニアになるためには、経験を積み重ねること。
たとえ小さなプロジェクトであっても、一つ一つが新しい技術や道具を自分の道具箱に加えるチャンスなのです。
そしてあるプロジェクトで学んだ技術と別のプロジェクトで学んだ通路を組み合わせて問題を解決することができれば、さらに大きな価値が生まれます。
その積み重ねなんですと言っています。
時間が長くなりましたけど、私は重要でなく賢明でなく独創的でもないと言っておきます。
じゃなければGoogleでずっと働くことはきついんじゃないかなと思いますけど。
早速読んでいくんですけど、テーブルオブコンテンツがあるんですが、テーブルオブコンテンツを見ただけでもめちゃくちゃ長いので、
今回の記事はさすがに、今日1日は全然読み切れる気はしないなというので、やはり多分3日になるかなと思います。
で、いきます。
ラーニングニュースインです。新しいことを学ぶところですけど。
ソフトウェア工学のパラダイムにおける標準的なプロセスに従って、新しいベストプラクティスを発見しながら、
多くのジュニアまたミドルキャリアの開発者が前進し、変化する技術に対処し複雑なシステムを構築するには、
03:01
以下のポイントが役立つはずですと。
できる限り第一原理を適用する問題より小さく、断片的なものに分解する。
ということが人生において最も重要なスキルの一つだよというふうに言ってますね。
マスタリーですね。
年間を身につけるってことでしょ。
技術的熟練度とは、労働時間に対する出荷額の割合が高いことを意味します。
労働時間に対する出荷額、出荷額と言いますが、単語的には、要はどういうバリューですかね。
対価を生み出したかというところですね。
の割合が高いことを意味します。費用対効果に近い感じかな。
というのが技術的熟練度ってところを意味するそうですね。
つまり、付加価値のある仕事を見極め、チームがその方向にエネルギーを集中できるようにすることができるんです。
また、チームや会社に価値をもたらさない仕事を避ける方法を知っていることも意味します。
最高のエンジニアはチーム全体を有益していない仕事から遠ざけることさえできるのです。
よく自分の時間を有効に使っているかどうか、どうすれば分かりますかと聞かれます。
忙しいと感じるために時間を埋められる仕事は必ずあります。
しかし本当に大切なのは、正しいことに取り組んでいるかどうかを確認することです。
山を動かしたいのであれば、たとえ小さな動きであっても針を動かすような仕事に集中することです。
また、自分に問いかけると良いでしょう。
2つですね、問いかけがあります。
1つ目ですけど、私の目標は何ですかと。
今やっている仕事はその目標に沿ったものなのだろうかというのが1つの問いですね。
2つ目の問いとして、もっと違うやり方があるんじゃないかと。
もっとよくできるんじゃないかという問いですね。
この2つを自分に問いかけると良いでしょうと。
このような問いを自分に問いかけるだけでも非常に大きな時間になりますよというふうに言っています。
まず1つ目として、マスターで何かを熟練するというところでした。
続きまして、次はTHINK CRITICALLY AND FORMULATE WELL-RESPONSED ARGUMENTSですね。
批判的に考えて、理論を生前とした理論を展開しましょうということです。
クリティカルシンキングとは、資料深い決断を下すために認知能力を駆使して、主体的に考える能力のことです。
このスキルに投資して思考の明確さを向上させましょうと。
エンジニアとして私たちは特に問題をすぐに解決しようと急ぐあまり、
それがあたかも前進しているように、あるいはステークホルダーに応えているように見えることがあります。
しかし原因や結果を十分に検討しないと、かえってリスクを招くことがあります。
クリティカルシンキングとは目的を持って考え、自分なりの結論を導き出すことです。
06:01
この目的思考は、原因と結果を念頭に置かないことから生じる将来の問題を解決するために根本的な原因に焦点を当てることができます。
これは良い支援だと思いましたね。
僕もそうなんですけど、ついついとにかく物事を早く解決するところにフォーカスを置くんですけど、
速さが問題になることもあるし、やっぱり考慮不足だったり、僕らも人間ですので間違いを犯したりする可能性もあるので、
そういうところもしっかり加味するようにクリティカルシンキングを使うというところは本当に大事だと思うので、
とにかく早ければいいというわけでもなかったりしますよね。
確かにチケットは終わっているかもしれないし、物事は進まっている可能性はありますけども、
何だかんだ後で引き起こす問題によってストップしたり、先頭返りしたりとか、時間を戻さなきゃいけなかったり、やり直しをしなきゃいけなかったり、
余計に時間がかかったりするので、結局長い目線で見たときに、今やっているタスクが本当に本質的なものなのかというところを見直すのは結構いい話かもしれないですね。
これはずっと自分に自愛を込めて言い続けたいことだと思いましたので、いいなと思いますね。
戻ります。
細かに言えば、私がクリティカルシンキングに基づいて行いたい質問は次のようなものです。
はい、めっちゃ多い。
なるほど。
1つ目ですね。
私たちが正しい問題を解決しているとどうやってわかるのでしょうか。
はい。
ほとんどこれに尽きるんじゃないですかね、クリティカルシンキングって。
はい。
我々が正しい問題を解決しているとどうやってわかるのでしょうかというとおりでした。
2つ目が、正しい方法で問題を解決していると言えるのでしょうか。
例えば、かっこ問題や制約を理解した上で、厳密さと効率性のバランスをとることですと言います。
はい。
3つ目ですね。
問題の原因がわからない場合、どのようにして根本原因を特定することができるのでしょうかと。
はい。
そうね。それは本当にそうですね。
はい。
4つ目ですね。
重要な質問をさらに分析できるような小さな質問に分解するにはどうすればよいでしょうかと。
はい。
次です。
1つまたは複数の仮説を立てたら、それを評価するためにどのような科学を構成するかというところです。
うん。
このですね。
そもそもちゃんと前提として仮説を立てたらと言っているので、
まず仮説を立てることが重要だというところも割とポイントだと思ったりしますけどね。
まあでも問題解決するには仮説は絶対必要ですからね。
はい。いきましょう。
続いて。制約。
まあ過去時間的なプレッシャー的な意味の制約ですね。
がある場合、その質問に関する分析の厳密さを過度に損なわずにどのような近道をとることができるでしょうかと言っています。
09:01
はいはいはいはい。
まあいわゆる納期がある場合ですよね。
はい。
分析と厳密さを過度に損なわずにかつどのような近道をとることができるかというところですね。
いやこれは悩ましい問いであるし、まあそれができれば問題はより早く解決できるんでしょうけど。
難しいところだなと思いますねこれは。
けど追っていくのがまあ多分良いソフトエンジニアなんでしょうね。
はい。続いて。
結論は証拠によって十分に売れかけられていますかというところですね。
はい。
これはもうそのままですね。しっかり証跡とか裏付けをとっていきましょうとかですね。
はい。続いて。
どのようにして完了を知ることができるか解決策が十分であるのはいつなんでしょうかと言ってますね。
はい。
いわゆる断の定義って言われるもんですね。
えー。
まあよくある開発者がもう断これで終わったよって言ってますけど、
実際ステークホルダーとかお客さんからするといやいや終わってないじゃんとかこれ解決してないじゃんみたいなところがあったりするので、
本当に十分に解決したっていうふうに言えるのはいつなのかっていうのをちゃんとしっかり合意を取ったり認識をしたりとかしていくのがいいと思います。
自分の中で終わったって思うんじゃなくて本当に第三者が見ても終わったというふうに分かったところでチケットをクローズさせるのがよいのかなと思ったりしてますね。
はい。
続いて。
すべてのステークホルダーに対して解決策を明晰かつ論理的に伝えるにはどうすればよいでしょうかと言ってますね。
はい。
いやーこれもまた難しい問いだな。
僕らやっぱり技術者、特にクリエイター全体ですね。
多分デザイナーさんもそうだと思いますけど。
クリエイターはすべてのステークホルダーに対して自分たちの行った仕事、つまり解決策。
明確にかつ論理的に伝えるにはどうすればいいかってところはずっと問い続けないといけないなっていうところがあるので。
なんだなんだこれも結構重要な問いです。
はい。
というところでした。
お、視聴優先さんですね。
おはようございます。
参加ありがとうございます。
サイトになる記事をダラダラとダラダラ読んでます。
今回からとにかくソフトスキルについてずっと読んでいける感じですね。
はい。
今の問いはいくつかありましたけど、
私はこれらの質問がしばしば役に立つことに気づきましたと。
特に、
時には問題の兆候に対処したつもりが別の症状が現れていくことに気づくこともあります。
また解決策をすぐに実行に移したがために後々さらに問題が発生することもありますと。
クリティカルシンキングのレンズがあれば前提を覆し、
リスクとベネフィットを精査し、
矛盾する証拠を探求し、
信頼性を評価し、
正しいことを行っているということに確信を得るために、
さらにデータを探すことになりますよと言っています。
はいはいはい。
例えば私が見てきたエンジニアのよくある間違いというのは、
相関関係が因果関係を意味せるという思い込むことですと。
いや、これは本当に鋭いご指摘ですね。
確かに物事に対して相関関係があったらそれが因果関係を意味するって、
結構現場で見てる気がしますね。
僕も使っちゃってる可能性が大いにあり得そうというか、
12:02
いくつかパッと浮かんじゃいましたから。
これはちょっと痛いな。
つまり2つの物事が相関しているからといって、
一方か他方を引き起こすとは限らないよということですね。
相関関係があるかもしれないし、
あったとしてもそれが原因で物事が起きているとは限らないということですよね。
はい、いやもう本当。
これは鋭いご指摘ですね。
ちょっと肝に見せておきます。
クリティカル進化ですね。
こういう物事の考え方ができる人たちは、
このような思い込みに対してなぜそれが信じてあるのかって、
問い返すことができますと。
いやー本当素晴らしいと思います。
クリティカル進化っていうのはこういう人だよっていうのをいくつかの項目に分けられています。
はい、いってきます。
1つ目ですね。
心に響く質問をし、それを明確かつ正確に定式化するということですね。
言語化するということです。
続いて、関連する情報収集し、評価し、
その質問にどのように答えるかを検証しますと。
次で、根拠ある結論と解決策に到達し、
それに対する基準や標準に照らして検証しますと。
次です。
大体的な思考システムの中で心を開いて考え、
必要に応じてその前提、意味、現実的な結果を認識し、評価すると。
はい、ラストですね。
複雑な問題の解決策を見出すために、他者と効果的にコミュニケーションを取りますと。
はい、いやーこれ大事だよな。
とにかく自分一人でやってたら大変なことというか、
正しさというのは結構評価するのは難しいと思いますよね。
自分自身でやったりしたら、自分にとって正しいと思っても他者が違ったりするというのはザラにある話ですので。
はい、ちゃんと効果的にコミュニケーションを取るのもすごく大事だよなと思いましたし、
やっぱりクリティカルシンキングって自分自身だけで物事を解決するわけではないので、
やっぱり他者とコミュニケーションを取るところもコミュニティがあるシンキングの中で結構重要な要素だったりするなと思ったりしました。
もちろん相手がちゃんとクリティカルシンキングできる人だったら最高ですけどね。
そうじゃないとしても、やっぱり他者視点から評価をもらうというのは結構重要なことだと思いますね。
はい、1個だけ注意書きがありますね。
注意として、クリティカルシンキングというのはソフトスキルとハードスキルの両方の側面を持つため、
本記事ではソフトスキルに一旦含めていませんと言っています。
はい、というわけでした。
はい、いい問いというかセクションだと思いますね。
批判的に考え、理路整然とした議論を展開しましょうというところでした。
続きまして、ビルディングはストロングベースですね。
これは結構短いですね。
強固な基盤作りという略し方ですけど。
はい、いきます。
基本をマスターし、繰り返し応用することで新たなスキルを身につけることができますよ。
基本を学ぶことの長期的な価値というのは、それが移植可能であることです。
15:03
短期的にはより良い判断を下し、より効率的なコードを作成するのに役立つということです。
はい、なるほどでした。
なんやかんや基本が大事だよということを言っています。
まあ、なんとか基本から離れちゃうことは、別に離れることは悪いというわけではないですけど、
基本をおろそかにした離れ方をすれば良くないですよね。
やっぱり基本にしっかり立脚した、そういう基盤に立脚して、
物事をどんどん変化したり、展開させたり、拡張させたりというところは良い話なんですけど。
基本のすごい大事なことは、移植可能だというところを述べますね。
長期的な価値というところですけど。
もちろん短期的にも価値があって、より良い判断をしたり、
効率的なコードを作成するのに役立つということでした。
とにかく基礎、基本というのを大事にしましょうということでしたね。
はい、いやー、これまた良い指摘ですね。
Googleで10年間働いてきたシニアエンジニアの方ですら、やっぱり基本に忠実にという風に言っているので、
やっぱりこれは真理というか、格言なんだろうなと思いました。
はい、続いていきます。
トランスファラブルスキルですね。
トランスファなので、移すというところですよね。
移行可能なスキルというところだと思います。
どういう意味なんでしょうね。
読んでいきます。
移行可能なスキルとは、プロジェクト間で持ち運びができるスキルということです。
ここでは基礎と関連付けて説明をしていきますと。
基礎というのはソフトエンジニアリングのキャリアの基礎となるものです。
基礎にはマクロとミクロの2つの層があります。
マクロ層はソフトウェア工学の中核であり、ミクロ層は実装ですね。
各個技術スタックやライブラリやフレームワークなどでありますと言っています。
これも結構ポイントだなと思っていて、
特に僕ら、フロントエンドエンジニアとかがそうかもしれないですね。
入門しやすかったりするし、入りやすかったりするんですよね。
なので、他のキャリアからエンジニアになりたいなという方で、
まず最初にHTMLとCSSとJavaScriptから入る。
いわゆるフロント側のスキルから入る方が結構多いんですよね。
別にそれは悪いと思わないですし、
まずプログラミングの楽しさとか、その世界を知るという意味で
入りやすいところから入ったというのは別に、
全然いい意思決定とか判断だなと思ったりしますが、
やはり大事なのがやっぱり今言ったマクロ層のところですね。
ソフトウェア工学というところですね。
があるなしで結構変わってくるし、
エンジニアとして生きていく中では、
そこの差が割と出るなとすごく思ったりします。
なので結構皆さん、ミクロ層に重きを置いたりしがちですよね。
技術スタックとライブラリというフレームワークですよね。
今こういう言語を使います。
こういうライブラリとかフレームワークに使った開発経験ありますと。
もちろんそれを売りにすることもできますし、
そこがあるから、
転職だったりキャリア的なところの評価をされるというのは、
もちろん大いにあり得るんですけど、
18:01
良いエンジニアというところにフォーカスを組んであれば、
やっぱりソフトウェア工学のところまで、
ちゃんと加味したりとか、そこも知ってますよとか、
大いにそれを活用してますよというのは結構大事だったりするなと思います。
もちろんそれをどうやって評価するのかというのは、
結構難しい別のテーマはありますけどね。
ただそういうところが良いソフトエンジニアリングの基礎となるものなので、
そこをもちろん技術とか、
いわゆるミクロのところを身に付けたら、
次はマクロのところもしっかり勉強していくのが良いのかなと思ったりしました。
逆に僕は、僕みたいに情報系の大学に出た人でも、
マクロ層は結構おろそがいしがちだったりする可能性もあるので、
さっきの強固な基盤みたいなところの章と同じで、
やっぱり基本とか基礎を大事にしなきゃなというので、
今復習したくなりましたね。
はい、こんな感じでした。
で、いきましょう。
マクロ層では言語に関係なく、
ほぼ互換性のあるプログラミングの概念を学びますと、
文法は違っても格好のある考え方は同じです。
例えばデータ構造ですね。配列、オブジェクト、モジュール、ハッシュみたいなところですね。
とかアルゴリズム、検索とかそうとかありますよね。
ヒープとかもあったりしますけど。
とかあとアーキテクチャですね。デザインパターン、状態管理とかですね。
さらにはパフォーマンスの最適化ですね。
いいかとレイジー評価とか、メモ化、キャッシュ、レイジーローディングなどなどが含まれます。
この辺がマクロ層だと言っていますね。
これは頻繁に使う概念なので、逆に知ることで多くの価値が生まれますと言っていました。
アーキテクチャとかは割と開発しながら実際学べると思いますが、
データ構造のところもまだ悩ましいですね。
配列、オブジェクト、モジュールとかまでは行きますけど、
ハッシュまで行くかなというのがちょっと気になりましたけど。
またソフトウェア、特にフロントエンジニアの人たちで、
アルゴリズムをしっかり勉強していることはかなり少ないんじゃないかと思ったりします。
実はみんなやられてるかもしれないですけどね。
検索についてはできましたけど、想像的なところとか。
ヒープはアルゴリズムというかちょっと悩ましいところがありますが。
あとパフォーマンスも人によって待ちましてですけど、
フロントエンジニアのパフォーマンス観点はしっかり持った方がいいと思いますけどね。
レイジーローディングとかレイジー評価のところもそうですし、
メモかキャッシュのところも知っておくことは全然損ではないなと思ったりしましたね。
JavaScriptにそういう機能はやっぱりあったりしますし。
こういうものが含まれます。
これらは頻繁に使う概念だから逆に知ることが結構価値を生まれるかもしれないなと言ってました。
続いて、Microのレベルの話ですけど、
Microではこれらの実装のですね、概念の実装を学んでいきましょうと言っています。
これには使用する言語ですね。
例えばJS、Python、Rubyなどだと。
使用するフレームワーク、React、Angular、Vueなど。
Angularを出してるってのはちょっとあれですけど、
やっぱりGoogle社なんでAngularですよね、そりゃ。
あとは使用するバックエンドですね。
ジャンゴとかレールズとか。
ラベルが出てこないですね。
Googleって世界的企業なのでやっぱりまずPythonの方が高いんでしょうね。
21:06
世界はPythonで動いてるって言ってもいいぐらい使われてるらしいですからね。
PHPではないそうです。
ジャンゴとかレールズなど。
使用する技術やスタックですね。
Google App EngineとかGoogle Cloud Platformなど。
さすがにGoogleの人だなって感じでした。
などなどが含まれます。
このように専門知識を身につけることで
効果は期待できる内容ももちろんありますけども
必ずしも転用できるわけではないですよ、言ってますと。
確かにこのセクションのタイトルがTransfer Skillsですからね。
基本を学ぶことで基本を無視して成長するためのスキルセットとツールを手に入れることができます。
無視してっていうか基本を飛び越えてというか
オーバーラップしてみたいところもあると思います。
はい。
とはいえ現実的にはキャリアの初期にすべてを学ぶ時間的余裕は足りません。
基本的なことを学びすぎず実際にアプリケーションを構築するために
必要なことを学ぶべき時期が来るのです。
そこでやってみるアプローチの出番だと言っています。
はい。
いや、本当に良いことをこの表図と言っているな。
はい。
とにかく基本を忠実にいても基本から来るタイミングも来るので
あれはしっかり基本を学んでいきましょうということでしたね。
その観点としてはMicroとMacroのレイヤーがあるので
そのレイヤーで物事を勉強してみれば良いんでしょうかというところでしたね。
はい。
順番的にはMacroからやって次にMicroな気はしますけど
技術をその範囲につけてやっぱり食べていかなきゃ
仕事になっていかなきゃいけないので
まずMicroから入るっていうのも良いかもしれないですけど
個人的にはMacroからやってMicroの方が良さそうな感じはしましたね。
あくまでやっぱりMacroは概念なので
本質的な具体的なところはMicroのところという感じはします。
ただMicroやらないとMacroを理解できないっていうのも全然あると思うので
その辺は人によって違うかもしれないですね。
どっちもワードボードが絶対に重要だよなっていうのは
僕は変わらないなと思いました。
はい。
じゃあ続いていきましょう。
次ですね。
エフィシェンシー。
効率化のところですね。
基本的なことをよく理解することで
より効率的なコードを書くことができます。
これには時間の複雑さ、
コードの実行にかかる時間とか
メモリ使用量、パフォーマンスと
修正のトレードオフなどの概念が含まれます。
これらの考え方により
過度に大きなアプリケーションを構築する際に
役立つトレードオフを行うことができます。
最近のアプリケーションでは
スピードが重視されることが多く
エンドユーザーのエクスペリエンスに
顕著な影響を与えることがありますと言っています。
はい。
なるほどですね。
効率化と言ってますけど
要は全体的なところのパフォーマンスとか
レードタイムとかというところを見ている感じがしますね。
僕ら開発者の時間の短縮もそうですし
アプリケーションそのものの実行時間とか
パフォーマンスというところも
24:00
結構重要なんだろうなというところがありますね。
ただ大きなアプリケーションを構築するには
もちろん時間というのはトレードオフになりますし
あと本当にアプリケーションのパフォーマンスを
上げるというところですね。
スピードを重要視するには
効数は逆にかかると思いますね。
しっかり時間を使わないといけなかったりするので。
はい。
矛盾はしますけど
両方を求めていくというのも結構いい話だなと思いましたね。
はい。
やっぱり生産性の話が次に出てきたりしますからね。
はい。というところでした。
効率化というところですね。
あとはパフォーマンスは僕あんまり詳しくないので
しっかりパフォーマンス勉強しなきゃなと思いましたね。
一応本は買って一回か流して読んだことあるんですけど
やっぱりアプリケーション、実際の開発のところで
パフォーマンス改善というのを全然ガッとやったか
あるかというとそんなにやったことはないので。
サーバーサイエンジニアのときにやったりしましたけど
結局クエリなんだっけ
ログだけ書き出して
データベースのところの周りのチューニングをした
というぐらいはありますけど。
はい。ちょっと余談でした。
次の章に行きましょう。
次はですね。
ベターディセイジョンメイキングですね。
より良い意思決定ということです。
時間はあと3分なので
これと次のセクションを読んだら終わるかもしれないですね。
マクロとミクロの基礎知識を十分に理解することで
より良い意思決定ができるようになります。
プロジェクトの目標は制約に基づいて
どの技術を使用し、どの技術を避けるべきか
より適切な判断を下すために知識を活用できます。
これにより間違った技術や間違ったツアーや話し場という
ものを避けることができるんです。
その通りで、グーの音も出ないですね。
で、一つ引用が出てきますね。
道具を使いこなすには
それを使うべきではないときを理解する必要があります。
ケルシー・ハイタワーという方なんですね。
Twitterのリンクは書いてありますけど。
ソフトエンジニアリングにはですね
コア言語であったりとか実装であったり
インフラ、ツール、そして人など
多くの異なるレイヤーについて考える必要があります。
これらのレイヤーを表面的に理解するだけでも
絶対に早く構築できるようになります。
しかし、ON時間複雑性ですね。
ランダム記号のON時間複雑性を含む
基本的なことを本当に理解していれば
特に言語やフレームワークの状況が
時代共に変化していく中で
より大きな成果を上げることができるんです。
あと関連記事として3つの記事のリンクが貼ってますね。
ソフトウェア工学における基礎の価値
なぜ基礎を学ぶのか
作れた開発者の考え方の基本を学びますみたいなところですね。
3つの記事のリンクが貼ってます。
これは全部、外部リンクですね。
同じ方が語っているような記事ではないですね。
3人の人がバラバラに書いた記事ですね。
のリンクがあるんで。
これは本記事のリンクを一応
27:01
昨日もツイートしたんですけど
その中から載ってますので
Better Decision Makingの章まで行ってくるときに書いてますので
そこから追っていただければなと思います。
次のセクションですね。
おそらくここで時間が切れる気がしますので
いきましょう。
次のセクションは
Focus on the user and the rest will follow.
ユーザーに焦点を当てれば後はついてくるよと言ってます。
なるほど。
ユーザーエクスペリエンスから始めて
必要なテクノロジーまで逆算しましょうと言ってます。
スティーブ・ジョブズの有名な言葉に
カスタマイズエクスペリエンスから始めて
テクノロジーまで逆算しなければならない。
技術から始めて
それをどこに売るかを考えることはできないよと言ってました。
これもなんだかんだ資源だよな。
やっぱり技術から始めがちなことありますけど
違いますよね。
やっぱりユーザーのことが大優先で
物事を考えていけないなというところですね。
なぜならエンジニアは
人気だったり開発者の経験だったり
あるいは個人的な好みから
得点ソリューションを使いたいというところから出発し
それを使うことを合理化する方法を探そうとするんですけど
その考え方というのは
あまりにも簡単だからそこにたどり着くよと言ってますね。
そうではなくてやっぱり誰のために作るのか
どんな問題を抱えているのか
現在ある選択肢ではどう足りないのかに
焦点を当てるべきなのですと言ってます。
はいもう本当に何も全くもって同意なので
はいここですね。
で、発売された機能を選ぶ喜ぶユーザー
発売されたというかあれですね。
これはちなみに画像のことです。
画像をそのまま翻訳機にかけたら
画像のオールドがこれ出てくるんですね。
ちょっと知らなかった。面白いですね。
はい。
で、優れたユーザー体験というのは
お客とテクノロジー、両方の視点を組み合わせることで生まれます。
お客様が欲しいと思うものを見せ
お客様の言葉に耳を傾ける。
もちろんこの問題領域には非常に微妙なニュアンスがあります。
どのようなエンジニアリングの選択をすれば
モバイルハードウェアで素晴らしい体験を提供できるのか
どのような選択がエンジニアリングの速度や規模、雇用に影響を与えるのか
最終的に私たちが恩恵を受けるのは
お客様は第一に考え
制約の中でお客様のニーズに応えるために
何ができるのかをナビゲートすることですと。
はい。
最古のソフトウェアはユーザーに共感する
エンジニアによって作られますと言っています。
ユーザー視点があるエンジニアによって
最古のソフトウェアというのが作られるということですよね。
何のためというと立脚して
どものごと設計したり実装するエンジニアが
やっぱりユーザーに共感する
ところでユーザーのためのソフトウェアが作られますからね。
多分最古と言っているのは
あくまでユーザーのための最古だと思うんですよね。
ギリシャにとっての最古は
もちろんギリシャのための観点で
ツールとかを作っていく可能性はもちろんありますけど
結局誰が使うのかというのに重きを置いて
30:02
物事を生み出すエンジニアというのが
最古のソフトウェアを作るんでしょうね。
最後ですね。
ビジネスの成功というのは顧客満足度にかかっており
それはソフトウェアの場合
しばしばユーザーエクスペリエンスに置き換わりますと。
エンドユーザーが製品やユーザーを
パーフィスをどのように体現しているかを理解しましょう。
このソリューションが彼らの仕事を
効率的に行う能力を妨げないことを確認しましょう。
もしあなたがエンドユーザーと
直接対話できる立場にあるのであれば
彼らのニーズや苦痛をよりよく理解するように
試みてくださいというところでした。
このセクションもかなり大事なところですね。
フォーカスオンラユーザーアンザレストウィルフォローですね。
というところでした。
というところで時間が30分過ぎてしまったので
また一旦以上にしたいかなと思います。
やっぱりソフトスキルって本当に大事だなって
すくずく思いましたし
後ほどいっぱいずっとここから先も出てくるので
しっかり読んでいきたいかなと思います。
残念ながら3日で終わると言ったかもしれないですけど
多分4日かかるかもしれないですね。
今日読んだセクションの中でスクロール量を見たら
4分の1、1回か何回かだったので
ちょっと長くなるかもしれないですけど
ゆるーく読んでいこうかなと思いますので
そのままお付き合いいただければ嬉しいなと思います。
では今日も朝勝以上にしたいかなと思います。
ご参加いただいた方ありがとうございました。
最終的に市中優先しか残ってないですけど
いつもありがとうございます。
市中優先さんとまたお話ができたらいいなと思っています。
じゃあ今日の朝勝は以上にしたいと思います。
日曜日ですね。ゆるりと休日をお過ごしいただければなと思います。
では終了します。お疲れ様でした。
