「エンジニア」の記事 - Crieit

📔 マイペースに技術研鑽を継続する方法

2021-06-26T20:44:05+09:00

Image by Hans Braxmeier from Pixabay

はじめに

技術研鑽のための行動が習慣化して確立してきたので、また困り始めた時に参照するための備忘録的な感じで、習慣化に至るまでの流れを記事化しておくことにしました。自分の中では努力していると一切感じず自然に技術研鑽及び技術者としてのプレゼンス向上のために行動できるサイクルができた印象です。

昔から色々なやり方で上記の習慣化にはトライしていたものの、全てが長続きしなかった自分でも継続できるやり方なので、ある程度の再現性はあるかもしれません。(が、あくまでも自分のやり方にはなります。。🙃

ちなみに本記事の内容を推敲していたところ、最近読んだ心理的安全性のつくりかたに出てきた 「きっかけ・行動・みかえり」 のパターンになっていることに気づきました。

技術研鑽のサイクル

自分で自分のモチベを保ちつつ、自然な技術研鑽サイクルとして定着したフローを説明していきます。

「きっかけ」：実現したい開発アイデアが浮かぶ

Image by Hans Braxmeier from Pixabay

個人的に突発的にコレ作れたら面白そうとか、自分はコレがあったら便利だなっていうアイデアが浮かぶことがあるのですが、大体そのアイデアを本気で実現したいと本当に思えるピークは体感最長でも 3-4 日くらいです。 そのため、アイデアを具体化して開発に着手するまでの期間としては 3-4 日以内を目安に考えています。

アイデアが思い浮かんでから長く期間が空いてしまい、具体化する気が無くなってしまった場合はメモアプリにアイデアをストックしておきます。 それらを見返すとより有益なアイデアが浮かんだりするので今後のきっかけ作りに有効活用できます。

また、 開発のアイデアについてですが、プライベートだけでなく仕事で開発しているシステムの新機能/改善案等もアイデアとして扱うことが可能です。 自身の仕事の質向上にもつながりますし、行動を起こすためのきっかけ作りとしても利用できて、技術検証や実装等は業務時間で行えるため割とオススメの方法です。

当たり前ですが NDA に触れるような内容を自身の成果として公開してしまうのは絶対にダメです。あくまでも一般的な技術知識のみを自身の得た知見として公開するというスタンスです。

「行動」：開発アイデアを検証可能な形で実装する

Image by Sasin Tipchai from Pixabay

開発では、とにかく動作確認が可能な形で実装を行うことに注力します。細かい設計などは置いておいて仮説検証を優先していくイメージです。 そのため、技術選定は何基準でも問題ありませんが、アイデアの内容によってそこら辺の技術基準は変えていくのが良いと考えています。

例えば、プラグインやライブラリの開発については使い慣れた言語や業務で利用している技術を選定すると、知識や知見を深めることに繋がりやすかったです。サービス開発については初期は触れる技術領域が広く浅くになりがちなので、新しい技術など使い慣れていない言語などを採用して知識や知見を広げることを意識すると最後まで楽しく開発できました。

技術研鑽という名目で取り組む開発なので、完成を目指す必要はありません。しかし、成果物として完成させることを目指したいという場合は、モチベーションを絶やさないようベースとなる機能の実装を短期間で行うことを意識します。ベースとなる機能の実装というのは、一通りそのシステムの動作検証を他者が行える状態を示します。システムの動作検証を他者が行える状態まで持っていければ、正しく成果物が評価できる状態になっているはずだからです。

まとめると、モチベを保てるやり方を意識して技術選定を行い、具体的な成果物を意識してベースとなる機能の実装を短期間の細かいサイクルで進められると、満足感のある形で開発を進めることができました。

「みかえり」：過程で得たもの全てをアウトプットする

Photo by Greg Rakozy on Unsplash

成果物の公開だけでなく、その開発を通して得た知見や知識及びソースコードなど全てアウトプットします。行動の途中だとしてもモチベが下がってきたら、みかえりのフェーズに移行します。例えば、成果物で言うと、ストア公開するだけでなくソースコードも GitHub の公開リポジトリにアップします。知識や知見などは技術ブログで記事化してまとめて公開します。 他者の目に触れる場所へ公開することを意識すると、アウトプットの質を高めるモチベに繋がります。 承認欲求を満たすためではなく、あくまで自分のアウトプットの質を高める施策の一貫として考えます。

上記を意識するとリファクタリングやベスプラに沿った開発ができているか等のチェックに繋がり、知識や知見をより深めることに繋がります。記事化も同様で、文章として知見や知識を残す過程で正しい内容なのか、本当に正しく動作するソースコードが書けているかに意識が向くため、誤った知識の修正や復習に繋がります。

成果物だけでなく身につけた技術も含めて全てをアウトプットすることで、余すこと無く行動した結果を有効活用できます。このサイクルを何回か行い習慣化してくると、インプットした内容を全てアウトプットしきるための行動が自然と起こせるようになっていきました。アウトプットする過程できっかけが生まれて更に行動することにつながっていくという流れも生まれました。

具体例としては、シンプルなプラグインを作っていく過程で、ライブラリ化やモジュール化した方が良い機能がでてきたので、別リポジトリに切り出してパッケージマネージャーからインストール可能にしました。また、業務で特殊な事情で取り組んだ開発内容を新たな知見として記事化してアウトプットを増やすことができるようになりました。

ちなみに私はアウトプットする手段としての記事化には重い腰が中々上がらない人間だったのですが、堤修一さんの Youtube 動画と同様の考え方に自然に至りました。

全てが自分のやった成果として目に見える形で残っていくので、後から見返したときに自分の実績として実感が湧きやすく、作りっぱなしで終わっていた頃と比べると相当な達成感を味わうこともできます。ゲームでいう様々な実績を解除してくような感覚に近いかもしれません。🎮

おわりに

現状個人的には上記のサイクルが上手く機能していて、最近習慣化の軌道に乗った感じが自分の中にあったので知見として記事化しておくことにしました。今後、上記サイクルについては改善を繰り返しながらアップデートしていきますが、一旦現状の内容を後から見返せるようにしました。

また今回始めて記事内でイメージ画像をふんだんに使ってみましたが、画像探すの楽しいし記事のクオリティが上がったと錯覚できるので、今後もポエム記事については積極的に画像を利用していこうと思いました (違

この記事内容がどなたかの行動を起こすきっかけとなれれば幸いです！🙏

Moonlander というエルゴノミクスキーボードのススメ

2020-12-13T07:09:50+09:00

はじめに

Moonlander の画像 (色は白か黒を選ぶことが出来る)

最近 ErgoDox EZ からの乗り換えで Moonlander というエルゴノミクスキーボードを使っているのですが、諸々非常に満足しています。コンパクトながら安定感のある打ち心地でカスタマイズ性も高く、試行錯誤しながら自分好みにセットアップして使い勝手を最適化することができます。

バックライトがあり、デフォで様々な光り方が用意されているのも非常にカッコよいです。あまりキーボードのバックライトを気にしたことは今まで無かったのですが、何となく 1日毎にエフェクトを切り替えると良い気分転換になります。なんとなくだけど。。ｗ

また、これについてはエルゴノミクスキーボード全般に言える話で Moonlander に限った話では無い気がしますが、体がこわばった姿勢にならなくなり、肩が開いてリラックスした姿勢でタイピングできます。

そのため、長時間 PC で作業していても、呼吸が浅くなりづらく、肩への負担も少なく感じます。現に筆者はキーボードを変えただけで生活習慣変えた覚えがないにも関わらず、長時間作業しても疲れにくくなりましたし、肩こりになりにくくなりました。
毎年冬になると肩こりになる体質だったのですが、ErgoDox EZ を採用し始めてから肩こりに悩まされることは無くなりました。

今回はそんな気に入って仕事プライベート問わず酷使している Moonlander についての紹介記事を書いていこうと思います。

ちなみに筆者はキーコンフィグを軽くカスタマイズしている程度のライトユーザーです。

セットアップが簡単

Web から簡単にキーコンフィグを設定することが可能です。キーコンフィグ設定のためのサービスは Ergodox EZ Configurator というやつです。名前に Ergodox がついていますが ZSA Technology Labs から購入可能なキーボード全てに対応しています。(Moonlander にも Planck にも対応)

今回は Moonlander Mark I を利用する

Search layouts ボタンをクリックすることで、他の人が既にカスタマイズしたキーコンフィグをダウンロードしたり、そのキーコンフィグを元に自分用のキーコンフィグをカスタマイズすることも可能です。
ちなみにデフォルトのキーコンフィグは Configure ボタンをクリックすると確認することができます。もちろん、そこからキーコンフィグをカスタマイズしていくことも可能です。

また、カスタマイズした設定内容は常に Ergodoz EZ Configurator に保存されるので、後から細かくキーコンフィグを修正していくといったことも可能です。最初のうちは頻繁にキーコンフィグに微修正入れると思うので、めっちゃ便利でした。

Ergodoz EZ Configurator の Search layouts で "coding" で検索した結果

ちなみに僕が使用しているキーコンフィグはこちらです。他の方々のキーコンフィグと比べると大分シンプルですが、その分初見の方でも扱いやすいコンフィグだと思います多分...

キーコンフィグの更新も簡単

キーコンフィグの設定が完了したら Wally というツールを使ってキーコンフィグ設定を実際にキーボードに反映させることが可能です。余談ですが、Wally は Go言語で作成されていて GitHub でソースコードが公開されています。

Wally のトップページからツールをダウンロードする

Wally アプリを起動したら、Moonlander を接続していれば認識されている様子が確認できるはずなので、 Ergodox EZ Configurator で生成してダウンロードした bin ファイルを Wally アプリウインドウ上にドラッグ & ドロップします。

Wally を起動してダウンロードした bin ファイルをドラッグ & ドロップする

その後、リセットボタンの入力を求められるのでキーボード左上の小さな穴内部にあるボタンをクリックするか、アプリ右下の Reset をクリックします。これだけでキーコンフィグを反映させることが可能です。

ちなみにリセットボタンはキーコンフィグで特定のキーに割り当てることも可能です。

デュアルファンクションキーが便利

例えば Shift や Ctrl キー等について、特定キーを長押しすることで発火させることが出来るような機能です。これはシンプルなのですが、個人的に非常に強力で一度慣れると普通のキーボードにも設定したくなるレベルでした。

F キーのデュアルファンクションキーの設定内容

例えば A キーもしくは；キーを長押しすると Shift キーの振る舞いになるよう設定していると、プログラミングしている最中キャメルケースで変数を書く時に、ホームポジションから、一切指を動かさずに楽に英語を大文字入力することが可能です。

また L キーもしくは S キーを長押しすると Win/CMD キーが発動する様にしているのですが、そのおかげで Windows では作業中、特定アプリを起動したい時に L キー長押しで出てきた Win メニューから文字列検索でサクッと特定アプリを起動することが出来ます。この間も指は一切動かさずに済みます。

デュアルファンクションキーは Ergodox EZ Configurator で Modify layout 中に、該当キーをクリックして出てくる、Keys タブから行うことが可能です。

デュアルファンクションキーの設定方法

上記のおかげでマウスに触る頻度も低くなり、結果としてキーボードで色々な操作をやり繰りしていると PC での作業効率が非常に上がりました。

レイヤーを用いることでキータイプの効率を向上させる

Moonlander にはレイヤーという概念があり、各種キーの動作をマルっと差し替えることが可能です。例えばレイヤー1 には通常通りの英字入力を割り当てておき、レイヤー2 には特殊文字や記号入力を普段打ちやすい位置に割り当て、レイヤー3 にはネットサーフィン用にマウス操作やブラウザ操作等を割り当てておくことが可能です。

レイヤーの確認および設定方法

この設定を切り替える方法も様々用意されていて、例えば特定キーを押しっぱなしにしているとレイヤーが切り替わるように出来たり、特定キーを押したらもう一度同一キーをクリックしない限り、そのレイヤーが適用され続けるといったことも可能です。

設定を切り替えるためのキーコンフィグ (レイヤースイッチ)

ちなみに上記のレイヤー設定の例は筆者が現在利用しているキーコンフィグです。基本レイヤー1が常に使われ続ける設定で、レイヤー2 には親指周辺のキー押しっぱで切り替わるようにしております。レイヤー3 は一度特定キーを押したら反映され続けるようにしていて、ネットサーフィン用の設定を割り当てられています。

レイヤーは最大 32個まで設定可能らしいですが、筆者はフルで設定されているキーコンフィグには未だ出会ったことがありません...w

よく聞かれる質問

エルゴノミクスキーボードを使っていると良く 「何が良いの？」「普通のキーボードが打てなくなるんじゃない？」「タイピング速度は速くなるの？」 等色々聞かれることが多いので、今回はそれらのよく聞かれる質問について自分の回答をまとめてみました。

Q. どれくらいの期間でエルゴノミクスキーボードが実務でも使えるくらいに習熟した？
A. 英字は最初から問題なく打てましたが、記号については慣れるまで 2-3週間くらいはかかった記憶があります。 慣れるまでは、自分の設定したキーコンフィグを何回も見返して照らし合わせながら打ってたので尋常じゃなく打つの遅かったです...

Q. いつも使ってる普通のキーボード打てなくならない？
A. 僕は最初会社では通常キーボードで家では ErgoDox EZ で特訓していたのですが、確かに最初のうちは混乱して頭の切り替えまでに 20分くらいは要してました。ですが、大体 1ヵ月程度で勝手にキーボード触る時に頭がそのキーボード用の操作にスイッチされるようになりました。今ではどちらのキーボードでも全く問題なく打ててます。
キーコンフィグを常にライトにしているせいもあるかもしれません。

Q. キーコンフィグはデフォルトのままでも大丈夫？
A. デフォだと英字配列になっているのと、一部キーが特殊な振る舞いをするように設定されているので、最初にそこら辺のキーを整理しないと普段使いにはキツいと思います。そのため、無理にデフォ設定を使用するよりも、キーボードが届いたら真っ先に自分用のキーコンフィグを行うことをオススメします。ちなみに最初のうちはキーコンフィグの設定にめちゃくちゃハマって色々細かくチューニングしまくって時間溶けまくってたのですが、筆者は最終的にシンプルな設定に落ち着きました。

Q. 肩こり解消にもなるって本当？
A. 僕は肩こり改善しました。運動は普段一切しないし、通常キーボードで日常業務していた時は常に PC と向かい合っていて慢性的に肩が緊張状態で肩こり気味だったのですが、分割キーボードにしてからは肩こりになったことは通年でほぼありません。

Q. タイピング速度は速くなる？
A. タイピング速度が早くなったかは分かりませんが、打ち間違いは減りました。 手が小さいのも関係しているかもしれませんが、基本ホームポジション中心にキーを配置して、配置しきれないキーはレイヤー分けしてホームポジション中心に配置しているので指の動きが常に小さくなったのが関係しているのかもしれません。

おわりに

最初購入して届いたときは不安でしたが、真っ先にキーコンフィグを普段使っているキーボードと同等にしてから、徐々に自分用のキーコンフィグにカスタマイズしつつ、寿司打等でキータイプ練習および実際のプログラミングで記号入力の練習をしていれば、大体 1-2週間くらいで実践投入可能になると思います。

一旦慣れてしまえばタイピングしていても、体がこわばった姿勢にならなくなるので疲れにくくなりますし、肩も開いてリラックスした姿勢でタイピングできるので呼吸もしやすくて、肩への負担も少なく感じます。

キーボードが分割されているので、恐らくブラインドタッチも身につくと思います。というより身につけざるを得ない...？？

ちなみに Moonlander のキーコンフィグには他にも便利なキー設定が沢山あり、Hyper キーやバックライトを変更するキーを割り当てたり、チュートリアルが起動するキーなども割り当てることなども可能です。音楽の再生切り替えたりとかも...w

この記事を見てエルゴノミクスキーボードに、少しでもご興味持っていただいた方がいれば、最初は飛び込むのにはちょっと勇気がいるかもしれませんが、、値段もそれなりだし... ｗ この機会に是非 ErgoDox EZ もしくは Moonlander 等のエルゴノミクスキーボードを試してみて欲しいです！

誕生日のノリでアドベントカレンダーに投稿予約して感じた変化

2020-12-06T07:00:00+09:00

はじめに

まず、私の誕生日は 11/6 なので本日 12/6 は誕生日からちょうど 1ヶ月後になります。

誕生日なので何か書くことにした✍️ | なんでもに参加しました！ https://t.co/1NXySfMlak #Crieit #crieit_advent_calendar @crieitcommunityより
— 𝚗𝚒𝚔𝚊𝚎𝚛𝚊 (@n1kaera) November 2, 2020

はい。完全にノリで参加しようと投稿予約してから、後日確認して気づきました。。ｗしかし、その間違えに気づいてから、何を投稿しようかなあと考え始めた時に、ふと「以前の自分だったら絶対ノリでアドベントカレンダーに登録するっていう行動しないよなあ」ということに気づきました。

そこで、今回は以前の自分と比較して、今の自分がどう変わったのか考察してみることにしました。この記事書いてるときは誕生日からまだ 1週間経ってないし、ちょうど考察するには良い機会かなと思って。

以前の自分

Photo by Luis Villasmil on Unsplash

以前はやりたいことがあっても全部後回しにしてしまっていました。何故かと言うと仕事やプライベートも含めて、他に直近でやらなければならない、もしくはそう思いこんでいる TODO があったときに、それらが残っていると次々に心配事や考え事が増えていってしまい、やりたいことに集中出来なくなるからです。

つまり、やりたいことは本気で集中できるタイミングが来たらやろうと考えていました。

そのため、読もうと思って買った本を読みたい、買って届いた新作ゲームをやりたい、OSS 活動をしてみたい、ライブラリを自分で作成してみたい等々のやりたいことは全て後回しになっていました。

何も考えないでサクッと取り組めるプレイ済みのゲームを遊んだり、気に入っている Youtube の動画を何度も繰り返し見たりして時間を浪費していました。

ボーッとしながら何も考えないで過ごす時間や遊ぶ時間は気力を養う上で重要で必要だと認識しているのですが、それだけを余暇に費やすのは少し勿体ないなと感じていました。

そして、ある時ふと気づきました。多分このままの生活してると連休とか仕事の区切りのタイミングとかでしか、自分がやりたいことに取り組むことはできないなと。。ちなみに、私はいわゆる ON/OFF みたいな切り替えが出来ないタイプなので、「仕事が終わったらスイッチを OFF にしてプライベートを全力で楽しむようにする」とかは無理なタイプです。

そこで、過去自分が気分がノリ続けて作業できたり、新しいことに挑戦し始めたときのことを思い返しながら、現状改善のために簡単に出来ることからやってみようと 1年前くらい前から行動を起こし始めました。

試したこと

Free-PhotosによるPixabayからの画像

まず、前提として下記項目はあえて頑張って解決するとかは諦めました。理由は中学生くらいの時から「そうだったなあ」って感じていることだったので潔く諦めた感じです。

仕事プライベート関係なく、やりたくない面倒な TODO を意識してしまい無駄に疲れる
- ふとした瞬間に思い出して不快になるかつ、それらの TODO は後回しにしてしまいがちなので、更に不快になる機会が増えてきて、結果疲れ続ける
やるべき必要がある TODO が増えてくると最優先で迅速に全部片付けたくなる
- それらが意識の端にあると心を休めた状態で日々を過ごすことが難しくなってきて、結果疲れ続ける

上記の解決を諦めても、やりたいことが自然と出来る環境が作れるようにしようとしました。

仕事プライベート問わず TODO の総量を減らしていく

TODO が増えてくることによって、やるべき TODO も必然的に増えてきます。最初は優先度の低い TODO だったのに、作業していくうちにそこから更にやるべき他の TODO が生まれてくることもあります。

そのため、そもそも仕事でもプライベートでも優先度とか関係なく TODO を日常的に増やさない努力を行いました。 割とお願いされたら何でも引き受けてしまいがちだったので、そこは常に意識するようにしました。

直感的に自分に向いて無いと思ったり、自分が請け負う必要が無い TODO は極力減らすか、その内容を簡素にしてもらいました。 常に多少の余裕が感じられる範囲で TODO を抑え込むようにすることで無駄に TODO を意識して気力を消耗し続けることは少なくなっていきました。

やりたくない TODO は疲れない範囲で対処していく

もちろん、それでも 出来ればやりたくないけど、やらないといけない TODO は出てきました。

ただ、やりたくない TODO は大抵やりたくない何かを自分が勝手に想像していることも多いです。つまり、TODO の具体的な内容が明らかになっていない中で勝手にその作業内容を想像してしまい嫌になっているケースです。

その場合は、作業内容を具体化する作業を行うことで解決できる可能性があります。やりたくないと考えていることが、実は絵空事の場合もあるからです。

例えば、TODO を依頼してきた相手がいる場合、具体的な作業内容を文章にしてもらう、万が一それが出来ないと言われた場合は、自分が不快に感じないレベルで作業して適宜内容を報告することで、相手が方向性を正しいか間違っているかを随時指摘してくれて、次の作業の内容もどんどん具体化してきて TODO の全体像が見えるようになってきました。

全体像が見えてきてしまえば、あとは適切な粒度に TODO を切り分けてひたすら消化していくだけなので、無駄に意識が TODO に向かってしまい気力が消耗していかないよう、サクサク片づけるように心がけました。

段々 TODO の扱い方が分かってくると、常に一定以上は自分のために使える時間が作れるようになってきました。

軽めのやりたいことは時間が出来れば自然にやれてた

意識するまでも無く時間が作れるようになってきてからは、新作ゲームや積読してた本に取り掛かることを意識せず自然にやってました。TODO 意識しちゃって新作楽しんでても心から楽しめないとかいう気持ちから脱することができる状況になったおかげで、自然と新たな行動が起こせるようになったからかもしれません。

重めのやりたいことには必ず「自分のため」の理由付けを行う

例えばやりたいことを行う理由が「誰かに認められたい」とか「自分の価値を周りに認めてもらいたい」とか世間体を気にした動機になってしまっていると、そのやりたいことは他人が認めてくれて初めて達成となります。つまり、例えやりたいことが達成できたとしても、他人に評価してもらえない限りは未達の状態であり、その結果が気になって気力を消耗し続けます。

私は上記のパターンに過去何度もハマり、やりたい TODO が達成できたはずなのに、その後 TODO に対する他人からの評価を常に気にし続けなければならず、無駄に気力が消費され続けて全くその後の行動が続いていかないという現象にハマっていました。

例を言うと、例えば技術記事を書くとしたときに 「世間に新たな価値を提供したい」「誰かの役に立つような内容を意識する」「しっかり内容を書かないと記事にする意味が無い」 という他人から見られることを意識している動機づけは世間体や他者からの評価です。

それら一切度外視で、「文章書く練習のために書く」「後々また困りそうな技術的問題を自分が解決できるようにするために書く」「他の記事と内容が重複しても自分の勉強や理解を深めるために記事は書こう」と自分の行動の動機を他人と切り離すことで、やりたい TODO を完了したときに「達成できた！満足！」という実感が即湧きます。

やりたい TODO をちゃんと達成できたという実感は次の行動のモチベにも繋がっていくので、一石二鳥です。

ちなみに、やりたいことのモチベは 「なんとなく興味あってやりたいからやってみるけど飽きたら即止めよう」 という意識でも自分の行動の動機としては全然問題無かったです。そんな薄いモチベでもやり始めたら楽しくなってきてこだわり始めてやりたいことの精度や質がグングン上がっていき、継続して取り組める趣味となることも経験しました。

自分の具体例で言うと、その程度のモチベで始めたことである普段飲むコーヒーの質向上が、結果、自家焙煎とか豆のブレンド比率にこだわり始めたところまで来ていて飽きずに今でも続けられています。

その結果

Photo by Jorge Gonzalez on Unsplash

そうして、やりたくない TODO の総量を減らして使える時間が増えていくと、最初のほうは時間を浪費していた時の行動となんら変わりない行動をしてしまうのですが、、ふとした瞬間に、それらの浪費行動に飽きるタイミングが来ます。暇すぎたり飽きに耐えきれなくなってきて、気力も十分に蓄えられてくると、ふとした瞬間に「やろうと思ってたことやってみるか」という感情に僕はなりました。むしろ、そういう感情になるまでは、仕事プライベート問わず TODO を減らし続けたり、遠慮なくダラケまくってボーッとしまくって休息する時間が必要なのかもしれません。

あとは、気力は体力と同じく有限であるが、無くなっている状態が慢性的に続くと、それに気づくことすら出来ない。更に失った気力を回復するのには結構時間がかかる (1週間とかの単位) ということに気づくことが出来ました。

私は気力を失っているかどうかの判断軸として、何かをやりたいと思えてたはずなのに「今は忙しいからな」とか「途中でやめそう」とか保守的なモードに入って行動が起こせなくなっていたら、気力が失われていると判断しています。そうなっていたら、休息だけでなく TODO の総量も同時並行で減らすように心がけています。

「2」がお題の時の web1week の時に参加出来なかったのは、まさにやりたいと思っていたのに、上記の保守的なモードに入っていたので行動に移せず終わってしまった感じでした。

また私は前述してきた内容を意識してきた結果、下記の以前からやりたいと思っていたことを自然に達成できました。

これらは世間体や他人の目、TODO などを気にせず、自分の意志のみにフォーカスして活動できるようになったことが大きく起因していると感じています。

おわりに

My pictures are CC0. When doing composings:によるPixabayからの画像

まとめると、私にとっては下記が重要だったということになりそうです。

仕事やプライベートや大小や重要度関係なく TODO の総量はとにかく減らす
- やりたいことがあっても時間や心労が原因でできていないのであれば、まずは自分のために使える時間を増やすことにだけ、ひたすら意識を傾ける
世間体や他者からの評価をモチベの糧にするような行動は決して起こさない
- それで一時的に行動できていたとしても評価されないと気力を消費し続ける原因になってしまい、モチベや行動が後に続いていかない
気力の消費には自分で気づくことは難しいので常に余力が持てるよう意識し続ける
- 何かやりたいことがあるなら、他者に縛られる時間や仕事プライベートにおける TODO の総量を極力減らしていく
無意識に気力を削ぎ取ってくる外部要因は意識的に排除していく (フォロワーの数や SNS での反応等々)

今回ノリでアドベントカレンダーに参加できたのも、上記が達成できていたからだと思います。(気力が十分にあって、世間体等を気にせず、自分が記事を書いてみたいと思ったから参加できた)

もちろん、この記事が誰かの参考になれれば物凄く嬉しいは嬉しいのですが。。ｗ

また最近は行動を起こすにもインプットの量が足りてないとアウトプットしたいものも無くなってくるなと感じているので、自分が本当にやりたいことの総量を増やして、アウトプットを増やすことで人生を純粋に楽しむためにも、インプットの量を意識的に増やしていっています。

ちなみに私がモチベや記事に書いている内容を意識し始めたキッカケは教育心理学を学ぶ会で購入した理論と事例でわかるモチベーションですので、本記事内容にご興味お持ちいただいた方は是非チェックしてみてください。著者は kawagoi さんです。

最後にこのような機会を用意してくれただらさんに感謝して終わりたいと思います。

エンジニアのPCはWindowsとmacとLinuxのどれがいいのか

2019-11-18T08:12:26+09:00

エンジニアのPCはどれがいいのか、駆け出しの場合は特に悩む人も多そうなので一度主観でまとめてみました。ちなみに僕は2, 3年ほどLinux（Linux Mintというやつ）、時々mac、あとはほとんどWindowsですので一応一通り多少は使ったことがあるエンジニアの視点からです。仕事で決まっているから、という話は今回は含めません。個人で選択する場合です。

ゲームがしたい場合

Windows必須です。ゲームだけがしたい人はここで記事は終わりです。同じ理由でゲーム開発をメインにしたい方も同様かと思います。

他の開発を行う場合、Windowsだけでやるのか、macも購入するのか、引き続き検討が必要です。ゲームを作る場合もiPhoneアプリ用のゲームも同時に作りたい、という場合はmacと両方、もしくはmacだけで問題ないゲームを作るか、などの検討が必要でしょう。

iOSアプリ作る人

mac一択です。せっかくなのでいいmacを買って何でもかんでも全部それでできるといいと思います。

Web開発とかやりたい駆け出しの人

mac一択だと思います。

とにかくRubyとか、Node.jsとか、ナウいものをやろうと思ったらmacの場合環境構築がやりやすいし、情報も多いのでスムーズに進みます。Windows上の直火でやろうと思ったらむっちゃっくっちゃ！　大変です。結構知識が無いと厳しいしあったとしても厳しいと思います。というか無理ゲーに近いです。PHPとかだとまだマシですが。というかわざわざ時間をかけて解決する意味もあまりないと思います。

そのため大変な環境構築を避けて簡単に行おうとするとWSL、Docker、Vagrant、VirtualBoxなど、Windows上で別途Linuxを動かすための環境で行ったほうが楽なのですが、結局そのための知識も必要になってきます。分かる人であればそれで容易に開発できるのですが、駆け出しでそれはまずそこを勉強しなければならなくなり遠回りなので、おすすめできません。

しかも環境によってはこれらも使えないものがあったりしますし、どれを使うかによってその後発生するトラブルも違ってきます。そうなってくると問題が発生した時にプログラムが問題なのか環境が問題なのか、環境だとするとどの部分の設定がおかしいのかなど、とにかく原因を確定させるだけでも大変になりますので、そのエンジニア本人も大変ですし、周りでヘルプを受けた人もめちゃくちゃ大変です。

とにかくよくわからない場合はmacがおすすめです。その方が世界は平和です。無理であればせめてWSLは導入しておきたいところです。

開発慣れしてる人

慣れて色々使えるようになったら、WindowsでもWSLとかDockerを使えばいいので何も問題はありません。WindowsだろうがmacだろうがLinuxだろうが好きなものを使えば良いと思います（もちろん必要なソフトや何をやるかによっても違ってくることはあると思います）。

一昔前はWSLもDockerも無かったり、まだ未発達だったりしたので、それより前の時代はmac最強だったはずです。でも今は前述の通りWSLとDockerさえ使えばとてもいい感じに何でも開発できるのでWindowsもmacもファッション感覚で選べるくらいにはなりつつあると思います。

まあそれでも僕もWindowsを使っていて不満はありますが、ただどのOSでも不満はある程度出てしまうと思うので、妥協するという点では差はないのかなと思います。

ちなみに下記はLinuxからWindowsに戻ってきてから試行錯誤した時の記事です。

Windowsで快適なWebシステム開発を行えるか検証中

まとめ

WindowsとmacとLinuxそれぞれのハイスペックPCがほしいです。

ターゲットを考えてタイトルを考えよう

2019-05-07T21:04:23+09:00

タイトルは文字数も少ないですが、人はそれを見てまず記事を読むか読まないかを決めてしまうため奥が深く、考えるのには意外と時間がかかります。色々とタイトルを決める考え方はあるためいくつかあげてみます。

伝わるかを考える

エンジニアが記事を書くとなると、やはりプログラミングや何らかのソフトウェアやライブラリなどの、人によっては良くわからないワードなどが出てきます。

例えば僕が過去に書いた記事で、Puppeteerについて書いた事がありました。具体的にはPuppeteerでスクリーンショットをとる記事なのですが、例えばそのものズバリのタイトルにすると「Puppeteerでスクリーンショットを撮る」となります。

しかし一つ考えておきたいのが、Puppeteerを知っている人がどれだけいるのか、ということです。

知ってる人からすると「お、面白そう」と感じて見てくれるかもしれませんが、知らない人は「ふーん、なんかのデスクトップ用のよくあるようなフリーソフトかな」と思ってしまう可能性もあると思います。

このように、専門用語や固有名詞をタイトルに入れてしまうとそもそも何の記事なのか、ぱっと見で伝えられない可能性が出てきます。そのため上記の例でいうと僕は「Node.jsでChromeを動かしてスクリーンショットを撮る」のようなタイトルを付けました。PuppeteerよりもNode.jsとChromeを知っている人の方が多いと思ったからです。

ちなみにこの記事はあまり興味を持たれなかったようでさほど閲覧されませんでしたが、とはいえ、適当にタイトルを考えるよりは一度「本当に伝わるのか？」という疑いを持ってタイトルを見直すようにした方が良いのではないかと思います。

誰に伝えたいのかを考える

上記の例で、Puppeteerを知っている人だけにこの情報を伝えたい、ということであればそのものズバリPuppeteerをタイトルに入れる形でも問題ないと思います。Puppeteerを知っている人には有益な記事でも、知らない人には全く価値のない記事の可能性もあるためです。

かならずしも全ての記事が幅広い層に見てもらう必要のある記事ではないと思いますので、ターゲットがあるのであればそちらを優先してタイトルを決めてしまっても良いと思います。

文字数

色々な場所に表示されるタイトルの文字数というのは決まっています。大体30文字までにしておくとどこでも尻切れにならずに表示されますのでそれを意識してみましょう。

また、どうしても長くなってしまう場合は重要な内容を最初の30文字くらいに入れておいて、あとはまあ切れてしまって読まなくても伝わるし、読んでから伝わればいい、みたいな形にしておけばさほど支障はないと思います。

Crieitでは記事入力画面でタイトルの文字数を表示しているので是非参考にしてみてください。

いろんな技を使う

その他、タイトルの付け方は色々なバリエーションがあります。めちゃくちゃ草をはやして気になる感じにしたり、「～～の７つの方法！」のようなものなど、世の中にあふれている多くの記事を参考にしてみると目を引きやすいタイトルの作り方がわかってくると思います。ただ、エンジニア向けのものであればさほどそのようなタイトルの決め方をする必要もないのでは、と個人的には思います。僕は結構余分な装飾をせず、短いタイトルの中になるべく必要な情報を詰め込みたいタイプですので、そういったことはしません。

そのあたりは個人の色や読者のターゲットによるものになりますので、適宜自分にあった形を決めていくと良いのではないかと思います。

すぐに決めなくても良い

記事は最後に投稿する時に決めればよいので、記事の書き始めなどで無理に決める必要はありません。なかなか決まらなければ空欄にしておいて、最後に記事を読み返してみて、そこで考えてみるのも良いと思います。どちらにしろ、決めていたとしても最後に見直して見たほうが良いと思います。

概要を意識しよう

2019-04-26T09:29:15+09:00

記事を書くときは概要、つまりメタタグのdescriptionがどのようになるかを意識しましょう。昔は検索結果に表示される内容としての用途が主でしたが、現在は記事をTwitterなどでシェアした際に本文の一部として表示されるということもあり、有用さが増してきていると思います。みなさんもよく見ると思いますが具体的には下記のようなものです。

画像の下に表示されているのが分かると思います。

Googleの検索結果は人が能動的に探しに行くものですので「実際にページを開いてみるため」の判断材料なのですが、Twitterの場合は「全く考えもしなかったところに興味をもたせる」というところで役割も異なっており、非常に有用なものです。ここに興味を持たせるための内容を詰めておくことがわりと重要だと思います。

長さ

通常、descriptionの長さはGoogleの検索結果に合わせて300文字程度とかがいいという情報があります。もちろんそれはそれで重要なのですが、さらにシェア用の60文字程度には、記事に興味を持ってもらうための内容を詰めておくことがベストだと思われます。

概要の書き方

どの部分が概要として使われるかはブログやサービスによって異なります。

一般的なブログや記事投稿サービスの場合

一般的なサービスの場合、記事の先頭がdescriptionとして使われることが多いと思います。当サービスもその様になっています。この場合、記事の書き出しに自己紹介や最初の一ネタを書きたい場合などがあると思いますが、それだとツイートなどには内容と関係ない概要が表示されてしまいもったいないです。

我慢してまずはdescriptionに載せたい部分を書き、その後に補足として書くようにしましょう。

WordPressの場合

WordPressの場合はプラグインを使ったり改造したりすることで直接設定したりすることができるようになります。そのようにしている場合は本文は自由に書いて問題なさそうです。

困っている人がたどり着ける記事にしよう

2019-04-21T23:42:56+09:00

もしせっかく記事を書くのであれば、その記事を必要としている人がたどり着きやすいような記事にしておきましょう。せっかく問題解決の記事を書いても、その問題で困っている人がその記事にたどり着けなかったり、有用な考察を書いたとしてもそれを参考にしたい人がたどり着けなかったらもったいないです。

エラーメッセージはなるべく書いておきたい

なにかの問題が起きた時に表示されるエラーメッセージは共通言語のため、ブレが少ないです。行番号や変数名がエラーメッセージ内に含まれていれば多少のブレはありますが、それ以外のところは固定文言のため検索で非常にひっかかりやすいです。そのため困っている人がたどり着く可能性が非常に高くなりますので可能な限り記事中に書いておきましょう。

どのように検索されるか想像する

ある記事を書いた場合に、その情報を必要としている人がGoogleでどのように検索するかを想像しましょう。例えば、エンジニアがブログを書きたくなった時、どのように検索するでしょうか？

「ブログサービス」で検索するかもしれませんし、エンジニア向けのものを探す場合は「エンジニアブログ」や「エンジニア記事書く」、「技術記事」かもしれません。「コード書けるブログ」とか、「Markdown ブログ」のように機能を重視して検索するかもしれません。

どれもそのあたりのワードが記事中になければ検索に引っかかる確率が減ると思いますので、記事中でそれぞれについて言及しているのであればきっちりそれらのワードを入れておきましょう。

正式な記事であれば表記揺れをなくしたほうがよいという方もいるかもしれませんが、個人的には問題解決系の記事であれば表記揺れは無視し、むしろ時々言い回しを変えてどんな類似ワードの検索でもたどり着けるようにしてあげた方が親切だと思います。（ある程度はGoogleが吸収してくれますのでやりすぎる必要はないと思いますが）

よくSEOで重要なワードを記事中に何度も出現させてSEO力を高める、のような話も聞きますが、個人的には全く重要ではないと思っています。普通に人と話して問題を解決してあげる時でも、相手が意味を理解していなかったら「どういう意味？」と聞いてくると思いますし、それに対して言い回しを変えて教えてあげると思います。しかし、検索ではそんなインタラクティブなやり取りはできませんので、あらかじめ必要な言い回しは記事中に用意してあげる必要があるのではないかと感じています。

まとめ

とにかく、検索する人のことを考えてあげて、検索する人にとって優しい記事にしましょう。検索している人は、探しているものにたどり着きたいのです。

記事を書くネタの探し方（日常のプログラミングから）

2019-04-15T22:26:25+09:00

いざ記事を書こうと思うと、当然書くためのネタが必要になります。一番簡単なのは自分が普段書いているプログラムからネタを見つけることです。仕事であっても趣味のプログラムであっても、そこで書いたり調べたりしたことは記事のネタになることが多く、一番身近で、且つ既に自分で書いたもののため記事にしやすいです。

つまづいた点を書く

思いがけずエラーが出たりすればそのエラーの内容や、解決方法を書けばあっという間に役に立つ記事が出来上がります。

更に具体的にどういった理由でそのエラーが起きたのか、なぜその解決法で解決できるのか、もしくは現時点では解決方法がないとか、その上で自分で試しに行ってみた方法で一応は動くようになったとか、そのあたりの一部始終を書くことでそれなりの記事になっていきます。

しかもつまづいた点は他の人も困っている可能性があるため需要があります。検索流入を増やす可能性も高くなります。

新しいものを使ってみた話を書く

プログラムを書いていると、実装する機能のために今まで使ったことのないライブラリを使う必要出てくる場合があると思います。特に最近出てきたばかりのライブラリ等だったりすると、まだ世の中に使ったことのある人が多くなかったりします。そういったものは興味を持たれる可能性が高くなります。

普段はあまりそういったものに触れる機会はないかもしれませんので、記事を書くために寄り道をしてプログラムを書いて試していったりすることになるとは思いますのでちょっと大変にはなりますが、どうしても直近で書けるネタが無いときや、自分の趣向的に気になって使いたいと思っていたライブラリだったりする場合にこの方法を取ると良さそうです。

ライブラリだけでなく、クラウドのサービスや、アプリなど、色々なものを触ってみて書くこともできます。

当たり前のネタでも書いてみる

普段のプログラミングの中で、「これは当たり前のことだしいまさら書いてもなぁ…」ということがあると思いますが、それでもどんどん書いてみることをおすすめします。

というのも、自分にとっては当たり前のことであっても、まだその技術に達していない人や、少し普段使っているプログラミングの方向性が違う人からすれば、それはまだ知らない技術だったりすることもありますので、必ずしもそれは「当たり前」とは限りません。

むしろ、世の中の熟練度ピラミッドから想像すると難しいことを調べるよりも当たり前のことを調べる人の方が多いはずですので、気にせず書いてみることが重要となります。

すごく短い記事でも大丈夫

2019-04-12T23:51:45+09:00

記事を書く時、必ずしも頑張って長文の記事に仕立て上げる必要はありません。例えばそもそも、あるエラーに対しての対処方法を書くような記事の場合、無駄に長々と関係のない説明を書いても読むのが辛いだけで本質的ではない場合もあります。ですので例えば、こんな構成の短い記事でも問題ないです。

～～をしていたら下記のようなエラーが出ました。

Error: This is a special error code E2234 (aewfew is undefined)

原因として、～～のライブラリを使っている場合は～～の設定を書いておかないとエラーが発生してしまうため、下記のような設定を追加しておきます。

  setting: true,

こんな感じでも十分です。とにかく書きのこしておいた方が良いかな、と思ったことは短くてもいいのでガンガン記事にしてしまいましょう。もっと深く掘り下げた情報も追記したい、参考となる関連情報も書いておきたい、などがあれば、後で思いついたときにでも追記はできますので。

とくにエラーメッセージはそのものズバリで検索されることもあるので、それと改善方法さえ書いておけば困った人が検索でも引っかかりやすいです。実際に、僕も自分で書いた記事と同じエラーを出して検索し、自分の記事にたどり着いたこともあります。ですので自分のためにも他の人のためにも、とにかく書き残しておきましょう。

プログラムのコードを書こう

2019-04-11T22:44:15+09:00

やはりエンジニアが記事を書くとなるとプログラムのコードを書くことが必要になってくると思います。Markdownであればだいたいコードハイライトに対応しているため、簡単に色付けを実現することができます。

具体的にはバッククォート３つを並べた行で囲まれた行はコードとして扱われます。

1 | ```javascript
2 | function test(a) {
3 |   console.log(a)
4 | }
5 | ```

上記のように書くと（行番号部分は不要です）下記のようになります。

function test(a) {
  console.log(a)
}

最初のバッククォート３つのあとには言語名を書くことでその言語の色付けに対応しています。例えばphp, ruby, javascriptなどです。他にも色々ありますので必要なものがあれば調べてみてください。

注意点

間違えてパスワードや鍵などをそのままコピペして投稿してしまうと危険ですので、そのあたりは適当な文字に置き換えておきましょう。

基本的な体裁 - 見出しと段落

2019-04-10T23:57:02+09:00

Markdownで記事を書く場合、最も基本的であろうという体裁の作り方が二つあります。それは「見出し」と「段落」です。

見出し

↑のように、見出しというのはHTMLでいうh1タグとかh2タグで表現されるもののことです。Markdownの場合、# を使って書くことができます。

# h1
## h2
### h3
#### h4

一般的なブログサービスの場合、h1は記事のタイトルに使われたりします。そのため、記事中ではh1は使わずh2から使い始めたほうが良いでしょう。（ただしサービスによっては自動的に変換してくれたりするものもあるようです）

無駄に改行せず段落を使う

昔は改行をたくさん使って改行芸のようなことをする風習がありましたが、最近はPCとスマホ両方で表示できるようなレスポンシブ対応が標準となってきている関係で、あまり改行は望ましくないものになっています。

そのかわり、Markdown等の場合も改行を二つ連続で書くことで、段落わけを行うことができるようになっています。HTMLで言うところのpタグになります。そのため無駄に改行を使わず、キリの良いところで段落分けして読みやすくする、という書き方にしていきましょう。

とりあえずこの見出しと段落さえ覚えておけば基本的な文章は書けると思います。

プログラム言語やフレームワークのバージョンを書こう

2019-04-09T23:40:31+09:00

技術的な記事を書く時、まずは使ったプログラミング言語やフレームワーク、ソフトウェア等のバージョンを忘れずに書くようにしましょう。

なぜバージョンが必要か

例えば同じPHPでも、PHP5.6とPHP7.3ではそもそもできることが異なっていたりします。

「PHP＋Laravelでこんなライブラリを使ってみました！」という記事を書いていたとしても、それが最新のPHP7.3＋Laravel5.8でしか動かないライブラリだった場合、記事を見た閲覧者が同じことを試して見ようとしても、PHP5.6＋Laravel5.5とかだったらそもそも動きません。なんでだろう…と悩んで時間を無駄に浪費してしまうことになります。

また、「こんなエラーが出たので解決した」という記事を書いた場合も、バージョンによってはそもそも発生しなかったり、解決方法が異なっていたりする可能性もあります。

「何の問題もなく簡単にできました！」と書いたのに、他の人が試してみるとエラーばかり出て全然進めない、GitHubのIssueを見てみると最新のバージョンだとエラーが報告されていてまだ解決していない…なんてこともあります。

どのように書けばいいか

プログラミング言語の話だけであれば最初に「PHP7.3を使っています」とでも書いておけば良いと思います。言語、フレームワーク、ライブラリと、色々なものを使っている場合はリスト表記で書いておくと良いでしょう。Markdownの場合リスト表記は下記のようにアスタリスクやハイフンで記述できます。

* PHP7.2
* Laravel5.8
* Bootstrap4.3

このように書くと

PHP7.2
Laravel5.8
Bootstrap4.3

のように表示されます。

Markdownで書いてみよう

2019-04-09T23:38:18+09:00

技術系のブログを書く場合、Markdownで書くのがおすすめです。Markdownというのは、記号を含めたテキストの書き方で、簡単に見出しや強調など、文字の装飾、コード表記を行うことができます。

例えば強調する場合は

**ここを強調**する

のように書くと

ここを強調する

のように表示されます。

## 見出しです

のように書くと

見出しです

のように表示されます。

はてなブログ、Qiita等、技術系の記事を書くことができる様々なサービスで使われており、GitHubのREADMEも書くことができるため、とにかく一番オススメの書き方になります。

色々な書き方がありますので下記などで見てみてください。

Markdown書き方メモ - Qiita

Freelance Meet Up in Osaka #01 に行ってみた

2018-09-04T07:34:29+09:00

Freelance Meet Up in Osaka #01 に行ってきました。

関西で活躍するフリーランスエンジニアの方をお招きし、案件事情や、単価、ワークスタイルまで多方面からパネルディスカッションを行います。
大阪のフリーランス業界を盛り上げるべく不定期で開催しているイベントです。

とのことで、#01のため恐らく初開催だと思われます。

主催はACTBE Inc.で、こちらのCEOの方がモデレータとしてパネルディスカッションの進行を行っていました。場所はこちらの会社が運営しているACTBE Horieというコワーキングスペースでした。

あとは大阪で活動されている３人のフリーランスの方が前に並び、随時出されていくお題に対して色々と話をしてくださいました。

大まかなテーマは下記になります。

働き方
技術
営業
お金

登壇者

詳しくはイベントページに掲載があります。以後の話を分かりやすくするため簡単に説明しておきます。

伊瀬知さん

ほぼリモートで活動中

石村さん

常駐業務で活動中

横山さん

チームを作って全国を飛び回って活動中

働き方

大阪でのフリーランスとしての働き方に満足していますか？

東京はかなりの人数のフリーランスがいるため、スキルの低いフリーランスも非常に多くやっていけている印象。もしかすると大阪の方がスキルが高いフリーランスエンジニアの割合が多い可能性も？　単価は安いのでそのあたりが課題。
地方のエンジニアの方が真剣度は高そう。ただ、実績をつかみにくいので、その部分はうまく大阪と融合してやっていけると良いかもしれない。
地方の方が業務環境などが健全で働きやすい。（夜になると誰もいなくなる等）

エンジニアになろうと思ったきっかけは？

タウンワークで見つけた開発会社に入った

ここで僕が腹痛でトイレに篭ってしまったので話を聞けませんでした…

なぜフリーランスになろうと思ったのか

フリーランスになること自体はメリットだけでなくデメリットもあり、色々悩んだが離婚したため
協調性がないから

現在の働き方は？

エージェント使って常駐しながらクライアントとの縁が増えてきたのでリモートに移行していっている
クラウドワークスから。月の半分くらい全国うろうろして仕事を見つけてきてる。つねに仲間を探してる。（自分でも案件を出している）
クラウドワークスは全然案件をとれない。30～40応募して5万円くらいの案件一つとか。全く取れなかった方も。

技術

技術レベルに自信はありましたか？

一部は自身があったが、ひとりでは網羅できないためチームを作成。たまたま環境が良かったのでうまくいく自信はあった。
自信はなかった。よく分からない自分の技術でお金が本当にもらえるのか不安だった。
自信がないから色々なところで学んで行きたかったので常駐業務で色々な会社を行き来した。

独立後に苦労した場面は？

技術と仕事取るのは全然別スキル
SESだと時間計算なので、得意じゃないところやるとアウトプット量が不足してるのが気になり申し訳なくなる
不具合が発生した時の修正は苦労が多い
最初に業界を知らなさすぎて苦労（fixやマージってなんですか？　って聞いて鼻で笑われた）。たまたまその現場がフランクでやりやすかったのでなんとかなった

技術習得方法は？

本
チームの場合は習得せず、その技術をもってる人に入ってもらったりする。その方が全体的に早い。
コードレビューの収穫は高い（お客さんやプロジェクトで一緒の人とか）
仕事時に会話で出てきた知らない言葉を調べて理解を深めていく
OSSに感謝し貢献したい

チームの場合のお金配分は？

仕事を取ってから分配を考える（２割は積立てておき何かあった時のために使う）
お金の配分をオープンにしないとチームでトラブルになったこともあった
各メンバーのスキルを星にしてお客さんと交渉（安くしたいなら星の低いメンバー、星の高いメンバーを入れたいなら費用をアップしてもらう。お客さんが自分で選択できる）星もメンバーにオープン。
↑業界知らないところからここまでうまくできててすごい

営業

しんどかった。ココナラでyoutube動画作って仕事につなげてみたりもした。最終的に常駐へ
会社員時代からつながりがあってあまり営業しなくてよかった（今はエージェント使ってる）
日本中色んな所に飛んでる。安くても繋がり作るためになんとかして引き受けてみる。

単価交渉される？　その時の対応は？

作業者の星制度を作った。星の低い人には仕事のやり方を教えたりもしなければならないが、逆にそれぞれ関係ないところで得意分野があったりするので、コンテンツ作成業務などでそういったメンバーの知識も使って仕事につなげたりすることでなんとかバランスを取ったりしている。
常駐ではあまりない
自分のやったことないところは費用落としてもいいから取りに行きたい
単価交渉してくるお客さんとしてこないお客さんは明確に分かれてる
交渉をよくしてくるのは関西だと多い感じ？
常駐で単価４０万→８０万に５年かけて上げた人もいた
エージェントにはなんでも言いやすい（単価交渉とか）。むしろ何でもちゃんと言おう

エージェント何社くらい使ってますか？

ギークス、レバテックとか、２，３社
日数減らしてくれという交渉もしてる
フリーランスだと、常駐業務でなくても大手とやるときは代理店に入ってもらったりする（直だとダメらしい）

お金

いくらくらい稼いでますか？

会社員より２倍くらい（ここから税金も引かれるが）（常駐は日数で上下調整できる）
まわりの人よりもちょっとかせげてるかなーと
定期的に案件があれば良い
仕事が好きだし時間も自由に決められるのでつい働いちゃう
ちゃんと定期的に休む時間作ってる（お客さんにも伝えてる）

節税してますか？

とくにはやってないけど、保険の積立とか
税理士さんにやってもらってる（税理士さんによって節税方法や基準も違ったりする）
適当にやってたらプライベートとごっちゃになって確定申告でむちゃくちゃ怒られた。税理士さんにやってもらうことにした

大阪フリーランスはどうですか？　課題点など

個人的には好き。人情とか。単価関係なく大阪でやりたい。責任ある仕事任されるまでに時間がかかる。とりあえずスキルアップのためいろいろやりたい。
フリーランスの信用とか費用とかは関西のほうが苦戦してる。発注側の意識もまちまち。関東は勉強会多い。
発展途上なので良くしていかなきゃいけないけど、なかなか進んでいかないので課題。もったいない。

質疑応答

どうやったら輪が広がっていくか？

アウトプットして自分自身の露出をふやす。ブランディング。
一人勝ちしないように他の人にやってもらうようにしている。

働く日数を減らす交渉はしづらくないか？

入る段階で交渉。入ってからだといろいろ気になってしまう（進行具合とか）
やめるときのキリのいいタイミングで引き継ぎだけにして減らすとか。

継続的に仕事をとることはできるのか（スケジュールが埋まらないかもという不安）

稼働日数を減らして複数の仕事を取ったり
呼び出されたらすぐ行くやつと思われるようにしたり
保守案件の数を増やす（受託を受けたらなるべる保守とる）

有望な業種とかある？

WEB制作ができないところからとってる（ちょっとしたところにプログラムが必要な時代になっているのでそのへんをすくいとる。大阪特化ではない）

まとめ

最初はどういったイベントなのかあまり想像できていませんでしたが、登壇者の方々がそれぞれ違った働き方をしており、バラエティに富んだ生の声が聞けたのでなかなか面白いパネルディスカッションになっていました。

そもそも僕も大阪でフリーランスとして働いている方々とほとんど会ったこともなかったので、参加者の方々とのお話も含め色々と新鮮でした。フリーランスになったばかりの方や、これから目指したいという方もいたので色々と参考になったのではないかと思います。

退職ではないけどSESをやめたエントリ

2018-08-06T06:36:00+09:00

僕は元々フリーランスでリモートワークのみで働いていました。しかしここ２年ちょっとはSESの案件を行っていました。それが先月７月で終了してリモートワークのみに戻ったため色々感じたことをまとめてみます。

流れ

8年ほどリモートワーク
1年半ちょっとほど週３でSES
1年弱週１でSES（やめるつもりだったが細かい作業や引き継ぎのため）

※面白い激務の話ではありません。また個人的な話が含まれるため、面倒な方は「SESについての考察」セクションあたりまで適宜読み飛ばしてください。

どんな感じの案件だったか

わりとゆるい感じの案件ではあったと思います。そもそも週３ですし、私服でした。僕は自己中心的なので基本的に忙しい時期でも一切残業はせず定時になったらすぐ帰っていました。

暇すぎることの苦痛

１年位は一人でずっと一つの案件をやっていました。全く何も情報が来ずかなり暇な時期がありました。自宅でこういった案件をやっている場合は待ち時間に並列で対応している他の案件にスイッチして、みたいなことができるのですが、特定の会社で特定の案件をやっているとそういうわけにはいかず、ハッキリ言ってそういった時期は暇すぎてやることがなくて、Twitterをするわけにもいかずどうやって時間を潰せばいいかわからずかなり苦痛でした。

忙しすぎて苦痛ならまだわかるのですが、暇すぎて苦痛というのもあるのだな、とはじめて知りました。時間も無駄だし費用も無駄でしょうし無駄だらけでやるせなかったです。なるべく働く時間を減らすように通勤時刻をギリギリにしたりと、くだらない調整を行ったり。そして世の中には同じ様にしている人が大勢いるのだろう、と思うとなんかこう、切なくなりました。日本でどれだけの人がこの意味のないストレスを抱えているのか、日本全体でどれだけ貴重な時間が無意味に失われているのか。

結局、Web開発の技術を延々と調べて学びまくってました。そういったサイトだったら見ていても何も不思議ではないし、丁度いいものがあれば実際に対応している案件に組み込んでみたりもでき非常に合理的でした。それでもかなり暇でしたが。

本当に暇だったわけではなかった

一番最悪だったのは、それは本当にやることがなくて暇だったわけではなく、誰も仕様をちゃんと詰めたりスケジューリングしようとせず全部後回しにしていたことです。リリースちょっと前になって急に慌ただしくなり、あれこれ言ってくるようになりました。完全にペースがおかしかったです。

もちろんそれで忙しくなったのはスケジュール管理ができていないことが問題で僕のせいではないので、残業ゼロを押し通しました（とはいえ休日に急にかなり困っている部分だけ修正してほしい、みたいなことは言ってきたりはしてましたが）。むしろ僕は早めに大量の不明点をまとめた資料を提出して、問題のある状況であることを伝えたくらいですし。

結局リリースも未完成の状態でプレリリース的なノリで行われていたようです。

怒られなかったのか

むしろ最初から最後まで、フロントもバックも関係なく作成し、仕様の詰め等の細かいやり取りもひたすら行い、全部一人で完成させて無事リリースし、リリース後も不具合等が収まるまできっちりやり、しかも週３残業なしでこなしたので非常に評価は高かったようです。

現場自体はどうだったのか

他の案件もいくつかあったので、何人か他にエンジニアがいて、入れ代わり立ち代わりしていましたが、みなさんかなり残業をされていたようです。僕も後半はそちらに参加していました。もちろん業務スタイルは変えていませんが。

SESについての考察

メンバーの入れ替わりが激しい

SESは時間提供なので、嫌になったり自己都合である程度自由に他の案件に移動することができます。そのため同じ案件であってもちょこちょこ人が変わったりしていました。

きっちりなんでもいい感じでできる人が来てくれればいいのですが、人手不足も激しかったようで、それでも誰かを入れないといけないため、色々な人が来ていました。フレームワークも使ったことがない人も多かったです。もちろんスキルや経歴によって費用は違うのでしょうが、完全にギャンブルっぽくて怖かったです。プログラムも色々な人が自由に書いているので統一性もなくぐちゃぐちゃでした。

そして誰にも共通していたのが、結局入れ替わったりして元々自分が作ったプログラムじゃなかったり、今後自分は触らなくなる予定のプログラムだったりということで、作られるプログラム自体に全く統一性がありませんでした。すべてが突貫工事的。これは技術力ややる気の問題ではなく、入れ替わりで対応しているので誰にもどうしようもない部分です。それを可能にしているSES自体のデメリットなのかもしれません。

安い

安いです。僕の場合は間に１社挟んでいただけなので異常な安さというわけではなく、最初はまあ定期的に入るならいいか、と思っていましたが、段々と色々な知識を身につけるうちに、やっぱりこの金額でずっと続けるのは厳しいな、と思うようになりました。

しかも、僕が直接契約している開発会社さんは完全に僕のことはほったらかしで、１年経っても単価交渉などもせず、仕方なく僕が自分から言いだしました。よくある完全に搾取しているだけの会社さんのようでした。まあとはいえ間にはいっているだけなので何かやることがあるのかというと何もなさそうではありますが。（それでもよく何もわかっていない僕を案件につないでくれたことには感謝しています）

あと最近知ったのですが費用形態も謎でした。エンジニアは業務を行った時間を記録して申請してその分の費用を請求しますが、直でうけている開発会社などは固定（＋超過分）で費用をもらっているっぽいんですかね？　僕は週３で絶対に週５基準の時間に達することはないので、稼働時間が少なければ少ないほど開発会社が得をしている感じなんでしょうか。まあ別に自分が損をするわけではないのですが。

SES(仮)

契約は一応SESですが、実際の業務自体はちょっと違いますよね。直接お客さんとやり取りしたり、他のエンジニアは直接電話して怒鳴られたりしてましたし。本来SESだとこういうのはないんですよね？　でも当たり前のようにどこでも行われている。そもそも時間を提供しているだけなのであれば残業する必要も本来無いはずなので謎ですよね。

でもまあ「今はできません」とか、休みの日に「今日はやりません」とか営業さんに言えば調整してくれるので、それはありがたかったですが。（営業さんは自分のせいでもないので謝ったりしなきゃいけないのでそれはそれでストレスが溜まる仕事だと言っていました）

まとめ

SESはありか？

服装や振る舞いは自由で、一切常駐先の従業員とやり取りすることはなく、ずっと続けてくれるPMさんがいてちゃんと案件やissue、開発方針を管理してくれ、開発をしやすいベストな形で新しい技術や運用方法を取り入れ、おかしな残業時間が発生しないようにちゃんとスケジュール管理をしてくれ、時にはちゃんとリファクタリングの時間を作ってもらえ、入れ替わりで入った人にもそれらの情報を共有して誰がはいっても同じようにちゃんと仕事ができるようにしてくれる、という感じであればありだと思います。

でもこれってPMもお客さんもきっちり100%しっかり考えてくれる人が集まっている場合に限りますよね。人がどんどん変われば無理ですし、人が変わらなくても常駐先が変われば無理になる可能性もありますし、0.001%でもほころびがあれば無理ですから、机上では可能でも現実的には不可能なことなんじゃないかなと思います。

この机上の空論を信じすぎず、ちゃんと理解してそれでもしんどくてもいいからSESで働くことを今のところベストと考えてやっているエンジニアの方も多いと思います。正直自分もそうです。

それ自体は問題ないとは思いますが、そういった需要を増やしてしまうことが、SESを、特に利益だけを考えてむちゃくちゃな運用をするSESの会社を増やす事につながってしまっているということも認識しておいた方が良いと思います。

とはいえ誰もが自分のできる範囲で一生懸命仕事を探して一生懸命仕事をしているわけですから、正直単なる一エンジニアである僕がSESを否定することは不可能です。じゃあ受託開発できる方法を教えてよ、と言われても何も答えることはできません。これは恐らくみんなそうだと思います。ですのでこの場では肯定も否定もせず、あくまでも一つの声としての前提で書かせていただいた形とさせていただきます。

ただ、SES撲滅について日々Twitter上などでも活動されている米村さんは、自社開発限定のエンジニア人材紹介サービスを始めたりと、実際にSESを減らすための活動を頑張って行われているようです。これで日本中全ての問題を改善することは不可能だと思いますが、こういったことがきっかけとなって世の中が改善する方向に進んでいけばいいな、と思っています。

WebエンジニアがPCを買った時に考えたことをまとめてみた

2018-07-21T06:54:52+09:00

5年ほど使っていたPCが何をするにも重くなってしまい、そろそろ限界が近づいてきていたような気がしたので新しいPCを購入しました。Webエンジニアとして仕事で使うので、そのあたりも含めてその際に色々考えたパソコンの選び方を適当にまとめてみました。

2018/7購入の記事です。

PCでやること

ブラウザ操作
プログラミング
開発環境構築

など

重視したところは？

これはもう当たり前の部分なのですが、価格の安さとスペックの高さです。２つなのですがこれセットで一番大事です。どちらが欠けることは許されません。

あとはノートPCであることです。外に持ち運んだりはしませんが、PCを置く位置を簡単に動かせないのは厳しいので必須です。サブディスプレイも使わないので、15インチであることも必須でした。

スペックの高さ

元々使っていたPCは、Galleriaというゲーム用PCです。ゲームをしなくなったのですが、そこそこスペックが良かったのでそのまま仕事用に使っていました。それ以前はマウスコンピュータのデスクトップPCや、Thinkpadの激安なものを買っていました。

昔はWeb開発といえばサクラエディタ等を使ってWinSCPでファイルをアップする、みたいな感じではっきり言って性能などどうでもよかったため、ひたすら安さのみを考えていました。

ただ、現在のWeb開発だとChromeがそもそも重いしそこでSlackをいくつかとTwitterや時にはGoogle Analyticsを常時ひらっきっぱなしにし、プログラミングのためVSCodeもいくつか開いてdocker-composeでDockerコンテナをいくつか立ち上げ、Webpackでホットリロードしたりという感じで、作業中は結構CPUとメモリの稼働率が高いので、性能なんてどうでもいいとは言えなくなってきました。総合して重くなっていくので、何をするにも重い状態になってしまいます。

とにかく最低限のスペックの高さは必要です。

安さ

ソロとはいえ一応経営者なので、お金の節約にはこだわります。本当はケチなだけです。そのため安さは重要です。

あと出費がそのまま家庭にも反映してしまうので、今後子ども達や家族のために使う大切なお金であることを考えると、適当に無駄遣いはできません。スペックが良く、それでいて安い、最善のバランスを考える必要があります。

実際に検討した部分

SSD

SSDは必須でした。そもそもだいたいいつもPCが劣化して遅くなる原因というのがHDDの劣化によるものです。ものにもよると思いますが、今のSSDは性能が劣化しにくいという情報をどこかで見ました。本当かどうかは知りません。ただ、HDDしか使ったことがないので今回はじめて試してみています。さすがにHDDより劣化がひどい、ということはないのではないかと思います。ヘッダを動かしてデータを読み取ったりするとか正直よくよく想像すると信じられないことです。数年後どうなるか楽しみです。

容量は256GBにしました。512GBのものもありましたが、元々使っていたPCが128GBも使い切っていなかったので、おそらく256GBで大丈夫だろうと思います。（ただしスマホアプリやゲーム、デザインの開発環境などを入れると以前も限界近くにいっていたので厳しいかもしれません）

足りなくなった分は外付けのSSDを買えばいいか、と思っています。（追記：この判断は間違いでした。256GBはすぐなくなるので512GBにしておけばよかったです。ちなみに今は1TBに付け替えました。付け替えた方が安い場合もある？）

余談として、最近はSSDとHDDが両方入っているハイブリッドのPCもあるようです。見つけた時はいいかもと思いましたが、よくよく考えると劣化で遅くなるのが嫌だったのと、PCの大きさに影響したり熱の発生率の高さでファンが劣化したりと、色々と面倒なことが考えられる気がしたのでやめました。一時的なリースとかの用途であればそれでも良いのかもしれませんが。

メモリ

4GBは低すぎるし16GBは高すぎるし8GBくらい？　適当です。

追記）Twitterで8GBは少ないので16GBが良いという情報を見かけました。

追記）32GBのものを買って付け替えました。16GBでも良いのかもしれません。Chromeのタブのメモリ解放機能をストップすることができなくなったため、メモリが低すぎると作業に支障が出るようになりました。（付け替えた方が安い場合がある？）

CPU

よくわかりませんが良さそうなのを買いました。というか、SSDとメモリなどのバランスを考えると良さそうなのにするしかなさそうでした。

グラフィックボード

一応ちゃんとしたのが入っているものを買いました。全部CPUに任せるのはつらそうですし、もしまたゲームとかを作る気になったら必要だと思いますので余裕があったらつけておくとメリットがありそうです。

買ったもの

結局下記を買いました。

InfinityEdgeディスプレイを採用したXPS 15インチ9570ハイパフォーマンス4Kノートパソコン | Dell 日本

Dockerを使うためWindowsをPROにし、あとは保証をちょこちょこつけてだいたい20万円弱になりました。

決して安くないというか高い！　と思いましたが、LenovoとかMacBook Proに比べるとむちゃくちゃ安いです。買う気が失せていましたが、そのあたりの価格を見たら急に買う気が蘇りました。Dellはとりあえずラインナップを見てみるのはおすすめです。

そして今回は法人PCとして購入しました。余分なものも入っていないし、WebエンジニアがPCを購入するならどのメーカーにしろ法人PCが良さそうでおすすめです。

実際に使ってみてどうか

この記事を書いている前日に来たので、正直まだ良くわかりません。ただ、どのサイトを見てもスムーズですし明らかに早いです。前のPCはTwitterのタイムラインの上にあるformで投稿しようとするとキーボードを叩く度にカクカクなっていたほどです。Gmailも新しくなって異常なほど開くのに時間がかかっていましたし、Google Analyticsも同様でした。今はどれもぱぱっと開きます。そもそも回線のスピードチェックすら新しいPCの方が速いです。

これがどれくらいの期間維持できるのか、非常に楽しみです。

ちなみに前のPCはLinux MintというUbuntuベースのOSで、多分数年ほどそれだけで使えていました。が、今回はそのままWindowsを使ってみようと思います。

元々別にWindowsが嫌いというわけではなかったし、結局今はDockerも動くしあとはシェルがいい感じに使えればそれで不満はないので、意外といい感じに使っていけるのではないかと思っています。Git Bashが入っているので一応SubsystemのUbuntuを入れなくてもbashも使えますし、そもそも現在はWindows10のデフォルトになっているPowerShellが意外とすごそうなのでちょっと色々試していきたいと思います。

追記

開発の検証記事も書きました。
Windowsで快適なWebシステム開発を行えるか検証中

エンジニアが記事を書くためのブログやサービスまとめ

2018-07-18T06:35:41+09:00

エンジニアがアウトプット等の目的のためにIT系、テック系のブログを作ったり、サービス上で記事を書きたい、という場合があると思います。色々と選択肢があると思いますが、どういったものが良いのでしょうか？　僕自身実際に色々と使ったことがあるので、考察してみました。2020/9時点での考察となります。

特に下記あたりを考察しています。

使い勝手
集客能力

はてなブログ

使い勝手は？

はてなブログは恐らくブログサービスの中ではエンジニアに一番人気のものになると思います。僕も以前使っていました。

markdownで記事が書け、プログラム等のコードもちゃんと書けるので、技術系の記事を書くのには非常に適していると思います。デザインもカスタマイズ可能で非常に使いやすかったです。

有料ですが独自ドメインも使えますし、現在はSSLにも対応しています。

集客能力は？

特別なにか大きな集客能力は無いと思います。基本的には頑張って自分で集客が必要となります。

はてなブログは「スター」があり簡単に「いいね」みたいなことができますが、基本的には何の意味もありません。はてなブックマークボタンも別にはてなブログだけの機能ではなく他でもどこでも使えますし、特別はてなブログだから何か優れている、というところはないように思います。

ただ、記事がヒットすると提携しているSmartNewsにも掲載されたりすることがあるので、自分でうまく集客できる場合には相乗効果で大きなアクセスが見込める場合などがあります。

何にしろはてなブログは色々なところから注目されているブログではあると思いますので、独自でブログを作るよりは集客能力は大きいと思います。

SEO的に良いらしい

SEOで有名な辻正浩さんが下記のような記事を書いていました。

SEOに最適なブログとは？WordPressからはてなブログにした理由 - web > SEO

ざっとまとめると下記のようです。

特に他と比べて異常なまでに優れているということはない（そもそもそういうSEOは今は無いでしょう）
ただしちゃんと最新のSEOの対策に追従しているため、安心できておすすめ

サービスとして運営しているブログだからこそのメリットだと思います。WordPressのような自分で設置する形のブログだとこれはできませんし、上記記事でもSEOのメンテナンスのために時間を費やすことが難しくはてなブログに移行したということが書かれていました。

エンジニア向けの技術系の記事は実際にプログラムを動かしたりして正しいコードか確認したり、色々情報を調べつつ書かなければならないので記事を書くのにも時間がかかると思います。ですのでやはりこういったメンテナンスコストを無視できるというのは大きなメリットであると感じます。

色々総合すると、迷ったらとりあえずはてなブログを選んでおけば良いかな、という気がします。

引っ越しは？

独自ドメインで運用している場合は引越し先のURLを合わせるか302リダイレクトするかできっちり引っ越しできます。はてなブログのドメインで運用している場合はやめたくなっても引っ越しはできません。一生骨を埋める覚悟で使うか、あきらめて記事を残して引っ越す必要があります。

Qiita

Qiitaはプログラミングに関する技術系の記事を書くためのエンジニア向けのサービスです。ブログではありません。

自分が書いた記事をQiitaとして発信する、ということになりますので、全て寄稿する形になります。ただしその分導線がしっかりしているため、自分に集客能力がなくてもそこそこ記事を読んでもらうことができます。

また、ちゃんと記事を書ければわりと「いいね」も付けてもらえ、「いいね」がつくとさらに導線が増えアクセスが望めます。

ブログではないので引っ越しなどもできませんが、特にSEOも考えたくないし、自分の集客力に関係なく記事を誰かの役に立ててもらえたり、気軽にどんどん書いて自分の認知度を広めたりしたい、という場合にはおすすめです。

note

noteは特にエンジニア向けではなくて決まったジャンルもなく、何でも記事を書けるサービスです。有料記事が書けるため、記事を売りたいのであればここ一択だと思います。集客も考えるのであればどんどん自分の記事を増やしておいた方が良いと思いますので、無料記事も普段からnoteで書いておいたりした方が良さそうです。もちろん自分の集客力があるなら有料記事だけnoteで他は他で、でも良いと思います。

エディタは特殊ですが、わりと深く考えずにどんどん文章を書けるので、あう人には非常に書きやすいと思います。プログラミングのコードも一応書くことができるようになっています。

あとは有料ですが独自ドメインのプランもあるようです。

あとはバズったりすると公式のおすすめ記事などで紹介されたりするので、さらにアクセスを増長することができたりします。

Zenn

こちらは2020/9にリリースされた個人開発サービスですが、いくつもの有名なサービスを作った方が開発された、プログラマーのための情報共有サービスです。Qiitaとnoteの良いところを組み合わせたようなサービスで、記事、本が投稿でき、本は有料販売できます。記事についても販売はできませんが、サポートを受け取ることが可能です。

Markdownで記事を書きますが、CLIやGitHubと連携することで好きな環境で執筆することもできるようになっており、まさにプログラマー向けという感じがします。

WordPress

WordPressは自分でサーバーにインストールする形のブログです。とにかく自分でガンガンカスタマイズしたり、遊びつくしたい、改良したい、という場合にはWordPress一択になると思います。

一般的なサービスではないため、集客も100%自分で行う必要があります。また前述の辻さんの記事の通り、何かSEO的に改善が必要な場合自分で調整しなければなりません。WordPress自体のプログラムをいじるか、対応するプラグインを探すか、という形になるのでメンテナンスコストは高いと思います。あとはバズった時にサーバーがしっかりしてなければ止まってしまう恐れもあります。

ただ、やはり「記事を書いて集客する」という目的がメインになると思いますが、そのメイン以外のことに時間を費やさなければならないため個人的にはあまりおすすめできません。何かしらのサービスを使うことがベストだと思います。

本当にカスタマイズが好きな人のみが利用した方が良いと思いますが、真剣に書き始めていき段々と記事を書いたり調整することがメインになっていった場合、あとで後悔する可能性も出てきますのでそのあたりも考えてみてください。

ただ、302リダイレクト等も自由ですので、引っ越しはきっちりできる、というメリットはあります。

Medium

使い勝手など

Mediumは海外製の記事投稿サービスです。自分のブログのように使うことも可能です。結構日本の方も利用しています。

ジャンルは何でもOKです。とにかく見た目が美しく、僕も何か用途があれば自分でもメインで使ってみたいと思っています。そういう部分でファンも多いと思います。

独自ドメインの利用や、最近ではnoteのような収益化の方法もいくつかあるようです。

集客方法は特に無く、適当に記事を書いても一切アクセスはありませんので、自分で頑張る必要があります。

noteは結構Mediumを参考にして作られていると感じます。日本の場合記事を書いた時の集客力はnoteの方が多少大きいと思いますが、Mediumの方が規模が巨大でSEO的にも優れていると思いますので、サービスの集客力に頼らず検索流入なども利用して長期的に自分のブログを育成したい、というのであればMediumの方が良いと思います。

ただ、noteの方が日本でユーザー登録済みの人が多く有料noteの購入頻度は高そうな気がしますので、日本で自分で集客してガッツリ売りたい、という場合はnoteの方が良いのかもしれません。

カノニカルURLの利用

Mediumは記事にカノニカルURLを指定でき、SEO上重複記事とならない形で自分のブログとまったく同じ記事を投稿することができます。ですのでブログは他で書き、記事が目に触れる頻度を増やしたい、という場合はこういった使い方もアリです。

dev.to

こちらも海外のエンジニア向けのコミュニティで、記事を投稿したりできます。一応日本の方も投稿されているようですが、ほぼ英語メインのように思います。

ただ、こちらもカノニカルURLを指定してのクロス投稿が可能ですのでとりあえず自分のブログの記事を投稿しておくのもアリだと思います。

Crieit

Crieitは当サービスです。Qiitaのように記事を書けるサービスです。

作成した意図としては下記になります。
次に作りたいQiita、dev.toの様なサービスについて

Qiitaは基本的にはプログラミング関連の記事のみしか書くことができません。実際にはかなり多くの方が関係ない記事も書いていますが。当サービスはエンジニアが興味のあることであれば何でも書くことができ、質問、議論なども自由に気軽に書けることでQiitaとの差別化を目的として開発しているコミュニティです。よろしければ是非何か投稿してみてください！

また、当サービスも日本ではめずらしくカノニカルURLの設定を採用しており、自分のブログの記事をクロス投稿することができます。とりあえず自分のブログの記事への流入機会を少しでも増やしておきたい、という場合はどんどん投稿していただいて大丈夫です。

個人でやっているためパワー不足ではありますが、開発者や公式ツイッターアカウントにて可能な範囲で記事をツイート等で拡散したりしています。

Qrunch（閉鎖）

こちらも個人の方が運用されている、当サービスと同様のコンセプトを持ったサービスです。ただ、こちらはブログという形態での運用となっています。寄稿形式ではなく自分のブログをちゃんと持ってアウトプットしたい、という方はこちらのほうがオススメです。

まとめ

色々とエンジニアがIT系の記事を書くためのブログやサービスを紹介してみました。どれも少し特徴が違うので、丁度自分にあったものを使ってみると良いと思います。何も決まらなければはてなブログ、記事を売りたいならnote、自分で頑張って育成するのでブログにしてマネタイズもしたいならMediumがとりあえずは良いかな、と思います。無料プランだと記事の価値が各サービスのドメインに行ってしまいもったいないので、有料プランにして独自ドメインでの運用がおすすめです。

これにかぎらず、書いた記事は自分の大事な資産ですので、独自ドメイン運用ができるものはできるだけそのようにしておいた方が良いと思います。そしてカノニカルURLを設定してクロス投稿できるサービスにも投稿しておく、とするとベストだと思います。自分が書いた一つ一つの記事を大事にして価値を高めていきましょう。

追記）
最近エンジニアのブログの書き方の連載を始めてみました。フィードもありますので、これから始めてみたい、という方はぜひ購読して追ってみてください。

連載 - エンジニアのブログ始め方