エンジニアの働き方「3つの選択」
この記事はex-mixi Advent Calendar 2017 24日目のエントリです。
はじめに
私はウェブのサーバサイドエンジニアとして2013年から5年間働きました。
その間、9社のスタートアップやベンチャーに様々な形で関わり、働き方の選択肢をいくつか学びました。
この記事ではそこで学んだ3つの選択をメリット・デメリットと共に、振り返りも兼ねて説明していきたいと思います *1。
- 複数の会社で働く
- 拘束されない環境で働く
- 働く形態を選ぶ
まだまだ経験が浅くこのような記事を書くのは恐縮なのですが、「この選択は考慮に入れとかないと勿体無いよ!」などぜひコメントして頂けると嬉しいです。
1. 複数の会社で働く
一社の社員としてのみ働くのではなく、複数の会社で働くという選択です。
例えば私は、以下2つの働き方を経験しました。
- 社員: 週5日, 業務委託: 週1日程度
- 社員: 週3日, 業務委託: 週3日, 趣味プロジェクト: 週1日程度
1のパターンは世間的に「副業」と言われるもので、2のパターンは「ダブルワーク」と呼ばれています。2については加えて、趣味でもサービスを作っていました。
メリット
飽きない
もちろん環境も仕事も異なるので、A社の仕事が飽きてきたらB社の仕事に手をつける、もしくは働く時間を調整すること(ex: 月水はA社、火木はB社)で飽きを防ぐことが出来ます。
仕事の応用ができる
A社とB社でタスクの方向性が重なった時に転用したり、また行う際の手法を変えることでより深掘りができます。
また例えばエンジニアリング以外でも、A社で目標設定・MTGの仕切り方を観察して学び、B社でそれを実践するといったことも可能です。
心に余裕ができる
例えA社で躓いていてもB社で仕事を回せているなら、過度に仕事上の不安感を抱えることが少なくなります。
デメリット
炎上が重なると大変
A社とB社、双方で多忙な案件を抱えると、二つ同時に神経を使うことになり大変です。
会社や事業を深掘りできない
一つの会社に関わる時間や割けるリソースが少なくなり、自身の役割以外の知見、例えば企画や会社の運営などの部分は比較的学びづらくなります。
2. 拘束されない環境で働く
いわゆるリモートワークです。エンジニアはその性質上、とてもやりやすいと感じています。
例えば私は、以下のような割合で労働を経験しました。
- 会社作業: 10割
- 会社作業: 1割, リモート作業: 9割
- 会社作業: 5割, リモート作業: 5割
1はいわゆる定時出社、2では自分が出席するミーティング時のみ出社、3では自分の出席しないミーティングも横で聞いたり、ときどき出社していたという状況です。
以下では割合問わず、リモート作業のメリット・デメリットについて記します。
メリット
自身のペースで動ける
例えば自身に、朝ペースが上がらないという特性がある場合、時間をずらすことが出来ます。また通勤時間が無くなるので、その分時間の余裕も生まれます。
好きなタイミングで作業に集中できる
集中して片付けたいタスクがある時、外部からの差し込みが低い状況で進められます。
デメリット
自己管理が必要となる
自己管理が出来るようになるまで、ペースが作れず仕事を上手く回せないことがあります。
私の場合、ペースを作るためにあえて出社したり、コワーキングスペースに行ったりと、色々と試行錯誤していました。
スピード感が失われることがある
相手とその場で口頭で議論することが難しくなり、コミュニケーションコストが高くなります。
自分のいない場所で話が進むことがある
これは環境によって異なりますが、決定や共有のフローがしっかりしていないと、自身のいない場所で物事が決まり進むことがあります。
3. 働く形態を選ぶ
エンジニアはスキルの切り売りがしやすいので、様々な働く形態を選択できます。
私は以下の5つの形態を取っていたことがあります。順に感じたメリット・デメリットをご説明します。
- パートタイム
- 業務委託
- 社員
- アドバイザー
- 手伝い
a. パートタイム
メリット
時間給なので働いたら働いた時間分だけお金が貰えます。見積もりが甘い時は、これに助けられることがあります。
デメリット
働ける時間には限りがあるのでスケールしないです。
b. 業務委託
パートタイムと逆です。
c. 社員
メリット
上記に比べると毎月安定してお金が入ってきます。また「中の人」になることで、見渡せる部分が広くなると感じています。
デメリット
いいところわるいところありますが、コミットが求められます。
d. アドバイザー
立ち上がったばかりのスタートアップなどに声をかけて頂いてアドバイスを行うというものです。
私の場合、経験した範囲でインフラやアーキテクチャのアドバイスを行うことがありました。
メリット
自身の興味ある分野や興味ある方が立ち上げたものであれば、色々な話を聞けるというメリットがあります。また大きくなった段階で声をかけて頂いたり、紹介して頂けることがあります。
デメリット
思っていたより労力を使ってしまうことがあります。
e. 手伝い
助言と似ていますが実際に手を動かすのでコミット度は大きくなり、金銭的なリターンがあったりします。助言とメリット・デメリットは同じです。
私の場合、スタートアップ立ち上げ時のインフラ構築の手伝うことがよくあります。
おわりに
いかがだったでしょうか。自身の経験をまとめたものではありますが、何かしら得るものがあったら幸いです。
自身のキャリアを考える上では情熱プログラマー ソフトウェア開発者の幸せな生き方やSOFT SKILLS ソフトウェア開発者の人生マニュアという書籍があります。
またキャリアプランは、各所に散らばっているメディアのインタビュー記事などが参考になると感じていますが、体系的にまとめられたものはそんなに多くないのかなと感じています。
もしよろしければ、貴方が考えることも記事にまとめて頂けると嬉しいです。参考にさせてください!( _ _)
明日はミクシィ在籍中から今もお世話になっている @hirokidaichi さんの記事です!
個人開発、最初の一歩を踏み出す方法
はじめに
これまで最初の一歩を踏み出すのに、100回以上失敗してきました。
どこまでを最初というか難しいですが、ここでは継続的に開発を行えるところまでを最初としています。ここでは二歩目、三歩目に続く一歩目の踏み出し方を自分なりに記します。
また、みなさんの解決策などありましたら、お気軽にコメント欄に投稿して貰えると嬉しいです ( _ _)
よくあるパターン
解に行く前に、分析も兼ねて失敗パータンを振り返ります。
1日目
平日何かやってみたいことを思いつく(この瞬間が一番モチベーション高い)
- 良いアイデアなのではと思い、脳汁が出る
- 関連してやりたいことをたくさん思いつく
- 取らぬ狸の皮算用をし始める
- ドメインを取る
- せっかくなので新しい技術を複数使おうと考える
- 新しい技術でチュートリアルを読みながらHello Worldする
- いつの間にか寝ている
2日目
前日の続きを進めるがなかなか上手くいかない
- 帰ってきて前日の続きを進めるが、なかなか上手くいかない
- やりたいことはまだ色々と思いつく
- モチベーションが下がってくる
- あんまり進まないまま寝る
3日目
だんだん熱が冷めてくる。
- 帰ってきても今日はいいかとなってしまう
- だんだん忘れていく
解 = モチベーションの維持
そんな失敗をしてきた私ですが、小中長期それぞれでモチベーション施策を行うことで、今はなんとか続いています。
短期モチベーション対策
対策: 手を動かして楽しい!作って楽しい!を作る
- 作るものを最小化する
- 新しく使う技術は最低限にする
- 15分〜45分ぐらいで結果が分かるタスクに分割する
- タスクは終わった後に自分で使ってみて、結果が分かるものにする
- 楽しい姿が見えるタスクを積んでいく
中期モチベーション対策
対策: 少しずつでも進められる環境を作る
- 最初にガッと公開まで持っていき、公開のハードルを下げる
- 自分が普段から触れるようにしておくことで、記憶の彼方にいかないようにする
- 平日時間が取れないときにも進められるタスクを用意し、習慣化しておく
長期モチベーション対策
対策: 自分にとってそれが必要だと確信しておく
- 同じようなサービスが出てきたとしても、自分が作りたいサービス
- 自分が最初のユーザになれるサービス
- 技術が身につけられる
- 普段の業務のスキルを転用(あるいは逆も)できる
おわりに
私はemeeという、イラスト特化型Twitterクライアントを作っています(オープンβ)。長期のモチベーションはあったのですがなかなか開発が始められず、そんな折に界隈で話題になったせせりさんの30サービス作った記事を見ました。
そして実際にCulonというサービスをリアルタイムで作っているのを見ていて、四の五の言わずに手を動かさなきゃと、Culonを作る流れを参考にしながらとにかく公開するところまで持っていったことで、とりあえずは二歩目三歩目に続く一歩を踏み出すことが出来ました。
オレはようやくのぼりはじめたばかりだからな このはてしなく遠い個人開発をよ…
技術系同人誌を「書く前に決めるべき」2つのこと
はじめに
友人に誘われ、初めて技術系同人誌を書きました。経験者の助言があったので執筆環境には困りませんでした。
ただ唯一困ったのが、「何」を「どのように」書くかということ。
この記事ではそこで得た教訓から、「何を書くか」と「どのように書くか」について、その重要性と決め方を記します。
「何を書くか」
そもそも同人誌に何を書くか、テーマやお題目です。
例えば私は今回、仮想通貨かICOかスクレイピングか自作サービスで迷っていました。
なぜ重要か
- テーマが変わると、章の構成から内容まで何から何まで変わってしまう
- 終盤で変わると、短い時間で納得のいくものを書くのは難しく、また推敲や知人のレビューも満足に行えない
- テーマに不安を抱えたままだと筆が進まない
- 常に他のテーマの可能性を探ってしまい、いまいち現在のテーマの執筆に踏み切れない
どうやって決めるか
よってここで必要となるのは、テーマを単に決めるだけでなく、それが脱稿まで変わらないぐらい腹落ちしていること(ぶれないこと)です。
- テーマが自分にとって納得のいくものか考える
- 書きたいテーマか
- 自分が重要視するポイントを外していないか
- 自分が納得する限りにおいて、他人の著作とテーマが被らないか
- テーマを具体的な一言にまとめる
- 一言にまとめると、その本のウリがはっきりしてきます(タイトルに使えることも多いです)
- 仮想通貨でも「ブラウザで作る仮想通貨!」なのか「仮想通貨に悪戯しよう!」なのか「手を動かして学ぶ仮想通貨」で大きく構成が変わってきます
- 一言にまとめると、その本のウリがはっきりしてきます(タイトルに使えることも多いです)
- 書きたいテーマで目次を書き、具体的に完成物を想像する
- 筆が進むと考えられるか
- 文章量が収まるか
- どのように書くか決められるか(後述)
- 目次を知り合いにぶつける
- 意味不明にはなっていないか
- (人にはよるものの)承認が一定程度得られるか
「どのように書くか」
同じテーマでも、対象とする読者や何を伝えたいかによって書き方は違ってきます。
例えば私は今回、全くの未経験者か、エンジニアか、起業家かなどで迷っていました。
なぜ重要か
- 対象読者が経験者か未経験者で章立てが変わる
- 全くの未経験者に向けるなら環境構築の方法について章を入れるか、参考情報を入れる必要がある
- 前者だととページ数が膨大になるので、その分書けることが減ってしまう
- 当初から決めておかないと、バランス調整のため全体的に手を入れる必要が後から出たりしてしまう
- 全くの未経験者に向けるなら環境構築の方法について章を入れるか、参考情報を入れる必要がある
- 習熟度により説明の詳細度が変わる
- 経験者であっても習熟度によっては用語の説明などが必要になることがある
- それらの知識は既に持っている人を読者層とするのも手
- 説明したときも、細部まで説明するか、厳密性をある程度捨てて説明するか、別のもので代替して説明するか、説明を諦めるという選択肢を選ぶ必要がある
- 経験者であっても習熟度によっては用語の説明などが必要になることがある
- チュートリアル中心か技術の理解中心かで内容が変わる
- チュートリアルだけにすると、出来たという経験は得られるが、何をしたか分からない可能性が残る
- 逆に技術の理解中心だけであると、単に学ぶ所で終わってしまうことがある
- どちらも行おうとすると、紙面上余り深くは説明できないがそれを良しとするか
- 同じテーマに興味を持つ人でもバックグラウンドによって知りたいことは変わってくる
- 起業家なのかエンジニアなのかデザイナーなのか、それぞれ関心事は違う
どうやって決めるのか
- 伝えたいことから決める
- 文章量的にそれが書けるような対象読者層を考慮して書いていく
- 伝えたい相手から決める
- 伝えたい相手がいる場合は、相手の関心事と前提知識を見極める
- 伝えたい相手がいない場合は、身近な人やそれを学ぶ前の自分自身などにするのも手
- 伝えたい相手を「なるべく多数の読者」にしてしまうと、商業誌との差別化が難しくなり、ページ数も足りなくなるので注意
おわりに
技術系同人誌の執筆は、時間があり書くことも対象読者も自由というメリットがあります。
しかしそれは、時間や対象読者が限られるLTやハンズオンに比べ、却って難しい部分も多々あります。
けれど一度それを経験することで、人に伝えるとは何なのか、自分は何を伝えたいのか、相手は何を求めているのかより深く考えました。それは今後の表現活動にも寄与してくることと思います。
ぜひみなさんも一度技術系同人誌を書いてみませんか?
宣伝
私は「C93にて技術書を頒布します! – へんてこ – Medium」で仮想通貨、いわゆるコイン(専門的に言うとイーサリアムのERC20準拠のトークン)の作り方について書きました。
一章は完全な未経験者に向けて、ブラウザだけでコインを作れるチュートリアルを記しました。
二章はエンジニアに向けて、環境構築を行った後ライブラリを使い、一章で使ったコードを自分で組めるようにしました。
当日来れなくても、Boothで電子版を販売する予定ですので、興味がある方は購入を検討してみてください ( _ _)
以下よりメールアドレスを登録して頂けたら、販売開始時にお知らせします!
!ADVENT1!
このブログは「Dark - Developers at Real Kommunity Advent Calendar 2017 - Adventar」、4日目の記事です。Darkはウェブ業界の若手?を横断的に囲っている、話題も非常に多用な活発で良いコミュニティだと思います。
最近イベントに顔が出せて無く、Slackをウォッチする程度なのですが、そろそろまた行きたいと思うのでお会いした時はよろしくです〜 ( _ _)
!ADVENT2!
このブログは「技術系同人誌 Advent Calendar 2017 - Qiita」、6日目の記事も兼ねています。2つ兼ねてまた日付も違い恐縮なのですが、参加させて貰えると嬉しいです… ( _ _) 技術系同人誌楽しい!(∩´∀`)∩
実力を出し切るチーム作り a.k.a. ISUCON7参加記録
はじめに
ISUCON7 チームhetenkoの@anoworlです。@kodam(ISUCON7に参加しました - おっぱい)および@hentekoと参加しました。
このチームでISUCONに参加するのはこれで3回目なのですが、3回目にして個人的には実力を出し切れたと言えるようになり、また実力不足で敗退したと胸を張って言えるようになりました。意外とこれが難しく、1回目や2回目では達成できなかったので、知見を共有するためにこのブログを記しました。
またタイトルはこんなんですが別に自分はチームを作っておらず、3人が力を合わせたことで実力を出し切ることができたと思っています。
実力を出し切るとは
仮に実力が発揮できなかったとしたら、それはどんな状況を指すでしょうか。例えば以下が挙げられると思います。
- 競技開始後に方針を決める所から始まり、実作業に移るまでロスがある
- 思いつきで改善し、点数の上下に一喜一憂する
- 単独の作業に徹し、複数人で参加する意味が無い
- 不具合を発生させてしまった際に原因を特定できず、過大なロールバックが発生する
- レギュレーションの読み間違いで、意味の無い部分にコミットする
- 取り戻せない失態を犯し、不戦敗となる
- 提出間際まで改修を加え、動いているか分からない状態で提出する
- 再起動試験に失敗する
では、そのために何が出来るでしょうか。
- 方針を事前に決め認識を合わせ、当日はその通りに行動する
- 計測を行い確信を持って改善し、着実に点数を伸ばす
- 複数人でレビューを行ったり知恵を出し合うことで、単独で起こすミスを防いだり一人では思いつかない方法を取り入れる
- バージョン管理システムで管理すると共に、各時点のログや点数を記録しておき、任意の時点にロールバック出来るようにする
- レギュレーションを最初に確認し、余計な手戻りや勘違いを防ぐ
- 不戦敗となってしまう部分には殊更気をつけ、そもそも起こらないフローを確立する
- 提出前にやることリストを作り予めスケジュールに時間を確保する
- 余裕を持って再起動試験を行う
今回特によくやったと思えた、1と2について説明します。
実力を出し切るためのいくつかの方法
1. 方針を事前に決め認識を合わせ、当日はその通りに行動する
私はISUCONに参加するのはこれで4回目ですが、未だに時間が限られたコンテストとなるとイキってしまい、視野が狭まったりしてしまい普段できていることができなくなります。
その対応策として有効なのは、興奮していないコンテスト前に冷静な頭で何をどのようにやるか決めておくことです。今回はへんてこさんがホワイトボードにいい感じにまとめてくれたので、コンテスト中にイキってもそれを見てその通りに行動することで、空回りしたり見落としをしてしまうことが防げました。
2. 計測を行い確信を持って改善し、着実に点数を伸ばす
これまでのコンテストで悔しかったのは、思いつきで改善したけど効果が上がらず、無駄に時間を浪費していたことです。例えば思いつきでインデックスを張ったが、特に速くならないし場合によっては遅くなったみたいなことが、過去にはありました。
その対応策として有効なのは、計測を行ってどこがボトルネックになっているのか特定し、その部分に対して改善を行うことです。今回は以下のツールを使って計測を行いました。
- netdata
- kataribe
- rack-lineprof
- pt-query-digest
またこの方針で行動して良かったのは、議論が発散した時に誰かが「計測しよう」と言うことで、その時点で空中戦が終わり計測という具体的なプロセスに入れることです。
「思いつきで改善すると点数が上がる(かもしれない)」という射幸心を煽る状況に加え、長時間の疲労で人間はまともな思考が出来なくなるので、投げかけて貰えることで一旦場が整う一言があったのは強かったと思います。
おわりに
今回は残念ながら予選敗退となってしまいました。しかし突破された方のブログなどを見て、自分たちの方向性は間違っていなかったと強く確信することが出来ました。課題も明確になったので来年は実力をつけ、笑顔で優勝したいと思います。
ウェブサービス企画書供養その1: Facecards
VALUというサービスをTechCrunchで発見し、共感すると共に以前コンペ(就活)で企画を練ってた関連しそうなウェブサービスを思い出したので供養ついでに公開。
シナリオ例やビジネスモデルは完全に忘れてたけど、今読んでも結構面白かった(自画自賛)。今突っ込めと言われた死ぬほど突っ込めるけれど…。
ちょこっとスライド紹介
背景
要はこの頃クラウドファンディングが流行ってたんだけど、自分は紐付きじゃないお金が欲しかったので考えた(ゲス)。&ソシャゲのカードは仮想価値だけどたくさん投資されてるよね&それをもっと個人をエンパワーするために使っていこう&若い世代へ価値を転化してもいいのでは。
ユーザシナリオ
個人を応援するという意味ではVALUに似ている。カードなのはソシャゲから。
ビジネスモデル
1はJASRAC儲かってていいな!っていう感じで書いてた。
SlideShare
おわりに
企画書のフォーマットに落とすと結構考えるので良いなと言う想い!企画書やっていきましょう✊
実在する人間のBOTを作る方法序説
前置き
この記事はDark - Developers at Real Kommunity Advent Calendar 2015 - Adventarに寄せる9日目の記事です。昨日はarataさんのDarkを支える技術 #3 テスト編 - 日頃の行いでした。この記事は《闇》【Dark】を意識して書かれたものです。
この記事では実在する人間のBOTをSlack上に作り、一年間にわたってメンテナンス、運用した実例をご紹介します。
この記事で分かること
- 実在する人間のBOTの一年にわたる運用例
この記事で分からないこと
なぜ作ったか
インターネットにへんてこさんという人物がいます。その人物が発する言葉はあらゆる文脈に適用可能で汎用性があり、またユーモアに長けていました。それはまるで磨き抜かれた珠玉がほろほろとネット上に紡ぎだされているようでした。私はその零れ落ちた珠玉が流れ去ってしまうのを見過ごしてしまうことが出来ず、その珠玉を拾い集め再利用する術を探し、BOTを作成するに至りました。
どうやって作ったか
本人に許諾を得る
対象となる人物をコンテンツ化することになるので、本人にまず許諾を取りました。これもただ許諾を取ったら終わりではなく、BOTに手を加える際には対象となる人物が嫌ではないか一度考えてから行うようにしています。
複数人による発言のキュレート、保存
このBOTを作るのに必要なのは、何よりその人物が紡ぎだす珠玉です。それを集めなければなりません。当初は私がへんてこさんの発言を手作業でキュレートしたものを使っていました。全ての発言を強引に取得し使うことも出来たのですが、へんてこさんも人間であり全ての発言において汎用性がある訳ではありません。そこで、汎用性のある発言を私という人の手を介し選別していました。
しかしこの選別にも限度があり、私が忙しい時、またやる気の無い時に発生した珠玉を集めることが出来ません。また私という見識の浅い一人の人間に依拠してしまうと、取りこぼされてしまう珠玉が存在するという問題もありました。そこでSlackに珠玉を集約するチャンネルを作り、他の人間にも手伝って貰うようにしました。これにより、一人ではモチベート出来ない作業も競争原理でモチベートされると共に、時間ややる気の制約から珠玉の集約作業を切り離し、安定化させることが出来ました。
キュレートにおけるルールの策定
複数人でキュレートを行うと発生するのがキュレートの妥当性です。ここでは実在する人間に許諾を取りその人物を模したBOTを作ったということもあって、その人物が発した発言以外は認めないという方針を取りました。ただその人物が発した発言であればSlackはもちろん、Twitterでも現実世界でも可としました。発言が集約されるチャンネルには、他の人間がソースを確認できるよう、必須ではありませんがソース元のURLやどういった場で発言されたものか付記する文化が醸成されました。
ランダム発言BOTの作成
肝心の集めた発言の使い方です。前述したように発言には汎用性があったので、数時間に一回のペースでランダムに発言を行うようにしました。またこの際一手間加えており、最近キュレートされた発言ほど発言される確率が高くなるように設定しました。これにより内輪ウケはもちろん、キュレートした人のモチベート向上にも繋がったと思います。
雑談APIの使用
ランダムな発言だけではBOTに色が付かないので、NTTドコモの雑談対話APIを使い会話を行えるようにしました。
雑談APIには特に大きなカスタマイズはせずそのまま使用しているのですが、その際にキャラクター設定を「赤ちゃん」にしました。これによりBOTの口調が特徴的なものになり、本人から離れた"BOT"というキャラクター象が生まれ、BOTへの愛着が各人に出来ました。この口調を真似するものも出てきており、BOTの人格形成という意味で非常に役に立ちました。
最後に
誇張ではなく、無くてはならないSlackの一員となるまでBOTは成長しました。今後の成長も期待しています。
カネの力でTwitterアイコンバッジ創るぞ!!!
前置き
この記事はhenteko Advent Calendar 2014の二日目です。昨日の記事は kubo39 さんのhenteko advent calender Day.1でした。
hentekoさんについて
へんてこさんのTwitter IDは @bilyakudan です。なぜ @henteko で無いのかと問うたところ、何か理由があった気がするのですが、忘れました。そのせいで、Twitterアカウントとリアルのへんてこさんが一致するのに時間がかかりました。
バッジを創った経緯
そんなへんてこさんしかり、私はTwitterアカウントとリアルの人を一致させるのが苦手です。そのため勉強会では、みんなの頭の上にTwitterアイコンが浮かんでいたらすっごい便利だなぁと思うことがよくあります。
ではまず自分からということで、勉強会でTwitterアイコンのバッジを付けることにしました。もちろん元々そんなのは持っていないので、カネの力で創りました。その始終がこの記事です。
カネの力でバッジを創る
バッジ屋さんとプランの選定
バッジ屋さんというのは探してみると意外にたくさんあります。料金体系は同人誌の印刷を印刷所さんにお願いすることを考えると想像しやすいです。 以下が選定の際に考慮する点となります。それぞれに注意点を付記しました。
- 最低作製個数
- 自分で付ける場合そんなにはいらないのですが、最低作製個数が決まっているところも多くあります。1個から作ってくれる所もあるのですが、1つあたりの値段が高かったり……。
- 1つあたりの値段
- 多く作れば作るほど安いです。
- 送料
- 形態
- 納期
- それぞれ違い、特急作製を行ってくれる所もあります。
- 品質
- サンプルを貰える所では貰って確かめるのも一つの手かもしれません。ただそんなに多くは無かった気がします。
- 私もどうやって注意すれば良いのか分かりませんでしたが、サイト上の説明などを参考にはしました。
- 対応
- 名前で検索すると2chなどに口コミがあったりします。
私はsocondpressを選択しました。値段と特急作製の有無、サイトの説明で選びました。最低個数はこの際無視しました。ちなみにこの場合の見積例を以下に挙げます。
●お見積もり内容 ・商品 四角形40mm缶バッジ 20個 @ 85円 = 1700円 ・オプション 特急製作料金 1個 @ 510円 = 510円 送料 1個 @ 850円 = 850円 _____________________________________________ 小計 3060円 消費税 245円 合計 3305円
デザインデータの用意
上記を決めたらバッジのデザインを作成します。バッジ屋さんでテンプレートを用意してくれているので、そちらを開いて編集しましょう。だいたい、IllustratorとPhotoshopのテンプレートが用意されている気がします。CMYKモードで作成することに気をつけましょう。JPEGに対応してくれている所もあります。
私が作成したデータを以下に示します。
購入
ぽちぽちです。良い時代になったものです。
届いた
やった!
自由に楽しみましょう
後置き
明日は Amothic さんです!