2022年の抱負
2022/01/07 2022/01/072022年の抱負 明けましておめでとうございます。今年もよろしくお願いいたします。 のんです。 遅ればせながら、今年の抱負記事を書いてみました。 自分の作成した今年の抱負メーカーを利用して画像も作成しました！ よかったら使ってみてください！ 今年の抱負メーカー | Twitterで今年の抱負をつぶやこう！筆書き風の画像をダウンロードして背景に設定したりしてください！ 今年の抱負メーカー | Twitterで今年の抱負をつぶやこう！筆書き風の画像をダウンロードして背景に設定したりしてください！ 時間をフル活用個人アプリを次のステップへ 去年はちょっと色々なことに手を出しすぎてグダってしまったというか、本当にやりたいことに対して時間を割くことができなかったなという反省がありました。 そこで、今年はやりたいことにしっかりと時間を割けるように意識していきたいと思います！ 個人開発したアプリの面倒をあまり見れていなくて、去年のうちにやっておきたかったことも他のすべきことで時間を使ってしまい、未達となってしまいました。 個人開発のアプリに時間をたくさん使って、たくさんの人に使ってもらえるように頑張りたい。 常日頃からそのように思っているので、今年はしっかりと個人アプリに対して時間を使ってあげたいと思っています。 Rust / Golangの勉強 今まで個人アプリをPHPで書いていましたが、ある程度成熟したアプリについてはRustやGoで書き直してみようかなと思っています。 特にこのブログはおかげさまで色々な方に見ていただけているので「もっと早く描画できるようにしたいな」と結構前から思っていたところです。 パフォーマンス的にどのくらい改善されるかはわかりませんが、勉強がてらやってみるのもいいかも。 実は少しずつRustの勉強を初めていたのですが、他のブログなどを見るとGoの勉強から始めてみるのもいいかもとあるのでGoで実装してみようかなと考えを改めて見ようとしているところ。 あとWEBでRustはオーバースペックっぽい？仕事ではGoが主流のよう。 実際にどうなるかはわかりませんが、ひとまずRustでMVCっぽいことをできるようになったのでGoでそれをできるようにしたいと思います。 最後に 今回は今年の抱負記事でした。 数を絞ることで目標を見失わない作戦は果たしてうまくいくでしょうか？ 仕事も頑張りつつ、自分のための一年にできたらと思います！ また記事書きます。 そのときはよしなに。 .
2021年の振り返り
2021/12/26 2021/12/262021年の振り返り こんにちは。のんです。 今回は2021年の振り返り記事になります。 今年も色々イベントがありまして、楽しい年になりました！ ということで振り返っていきます。 会社の業務以外の活動（副業）をたくさんした年 中には途中で止まってしまっているものもありますが多めに見てくださいｗ やはりいちばん最初に挙げられるのは副業ですね。 副業（プログラム開発支援） たまたまとあるサイトで出会った方に「開発の手伝いをしてくれないか」とお声がけいただき、丁度私も探していたところでしたので、協力させていただきました。 その方がとても良心的な方で、技術的にも仕事的にも大変良い思いをさせていただいております。 このブログを見ているかはわかりませんが、本年は大変お世話になりました。引き続き変わらぬお付き合いをさせていただきたいと思っております。 これ以外にも他の方から、ちょっとしたお手伝いに誘っていただくことも多く、大変ありがたいことに本格的に始動した今年から、嬉しい悲鳴をあげさせていただきました🙇 副業（プログラミングレクチャー） こちらは結構前から活動していました。 最初は友達やその知り合いのレクチャーや相談といった感じでしたが、こちらも今年をきっかけに色々な方からお声がけいただき、いつも予約パンパンの状態にさせていただいております。 本当はお断りしている方々にもレクチャーしたいと思っているのですが、本業との兼ね合いで最大同時に2名までと決めているのです。本当に申し訳ない🙇 機会があればまたお声がけいただければと思います。 プログラミングレクチャー系の動画投稿 こちらは完全に止まっていますね... なんとか投稿していきたいですが、動画の作成に時間がかかりすぎる。中途半端なものを出すのもアレなので、一度STOPしているというのが現状です。このあたりはキチンと解決して動画を出していきたい。私は学生向けに投稿していきたいので、簡単なものを短期間で成果が出るような内容で投稿するつもりです。 来年どうなるかは...まだわからない。 名刺代わりのサイトを作りました こういうこともあり、自分のことを紹介することが多くなりました。 ということで、 Nozomi Hosaka https://nozomi.bike を作成。 こちらから私の情報にアクセスできます。 コンタクトのとり方はまだメールオンリーですが、追々増やしていくつもりです。 よかったらTwitterも覗いてみてください。このサイトに掲載しています。 お仕事も頑張った年 去年ももちろん頑張ってましたが、今年はベクトルを変え、社外の方々に会社のことを知ってもらうために、自分のTwitterで社内のことをつぶやき始めた年でもあります。 TwitterのDMから何回かアプローチが届くこともありましたし、そこそこ貢献できているでは？ あとは自分のプロダクト絡みで、顔と名前だして動画を投稿したりもしました。 作るのを頑張ったというより、知ってもらう努力をした年。という感じですね。 バイク乗り換えた これは比較的最近の話ですが、５年ほど乗ったバイクを乗り換えました。 これは感慨深かった... 愛車を手放すのがこんなに喪失感あるとは... まぁその代わりバルカンSという新しい相棒に出会えたわけですけどもね！ｗ 来年も乗って乗って乗りまくります！！ 最後に こう見ると割と仕事人間なのかもしれん。 でもPCの前に居るか、バイクに跨っているかとどちらかなので、間違っていないかｗ ついに確定申告が必要な規模になったので、戦々恐々としています。 来年は一発目は今年の抱負メーカーを利用したつぶやきにしたいなという思いです。 またお会いしましょう！ その時はよしなに。 .
バルカンSを納車しました！
2021/12/12 2021/12/12バルカンSを納車しました！ こんにちは！のんです！！ バルカンSを納車しました！ 前々から気になっていたクルーザータイプのバイクです！ 株式会社カワサキモータースジャパン 日本国内におけるカワサキブランド製品の総販売元 株式会社カワサキモータースジャパンのオフィシャルウェブサイトです。モーターサイクル、ジェットスキー、オフロード四輪車、ATVなど、カワサキブランド製品の情報をご紹介します。 実は結構前から乗り換えは検討していた。 やっぱり、２５０ccは軽い。高速ではおもちゃみたいにどっかすっ飛んでいきそうで怖かったのです。 もちろんZ250はいいバイクで街乗りや峠のツーリングはとても楽しいです。 でもそろそろ大排気量のバイクも乗ってみたいなでもリッターバイクはでかすぎるし乗らなくなってしまいそう。ということでZ650やZ900を候補にあげていました。しかしまたタイプの似ているバイクはどうなのか。。。ということで。。。↓ 前乗っていたZ250とは全く別のタイプを選択しました これまでのZ250 前乗っていたのはZ250。ストリートファイターという見た目が尖っているスポーツタイプのバイクといったところです。 こんな感じです。結構尖っているバイクかと思います。 でも見た目の割に軽量で取り回しが簡単なので、女性人気が高いバイクでもあります。 あと、めちゃくちゃコアなファンが多いことでも有名ですｗ 新しく納車したバルカンS めちゃくちゃマッシブ。クルーザータイプではありますが、バルカンS（このSはSportのSだそうです）と呼ばれるだけあり取り回しがスポーティーな味付けです。ドコドコというエンジン音も控えめなので、ライトにアメリカンタイプのバイクに乗りたい方にはオススメかもしれません。 足つきも抜群。何ならZ250よりもいいまであります。まぁクルーザーですし。 重心が低いので人馬一体のような乗り方はとても難しい。ニーグリップもできない（いや、できるんだけど、するとダサいｗ）のでコーナーは要注意ですね。 しかし、その分ロングツーリングでは力を発揮します。優れた安定性にパワーもあるし、乗り心地も最高です。積載性能は相変わらずなしですが、サイドバック装備を前提にしているので思ったより載ります。 スポーツタイプから乗り換えるために装備も一新した どうですかね？ 乗り心地の違い やっぱり重い 押し歩きは考えたくないですね。重心が低いのもあって押して歩くと転けそうです。 転びそうなときに復帰するのも大変そう。。。 重さのおかげで高速巡航が快適。 ちょっとした風や衝撃で車体が揺れません。どっしりと走れるのはとても快適です！ 足を投げ出すタイプ 足が真下に下ろすのではなく、前に投げ出すタイプなのでバイクで立つことができません。 注意して乗らないと結構、腰に来るバイクかもしれませんｗ それでも他のバイクよりはふかふかなのは嬉しい。 前傾姿勢というより前屈姿勢。ポジションの調整は必要になるかも。体が硬い人は試乗してみてください。 背もたれをつけるとめちゃくちゃ違いそうｗ今度試してレビューしてみます。 最後に とまぁこんな感じで全然違うタイプのバイクに乗ってみる。。というのもいいですね。 この週末は完全に体調不良で死んでました。2日も寝込んだのいつぶりだろうか。口の中が風邪の味がするｗ 次回は今年の振り返り記事、その後に今年の抱負記事になりそうですね。 また書きます。そのときはよしなに。 .
自己紹介ページ（ポートフォリオサイト）を一新した話
2021/11/28 2021/11/28自己紹介ページ（ポートフォリオサイト）を一新した話 こんにちは。のんです。 今回は自分のポートフォリオサイトを一新した話です。 今回作成したポートフォリオサイト Nozomi Hosaka https://nozomi.bike 結構前からポートフォリオサイトは用意していた。 それがこちら https://portfolio.nozomi.bike/ こちらは完全に自作のhtmlとjsとCSSのみ。 モーダルなども全て自作となっていますが、機能重視で正直ダサかったので、一新しようと思っていました。 新しいサイトはどのような構成か？ NuxtでSSGしています。 やっぱりポートフォリオサイトは静的なもので十分なので、SSRに対応できるように作成していたり、環境もDockerのコンテナで起動できるように調整済みですが、インフラ周りはそこまで用意せず、ただ単にSSGで生成したものを配置しているだけです（手抜き） このブログもサーバーやバックエンド（PHPではなく違う言語など、）丸ごと変えたいと思っているので、そのタイミングで、このポートフォリオサイトも構成が変わることでしょう。 ひとまず、サイトとしてやりたいことはできているので及第点としたい。 地味に自分の名刺代わりになるサイトが存在しなかったので、年内のうちに用意できたのは大きいなぁと感じています。 新しいサイトでやりたかったこと せっかくドメイン登録している（nozomi.bike）のに、このドメインにふさわしいサイトが無かった。 これまでの制作物のまとめが全然できていなかったので、そのピックアップとその見せ方を整えたかった。 自分の名前や顔を公開してもいいと思った。 お仕事の受付ページを作りたかった。 この辺を静的サイトではできないので、今後改善予定 といった感じでしょうか？ ポートフォリオというと初学者の面接対策のように考えられがちですが、イチプログラマーとして名刺のように使用したいという側面が強いですね。 最後に 現状はただの１枚のページですが、ここに書ききれない成果を上げられるようにがんばります。 Nozomi Hosaka https://nozomi.bike よかったら見てください。 あと、ブログの更新や今年の抱負メーカーの更新もしなきゃなと思っています。 また記事にするので、そのときはよしなに。 .
WSR-5400AX6Sのネットの速度が異常に遅いときの対策法
2021/09/12 2021/11/14WSR-5400AX6Sのネットの速度が異常に遅いときの対策法 こんにちは。のんです。 5年位使った無線LANを買い替えたときにネット回線が遅くなっちゃいました。 それについて記事にしていきたいと思います。 前回まで利用していた無線LANルーター「WSR-1166SHP2」 WSR-1166DHP2 : Wi-Fiルーター : AirStation | バッファロー Wi-Fiルーター WSR-1166DHP2の商品情報サイト。バッファロー公式情報です。 正直、賃貸で利用するレベルのネット回線ならこのレベルでも十分でした。一人暮らしですので、家もめちゃくちゃ広いわけではありませんので、性能的に無問題。 しかし、5年間も利用してきた経緯からか、度々再起動がかかるようになってしまいました。しかもインターネットから切断されることもしばしば。 そろそろ新調しようかということで購入を決意。 この子は中古屋さんに売ろうかなと思います。 今回購入した「WSR-5400AX6S」 WSR-5400AX6S-MB : Wi-Fiルーター : AirStation | バッファロー Wi-Fiルーター WSR-5400AX6S-MBの商品情報サイト。バッファロー公式情報です。 この子が問題児でした。というか、最近のBuffalo製の無線LAN全般ですね。 なんと、最新モデルにも関わらずネット回線が激重。 アップロード0Mbps いや、流石にない というか、他の作業でアップロードはできているので、何かの要因があるはず。 めちゃくちゃ調べた。 結論 ネット脅威ブロッカーをOFFにしました。 いや、ありがたいけどアップロード0はない。 切った瞬間ネットのレスポンスがめちゃくちゃ良くなりました。 セキュリティ的に不安がある場合は各デバイスにセキュリティソフトを入れておくべきでしょう。 これにて解決。 最後に WSR-5400AX6S、上記の問題以外はいい商品でした。 WSR-1166SHP2より若干レスポンス良くなりましたし、パワーも向上しました。 去年からリモートワークをガッツリするようになって、そのうち買い替えたいと思っていたことが叶って嬉しいです。 のんラボでは基本的に技術記事を書いています。今回は例外ですが、ガジェット系なので許してね。 また書きます。 その時はよしなに。 .
ITエンジニアがインサイドセールスの白本読んでみた（最終回）
2021/10/31 2021/10/31ITエンジニアがインサイドセールスの白本読んでみた（最終回） こんにちは。のんです。 今回から、スマレジの営業さんからお貸しいただいた「インサイドセールス」を読んでいこうと思います。 いえーい！インサイドセールスについて呟いたら、 @Mar_Cyyy さんが本を貸してくれました！😊 スマレジはインサイドセールスにも力を入れています！ pic.twitter.com/ejVLBxvAaM— のん🐘夜型言語 (@nonz250) August 2, 2021 あくまでも私主観での「感想」に近い感じで書きたい。 やはり本である以上、そのまま丸写し、よくない。良いか悪いかは置いておいて私主観の感想を述べる感じになります。 エンジニアがインサイドセールスについて知ったらこういう事考えるんだなぁ...くらいに考えてください。 具体的な内容が知りたい方は実際に購入しましょう！ Amazonのリンクです。アフィではないので安心して踏んでください。 https://www.amazon.co.jp/dp/4798167541/ref=cm_sw_r_tw_dp_AB7HZM7N66CZYJ2X5PMR?_encoding=UTF8&psc=1 https://www.amazon.co.jp/dp/4798167541/ref=cm_sw_r_tw_dp_AB7HZM7N66CZYJ2X5PMR?_encoding=UTF8&psc=1を見... ITエンジニアがインサイドセールスの白本読んでみた② | のんラボ ITエンジニアがインサイドセールスの白本読んでみた②こんにちは。のんです。今回から、スマレジの営業さんからお貸しいただいた「インサイドセールス」を読んでいこうと思います。いえーい！インサイドセールスに... 今回は前回の続きから見ていきましょう。 成果を出すインサイドセールスのテクニック この章は具体的なインサイドセールス、またはオンライン商談のテクニックについて書かれていました。 私は普段商談をしていませんし、いくらエンジニア目線とはいえ、当たり障りの無い意見になってしまいそうなので、サクッと終わらせたいと思います。 いつもどおり、気になったキーワードをピックアップすると... オンライン商談時には「普段の半分のスピード」を意識して行うこと、でした。 当たり前のようで、普段できていなかったなと新しい気付きになりました。社内のMTGでも同様のことが言えると思うし、私は議論にのめり込んでしまうと、ヒートアップしてきてしまう癖があるので、より一層注意したいと思いました。 あと、めちゃくちゃ細かいですが、ホイールを利用したスクロールもそうですねｗｗ Macの仮想デスクトップもよく使うので、注意したいと思いました。 ここで筆者が言いたいのは、できるだけタイムラグを抑えるために、紙芝居的に進められるように工夫すべきということですね。 他には商談前の心構えや、PCの環境準備ですね。 エンジニアの私が普段無意識に注意していた部分が改めて文面になっていたので、「ふむふむ、こういうことをキチンと明文化することも重要なのだな」と感じました。できるだけ自分の考えは口にするようにしていましたが、まだまだ足りませんね。 チームマネジメントの鉄則 うーん...一緒！！ｗ どこの部署も同じような考えで、同じような悩みを持っていると改めて感じました。 事業戦略の理解度を上げる エンジニア / プログラマーですから、技術傾倒しがちな人めちゃ多いです。 いや、技術軽視してるわけではないんですよ でも、その対応で事業成長する？ってこと。よくある。 いくら高度な技術で実装されていたって課題を解決できなければ無価値なんですよね。 もちろん、課題を解決するために技術を求められるときもあるし、課題を解決したときに、すでに高度な技術で実装されていれば文句はないんですよ。 よく、技術と課題を一本の線でグラデーション的に引いて 「このトレードオフが難しいよねぇ」と語る人がいますが、それは違うと思っていて、この2つは全く違うコンテキストなはずです。 「技術がなくても課題は解決できる！」←間違い 「課題を解決する前にまず技術を究めるべきだ！」←間違い 技術と課題のバランスはマネジメント能力とプロフェッショナル能力の2軸のように、縦軸と横軸で展開され、両方とも高いレベルのものが理想形なのに、お互いが敵視しあって、 「技術重視のやつは経営をわかってない」 とか 「良いプロダクトを作るには良い技術が必須だ」 とか、不毛な争いをしているんですよね。 アホらし。 両方チャレンジすればいいじゃん。と。 どちらから手を付けたかの違いじゃんか。と。 僕はそう言いたい。 お互いもっと歩み寄りません？ そのためにはメンバー側は「事業戦略の理解度を上げる」必要があると思っているし、事業側は「技術（プログラミングとかITツールとか）の理解度を上げる」必要があると思っている。 そのためには事業戦略の布教が必要だよね？ということをこの本は言っている（ように感じた） 事業責任者の説明努力がやはり必要。 ぶっちゃけメンバーはほぼ平社員だし、サラリーマンだし、事業がうまく行ったときのリターンを具体的に思い描けていない（と思う）。 この事業がうまくいくとこういう（めちゃ具体的に説明する。給与とか。）リターンがあるよ！ そのためにはこの事業のこの課題をクリアする必要があるんだ！ この課題は〇〇さんの持つ技術にかかっているんだ！助けてくれ！ これでやる気の出ない社員は...いないと信じたい。僕なら結構頑張ると思う。 このリターンを具体的にするために、次の章の... 挑戦と称賛の制度化 につながるわけですね。 この制度ではメンバー側からの訴えが反映されればうまくいくと思っています。 例えば、このようなツールを使って〇〇の課題を解決したいとか、この技術を導入してこの課題を解決したいとか。 その挑戦を評価に落とし込んで、そのリターンそのものを称賛にすると、事業は伸びるし、メンバーは成長するし良いことづくめな気がする。 とまぁ、このIT業界に入ってそれなりの経験をしてきた愚痴の塊のようなものを書いてしまった。 これはエンジニア特有の課題ではないと思うし、きっとISにも通ずることなんだろう。 委任と放置の違い めちゃくちゃ耳が痛いです。 SLⅡモデル...覚えておきたいと思いました。 私は委任のつもりの放置ってやつかも知れません。。。 この辺はこのキーワードで色々参考になるWEBページがあるので、そちらに任せたいと思う。 このブログはあくまできっかけにしてください。 1 on 1 どの業種もやっているようで安心しました。（エンジニア特有のものかと思っていた...） 業種またぐと突然井の中の蛙になってしまうのなんとかしたいですね。 今の時代、報連相より雑相（雑談と相談） というのはよく耳にします。そのきっかけに1on1を利用するのは良いかも知れません。相手も感情のある人間ですからね。あまりにビジネスライクに接してしまうと参ってしまう人、多いと思います。 ということで最終章まで（軽く）読むことができました🎉 完全に違う業種かと思いきや、思いの外マインドセットというか、目指すべき方向性に共感を持てることが多くニヤニヤしながら読んでいた章もたくさんあります。 本当はしっかり文字に起こしてブログにまとめたかったのですが、読むという行為と書くという行為、どちらが重いかは、、、書いてみた人ならよく知っているはずｗ ということで、結構隅々まで読んだつもりでしたが、文字に起こせていない部分もたくさんあります。 少しでも興味がある方は是非ともお手に取ってみるなり、僕のように借りてみるなりしてサラサラと眺めてみるのも悪くない1冊でした！ あ、今思いついたけど商談のYoutube投稿とか良いかもと思った。 メモっとこ。 最後に 今回は6章から最後まで読みました！ 感想はすでに書いたので、割愛して... 年末にかけて更に忙しくなりそう。次は何について書こうかな。しばらくはお休みしていた技術記事を書きたい気分。多分Rust周りかな。 あと、バイクを買い換える予定なのでそれについても書きたい。 その時はよしなに。 .
ITエンジニアがインサイドセールスの白本読んでみた③
2021/09/21 2021/10/17ITエンジニアがインサイドセールスの白本読んでみた③ こんにちは。のんです。 今回から、スマレジの営業さんからお貸しいただいた「インサイドセールス」を読んでいこうと思います。 いえーい！インサイドセールスについて呟いたら、 @Mar_Cyyy さんが本を貸してくれました！😊 スマレジはインサイドセールスにも力を入れています！ pic.twitter.com/ejVLBxvAaM— のん🐘夜型言語 (@nonz250) August 2, 2021 あくまでも私主観での「感想」に近い感じで書きたい。 やはり本である以上、そのまま丸写し、よくない。良いか悪いかは置いておいて私主観の感想を述べる感じになります。 エンジニアがインサイドセールスについて知ったらこういう事考えるんだなぁ...くらいに考えてください。 具体的な内容が知りたい方は実際に購入しましょう！ Amazonのリンクです。アフィではないので安心して踏んでください。 https://www.amazon.co.jp/dp/4798167541/ref=cm_sw_r_tw_dp_AB7HZM7N66CZYJ2X5PMR?_encoding=UTF8&psc=1 https://www.amazon.co.jp/dp/4798167541/ref=cm_sw_r_tw_dp_AB7HZM7N66CZYJ2X5PMR?_encoding=UTF8&psc=1を見... ITエンジニアがインサイドセールスの白本読んでみた② | のんラボ ITエンジニアがインサイドセールスの白本読んでみた②こんにちは。のんです。今回から、スマレジの営業さんからお貸しいただいた「インサイドセールス」を読んでいこうと思います。いえーい！インサイドセールスに... 今回は前回の続きから見ていきましょう。 インサイドセールスの採用 この章ののっけから「設計者」という単語が登場しました。 やはりエンジニアとの親和性が非常に高そうです。しかも「設計者」と「管理者」が明確にわかれているところはポイントっぽいので読み込みたい。 と思ったら「設計者」＝「管理者」となることは多いとのこと。何かの引き継ぎで管理者になることが結構あるエンジニアとは少し違うのですね。 設計者＝土壌づくり。つまりスクラムマスター 管理者＝チームリーダー。機能を考えて指示を出す。 実行者＝メンバー。実装する。 と思い込んでしまった。 また、これは前回の記事でも取り上げたけど、面接の章を見ているとやっぱり成果物を共有するようなプラットフォームはあると便利かもですね。 どうしても数値化が（守秘義務も合わせて）難しい領域だと感じました。 プログラミングだと、個人で作成したアプリとかは自由に公開できるので、いくら作っても成果物になりますが、「売る」という行為そのものを技術としているインサイドセールスはその成果物を共有するのが難しそう。 一度インサイドセールスや営業の面接風景を見てみたいかも。色々勉強になると思う。 「抽象的な質問」と「具体的な質問」を交互に質問し、思考力を見極める。 面白いと思った質問の方法がこれでした。 読んでいて、「なるほど！真似しよう！」と感じたことです。これはエンジニアでも通じる事だと思いました。 エンジニアだからといって常に論理的な仕事をしているわけではありません。管理者はチームのタスク調整や指示、関連チームとの折衝までこなします。もちろん指示を受ける作業者もチケットなどでシステム化されてはいますが、コミュニケーションは必須です。 このときに、プログラミングに必要な論理的思考とコミュニケーションに必要な説明能力の２つを交互にぶつけてストレスをかけ、思考力を見極めるというのは是非これから使っていきたいと思います。 数字を追うということ 明らかにこの章でも数値について語られています。 成果の数値化を追う以上、MAツールは必須ですね。インサイドセールスチームがここまで管理してくれると開発側がそのような分析をする必要が無くなる（語弊があるかも。主担当ではなくなるというニュアンス）ので、開発に集中することができると思います。 現に、私が今担当しているプロダクトはセールス側にもろもろの対応を完全に任せることができているので、開発に集中できています。本当にありがたいことです... 正直な話、エンジニアの採用もめちゃくちゃ苦労していて、技術を見ながら人柄も見る。成果がない場合はどのように判定するかなど、めちゃくちゃ難しいです。 ここでは全てに触れていませんが、他業種の採用について知見を得られたのは大きいかも知れません。 成約率を高めるインサイドセールスのKPI 最初に申し上げると、正直専門的で理解が浅いかも知れません... この章を読んで、リードとは？という初歩的な疑問を頂いてしまいました。簡単に言うと、リードというのはお問い合わせのこと？それとも問い合わせしたもの？ ただ、有効リードの章は正直わけわからなかったです。普段そのような業務をしていないせいもあって、専門用語はわからなかったし、数字の追い方もあくまで空想の世界になってしまいました。商談している方が、商談だけに注視していないということが改めてわかりましたね... この章を読んでいて思ったことは、やはりエンジニア目線でいうとツールですかね。 このような専門用語は業界として一般化できていればいいのですが、できていないことも多いでしょう。 なので、フレームワークというか、エンジニアにおけるアジャイル開発支援ツールのようなものがあれば更に上手く進めることができると思いました。 また、インサイドセールスを学ぶと使えるツールではなく、ツールを使うことでインサイドセールスを学べるツールというのが素晴らしいと思います。 簡単にぐぐってみるとこの辺のツールはすでに豊富にあるようですね... ただ、スプレッドシートでやっているところも多そうで、このようなツールは「コスト」として見られがちなので導入障壁はやはり高そうという印象。 この辺のツールが普及すれば、インサイドセールスチームがメインで使用し、その他ステークホルダーが、閲覧のための権限のみを持ち、定例MTGなどで、成績の共有とかできれば、クリエイター側からも色々協力はできそう。 最後に 今回は4章と5章の内容について書きました。 最近忙しくて、全然読書時間が取れる、亀の歩みですが、引き続きお付き合いいただければと思います。 次回以降は更に専門的なことになりそうなので、上辺を掬って感想を述べる...みたいなライトな内容になってしまうかも... その時はよしなに。 .
RustとDockerでWEBサーバーを立ててみた
2021/09/12 2021/09/13RustとDockerでWEBサーバーを立ててみた こんにちは。のんです。 今回は前回からやっている RustでHello Worldやってみた | のんラボ RustでHello Worldやってみたこんにちは。のんです。今回は前々からやってみたかったRust言語の勉強をしようと思って、やったことを記事にしてみました。Rustに関しては本当に初心者なので、... の続編になります。 Rustを使うにしても、結局私はWEB屋なので組み込みとかにはあまり使わずWEBアプリの開発に利用するでしょう。 ということで、WEBアプリとして実行できる開発環境の構築をしつつ、WEBアプリとして基礎的な動作をするところまで進めたいと思います。 勉強用リポジトリ GitHub - nonz250/rust-sample Contribute to nonz250/rust-sample development by creating an account on GitHub. バージョンの管理とか面倒。Dockerを使いたい。 こちらは前回触れていなかった内容です。 公式の推奨はRustupを利用することです。 はじめに 効率的で信頼性のあるソフトウェアを書く力を与える言語 しかし、正直複数人でプロダクトを管理するときにバージョン管理とか面倒。絶対Node.jsとかと同じ道を歩みそう。 ということでDockerを利用しています。 copied.app: container_name: app ports: - 8080:8080 build: context: ./ dockerfile: Dockerfile volumes: - ./app:/app:cache - rust-target:/app/target - cargo-cache:/usr/local/cargo/registry working_dir: /app depends_on: - mysql command: /bin/sh -c "cargo watch -x run" WEBアプリとしてポートを開放するときには8080番ポートを利用するようにしています。80番はよく使うし、他のアプリとも競合しそう。セキュリティ的にどうなんだというところも。 copied.ports: - 8080:8080 と記載することで、http://localhost:8080 でアクセスすると出てくるようにします。 copied.volumes: - ./app:/app:cache - rust-target:/app/target - cargo-cache:/usr/local/cargo/registry rust-target:/app/targetでtarget内のものをボリュームに保存できるようにします。target内にはコンパイルした成果物が保存されます。 cargo-cache:/usr/local/cargo/registryでcargoコマンドのキャッシュを保存しておきます。一応cargo run時に時間がかからないようにするために追加していますが、あまり．．．効果は無さそう。この辺は後で勉強し直しましょう。 copied.command: /bin/sh -c "cargo watch -x run" これはホットリロードのためにしています。詳細は後で。 actix-webを利用してWEBアプリとして起動する Cargo.toml copied.[package] name = "sample" version = "0.1.0" edition = "2018" # See more keys and their definitions at https://doc.rust-lang.org/cargo/reference/manifest.html [dependencies] actix-web = "3.3.2" [[bin]] name = "sample" path = "main.rs" に変更。 変更箇所は以下。 copied.[dependencies] actix-web = "3.3.2" actix-webのライブラリをインストールするようにしています。今の所、このファイルの設定はPHPでいうcomposerという認識。多分合っているでしょう。 https://crates.io/crates/actix-web https://crates.io/crates/actix-webを見る この状態でcargo runすると、ライブラリをインストールしてコンパイルしてくれます。 肝心のソースコードはこちら copied.use actix_web::{get, App, HttpResponse, HttpServer, Responder}; #[get("/")] async fn index() -> impl Responder { HttpResponse::Ok().body("Hello world!") } #[actix_web::main] async fn main() -> std::io::Result<()> { HttpServer::new(|| { App::new() .service(index) }) .bind("app:8080")? .run() .await } ほとんどはactix-webのサンプルの通り。 一点、他と違うのはこちら。 copied..bind("app:8080")? 127.0.0.1:8080としてはいけません。 頭がRustでいっぱいになっていて忘れがちです。私はここで1時間ハマりました。 ここではDockerを利用しているので、コンテナ間で共有されている仮想ホスト名である、コンテナ名を指定します。 ソースコードが書き終えたらコンテナを起動します。 copied.docker compose run --rm app cargo run このとき、コンパイルのためのモジュールが足りないとエラーが発生する場合があります。 copied.FROM rust:1.53.0-alpine3.13 RUN apk update RUN apk add alpine-sdk COPY ./app /app alpine-sdkが足りないので、Dockerfileに追記しておきます。 copied.RUN apk update RUN apk add alpine-sdk ここで気づいたのですが、WEBサーバーがありません。 調べてみると、どうやらactix-webがその辺もしてくれているようです。もちろんnginxを前に立ててプロキシ機能を利用すれば、Appサーバーのように振る舞うこともできます。 (adsbygoogle = window.adsbygoogle || []).push({}); ホットリロードに対応する ソースコードを変更するたびにコンテナを起動し直すのは面倒ですし、時間がかかります。 そこで、ReactやVueのようにホットリロードできるようにします。npm run watchですね。 このあたりの機能も用意されています。 今回利用するのはcargo-watchです。 https://crates.io/crates/cargo-watch https://crates.io/crates/cargo-watchを見る Dockerfile copied.FROM rust:1.53.0-alpine3.13 RUN apk update RUN apk add alpine-sdk RUN cargo install cargo-watch COPY ./app /app copied.RUN cargo install cargo-watch を追記します。 copied.docker compose run --rm app cargo run を毎回打つのが面倒くさいです。 copied.docker compose up -d で全てを終わらせたいので、 docker-compose.ymlに下記を追記します。 copied.command: /bin/sh -c "cargo watch -x run" copied.cargo watch -x run でホットリロードできるようになります。この辺のコマンドは公式ページを見て変更しても良いかもしれません。 最後に 今回はRustの勉強の続きを記事にしてみました。 このブログはレスポンス遅いですし、処理も昔のコードのまま。 現在はPHPなのですぐに書き直してもいいのですが、せっかくなので高速と言われているRustで書き直そうかなと思っています。 フロントはNuxtかReactですかね。NextはReactの本格的な勉強をしてからにしたいので、候補外。 それかWebAssemblyでもいいかもと思っていますが、これだといつになるやら...という感じなので、、多分Nuxtかなと思います。 次回はHttpRequestやResponseを捌く箇所を勉強したいです。 また記事にしたいと思います。 その時はよしなに。 .
Z250で曽爾高原ツーリング！
2021/09/11 2021/09/11Z250で曽爾高原ツーリング！ こんにちは。のんです。 今回はツーリング記事になります。 ツーリング仲間と何回かの曽爾高原ツーリングに行ってきました。 結構前から廉価版のアクションカメラで色々撮影はしていましたが、今回からGoProで撮影するようになりました。 スーパーバイクワールドアドベンチャー LINEのグループ名をそのまま引用しました。由来は不明です💥 スーパーバイクワールドアドベンチャー ツーリング動画垂れ流します 曽爾高原に行く前にヤマユリの自生地をチラ見してきた なかった......😇 ヤマユリが自生しているというスポットを発見したので、行ってみましたが咲いてなかった... ヤマユリは7月から8月に咲くそうですが、どうやらシーズンを逃してしまったのかも。 それか、ただ見つけられなかっただけか... ヤマユリとは｜育て方がわかる植物図鑑｜みんなの趣味の園芸（NHK出版） 日本には10種以上のユリが自生しています。中で園芸的に最も重要なユリの原種がヤマユリです。ヤマユリは本州の平地から山地に分布し、日陰がちの斜面や、明るい林、草原に見られる球根植物です。7月から8月に、... ダイジェスト その後曽爾高原まで流しながらツーリング。 頂上まで頑張って登った いや、もうしんどい。 バイクのブーツで登山するものではないですね。 途中、ヒップドロップされたベンチを発見 ちなみにGoProの顎マウントです こんな感じ。 ピンマイクの風防を外していたので、音声悪かったんでしょうね。次回の反省点にしたいと思います。 マイク機器はヘルメットにペタリ。 最新機種のGoProはこの辺の機器が大きめなので少しブサイクですね。 最後に のんラボでは定期的にツーリングの記事も掲載していきます！ 専用のYoutubeチャンネルも開設したので見てみてください〜🏍 スーパーバイクワールドアドベンチャー ツーリング動画垂れ流します さて、インサイドセールスの白本を読もうかな。 これについても記事にします。 その時はよしなに。 .
ITエンジニアがインサイドセールスの白本読んでみた②
2021/08/16 2021/08/29ITエンジニアがインサイドセールスの白本読んでみた② こんにちは。のんです。 今回から、スマレジの営業さんからお貸しいただいた「インサイドセールス」を読んでいこうと思います。 いえーい！インサイドセールスについて呟いたら、 @Mar_Cyyy さんが本を貸してくれました！😊 スマレジはインサイドセールスにも力を入れています！ pic.twitter.com/ejVLBxvAaM— のん🐘夜型言語 (@nonz250) August 2, 2021 あくまでも私主観での「感想」に近い感じで書きたい。 やはり本である以上、そのまま丸写し、よくない。良いか悪いかは置いておいて私主観の感想を述べる感じになります。 エンジニアがインサイドセールスについて知ったらこういう事考えるんだなぁ...くらいに考えてください。 具体的な内容が知りたい方は実際に購入しましょう！ Amazonのリンクです。アフィではないので安心して踏んでください。 https://www.amazon.co.jp/dp/4798167541/ref=cm_sw_r_tw_dp_AB7HZM7N66CZYJ2X5PMR?_encoding=UTF8&psc=1 https://www.amazon.co.jp/dp/4798167541/ref=cm_sw_r_tw_dp_AB7HZM7N66CZYJ2X5PMR?_encoding=UTF8&psc=1を見... 前回の記事はこちら ITエンジニアがインサイドセールスの白本読んでみた① | のんラボ ITエンジニアがインサイドセールスの白本読んでみた①こんにちは。のんです。今回から、スマレジの営業さんからお貸しいただいた「インサイドセールス」を読んでいこうと思います。いえーい！インサイドセールスに... 今回は前回の続きから見ていきましょう。 なぜ今インサイドセールスが必要なのか この白本の目次から抜粋すると、このくらいあるそうです。 顧客の購買行動の変化 サブスクリプションモデルの対等によるビジネスモデルの変化 生産年齢人口現象による働き方の変化 テクノロジーの進化による働き方の変化 ゼネラリストからスペシャリストへ。キャリア志向の変化 この中から気になったところをエンジニアの私目線で書いてみます。 顧客の購買行動の変化 「最初に検索し、情報収集を繰り返して出会ったときには購買の57%の購買プロセスが終了している」が気になりました。もちろん、普段私は上記のようなプロセスでやはりモノを購入しています。何ならECサイトでポチーですね。100%終了してしまいます。 BtoBでも同じことが言えそうです。前職もエンジニアだったのですが、外部システムを導入するにあたって、そのシステム関連の営業さんに色々なソリューションを紹介していただきました。 まずググって評判を見たり、お試し機能を利用してみたりした後、心の中ではほぼ購入確定のレベルになって最終確認の意味を込めて営業さんを通して購入します。 営業さんを通して狙うのは 直接交渉の値引き 社内の同意を更に深く取るために味方になってもらう 何かあったときのフォローの期待 ですね。ネットからの申し込みより、優位性がある気がして営業さんを通すことはあるかもしれません。 この時すでに私はある程度の商品知識があるので、初見ではないんですよね。そのときにインサイドセールスというスペシャリストに対応してもらうことができればスムースに購入まで到達できるかもしれません。 テクノロジーの進化による働き方の変化 これはもはや言うまでもありません。 最近ではTwitterやFacebookで営業活動や採用活動をしているアカウントすら見かけます。 こういうのを見ると足で数を稼ぐ「だけ」が正義では無くなったように思えます。 むしろ、SNSやYoutubeで有名になって、向こうから来てくれる仕組みを作り、インサイドセールスが捌く方が効率的なまであります。 ゼネラリストからスペシャリストへ。キャリア志向の変化 別の業界の「キャリア」について考えたことがなかったので、結構ゆっくり読み込みました。 エンジニアやデザイナーでキャリアと言えば、ポートフォリオなどを思い浮かべます。 現に私もどんなものを作ったことがあるのか、どんなコードが書けるのかをGithubなどにアップロードして公開しています。 セールスにも似たような成果共有プラットフォームがあると良いかも？と思いました。 また、オンラインで商談が可能になるということなので、働き方に柔軟性が出ますね。 オンラインということは商談のための資料作りも充実させなければなりませんし、PRの間に15秒くらいのCMを流すのも良いかも。 学会とかではスポンサーのCMをセミナーの間に流したりしますよね。 オンラインということは画面を見ているはずなので、なんかうまくいきそうかもしれません。 資料を充実させるために教育の資料も充実するという良いスパイラルを作ることもできそう。このへんは開発者である私たちや、お客様に説明する部署であるサポートとも連携を取れれば相乗効果が生まれそうですね。 インサイドセールスの立ち上げ この章を読むと更にエンジニアの考えに近いなぁ。と思いました。 組織論の話なので、やはり共通するものが多いのでしょうか？ やっぱり。と共感 インサイドセールスの本質はカスタマーサクセス 完成形は常に変化できる組織（アジャイル？と認識） ここは勉強になった 量の時期から質の時期への変化 この辺について書いていきます。 インサイドセールスの本質はカスタマーサクセス そうですよね。エンジニアと同じです。というかどの職種も同じです。 営業は売ることが目的ではありませんし、 エンジニアは作ることが目的ではありません。 結局は利用者のためというのが結論です。 これが崩れるとしたらこの世から仕事が消えるでしょう。 ただ、この思考を持ち続けるのは非常に困難です。 私もプログラミングしているときに、利用者のためとか考えている余裕はありません。 だから要件定義や、設計フェーズを作って段階的に作成していくのです。 セールスではどのように利用者のことを忘れないようにしているのか、目の前の数字に囚われないようにしているのか結構気になります。 完成形は常に変化できる組織 インサイドセールスがテクノロジーの進化を基盤に成立しているのなら、テクノロジーが日進月歩であることを是非とも頭に入れておいていただきたいです。去年の非常識が今年の常識になることもあります。 ということは、アジャイル開発のように短いスプリントを区切ってPDCAサイクルを短く繰り返し回していく他ありません。 是非セールスの方にも、スクラム開発について知っていただきたいと思った章でした。 もはや縦割り組織は化石と同義です。一人一人がプロジェクトメンバーであり開発者であるセールスです。 量の時期から質の時期への変化 大変勉強になりました。 開発においても同じようなことが言えそうです。 コードの内容が...というわけではありませんが、最初期は機能実装優先のミニマムリリースして、徐々に増員をしていき、安定稼働を目指すリリースプランは考えるべきかもしれません。 また、バグ数や、PV数などを数値化して、量から質への変換期というのを設ければスムースにチームビルディングができるかも...とも思いました。 最後に 今回は2章と3章の内容について書きました。 この本読んでいると、違う職種の人から開発手法のアドバイスをもらっている気分になってきますね。 最近忙しいので読むスピードが遅いですが、このままお付き合いいただければ幸いです。 その時はよしなに。 .
