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を利用しています。 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番はよく使うし、他のアプリとも競合しそう。セキュリティ的にどうなんだというところも。 ports: - 8080:8080 と記載することで、http://localhost:8080 でアクセスすると出てくるようにします。 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時に時間がかからないようにするために追加していますが、あまり．．．効果は無さそう。この辺は後で勉強し直しましょう。 command: /bin/sh -c "cargo watch -x run" これはホットリロードのためにしています。詳細は後で。 actix-webを利用してWEBアプリとして起動する Cargo.toml [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" に変更。 変更箇所は以下。 [dependencies] actix-web = "3.3.2" actix-webのライブラリをインストールするようにしています。今の所、このファイルの設定はPHPでいうcomposerという認識。多分合っているでしょう。 https://crates.io/crates/actix-web https://crates.io/crates/actix-webを見る この状態でcargo runすると、ライブラリをインストールしてコンパイルしてくれます。 肝心のソースコードはこちら 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のサンプルの通り。 一点、他と違うのはこちら。 .bind("app:8080")? 127.0.0.1:8080としてはいけません。 頭がRustでいっぱいになっていて忘れがちです。私はここで1時間ハマりました。 ここではDockerを利用しているので、コンテナ間で共有されている仮想ホスト名である、コンテナ名を指定します。 ソースコードが書き終えたらコンテナを起動します。 docker compose run --rm app cargo run このとき、コンパイルのためのモジュールが足りないとエラーが発生する場合があります。 FROM rust:1.53.0-alpine3.13 RUN apk update RUN apk add alpine-sdk COPY ./app /app alpine-sdkが足りないので、Dockerfileに追記しておきます。 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 FROM rust:1.53.0-alpine3.13 RUN apk update RUN apk add alpine-sdk RUN cargo install cargo-watch COPY ./app /app RUN cargo install cargo-watch を追記します。 docker compose run --rm app cargo run を毎回打つのが面倒くさいです。 docker compose up -d で全てを終わらせたいので、 docker-compose.ymlに下記を追記します。 command: /bin/sh -c "cargo watch -x run" 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章の内容について書きました。 この本読んでいると、違う職種の人から開発手法のアドバイスをもらっている気分になってきますね。 最近忙しいので読むスピードが遅いですが、このままお付き合いいただければ幸いです。 その時はよしなに。 .
ITエンジニアがインサイドセールスの白本読んでみた①
2021/08/02 2021/08/14ITエンジニアがインサイドセールスの白本読んでみた① こんにちは。のんです。 今回から、スマレジの営業さんからお貸しいただいた「インサイドセールス」を読んでいこうと思います。 いえーい！インサイドセールスについて呟いたら、 @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を見... まずはどの本にもある、インサイドセールスとは？ですね。 インサイドセールスの3つの役割 SDR（Sales Development Representative） BDR（Business Development Representative） Online Sales この業界にもDevelopmentという言葉が出てくるんですね。 確かに大型ショッピングモールのオーナーになったりする人のことをデベロッパーと呼んでいる営業さんを見たことがあります。モノづくり出身の私からすると目からウロコというか、市場を開拓するという意味でDevelopmentなのでしょうか。 問い合わせやイベントから商談を作るSDR 基本的には短期間で商談機会の獲得を目指しますが、場合によっていは複数回、長期間にわたって見込み顧客との関係性を構築し、必要な条件とタイミングが揃った時点で商談の日程を打診、調整完了後に営業へ引き継ぎます。 営業へ引き継ぎます。ということはSDRは営業では無いんですね。。。 営業をプログラマーと考えるなら、戦略や設計を行うSEに近いのでしょうか？しかもどちらかというと、要望開発に近い。完全請負は次のBDRな気がするので、多分そんな気がする。 ちなみに、BANT情報というのは知りませんでした。 ターゲット企業を選定し戦略的に商談獲得を狙うBDR ターゲット企業を選定し、場合によっては同一企業内で複数の商談機会を獲得すること こちらもSEですが、大企業を相手取るコンサルタントに近いイメージ。それこそSIerに近いと思いました。もちろん、商談を開拓するのかシステムを開拓するのかの違いはありますが、振る舞いは似ているのかも...？読み始めたばかりなので、これから楽しみ。 将を射んと欲すれば先ず馬を射よ。ではなく、将を射んと欲しているから将を射よ。って感じ。自分好み。 当たれば天国、外せば地獄とも思いました。SIerのノウハウが活きそうｗ 基本的にSDRを主戦力に置くイメージ？ 非対面で成約まで完結させるOnline Sales オンライン商談の特徴はなんと言ってもその生産性の高さです。 これはずっと思っていました。営業はしたこと無いのでなんとも言えませんが、個人開発などしている方を多く見てきたので、オンライン会議に限らず営業する方法はたくさんあるのになぁとは思っていました。 こう考えると、コロナというのは良いのか悪いのかわからないですね。 正直、SDRやBDR云々よりこれが一番大きいのでは？？ インサイドセールス3つの配置タイプ 商談のパスだけを行う分業タイプ SDRとBDRだけを配置するタイプ。 最大のメリットは生産性の向上ですが、一方でキャリアを描きにくくスキルアップの機会が少ないのではないかという意見もある。 SEとプログラマーが完全に別れているようなものでしょうか？ SEは要件定義や設計のみ。プログラマーはプログラミングのみを行うような感じ？ 商談の成約までを完結する独立タイプ SDR + BDR ＋ Online Salesの全てを配置するタイプ。 メリットは全てを配置するので、自社部門で全てをまかなえるということ。 デメリットは教育コストの増大と採用コストが上がること。なんなら人材の獲得も挙がりそう？ どの業界でもこれが理想系かもですよね。 SE、UI、UX、App、Back、Front、Infra...全部ほしーｗｗ ターゲット企業の規模や地域によって分ける混合タイプ メリットは状況に合わせた対応が可能になること。 デメリットは業務や予算策定における設計難易度が圧倒的に高いということです。 ターゲット企業だけでなく、自社の都合もありそうですよね。人員が少ないとかで分業や独立タイプを選択できないときに選ばざるを得ないときに採用しそう。 セールスのシステム化を目指しているのに、これを採用するメリットはあまりなさそう。 ここまでで第一章の内容に出てくるキーワードをまとめました。 セールスという枠の中で、営業とは違う部門を作って役割分担をして、よりシステマチックにセールをかけるための部門という印象が強いですね。 私の業界ではフルスタックエンジニアと呼ばれるようになって久しいですが、これを現実にしようとすると課題は山積みで、結局「雑用エンジニア」になってしまうことも少なくありません。実際にフルスタックエンジニアを実現できている方はすごい方ばかりです。 これを避けるために、単にエンジニア、プログラマーと分けるのではなく、インフラエンジニア、バックエンド、フロントエンド...etc。とわけることで、特化した技術を習得し、自分には無い能力を補うためにチームビルディングでグラデーション的にカバーする（スクラム開発）というのが最近の主流です。 私はこれまで、セールスのことを勉強してこなかったので、何もわかっていませんでしたが、セールスにも似たような考え方がありそうです。 上記から、「SDRだから」、「BDRだから」、「インサイドセールスだから」「営業だから」と縦に分けるのではなく、担当を分けた上で、チームに所属するメンバーとして、SDRとしての能力を存分に活かす...のような運用方法の方がこの考えを導入するメリットを最大限活かすことができる、スクラム風な運用ができると考えました。......違う畑から見た感想ですが😅 まだ採用の章は読んでないのでなんとも言えませんが、今後の採用は「営業職募集！！」ではなく、このような「〇〇セールス募集！!」みたいに明確にわけるのが常識になるのかもとも思いました。（もうなってる？セールスエンジニアとは違う意味で言いました。） 最後に 今回は違う畑の専門書を読んでみました。 読んでいて思ったのは、エンジニア視点で書いた白本の感想というのは意外に少なくないのかも... 考え方がエンジニアのチームビルディングとの共通点が多い。 多分ですが、すでに既存のエンジニアも興味をもって読んでいる可能性があると思いました。 この本は借り物なので、連載できるかはわかりませんが、引き続き読んで記事にしていきたいと思います！ その時はよしなに。 .
Z250で千里浜〜能登半島ツーリング！
2021/07/31 2021/07/31Z250で千里浜〜能登半島ツーリング！ こんにちは！ のんです。 今回はツーリング記事となります。 マスク常備＆ヘルメットということでコロナ対策はバッチリ行ってからのツーリングです！ 今回の目的地は2泊3日で国道8号線を主に使った千里浜〜能登半島ツーリングとなります。 積載の都合でお土産は買えませんでしたが、きれいなバイクの写真を代わりに御覧ください！ トラブル💥〜出発 出発当日。朝、相方から一本の電話が... 「バイクが動かん💥💥」 😇😇😇 とりあえず症状とかを調べて、「多分バッテリー上がったんやろな」という結論になりました。 バッテリーをとりあえず購入しにいき、載せ替え作業をしました。 バイク、無事起動する。 よかったぁ〜〜。 すでに時間は13時...出発予定から4時間後の出来事でした。 でも、バッテリーの載せ替えとか面白かったし別にいいけどねｗ サクッと昼飯を食べてから、高速ワープを使いつつ、加賀周辺までGO 夕暮れのしおかぜライン 怪我の功名という言いますか、出発が午後からだったというのもあり、しおかぜラインを走っている時間にちょうど夕暮れに🌅 相方がカメラを買った。（身内でカメラ流行ってる〜〜ｗ） だけどこれはブログ用に軽量化しているから荒いかも... うーんそれにしてもかっちょいいバイクだ。 この日はほとんど走りっぱなし。 いい道なので無限に走れるなぁ...と思いました。 千里浜なぎさドライブウェイ 千里浜（ちりはま）なぎさドライブウェイ|羽咋市公式ホームページ 羽咋市で一番オススメの観光スポットです！千里浜（ちりはま）なぎさドライブウェイは、全長約8キロメートルの砂浜ドライブウェイ。自動車はもちろん、バスやバイク、自転車でも、砂浜... 今回のツーリングの本命 千里浜なぎさドライブウェイ です。 相方の強い要望により、今回のツーリングのメインディッシュでした。 砂浜を走れるのですが、正直バイクは怖かった...ｗｗ 地面が海水でぬかるんでいるので、走行にはご注意ください⚠️ 写真撮影にはスタンドを支えるボードの利用を推奨します⚠️ 地面がぬかるんでいるということは、サイドスタンドで止められないということ😇 いや〜、写真取るために色々工夫しましたｗ多分1時間位試行錯誤しましたね。 泥道用のスタンドや、その補助ツールの持参を強く推奨しますｗ その頑張りの結果がこちら！！すごい！！ 相方が、かなり引きで撮影してくれました。 私の姿がちっぽけですね。 人なんてそんなもん。 すごい写真ですねｗ舗装されていない道にストリートのバイクが停まっているｗｗ ちなみに、オフ車結構多かったです。 相変わらず写真写りのいい相方 きっとカメラマンが良いんですね（自画自賛） 悔しかったので自分も同じポーズで撮影しました うーーーーん😇😇 いやぁ楽しかったです。 でも、 海岸保全対策の推進 千里浜は年々短くなっているそう。 行くなら早めにどうぞ。 千里浜海岸は、羽咋市～宝達志水町に位置し、日本で唯一、世界でも珍しい、車で走行できる砂浜海岸で、「千里浜なぎさドライブウェイ」として、石川県にとって後世に残すべき貴重な観光資源ですが、昔に比べ砂浜幅が年々狭くなってきており、砂浜を保全するために人口リーフや、砂の供給を行っています。 輪島でご飯 たしか...このへん... 県全体でカレーが有名ということでカレーを食べました。 輪島市は、「ライダーを笑顔で歓迎する都市」宣言を出しているらしく、そこかしこでJAF会員の恩恵を受けられます 持参を推奨です！電子版なら簡単ですね！ 能登半島の輪島市が「ライダーを笑顔で歓迎する都市」宣言！ 同市のモーターサイクル親善大使として冒険家・風間深志氏を任命 - webオートバイ ツーリングの目的地にしたい場所がまたひとつ増えました！石川県輪島市は、2019年1月23日、東京永田町の都道府県会館で「ライダーを笑顔で歓迎する都市」宣言を行ないました。宣言文を発表したのは、自身も大... 道の駅の名前忘れちゃった... ふぐがおいしいらしい。 そこで食べたカレーがこちら。おばちゃんいわく、バイクだそうです。 ふむふむ...バイクとな...🤔🤣 ボリュームもあり、美味しかったです！ 昼飯後、グロッキーになる自分 めちゃ眠かった〜〜ｗｗ 中日はこんなもんでした。本当は能登半島の先端の「狼煙」も行きましたが、それはこちらの記事↓ですでに紹介済みなので、良かった見てください。 Z250での冒険日記 | のんラボ 定期的にこんな感じの記事も追加して行くと思う。4月27日〜29日 西日本一周ツーリングこれはお友達と弾丸ツーリングに行きましたZXR1200のパワーを見せつけられましたね。鳥取砂丘写真は撮影してないけ... 最終日は帰り道。寄り道しながら帰りました 東尋坊 東尋坊もすでに紹介済みでしたね。 高くて怖い。 海岸線を走っているときに休憩した場所で砂像を発見！！ かわいい 最後に 今回はツーリングの記録でした。 やっぱりツーリングは楽しいですね。 こんな感じで技術記事だけでなく、不定期でバイクの記録も残しています。 良かった見てください。 次回は...Rustの勉強をしているので、その記事を書けたらいいかなぁと思っていますが、どうなるかな。 その時はよしなに。 .
RustでHello Worldやってみた
2021/07/18 2021/07/18RustでHello Worldやってみた こんにちは。のんです。 今回は前々からやってみたかったRust言語の勉強をしようと思って、やったことを記事にしてみました。 Rustに関しては本当に初心者なので、内容は間違っているかもしれません。今後のアップデートにご期待くださいということで... GitHubのリポジトリ GitHub - nonz250/rust-sample Contribute to nonz250/rust-sample development by creating an account on GitHub. 勉強用のリポジトリはこちら。 Hello Worldまでの道のり 正直Rustの開発環境をどのように作成するのかノウハウがなさすぎて非常に困りました。 というのもまともに触ったことのあるコンパイラ言語C#（.NET Framework）のみで、VisualStudioにすべてを任せていて、それ以外の言語の開発環境を作ったことがなかったのです。 Dockerイメージの選定 とりあえず、DockerHubにある公式のイメージを選択。 軽量OSのalpineで作成されている↓を利用しました。 https://hub.docker.com/_/rust https://hub.docker.com/_/rustを見る コンテナ ./app:/app:cache rust_dev_target:/app/target とりあえずソースコードが載るappを同期し、とバイナリが載る/app/targetをvolumeとして設定しただけの簡素なコンテナです。 app: container_name: app build: context: ./ dockerfile: Dockerfile volumes: - ./app:/app:cache - rust_dev_target:/app/target working_dir: /app volumes: rust_dev_target: driver: local ビルドなどに必要なファイルを設定 どうやら、ビルドするためのcargoコマンドにはCargo.tomlが必要らしいので、公式ページなどを見様見真似で作成。 [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] [[bin]] name = "sample" path = "main.rs" ぶっちゃけ内容は謎。 Cargo.lockというファイルが自動的に作成されたが、これも謎。Rustのパッケージ管理をcargoがしてくれるのだろうか。と推測するくらいしかできない。 ともあれ、今回の目的はHello Worldを出すことなので、この勉強は次回にまわします。 ソースコードを記載 main.rsに下記を記載 fn main() { println!("Hello, world!"); } ビルドと実行 cargoが動作するコンテナを用意したので、ビルドや実行はコンテナ経由で行います。 docker compose run --rm app cargo build でビルドし、 docker compose run --rm app cargo run で実行。 docker compose run --rm app cargo run Finished dev [unoptimized + debuginfo] target(s) in 0.08s Running `target/debug/sample` Hello, world! なんとかHello Worldまでたどり着くことができました。 最後に コンパイラ言語の経験が少なすぎて、WEBで利用するときの完成形が想像できないのが非常に辛い。完成したコードのバイナリを実行して、待機させるイメージなのは想像つくけども、それを具体的な手順が想像できない... この辺が得意な方に色々教えていただく必要があるかもしれないなぁ。 次回からはこのコンテナを利用して簡単なチュートリアルをしてみようと思います。 あとは、リクエストをさばいてみるということもしたいかも。nginxとどのように連携することになるかは想像つかないので、ここもひとつ大きな壁になりそう... 頑張りましょう。 次回のRust記事はいつになるかわかりませんが、また記事にします。 その時はよしなに。 .
検閲なし！スマレジってどんなところ？に回答するシリーズ！【インタビュー編】
2021/06/02 2021/06/27検閲なし！スマレジってどんなところ？に回答するシリーズ【インタビュー編】 こんにちは。のんです。 今回は私が勤めるスマレジの採用PRとなります。 https://corp.smaregi.jp/recruit/students/2023/ https://corp.smaregi.jp/recruit/students/2023/を見る 採用情報 | 株式会社スマレジ 企業サイト 株式会社スマレジの採用に関する情報です。「めちゃくちゃ良い！」が溢れる会社を目指して、当社が取り組む採用活動についてご紹介しています。募集職種や社員紹介をご覧いただけます。 弊社にはブログ手当という 開発関係のブログ記事 スマレジに関する記事 を書いていると月いくらかの手当をいただけるという制度があります。 私もその対象となっており、ふと、「スポンサーみたいなことをしてもらってるし、採用のお手伝いでもしようかな。」 と思ってPR記事を 勝手に（超重要） 書こうと思いました。 今回はよくある質問編ということで、カジュアル面談などでよく聞かれる内容について 公開できる範囲 で回答していきます！ 今なら就職お祝い金がもらえるよ！ スマレジHPの採用ページから先行を進んでJoinしていただいた方には就職お祝い金が支払われます！！ 是非、応募してみて下さい！！ TwitterでDM頂いても大丈夫です！ 今回は弊社の採用PR記事になります！現在スマレジでは新しい仲間を募集中です！私はバックエンドエンジニアとして勤めていますが、どのように働いているかとか書いたつもりです！気になる方はDMして下さい👍https://t.co/s8DmEaEj0E#のんラボ#バイクに乗るエンジニア— のん🐘夜型言語 (@nonz250) March 28, 2021 では早速回答を始めます。 自己紹介 こんにちは。のんです😃 業界に入ってどれくらい？ 2021年07月で、大体6年くらいになります。 ちなみに中途採用です。 前職では何をしていた？ とある医薬系ソフトウェアハウスで、電子薬歴や、症例登録システムの開発をしていました。 電子薬歴の開発 レセコンとの連携機能 出退勤機能との連携 症例登録システム 登録マスタ管理システム 統計処理システム とか 小さいベンチャー企業だったので、システムの雑用的なこともやっていましたｗ パソコンのセットアップ エクセルの使い方レクチャー 開発システムの運用/サポート とか 今はどんな業務をしている？ スマレジ・アプリマーケット スマレジ・アプリマーケットはスマレジにアプリを自由にダウンロードし、お好みの機能をスマレジに連携することができるスマレジ専用のアプリストアです。モバイルオーダー、EC、ポイント連携、在庫・顧客管理、予... スマレジ・デベロッパーズ - スマレジとコラボしませんか？ スマレジの次期バージョン「スマレジ4.0」がリリースされます。「スマレジ4.0」では、開発パートナーが参加することができるスマレジプラットフォームを構築。スマレジのAPIを活用したアプリを販売できるス... スマレジ・ユーザーリクエスト - スマレジに欲しい機能を要望に出しませんか？ スマレジ・ユーザーリクエスト - スマレジに欲しい機能を要望に出しませんか？を見る スマレジ・デベロッパーズ・コミュニティ スマレジ4・プラットフォームAPIについての技術的なコミュニティサイトです。APIの使用方法や、認証方法、アプリ作成のための知見を共有するためのコミュニティサイトとなっております。 この辺の開発をしています。 後半２つは外注したり、OSSを利用したりしているので、どちらかというと管理という感じです。 利用している言語や、ツールなどは 検閲なし！スマレジってどんなところ？に回答するシリーズ！【よくある質問編】 | のんラボ スマレジってどんなところ？に回答するシリーズ【よくある質問編】こんにちは。Nonです。今回は私が勤めるスマレジの採用PRとなります。 ... を見てください👀 趣味は？ 休日はもっぱらツーリングしています。 このブログにツーリング記事たくさん載せているので、ぜひ見てみてください🏍 Z250でしまなみ海道ツーリング！ | のんラボ Z250でしまなみ海道ツーリング！こんにちは。のんです。今回もツーリングの記事になります。技術記事更新してなくてごめんね🙏今回はしまなみ海道へ行ってきました。尾道へレッツゴー！お昼ごはん赤穂ICで降り... 部のミッションを教えて下さい 部のミッション...難しい質問ですね。 私が所属しているのは開発部となります。 ご存知の通り、開発部は スマレジ・POS スマレジ・ウェイター スマレジ・タイムカード などの主要システムや、それに付属するシステム（スマレジ・デベロッパーズとか）の開発をします。 弊社は自社アプリを開発する会社ですので、開発の上で重要視されるのは、お客様の要望をできるだけ迅速にできるだけ正確にお届けすることになります。 これがとても難しく、お客様のためと思った機能が実は使われなかったり、違う使い方をされたりすることもままあります。なので、どのような機能がよく使われて、どのような機能が使われないのかを分析したりすることもあります。 そのために、これまでの取引情報を分析するチームもいます。募集もしていますよ😃 取引情報などの会社概要はこちら 株式会社スマレジ 企業サイト 株式会社スマレジは、インターネット社会においてデザインとテクノロジーを駆使して「いい未来をつくる」ことを理念としたテクノロジー企業です。レジ、自販機、券売機、eコマースなど、世界中に広がる販売データの... 日々の業務内容 では、具体的に毎日どのような業務をしているのかという質問に回答させていただきます。 社内メンバーの全てが同じスケジュールではないので、以下は私の場合、ということになりますので、ご注意ください。 基本的に私は１人 + 委託メンバーで色々な作業をこなしているので、気持ちミーティングが少なめな感じですね。 08:00 〜 10:00 出社 10:00 〜 17:00 がコアタイムなので、出社時間には幅があります。大体09:30くらいから出社する方が多い印象です。 10:30 〜 11:00 デイリーMTG 委託メンバーとのミーティングを行います。本日の作業内容や、現在困っていること等を共有 / 解決する時間になります。 このようなミーティングは必ずメンバーが居る時間帯に行われる事が多いので、ご安心ください。 たま〜に時間がなくて、早い時間や遅い時間にミーティングがあることもあります。 11:30 〜 12:30 ランチ 12時から±1時間位でランチです。 11:30〜からランチをとる人が多い印象。 リモートになってからは12:00〜からが多いかもしません。 13:00 〜 17:00 開発業務 開発業務は大体この辺で集中的にしていますね。 もちろん、午前中にサクサクするときもありますが、こういうのは出社時間をコントロールして調整することもあります。 業務中は片耳イヤホンOKです。リモートになってからは、正直音楽聴きながらって感じですね。監視システムとかも無く、自由度は高いです。 17:00 〜 19:00 退社 この時間帯からチラチラ退社する方が出てきます。 のんさんにとってスマレジとはどんな会社ですか？ わりと自由度高い会社 前職は医薬系ということもあり、結構厳しい会社でした。 自由ではあったんですが、お客様は医師や薬剤師。しかも命を預かる方々やシステムを相手にするので、納期やミスに対して厳しかったです。 スマレジはいい意味でミスに寛容ですし、納期もある程度融通が効きます。 逆に言えば、計画を自分で決めたり、要件定義をする必要なことなので、指示待ちになってしまう方には結構難しいかもしれません。自由度が高いからこそ。ですね。 また、音楽を聞きながらとか、副業がOKだったり、やりたいことはやらせてくれるイメージです。 最近では、おかげさまで資金的な余裕も出てきて、新しいサービスやインフラを利用できたり、技術選定にも幅が出てきました。 結構ドライなイメージ 従業員同士がプライベートなことに突っ込んでくることはそんなにないイメージです。昔ながらの家族経営というか、そういうアットホームな感覚は無いイメージです。 もちろん営業さんなどは傾向上、プライベートでも遊びに行っていますし、開発でも定期的に何かイベントをしている方々も居ますが、強制では無いです。 その分お昼にはランチ会制度があり、会社から1,000円給付され、特定のメンバーでランチに行く制度があります。（コロナ禍で一旦中止） 仕事とプライベートは別々にしたいという方や、ぶっちゃけ定時ダッシュしたい方にはオススメです。 エンジニアとして、色々な繋がりはできるかも...？ 実は社内で仕事のやり取りがあります。チームを組んで、アプリを作成したり、HPの作成をしたり、家庭教師したり... これはスマレジの業務では無いので、噂で小耳にはさむ程度です。 私も受けた事が数回あります。 スマレジに入社して最も苦労したこと スマレジ・デベロッパーズの開発ですね。 外注に出していたのですが、その納品内容がひどく、その改修をしながら新規要望の追加などを行っていました。ローンチまでの時間も当初の予定どおりで、改修がなければ...というところだったのですが、ほとんど作り直しでした。 短い開発期間でローンチに耐えうる内容にするのは結構大変でした。 どう乗り越えてきたか 丁度このときに、ドメイン駆動設計という設計手法について勉強していたところで、単に実装するのではなく、今後のことを見通した設計をすることで、仕様変更や、機能追加に強い実装になったと思います。 機能追加・変更時にできるだけバグを出さずに迅速にリリースできるようにしたおかげで、大きな手戻りなくローンチ・リリースができたと思います。 とは言っても、まだまだ荒削りなところがあるので、ちょいちょいコードのリファクタリングをしています。 ちなみに、ドメイン駆動設計の勉強は社内の有志の勉強会で行っていました。この辺も記事にしていますので、見てみてください。 会社でドメイン駆動設計入門の読書会 #1 | のんラボ 会社でドメイン駆動設計入門の読書会した話こんにちは。Nonです。今回は会社で読書会をしている話をしようと思います。次回： ... 部が目指す１年後、3年後、10年後の姿 これもまた難しい質問ですね。 私の主観や、もし私だったら...という回答になってしまいますが、ご容赦を。 １年後 如何せん、人数が少ないです。 採用強化して、チーム開発を更に推し進めて行きたいと思います。 特定のチームはすでに本格的なスクラム開発をしており、着々のチームビルド進行中です。 今から入る方はこの辺のチームビルディングに根本から関われることになります。 3年後 チームが完成され、それぞれの開発ルールが確立されていることだと思います。 スクラムが必須というわけではなく、それぞれのチームがやりやすい方法を確立し、それに従ってメンバーが働けるようになっていると、より長期間システムが安定して動いていると思います。 このあたりから、比較的古いスマレジのシステム刷新が本格的に進んでいければと思います。 そのためには日々新しい技術に興味を持ち、自発的に学習できるメンバーが揃っていることも条件に入ってくるかもしれません。今はチームによってバラバラなので3年でこの気持ちも揃ってくればいいと思います。 10年後 システム刷新が全て済んでおり、それぞれのシステムが互いに影響を持たないようにできていると嬉しいです。 チームメンバーもマネジメントを得意とする方、技術を得意とする方でチームができており、ほとんどの意思決定をチーム内で行うことができるくらいになっていると良いなと思っています。 どんなメンバーと一緒に働きたいか 上記を目標としているので、 自分の開発しているシステムに愛着を持てる方 と一緒に働きたいと思っています。 なぜかというと、やはりクリエイティブな仕事で良いものを作るためには愛着は必要だと思うからです。 愛着があるから、システムの欠陥を見つけることができるし、 愛着があるから、機能追加に積極的になれます。 無関心なシステムを開発していてもモチベーションを上げることはできません。結果的に良いものはできないと思っています。 もちろん、技術に興味がある方にも入ってきてほしいですが、順位でいうと、これは2番目ですね。 技術は後からついてきますが、熱意はついて来ないとも思っています。 部のカルチャー（風土）を教えて下さい これまた難しい質問ですねｗ 今の所チームの風土という感じになりますね。 あくまで私目線ということをお忘れなく。 POSチーム スマレジの大黒柱のチームですね。 ここは連携というか、話し合いの濃いチームとなります。 最優先事項は組織内連携です。 カスタマーサポートとの連携 営業との連携 請求管理との連携 少し考えるだけで、これだけの連携と意思決定があります。 特徴といえば、やはり対人スキルでしょうか？POSチームには人と話すのが上手な方が多い印象です。面倒見が良いというか、人当たりが良いというか。 Waiterチーム ここは技術力のあるリーダーがいるチームです。 メンバーもそのリーダーに引っ張られるように技術力に関心が高く、機能実装をする際にそのようなつぶやきがSlackでよく見られます。 このチームの特徴は技術重視で安定稼働を目標としているところだと思います。 Timecardチーム とても穏やかな方々がメンバーとして揃っている印象です。 また、法律関連にノウハウが無いと実装できないチームでもあるので、技術だけではなく法律の勉強もできる方もいます。 最近、新しくシステム刷新を行っている最中なので、一番最新の技術に触れられるチームでもあるかもしれません。 求職者の方にメッセージ & 座右の銘 私の座右の銘は 「全身全霊」 です。 やけっぱちを起こすとか、根性見せるとか、そういうものではなく、自分の持てる技術の幅を広げ、その全てを自分の作りたいシステムに投入できる。 そのようなエンジニアの方と一緒に働きたいです！ 色々な技術に触れたい！ 自分のアイデアを商品として実装したい！ こんな方は一度応募してみると良いかもしれません。 最後に 今回はPR記事でした。 スマレジは新しい仲間を募集中です！ これからも色々なことを実現するために、是非この記事を読んでいるあなたの力を貸して下さい！ 今なら就職お祝い金がもらえるので、こちらのページからの応募も忘れないように！ 採用情報 | 株式会社スマレジ 企業サイト 株式会社スマレジの採用に関する情報です。「めちゃくちゃ良い！」が溢れる会社を目指して、当社が取り組む採用活動についてご紹介しています。募集職種や社員紹介をご覧いただけます。 私からも案内しますので、良ければTwitterにDMしてください！！ 今回は弊社の採用PR記事になります！現在スマレジでは新しい仲間を募集中です！私はバックエンドエンジニアとして勤めていますが、どのように働いているかとか書いたつもりです！気になる方はDMして下さい👍https://t.co/s8DmEaEj0E#のんラボ#バイクに乗るエンジニア— のん🐘夜型言語 (@nonz250) March 28, 2021 次回はツーリングの記事になりそうですかね。 その時はよしなに。 .
