Make組ブログ

Python、Webアプリや製品・サービス開発についてhirokikyが書きます。

英語・英会話が苦手なときは処世術やソフトスキルが重要なのでは?6つにまとめて考えてみた

「英語って難しい」というとき、ほとんどは英会話が難しいということだと思います。 そしてたぶん、その難しいというのは英語以外のスキルも含まれる気がしています。

要は 「ネイティブ同士でない会話におけるソフトスキル」が必要 ということです。悪く言えば弱者の戦略です。 その英会話の処世術・ソフトスキルを、僕なりに6つにまとめて考えました。

今回話す内容は「多少は英会話ができるけど、どうにもうまくいかないことがある」という人に向けています(僕自身に向けてもいます)。 コロケーションがどうとか、単語でなく音で覚えるとか、そういう話は他の方が書いているので任せます。英語つよつよな人は読まなくて大丈夫です。

本当に聞き取りがまったくできないという場合は、英語学習者向けのポッドキャストなどをオススメします。

背景と、日本人的な弱点について少し考える

これを感じた背景は、僕がVRChatというゲームで海外の人とボイスチャットをしていたときです。 僕は英語がすごくヘタですが、英会話をする点については多少はできます。でもたまにコミュニケーションを全く取れないときがあります。

それはなんでだろうと考えていくと、単なるスキルでない振る舞いが影響しているのではという仮説に行き着きました。 もちろん英語の勉強や英会話の練習も大切ですが、それ以外の処世術も伸ばすべきなのではということです。

日本人が日本に住んでいる限り、人生の大半はネイティブ同士の会話になります。 なので 僕ら日本人は会話のどちらかor両方がネイティブでないときに話をするのが下手になりがち です。

英会話を伸ばそうというとき、現実的にはその問題にも向き合う必要があると感じています。 僕自身が考える過程で6つにまとめてみましたので、ぜひ読んでみてください。

僕はTOEICTOEFLも英検も受けていないので、自分の英語力というものはわからないです。留学経験もないです。 ただいくつかの英語のYouTubeチャンネルを見れたり、ポッドキャストを聴いたり、映画や北米版アニメを観たり、会話は多少できるレベルと思ってください。

1. 自分の英語レベルをまず知ってもらう

相手に自分がどの程度の英語が伝わるかを知ってもらうのが大事です。 そうすれば相手もその速度、ボキャブラリーで話してくれる確率が高まります。

ファーストインプレッションで、相手に自分が期待するレベルの英語で話す のがポイントです。 相手に話してほしい速度で話し、相手に使ってほしいレベルのボキャブラリーで話しましょう。とくに1対1の会話では有効です。 相手に対しても、相手に伝わるような英語を心がけます。

逆に言えば、過度に見栄をはらないということです。相手の期待を下げるということです。

自分が話すときだけ早口になったり、よく知らないスラングを使ってみたり、難しすぎる英単語を無理に使ってみるのはオススメしません。 相手もその高いレベルで話してくる可能性が高まるので、後で自分が分からなくなってパニクるだけです。

うまいフリをするくらいなら、ヘタなフリをするくらいのほうが会話のレベルを下げられて得です。 お互いに伝わる範囲を模索してコミュニケーションしましょう

ともあれ、ありのままが一番です。

2. 分からない点は早めに聞くか確認する

一度英語が分かるフリをして辛くなったことはないでしょうか?

話が分かったフリをするとドンドン辛くなって会話から離脱したくなります。 その気持ちは相手にも伝わりますし、「この人は私と会話したくないのかな」と思われてしまいます。 不思議なことに、「あぁ英語が伝わらなかったんだな」と思ってくれる人は経験上、稀です。

分からないときは素直に聞きましょう。早いうちに 「話したいけど分からなかった」と知ってもらうのが大切です。 「ごめん、この言葉が分からなかったよ」とか、「あなたが言ったのはこういうこと、だよね?」とか素直に言えると良いですね。 考えているときにまだ分かってなくて考えている感を出すだけでもOKです。

単語がわからないのか、コンテキストがわからないのか、スピードについていけないのかの区別を意識できると、相手にも聞きやすくなります。

3. "肝"は押さえておく

そもそも、 英会話を100%理解できることのほうが少ない と思っておくと楽です。 100%はわからなくても、肝になる部分は理解しておけば、会話は成立します。 たとえばこんな返答を考えてみましょう

  • なるほどね。君の手法も理解できるんだけど、そうだな。うん、僕の友だちにもこの前Discordでレクチャーしたんだけど、バターは入れないのが常識なんだよ。あ!このYouTubeチャンネルはオススメだよ。

この場合、肝になるのは「バターを入れない」ということです。 間の単語とかを理解していなくても、 "Won't"、 "Butter" さえ抑えられれば会話には十分です。 重要なのはどの位置に話の肝があるかを、聞きながら意識することです。

相手に分からなかった点を聞くにしても、何でもかんでも聞くのでなくて、会話の肝になる部分が理解できないときに教えてもらいましょう。 会話に直接関係ない部分について確認されても、相手は困ってしまいます

少なくとも「(意見が)ポジティブかネガティブか」や、「事実を教えようとしているのか、感想なのか、冗談なのか」などは判断しておきましょう。

会話の肝がどこかというのは、慣れの部分が大きいです。 教材やニュースなどでは無駄な言葉が少ないので、実際の英会話を重ねるのが一番の近道です。

ポイントとしては、 前置きや枕言葉的な部分を見極めることと、どのフレーズや単語が分かれば話全体に合点がいくかを判断すること です。 自分自身のスキル的な要素もありますし、相手の会話のクセを見抜けば分かる場合もあります。人によって話し方も色々ありますからね。

本当に100%分からないときは、100%分からないと伝えるしかないですが、その場合は会話が続く可能性は(僕の経験上)低いです。

4. 相手と良いコミュニケーションをしたいと知ってもらう

相手と良いコミュニケーションを取りたいという気持ちを伝えることを意識しましょう。

これはもう大前提なのですが、あなたがまともで、差別意識なく相手と良好なコミュニケーションを取りたいんだと知ってもらいましょう。 言語に関係なく 対話する労力をかけて良い相手と感じてもらえれば、多少会話の齟齬があっても乗り越えられます 。 ぶっちゃけ話したい相手となら、伝わりにくくても話してくれます。ことVRChatなどのゲームでは変な人でないと知ってもらうのが重要です。

当たり前のことですが態度の丁寧さであったり、身振りであったり、きちんと言うべきことを言える人柄だったりのことです。 言語にはまったく関係しない部分ですね。

会話をするというのは英語の試験をするわけではないですし、自分の実力をひけらかす場所でもありません。 まず相手と良いコミュニケーションをしたいという気持ちをもちつつ、それが相手にも伝わるとスタート地点に立てます。

5. 分からないときは分からない

エラそうに書いていますが、僕もサッパリなときはサッパリです。 先日もサッパリなタイミングがあって、軽く落ち込みました。

分からないときは仕方ないので諦めましょう。 スキルやレベルに関係なく、自分の体調や気分、相手のクセや気分によっても変わります。 そういう、決まった答えがないすごく曖昧なものに相対しているんだという諦めはもっておくと良いと思います。

申し訳なくなったり、自分に悔しくなって英語力を向上させたいと僕も常に思いますが、しょうがないです。 同時に、相手も「伝わんないな」と感じて話す気がなくなることもあります。それもしょうがないです。

北米版あずまんが大王のちよちゃんを観て僕と一緒に癒やされましょう。 結果が分からないからこそ、楽しめるものです。

6. ネイティブが絶対の正義と思わない

正しい英語とは何か、とまじめに固執してしまうと英語学習者としては辛くなってしまいがちです。

とくに、 ネイティブの英語こそが至高でありそれを理解できないのは恥だと感じないようにしましょう 。 正直、どの言語についてもネイティブのラフな会話が一番難しいとさえ言えます。話しやすいネイティブの人は相手に配慮できる素晴らしい人なのでしょう。

第二言語として英語を学んでいる人(ESL)同士のほうが話しやすい場合もあります。 東アジア圏の人やスペイン語圏の人の英語が聞き取りやすいときもありますし、ネイティブ至高病は早く脱出して、ESL同士の会話を楽しむのも素敵だと思います。

僕が思うに 正しい英語というのは、あなたと良好なコミュニケーションが取れる英語 です。

もちろん定義上、正しい英語というのはいくつか存在するでしょう。 でも会話という場面において正しさはあまり重要ではなく、むしろ正しさを気にせず話しているときのほうが不思議と相手にも気持ちよく伝わります。

まとめ

英語と英会話の処世術、ソフトスキルを6つ紹介しました。

  1. 自分の英語レベルをまず知ってもらう
  2. 分からない点は早めに聞くか確認する
  3. "肝"は押さえておく
  4. 相手と良いコミュニケーションをしたいと知ってもらう
  5. 分からないときは分からない
  6. ネイティブが絶対の正義と思わない

英会話に限らず、大事なのは相手と良好なコミュニケーションができるということです。 変に自分を脚色したりせず、正解を求めず、人として魅力的であることがコミュニケーションに大切なのかもしれませんね。

僕自身も自分でまとめていて良い振り返りになったと思います。ここまで読んでくれたあなたにとっての助けになると嬉しいです。 良ければブログの読者登録もお願いします。

この記事はShodo (https://shodo.ink) で執筆されました。

はてなブログを執筆・レビューしてから公開する - Shodoにはてなブログ配信機能を追加しました

Shodoからはてなブログへの配信機能をリリース

はてなブログでブログ記事を書いていくときに、こんなことはないでしょうか。

  • ブログのアイディアを書いておく場所がほしい
  • 文章の校正を自動で行いたい
  • 文章中の頻出する単語を列挙したい
  • チームメンバーと記事を相互にレビューしながら書きたい

今、私が開発中のShodoを使えば、その問題を解決できると思います。 Shodoからはてなブログへの連携機能をリリースしました ので、ぜひはてなブログユーザーの方はお試しください。 Shodoは現在クローズドベータ中ですが、 https://shodo.ink からご応募いただければすぐにご利用いただけます。

なぜShodoが必要だったのか

私も以前所属していた会社で、ブログをチームメンバーと複数人で執筆していました。 人にレビューしてもらったり、期限を管理したりしたいのですが、そのためにタスク管理ツールやレビュー用のドキュメントツールを用意する必要があり大変でした。

そのときに私がShodo(https://shodo.ink) というWebアプリを個人的に開発して、当時のチームで使ってもらったのがShodo誕生のきっかけです。 チームには好評いただいていたので、今、Shodoはスタートアップの小さな会社として運営されており、クローズドベータとしてお使いいただけています。

Shodoで執筆して、はてなブログへ連携できます

Shodoを使えば記事の執筆が便利になります。

記事を書くアイディアを書いておいたり、執筆期限の管理をしたりできます。 ブラウザー上のエディターだけで自動で文章の校正ができたり、複数人でワークフローに則った記事のレビューもできます。

はてなブログ以外のツールを増やすと面倒と思われるかもしれません。 ですが先日Shodoから、はてなブログに記事を作成できる機能をリリースしました。

これによって、Shodoで記事の管理、執筆、レビューなどが完了したタイミングで、 ボタン1つではてなブログに記事を作れます 。 この記事自身も、Shodoで執筆してはてなブログに配信されています。

はてなブログへの配信画面

Shodoからは下書きの記事をはてなブログに作成するので、突然記事が公開される心配はありません。 事前に必要な準備は、はてなブログの設定画面にあるURLとAPIキーを設定するだけです。 設定方法はShodoのヘルプページを参照してください。

複数人ではてなブログを利用している人に特にオススメ

とくに、ブログを複数人で運用していて、期限の管理や相互のレビューなどをしているチームにはオススメです。 Shodoには複数人で記事を書くときに必要な期限管理やチェックリスト、レビューのワークフローといった機能があります。 チーム内で共通化したい「表記ゆれ」を設定して、チェックさせることもできます。

もちろん個人の方にも

もちろん、個人でブログを書いている人にも使いやすくなるように作っています。 例えば文章の自動校正を使って記事を書いたり、文章の分析をして検索エンジンに最適化することもできます。 感覚的には、1人でプログラミングするときにもGitやGitHubを使いたい人にはオススメです。

まとめ

Shodoにはてなブログへの連携機能をリリースしました。 個人ではてなブログを利用されている方も、チーム内の複数人で執筆している方もぜひお使いください。 企業テックブログなどにもぜひ。

以下からクローズドベータ利用の応募をしてください。 ぜひ使ってみての感想、フィードバックや知人への紹介をしてくれると嬉しいです!

shodo.ink

この記事はShodo (https://shodo.ink) で執筆されました。

はてなブログAPIを利用する前に知っておきたいポイント・注意点

ここ最近はてなブログAPIを利用していて学んだことを共有します。 はてなブログのAPIを使って何かを開発したいなと思っている方は、以下のポイントに注意が必要です。

  • OAuthはOAuth1
  • APIはAtomPubというXML形式
  • OAuthで認証した「ブログメンバー」は、API経由でアクセスできない
  • API経由で記事を下書き保存してもプレビューURLが取れない

この記事では、OAuth時のブログメンバーの挙動について詳しく説明し、他に細かなポイントについて触れていきます。

ともあれAPIがあるのはありがたいです! ありがとうございます。はてなさん、ぜひアップデートしてくれると嬉しいです。

この記事は2020年10月3日に執筆しておりますので以降のアップデートについてはご確認ください。 できるだけ追記、編集していきたいと思いますが、期待せずにご自身でご確認いただければと思います。 また記事の内容は、はてなさんに問い合わせ・フィードバック済みです。

はてなブログAPIをブログメンバーは使えない

はてな認証を利用してOAuthで認証したアカウントが「ブログメンバー」の場合、対象のブログへの操作が行えません。 はてなブログには「ブログメンバー」という仕組みがあり、ブログを作った人以外にも記事を投稿、編集できる仕組みがあります。

この機能はとても良いですし、実際にはてなブログの画面から利用する際には問題ありません。 ですが公開されている、 はてなブログAtomPub APIを経由するとブログのオーナーしか記事の投稿、編集はできません。 直感的にはAPI経由でもメンバーの権限が考慮されるかと思いますが、はてなブログAtom Pubからはブログメンバーは一切操作できません。

この情報は、はてなブログAtomPub APIのドキュメントには記載されていないので、APIを利用しようかなと思っている人は覚えておくと良いかもしれません。

2020年10月3日時点で、はてなに問い合わせして確認済みです。

エラーレスポンスの仕様

細かい話ですが、ブログメンバーがAtomPub経由で記事を投稿すると、以下の内容でエラーレスポンスが返ります。

はてなブログ法人プランでも同様にブログメンバーはAPIを使えない

はてなブログの法人プラン、 はてなブログBusinessでもこの仕様は同様です。 はてなブログAtomPub API経由では、ブログメンバーはブログに投稿、編集はできません。

2020年10月3日時点で動作確認済みです。

はてなブログAPIを複数人で利用する方法

方法としてはOAuthを使わないのが良いでしょう。 時代に逆行したようなアドバイスになり悲しいですが、現状はOAuthを使わずにAPIキーを使うのが良いです。

はてなブログAtomPub APIAPIキーというのを使った認証も可能です。 これはブログオーナーの名前とAPIキーを利用してBasic認証し、記事の投稿、編集をするものです。

その際はブログオーナーを個人のアカウントでなく、組織用アカウントとして別途用意すると良いでしょう。 APIキーを利用すると個人の他のブログにも投稿できたり、ブログメンバーのようなロール管理もできません。 個人のアカウントで複数ブログを用意し、特定のブログにのみブログメンバーを招待している場合はアカウントを整理したほうが良いでしょう。

実際に、はてなブログBusinessを契約する際は、個人に紐付かない共有できるアカウントをオーナーアカウントにすることが推奨されます。 はてなブログ的には、複数人で組織的に運用する場合はこの方法が良いということでしょうか。

はてなブログBusinessの契約画面

API経由で下書き記事を作成してもプレビューURLが取れない

はてなブログAtomPub APIは下書きも作成できて便利ですが、残念ながらプレビューURLは取得できません。

はてなブログAtomPub経由で記事を作成した場合も記事のURLは取得できるので、はてなの編集画面へのリンクは作成できます。

他の細かなポイント

はてなブログAPIがあることは非常に助かるのですが、今現在となると少し不便な点もあります

  • OAuthといってもOAuth1(OAuth2ではない)
  • APIがAtomPub形式なのでXML対応が必要(JSON APIではない)
  • OAuthではてなID認証したときのスコープが大きい

とくにスコープについては、はてな内のサービス単位でスコープができると嬉しいです。 公開・非公開情報を、読み・書きできるか、という4種類しかないので、はてなブログにのみ権限が必要でもはてなブックマークの権限も手に入れてしまいます。

あまり利用者もいないのかなぁと思いますが、少し昔の牧歌的なAPIという印象です。

まとめ

今回のポイントは以下でした。

  • はてなブログのAtomPub APIはブログメンバーがOAuthで認証しても使えない
  • ブログの下書きプレビューURLはAPI経由で取得できない
  • はてなブログAPIは全体的に少し昔っぽい

はてなブログに投稿できるのはとても助かりますので、はてなさん、ぜひアップデートしてくれると嬉しいです。 そもそもAPI自体がないサービスもありますので、あるだけで嬉しいのは間違いありません。

この記事はShodo (https://shodo.ink) で執筆されました。

ポッドキャストに出演して起業やプロダクト開発、Webフロントエンドについて語りました

@terapyon さんが運営するポッドキャストterapyon channel にゲスト出演しました。 ポッドキャストではこの8月にした起業についてや、今まさに開発しているShodoなどについて話しました。

ポッドキャストはこちら

以下からブラウザーで再生できます

terapyon channelのサイトはこちら

もしくは、お気に入りの配信サービスがあればそちらでも聞けます。 私個人的にはSpotifyを普段使っているので、Spotifyでterapyon channelをフォローして聴いています。

ここだけ聴いて!つまみ食いポイント

全部を聴く気はないなぁという人は、以下の再生時間でトピックが変わります。 気になるとこだけでもぜひ聴いてみてください! (再生するソフトなどによって時間がずれることはあるので調整してください)

  • あいさつと自己紹介: 0:00~
  • hirokiky的terapyon channelのオススメポイント: 3:09~
  • 起業と会社運営、ニューノーマル時代の社長の悩み: 9:28~
  • Shodoの話やオススメの使い方、最近リリースした機能: 18:10~
  • Shodoの技術スタック: 39:05~
  • Vue.jsについてと合宿: 51:40~
  • 今、興味があることや技術(清原): 74:50~
  • 今、興味があることや技術(寺田): 80:20~
  • まとめとおわり、最後にメッセージ: 86:28~

話した内容

起業やプロダクト開発について話しつつ、Vue.jsやステイホーム時代の社長の悩みなどについても話しました。 普段、ブログでは書けていない深い話などもできたかなと思いますので、このブログをたまに読んでいる人はぜひ聴いてみてください。

内容も技術だけでなく、会社の起業やShodoの話でしたので、Pythonや技術に詳しくないという方も聴いてみてください。

ポッドキャストなので、何か作業しながらや、一息休憩したいときや家事の合間に聞き流すのもオススメです。

ポッドキャストの前に、寺田さんや合宿について

このポッドキャストは寺田さん (@terapyon)によって運営されています。 あまり寺田さんのことを知らない方のためにお伝えすると、寺田さんはプログラミングに関するイベントでよく会い、お世話になっている方です。 Python mini hack-a-thonPyCon JP を主催する1人です。

トークの中でも「合宿」というワードがでてきますが、これは「Python mini hack-a-thon夏山/冬山合宿」のことです。 2泊3日などでプログラミング言語Pythonについて勉強したり、開発したりするイベントです。

収録について

今回の収録はオンラインで行ったんですが、録音もキレイに撮れて良かったなと思っています (ノイズキャンセリングや音量バランスとかは寺田さんが調整してくれて、聞きやすくなっていると思います)。 このポッドキャストの収録では原稿無しでぶっつけ本番なんですが、話の盛り上がりや聞きやすさも良い感じで良かったです。

ただ改めて聴き返してみると、私の話を入れるタイミングが早すぎるなと反省しました。 次にラジオに出ることがあれば、休符を入れることを心がけようと思います(オンラインのときは特に)。

おわりに

ポッドキャストへの出演は楽しいですし、自分の考えの整理にもなって良いですね。 とくに会社や起業については相談できる先輩も少ないので、こういうつながりは大切にしていきたいです。

かなり良い収録になったと思いますので、ぜひ仕事や家事の合間、ドライブのラジオ用としてでも聴いてもらえると嬉しいです。

https://podcast.terapyon.net/episodes/0039.html

Spotifyを契約している人はぜひterapyon channelをフォローしてください

https://open.spotify.com/episode/1s6uIFjRhEisiZESAeHXBl

Shodoに外部の人と協力して執筆・レビューする機能や、ロール・権限を細かく管理する機能をリリースしました

f:id:hirokiky:20200907124411j:plain
Shodoは外部の人とコラボレーションができます

何か本や連載を書くときに、 レビュアーさんを招待して原稿を読んでもらうのって大変 ですよね。 インタビュー記事を書いたときに、 インタビューに応じてくれた人に原稿を確認してもらうのも大変 です。 自分のブログ記事を誰かに事前にレビューして欲しい と思っても、なかなか簡単にはできないものです。

Slackに招待、Wikiを共有、DropboxPaperにコメントを書いて、TrelloやAsanaでタスク管理、期限はSpreadSheetで管理、と、執筆者が受け持つには手間が多きすぎます。 私自身も本の執筆やインタビュー記事の執筆に関わったことがありますが、 執筆の管理をする人の手間が圧倒的に多い のが事実です。 些細なことではありますが、すべてを管理するのはとても大変です。

その 執筆の管理の手間を省いて、執筆や推敲、レビューに費やせればすごいと思いませんか?

Shodoにロール管理、外部コラボレーション機能をリリースしました

Shodoを使えば1つのプラットフォーム上で執筆、レビューに関するすべての作業がまかなえます。 今回リリースしたロール管理や、外部コラボレーションの機能を使えば、以下のようなコラボレーションが可能です。

  • 友だちに記事のレビューだけしてほしい
  • 社外のライターさんにライティングを手伝ってほしいが、特定のプロジェクトのみ見せたい
  • 社内のメンバーが気軽にレビューや執筆を手伝える仕組みを作りたい

Shodoでどのようにロールやアクセス権を管理できるかを説明します。

Shodoではロールとアクセス権の細かい管理ができます

Shodoで仕事の単位として「プロジェクト」を作成して、そこで記事や執筆を管理します(たとえば「Shodoのブログ」や「Shodoのヘルプページ」といった仕事の単位)。 プロジェクトごとに以下のアクセス権を設定できます。

f:id:hirokiky:20200903162819j:plain
プロジェクトごとのアクセス権限

「レビューは依頼したいけど、記事の執筆はしてほしくない」場合などはレビュアーとして招待できます。 レビュアーは記事の変更や、「他人のレビューコメントの解決」などができないようになっていますので、外部の方を招待しても安心です。

さらにShodoは組織単位でのロールを設定できます。 組織とは「株式会社〇〇」のような単位で、執筆プロジェクトやアカウントも組織に所属しています。 組織のメンバーのロールを設定することで、プロジェクトへのアクセス権限も一括で管理できます。

f:id:hirokiky:20200903155401j:plain
組織のメンバーのロール

外部のライターさんやレビュアーさんは「コラボレーター」として組織に招待できます。 各プロジェクトごとにアクセス権限を設定しないと何もできないので、社内の関係ないプロジェクトに記事を読まれる心配はありません。

細かな仕様や利用ケースについてはShodoのヘルプページをご覧ください。

Shodoをすでにお使いの方は 組織・プロジェクト設定 から設定したい組織を選び、サイドバーの「メンバー」設定と、プロジェクトごとの「アクセス設定」から設定できます。 組織に招待する人はGmailアカウントが必要になりますのでご注意ください。

f:id:hirokiky:20200911105933p:plain
Shodoのメンバー管理画面

f:id:hirokiky:20200911110002p:plain
Shodoのアクセス設定画面

GitHubやDropboxPaperとは違うの?

GitHubを使えば細かい権限の制御も、レビューのフローも使えます。それで十分な気もします。

たしかにGitに慣れている人であれば良いかもしれませんが、インタビューに応じてくれた人やライターの人にGitHubを使ってレビューや執筆をしてほしいというのは難しいでしょう。 また執筆の環境も、ライター個人の裁量に依存してしまうので、校正ルールの統一などは別途設定する必要があります。

ですがShodoであればブラウザーだけでGmailアカウントがあるば誰でもすぐに利用できますし、執筆する環境や校正のルールも統一できます。

DropboxPaperも非常に便利ですが、レビューという点でコメントしかできないのが難点です。 Shodoであれば記事のバージョン管理、バージョンごとのレビューコメント管理、タスクやワークフローの管理がShodoだけで簡単にできます。

もちろんGitHubを使うほうが便利な場合や、DropboxPaper・Asana・GoogleSpreadSheetを組み合わせたほうがやりやすい場合もあるかもしれません。 ですがShodoは執筆のために作られている点は大きく違い、執筆のためのタスク管理やレビュー、Slack連携、AI校正といった機能が豊富です。

今であればShodoはクローズドベータとして無料で利用できますので、一度試していただくのが良いかもしれません。

まとめ

Shodoにロール管理、外部ライター・外部レビュアーとのコラボレーションの機能をリリースしました。 今まで外部の方にレビューを依頼したりするのは大変だったと思います。それら執筆に関わる問題や苦労が解決され、より生産的で楽しい仕事に注力できる手伝いができれば嬉しいです。

気になる方はぜひ以下のShodoのページにアクセスしてください。

shodo.ink

ビープラウドを退職して、起業しました

退色した看板(大洗にて)
退色

株式会社ビープラウドを退職しました。

こんにちは、 id:hirokikyです。 8年間勤めたビープラウドでしたが、先日限りで退職しました。 僕の中に大きなやりたいことがあり、それに挑戦したいという理由から退職しました。

「お前誰だよ、知らねーよ」という読者の方はブコメに好きな寿司のネタでも書いといてください。僕はエンガワです。

20歳から30歳が大事

僕は、人間の人生には重要な年齢というのが決まっていると考えています。 とくに20歳から30歳までは重要で、向こう30年の生き方を決定すると思っています。 そして20歳から28歳までのこの8年を、ビープラウドとPythonコミュニティの中で過ごせて本当に良かったと思っています。

その中でも、4人のメンバーで立ち上げから作ってきたWebサービスPyQと、 某大手経済新聞社さんにPython・Web技術のコンサルティングをさせていただいたことは大きな成長の機会になりました。 他にもたくさんの機会があり、Web技術のフロント・バックエンド・インフラは当たり前にして、デザイン、お客様含めたチームビルディング、製品企画、マーケティングまで学べました。

思い返せば色々ありました。一人ひとりお礼を言いたい気持ちですが、それはまた会ったときにしましょう。 個人的には退職ではなく、「ビープラウド卒業」か、「放牧宣言」くらいに考えています。

ビープラウドってどうなの

退職記事というとやはり「ビープラウドって実際どうなの?」ということが気になるかと思いますが、僕にとっては最高の"庭"であったなと思います。 なぜなら、ビープラウドは成長していきたい人、創造性を発揮できる人、自分から周りに働きかけて吸収できる人、タフな人、そういう人たちにとっては最高の職場だからです。

そのための柔軟な会社制度やカイゼンの仕組み、フラットな社風やすごい同僚に加えて、たくさんのチャレンジングな仕事があります。 逆に言えば、積極的に技術やスキルの取得を楽しめない人や、自分から動けず指示されたい人にはあんまり向いていないかもしれません (まぁそもそも、そんな人とは僕個人としては一緒に働きたくありませんが)。

もしあなたがスキル面に自信がなくても、「自分でこんなものを作ったことがあるぞ」、「こう成長していきたいぞ」というやる気や目標があればビープラウドの一員になってくれると僕も嬉しいです。とくに僕というKYかつ自分の理想を押し付けがちな人が1人いなくなってしまったので、ちょっと変わった人が入っても良いかもしれません。

大変なことや辛いことももちろんありましたが、僕にとっては日々楽しく、成長できて、これ以上のない職場でした。

起業しました

株式会社ビープラウドを退職したのは、自分の新しい会社を作るためです。 新しい会社では Shodo という記事の執筆とコラボレーションを支援するWebサービスの開発に注力します。 僕が代表取締役として作った会社なので、これからは社長として頑張っていきたいと思います。

Shodoは今までは「あくまでも個人」として運営してきたサービスですが、これからは法人としてしっかり良いものを作っていきたいです (事業譲渡などはしていないのでご安心ください。僕個人が会社化したというだけの話です)。

これからより一層大変な日々が待っていると思いますが、すごい製品・サービスを作って、関わる人達の人生を変えるものになれればと思っています。 ぜひ応援してくれると嬉しいです。もしこれを読んでいる社長の人がいたら、これから色々と教えてくれるとさらに嬉しいです。そして飲みましょう。

これからはブログ更新の頻度を増やして、学んだことや感じたこと、会社についてや製品について積極的に発信していこうと思っています。

ですのでぜひ、このブログの購読か、 Twitterのフォローをお待ちしています

最後に

僕はビープラウドを離れますが、これからもビープラウドのメンバーです。 そして新しい会社の社長として、さらに前に進んでいければと思っています。

関連記事

blog.hirokiky.org