みなさまは何が目的で仕事をされていますか？理想のため？将来の野望のため？家族のため？ 私は収入のため。つまり、シンプルに突き詰めると・・・お金のため。家族を守ることも、理想を実現することも、将来の野望を抱くことも、収入があってのことです。

それは個人も法人も変わりません。企業は営利団体であり、事業の収益を拡大すべく常に努力をしています。そこで働くひとたちも営利が目的です。同じ目的を持った者同士が相互に利益を得るために協力しあい、ともに闘います。だからこそ、ともに働く仲間を互いに信用できるのです。

しかし・・・実際のところ、社内外を問わず相互の協力関係がなかなかうまくいかない、協調できない、長く続かないという悩みをお持ちの方も多いのではありませんか？

我々は同じく業績や収益、そして成功を目指しているにもかかわらず、なぜともに闘いにくい状況が生まれるのでしょうか。

協力相手は、お互いの役割を同じように認識しているか？

協力を得たい相手や組織と自分。それぞれの目的は一致しているのに上手く共闘できない状況を想定して整理すると、以下のような原因が考えられます。

1. 施策プロセスの不一致
2. 「得られるもの」の認識と理解
3. 意思決定の主導権争い
4. 役割認識の不一致

それぞれどういった状況なのかを想定し、解決のポイントを考えてみましょう。

1.施策プロセスの不一致

【状況】

協力してほしい相手が、他者や他部門の提案した施策によって「結果的に得るもの」は認めていても、そこに至る手法や運用のプロセス選定に異を唱えている。

この状況は、少なくとも協力相手が起案者の施策を受け止め、その内容を吟味し、その手法や運用に別の考えを持っているという点で、比較的健全な状態ともいえます。
最初から受け付けない状態ではなく、プロセスへの異論ですから、少なくとも施策の目的と結果については意見が一致しています。

【解決のポイント】

認識が共通しているはずの「結果的に得るもの」を明確に定義し、施策目標を明文化すること。

そして異論が発生した箇所をアジェンダとして可視化し、列挙します。アジェンダごとに相互のメリット・デメリットを丁寧に議論し、不一致を解消していくことで、共闘体制が生まれます。
その議論の中で意見の対立があった場合、必ず定義された施策目標に立ち返るようにしましょう。双方の意見のどちらが目標達成へ貢献するのか、あるいは成果獲得に近いかを基準に議論すれば、解決に導くことができます。

それでもなお意見が分かれる場合は、施策目標に対して双方の解釈のズレが発生している場合があります。

2.「得られるもの」の認識と理解

【状況】

協力してほしい相手が、他者や他部門に協力することで事業の収益が得られる可能性は理解しているが、協力してほしい相手自身に評価または利益がもたらせるとは限らないと認識している。

これは所謂「セクショナリズム」を象徴するような状況です。同じ事業収益を目指しているにもかかわらず、その施策は「起案者やその部門だけが評価や利益を得るのではないか」「協力しても我々には利益がないのではないか」という考え方です。

本来、こういった個人や組織は事業貢献への姿勢が見えにくく、目標設計と結果の評価の不明瞭さが経営判断上でも指摘を受け、是正され浄化されていくものです。
しかし、協力してほしい個人や組織が専門的知識や技術を持つ「高度な属人化」（例えばエンジニア、ベテラン商品仕入れ担当、敏腕営業マンなど）の状態や、複雑な構造でブラックボックス化した管理部門などの場合、仕事の仕組み化や運用の実態に他者の指摘が入ることが少なくなります。そして最終的な成果が伴っていると「事業の重責を担っていると自認し他者に口出しをされない」ことが常態化します。

【解決のポイント】

誰が施策の成否を握る鍵であるのか、貢献者の明文化です。
「起案者の提案に協力してほしい」という起案ではなく、「（協力してほしい）○○さんが基軸となる施策や戦略」といった起案をすることがポイントです。彼らはすでに事業への貢献意識が強いため、その意識を尊重しつつ新たな事業貢献の中心となるチャンスを作るといった演出です。わかりやすく言うと「大人の対応」ということです。

この場合、相手の特権意識を増長させる結果にもつながるため、あくまでも事業の意思決定を理解し、高度な技術を持つ人やその組織に対象を限定すべきでしょう。高度な技術力を発揮していない人格や組織が自己利益の意識を優先する場合、そもそも職場から淘汰されてしかるべき人格です。

3.意思決定の主導権争い

【状況】

協力してほしい相手が、他者や他部門から提案された役割を全うすることで、意思決定権の主導権を奪われると考えている。

【解決のポイント】

これは（2）の後段で解説した内容に近いですが、主導権の剥奪と感じる個人的な感情によるものです。同じく「○○さんが基軸となる施策や戦略ですよ」という大人の対応が一番効果的です。が、この状況では普段から協力の依頼者をライバル視、あるいは敵視している場合が考えられます。ゆえに今後も依頼者の障害となり続ける可能性が高くなります。

であれば、いっそ共通の利益を得るための共犯関係に持ち込んでみるのも良いでしょう。コミュニケーションを面倒がらずに、評価の山分けをする相手として説得し、かつ相手を旗手として施策を提案することでプライドを尊重します。精神的にも負担の大きな役回りですが、今後の障害を回避して施策を推進しやすい空間を維持するという点では、効率的で健全な方法です。
（2）と同じく、この対応も高度な技術や判断能力を持つ相手に限られます。そうでない場合は、そもそも共闘を持ちかけても、依頼者側の負担だけが高まってしまいます。

4.役割認識の不一致

【状況】

協力してほしい相手が、他者や他部門から提案された役割を「本来は我々が担うべきことではない」と認識している。または工数を確保するべきではないと認識している。

容易に想像できる「協力したくない理由」としては、単に仕事量が増える、工程が増えるという物理的な状況への不満と考えられます。自分の考えたこと以外は余計な仕事であるというケースは、先述の（1）～（3）で述べています。
しかし、企画や施策に重要な役割を果たすような影響力を持つ人格や組織には、自ら積極的に仕事を作り出す行動を会社からも期待されているはずです。

こういった「縦割り行政」といえる状況は、高度に業務運用が確立された分野、たとえば広告管理やシステム対応、商品管理など、事前に定められたワークフローなどを担う組織に発生しがちです。

運用が基本フレームの反復（フレームへの依存）であるがゆえに、担当者が思考する時間あるいは機会が減少する危険性を常に孕んでいます。
そのため、担当者は「いま（自分たちが）何をすべきか？何が求められているか？」を考える機会が作れない、あるいは奪われてしまっている場合があります。つまり、「それは運用やルールにないから協力しない」という思想の根源は、その組織なり人格なりが事業を主語として「すべきこと」を判断し決断することを求められていない環境に起因しています。

【解決のポイント】

解決のポイントは将来のあるべき姿を意識させることです。
運用を担う、特に複雑な運用を担っている人や組織の場合、業務の判断がしやすい高度な運用フレームであることを、自分たちが高度な判断ができていることとして混同しがちです。

その人格が、もし違う役割を与えられた場合、あるいは管理職を任された場合、どのような判断と決断ができうるのか？その時に真価が問われます。
キャリアを考えた場合、他者と共闘する機会で運用フレームへの思考依存を脱却し、意思を持って判断できる能力（今後も活躍の幅を広げられる能力）を養うべきだと、相手自身に認識してもらえる語らいの場を積極的に作りましょう。

もちろん、協力すべきか否かを判断する提案の内容が、必要性や成果獲得において妥当かつ正しい判断である説得力を持つことが大前提です。さらに、意思を持つことを認識させる作業は経験がないと難しく、相手の考えを引き出すファシリテーションのテクニックが必要です。

相手の考えやあり方を自身で認識させるコツとしては、自社のマーケティングの問題点と課題点を「技術論禁止で」「事実（現象）や数字に則り」「あるべき状態とともに」相手に問うことです。

市場や企業、事業の視点で的確な内容を答えてもらえた場合は、その内容を討論し、共通する課題を推進するメリットを相手の今後の評価とともに確認します。
もし的確な内容が答えてもらえなかった場合、おそらく運用上の技術課題を中心とした回答や発言であると推測できます。その考えのまま仕事を進めていくと、自身の評価やキャリアがどうなると考えているのかを問い、認識を促してみましょう。

技術は時とともに変化し、やがて次世代技術への対応が難しくなっていきます。しかし、自分なりに思考して判断し決断することができる能力は、職種が変わっても時代が変わっても対応できる普遍的な能力であると、認識を促すのです。

そして、この解決方法は協力の依頼者に大きな副産物をもたらします。他者に能力を養う機会を作る「巻き込む力」を発揮できれば、あなたは経営層から組織を任せるべき人材としてみなされ、管理職へと近づいていくことになります。

不安要素の解消

いずれも共通している点は、協力してほしい相手が「不安を抱いている」と考えられます。施策プロセスへの不安、評価への不安、主導権を取られることへの不安、そして自身の理解にない役割を押し付けられるという不安。
協力要請の起案者が協力してほしい相手の行動を得るためには、相手が不安に感じている点を適確に捉え、「サポートしますよ」「支援しますよ」「役割分担しますよ」というメッセージを発信する必要があります。そのためには、協力してほしい相手の業務的な状況や心理的な側面を常に観察し把握しているべきです。

「めんどくさい」と思われますか？いやいや、もしあなたが企業や組織の幹部としてキャリアを積みたいと思っているならば、これらは「他者を巻き込む力」として必ず求められる能力です。少なくとも、経営層からの評価を獲得することになり、組織に影響力を持つ人材としてのニーズを獲得します。

情報の開示と解像度

協力してほしい相手の不安解消には、情報の流通にも気を配りましょう。人は常に「知りえないことへの不安」「情報が隔絶されていることへの不安」を抱いています。情報の流通はリスクもつきまとうものであると同時に、適度に開示して流通させないと組織内の心理的不安が蓄積され、人事的側面でも組織のパフォーマンスに大きく影響します。

協力を依頼するにあたっては、依頼者が持ち得ている開示可能な情報をすべて開示し、かつ細かい点も伝えて情報の解像度を高めます。情報を持っている側からすると「そこまでは必要ないな」と感じていても、それは情報の持ち手の主観的な判断です。その細かい情報が必要かどうかは、協力してほしい相手が判断することです。一旦は全て伝えましょう。
情報の開示はコミュニケーションに大きく寄与し、相互の理解と共感が促進されます。

協力を得るための考え方は部下に対しても同じ

これらの協力を得るための考え方は、自組織の仲間、そして部下や後輩に対しても同様です。上司あるいは先輩であるあなたの指示を、なぜ遂行しないのか？指示を出し指導する相手の心理的側面の対応、指示を遂行する評価や利益をイメージさせ、不安な点を解消することで解決できます。

また、指導を行う部下や後輩と常に定例ミーティングを行い、相手の希望や不安を常時把握すると同時に、こちら（指導者や組織）の相手に対する「期待値」を明確にして相互に理解している状態を作りましょう。応えるべき期待値が明確になればなるほど、指導相手が評価の獲得とその積み重ねで得るキャリアをイメージしやすくなります。

そして適切なフィードバックも必要です。部門間での協力要請の場合は、相手の直接的な行動評価者ではありませんから、フィードバックは協力結果に対する成果状況が主になります。
ですが成果に至る行動も評価する指導相手に対しては、成果状況のフィードバックだけで終わると相手の成長が促されません。

指導相手に「なぜそのような結果になったのか？」「その結果をどう解釈しているのか？」要因や次回への反省点を自分で発見をするような問いかけが必要です。指導者の問いかけがあってはじめて考える、そして自分が行うべきことが自分自身の考えで発見できます。

組織の内外を問わず相手の意思や意図を理解する

組織の内外を問わず、人の意志は100人100様、人それぞれに動くための意思や基準が異なります。同じ目的を持っていながら共闘できない相手の行動原理もまたさまざまです。
相手の目的や狙いを理解し共闘すべく、組織の外でも中でも相手を理解する時間を丁寧に作っていきましょう。ご自身のキャリアのためにも、組織への影響力を発揮する良い機会となるはずです。

カナダのバンクーバーに、日本で人一倍、名の知れ渡ったWebデザイナーがいます。その人の名は、「セナ」さん。Web業界で古くから存在感を示されていた「バンクーバーのうぇぶ屋」というサイトを運営している方です。現在、デザイナーやエンジニア、映像分野の留学をバンクーバーからトータルサポートする「Frog」という法人を立ち上げ、日本とカナダを行き来されています。貴重なお時間をいただき、「海外と日本のWeb事情」 について、インタビューさせていただきました。（以下敬称略）

※インタビューは2017年5月現在のものです

カナダのバンクーバーに、日本で人一倍、名の知れ渡ったWebデザイナーがいます。その人の名は、「セナ」さん。Web業界で古くから存在感を示されていた「バンクーバーのうぇぶ屋」というサイトを運営している方です。現在、デザイナーやエンジニア、映像分野の留学をバンクーバーからトータルサポートする「Frog」という法人を立ち上げ、日本とカナダを行き来されています。貴重なお時間をいただき、「海外と日本のWeb事情」 について、インタビューさせていただきました。（以下敬称略）

※インタビューは2017年5月現在のものです

画像：pixabay

GoogleなどのdeveloperサイトのQ&Aでも使われており、エンジニアの方は見たことがあるかもしれないQ&AツールStack Overflowから新しく、「Stack Overflow for Teams」の提供が開始されました。

「Stack Overflow for Teams」は1ユーザあたり月10ドルから利用可能であり、チーム専用のプライベートなQ&Aサイトを構築できます。
フリーワードで検索を行うと、まず「Stack Overflow for Teams」内で検索を行い、そこで見つからない場合には通常のStack Overflowの検索結果も表示されるそうです。

サイト制作やアプリ開発のときなど、チーム内でのQAおよびコミュニケーションツールとしても活用できそうですね。

チーム専用のプライベートなQ＆Aサイトが作れる「Stack Overflow for Teams」提供開始。月額10ドルから － Publickey

カナダのバンクーバーに、日本で人一倍、名の知れ渡ったWebデザイナーがいます。その人の名は、「セナ」さん。Web業界で古くから存在感を示されていた「バンクーバーのうぇぶ屋」というサイトを運営している方です。現在、デザイナーやエンジニア、映像分野の留学をバンクーバーからトータルサポートする「Frog」という法人を立ち上げ、日本とカナダを行き来されています。貴重なお時間をいただき、「海外と日本のWeb事情」 について、インタビューさせていただきました。（以下敬称略）

※インタビューは2017年5月現在のものです

カナダのバンクーバーに、日本で人一倍、名の知れ渡ったWebデザイナーがいます。その人の名は、「セナ」さん。Web業界で古くから存在感を示されていた「バンクーバーのうぇぶ屋」というサイトを運営している方です。現在、デザイナーやエンジニア、映像分野の留学をバンクーバーからトータルサポートする「Frog」という法人を立ち上げ、日本とカナダを行き来されています。貴重なお時間をいただき、「海外と日本のWeb事情」 について、インタビューさせていただきました。（以下敬称略）

※インタビューは2017年5月現在のものです

カナダのバンクーバーに、日本で人一倍、名の知れ渡ったWebデザイナーがいます。その人の名は、「セナ」さん。Web業界で古くから存在感を示されていた「バンクーバーのうぇぶ屋」というサイトを運営している方です。現在、デザイナーやエンジニア、映像分野の留学をバンクーバーからトータルサポートする「Frog」という法人を立ち上げ、日本とカナダを行き来されています。貴重なお時間をいただき、「海外と日本のWeb事情」 について、インタビューさせていただきました。（以下敬称略）

※インタビューは2017年5月現在のものです

【セナ プロフィール】バンクーバーのうぇぶ屋の中の人。カナダのバンクーバーに渡り10年目。日本で最も多くのクリエイティブ／IT系海外就職者をサポートしている『Frog』の代表。
◆Twitter twitter.com/onepercentdsgn
日々のWeb制作情報は@WebyaInVanから。
日系クリエイターの海外活動サポート企業Frogの情報発信は@frogagentから。
◆バンクーバーのうぇぶ屋
◆クリエイター留学サポート『Frog』

目次

• 日本と海外でのWeb制作会社の捉え方
  • 日本と北米圏における『Web制作会社』の認識の違い
  • 日本では考えられないような圧倒的スピード感
• 「オープンソースの脆弱性対策」、「役職の在り方」
  • 北米と日本とのCMS利用の違い
  • プロジェクトマネージャとWebディレクター、どう違う？
• 「北米圏での流行」、「エンジニアのキャリア」
  • 北米圏で現在、流行っているもの
  • エンジニアは日本を飛び出すべきか？
• エンジニア・サイド、マーケティング・サイドの話
  • 海外でのマーケターとは？
  • 日本、海外でのマーケターの学習環境の違い
• 今後のWeb業界予測や今ホットになっている学習
  • 最近の現地での勉強会のテーマって？
  • 今後を予想する
  • 実務から考えたマーケターの役割
  • 日本と海外の人材育成の違い

日本と北米圏における『Web制作会社』の認識の違い

お久しぶりです！本日はどうぞよろしくお願いします。Web業界に関する海外のトレンドや情報の取得方法を、セナさんならではの観点で伺えればと思います。

セナ：そうですね〜！よろしくお願い致します！

では早速、「日本と海外でのWeb制作会社の捉え方」について、伺います。 セナさんは、カナダ・バンクーバーで日々行っているWeb制作や多人種国家な環境を生かした情報収集をもとに、「バンクーバーのうぇぶ屋」というブログを発信されています。 日本のWeb制作会社のようなことをされているのかと思いきや、デザインやコーディングだけでなく、プログラミングや教育、カナダへの就職斡旋事業の事業構想まで、当時から幅広く関わられていますよね。制作会社の海外の立ち位置について、聞かせてください。

セナ： まず、そうですね…僕は、「海外には、Web制作会社という概念がない」と思っています。きっかけは、ビートラックスさんというシリコンバレーにある制作エージェンシーの方が書いたブログですね。
ここの会社にいるBrandon K. Hillさんが、おそらく一番最初に、「日本でいう制作会社の枠は、北米圏にはないよ」という話を言い出した人かと思います。

◆ビートラックス

そのときの記事を見るまで、僕のイメージでは、『デザインエージェンシー』と呼ばれるデザインをメインにした制作を提供する人達のことを、日本でいうところの『Web制作会社』と捉えていました。

でも、日本の制作会社のように、制作だけを請け負うとかって会社が海外にはないですね。大きい会社さんであれば『Web担当部署』が必ずあって、そこが担います。もし、海外で制作会社を名乗るとすれば、デザイン全般でクオリティーを高度に維持して提供できる会社か、Webも含めたうえでのマーケティング戦略が立てられる、いわゆるマーケティング会社が、それにあたるでしょうね。Webだけではなく、包括的に見ることのできる会社です。

バンクーバーだけでいうと、「デザインの制作会社」なら、まだWebに比べたら、いくつかあるかと思います。たとえば、ディーラー専用の制作会社だったりとか、法律関連だけだったりとか。業態に特化された会社のイメージになります。だいたい業界に合わせて、自社でCMSを持っているんですよ。Webはツールであるだけです。

ただそれでもやはり数は相当少ないです。日本で言う純粋な制作会社というのはないに等しい、という感じです。

なるほど。日本と北米圏とでは、かなり制作会社自体の在り方が違うのですね。

日本では考えられないような圧倒的スピード感

北米の印象ですが、日本の技術よりも3年くらい先にあちらで流行って、それが日本にも流れてくる、というイメージを持っています。バンクーバーで今流行っているものがあれば、今後の日本でどんな流行り方をするのか、予測できることもあると思います。これから流行るであろうものとか、逆に廃れちゃったものとか、北米のWeb事情を伺いたいです。

セナ：　僕の勝手な感覚値も含んでしまうと思うので、「これが正しい」とは言いたくないですが、おそらく日本が３年遅れて北米が３年進んでいるというのは、正直、技術的な部分じゃないと思っています。

技術力だったら、数の差はあれど、日本人のエンジニアにもとてつもなく高い方が数多くいます。 最近のスタートアップさんは、というと、技術力では全く見劣りしない会社も多いので、僕はそこにあまり差を感じてはいません。Webに限定して言えば、です。

最前線の話で、例えば「人工知能」とか「ディープラーニング」とかの分野だとちょっと話は別ですけどね。トロントとかに比べると、やっぱり日本の人工知能に関する技術は3歩〜4歩遅れているのは否めない、という話は良く耳にします。

それと、圧倒的に遅れていることもあります。『意思決定』の部分ですね。
北米圏…バンクーバーもそうですが、やはり意思決定するまでに「階層が少ない」ことで、決定権をもつ人にまで届くスピードが早いです。日本では あまり考えられないかもしれません。

例えば、データベース周りとかバックエンドの部分に関しては、BaaS（バース）のシステムを使えば、ネット上でやり取りが完結できたりするので 僕もよく使っています。
その間フロントに集中してサービス開発だけパパッとやって、とりあえず形にしてしまう所もあります。
それをベースにして資金調達を行い、「それじゃあ、次のステップへいこう！」となることが、サービス開発面だったら多いですしね。もちろんバックエンドの需要も非常に高いのですが「とりあえず今あるリソースで形にしちまえ！」というイメージで動く会社もあるということです。

逆に、日本の場合は、最初から完璧に作ろうとする主義が結構多い気がします。やはり、自社で開発した物以外は躊躇してしまって、第三者が提供したものをパパッと容易に使えない。総じて、スピードが遅いイメージです。

確かに、そういう考え方は少ないですね。

セナ：　サービス開発する時に関しても、まずは形にしてしまってからという話、ガンガン聞きますよ。すでにあるものは全部有効活用するっていう意思決定の速さは、北米圏の方が断然早いですね。

必要となるものが ほとんど揃っているのに、日本では選ばずにいるという。

セナ：　そうですね、間違いなく。だからぶっちゃけてしまえば、最近はバックエンドは、必要ないんじゃないか、という人も、たまにいるんですよ。

バックエンドの部分って、BaaSで結局なんとかなってしまうし、サーバー構築さえきちんと行える人がいれば、データベースをオンにして後から結合すれば良いんです。最初のタイミングはバックエンドなしで、もうフロントエンドだけで完結させてしまえ！という動きもあるくらい。

やはり、技術者一人が賄えるスピードも、作れる範囲も、その採用する技術やサービスを選ぶ意思決定も、スピードの差をすごく感じますよね。

もうバンクーバーでは、プロジェクトを進める際に、様々な使えるツールを使って、サービスを一人でローンチまでもっていってしまう、という形ですね。

セナ：　一人では、まだあまり聞いたことはないですが、少人数のチームですよね。3人～4人とかのチームで、一発でローンチまでもっていって、というケースは、結構あります。まぁ、どこを指して「Webの話」とするのか、にもよりますが。サービス開発の話であれば、間違いなくそうでしょうね。

例えば先程のデザインエージェンシーとかですと、受託で案件を取ってきて、例えば更新が必要なWebサイトで、「ショッピングカートをつけたい」となったら、とりあえずWordPressを入れて、Shopify（ショッピファイ）というショッピングカートシステムをパーっと入れてしまい、さくっとローンチまでもっていく。そんな提案のスピード感ですよね。

それがまぁ、僕が知っている頃の10年くらい前の業界事情であっているかわかりませんが、日本で同様のことをやろうとすると、ショッピングカート一つでも、最初から規模の大きいショッピングカートシステムを導入して、特に先の見通しを立てずに大規模な物にする、などという、結構回りくどい話になりやすいですよね。

確かに、日本では「信頼のおけるシステムを選ぶべき」という節があります。

セナ：　 これが良いのか悪いのかではないですし、どちらが絶対悪、というのはないと思います。ただ、結局の所それら開発に挑む姿勢や意思決定、リソース選択も含めて全てのスピードが日本と大きく事なる場合が多く、またそれらの意思決定が早いということは、それだけ時間的な工数も少なくて済む場合もあります。日本では費用対効果が叫ばれますが、その割にエンジニアサイドでは「こうしたらもっと早いのに…」という不平不満の声も多いようにも見受けられます。そういう意味ではもっと意思決定の裁量をエンジニア側に持たせられるようになる方が、よっぽど不必要な部分は削減できると感じますね。

【あとがき】

最初から、非常に刺激的な話をしてくださっているセナさん。「日本のスピード感の遅さは、意思決定にある」というご指摘は、はっとしてしまいました。

また、ツールの選び方も、日本と北米圏では大きく違うようですね。「信頼」のあるローカライズされたものを選ぶより、普及された価値を優先する、という考え方、大変参考になります。

日本でもWordPressは主流のツールの一つですが、海外製のツールを扱ううえで、「セキュリティ」は万全なのか気になってしまいますよね。次回は、その辺りに突っ込んでみました。

さらに、よく議論の場となる役職「プロジェクトマネージャ」と「Webディレクター」 も、日本とどのように職務領域が違うのか伺いました。お楽しみに！

画像：Pixabay

仕事中、雑談していますか？
ざっくばらんな会話の中にいいアイデアがポンとうまれた経験をしたことがある方は多いと思います。

「ほぼ日」では雑談を気軽な息抜きの役割を超えて、とても重要ととらえているそうです。雑談のためのスペースがオフィス内に多く用意されています。

個人的に「雑談って意外と大事だよね」と感じていて、部下や後輩、同僚にその重要性を伝えようとしてもなかなか具体的に説明できず、「雑談って時間の無駄ですよね？」と言われてしまうこともあったのですが、元記事ではとても分かりやすく「雑談の重要性」について書かれています。

「ほぼ日」はなぜ雑談を重視するのか | 組織社会学から見た「ほぼ日」｜DIAMOND ハーバード・ビジネス・レビュー

画像：pixabay

リクルートテクノロジーズでは、新卒社員向けの技術研修「ブートキャンプ」を3か月間実施しているそうです。
この研修資料が一般に公開されています。

技術者向けなのでワタクシには内容が難しいセッションもありましたが、基礎を学ぶのにとても勉強になります。

• エンジニアとしての心構え
• HTML/CSS入門
• TDD Boot Camp
• Javascript入門
• Git入門
• Java入門
• AWS体験ハンズオン ～セキュア＆スケーラブルウェブサービス構築編～
• DevOps導入指南改め Infrastructure as Code
• データベース入門
• 検索結果の品質向上 ～Elasticsearch入門～
• セキュリティ　～Web Application Hardening～

リクルートテクノロジーズ　新人研修特別編を公開します | リクルートテクノロジーズ　メンバーズブログ

画像：pixabay

自分ひとりで進めている案件、チームで進めているプロジェクト、パートナーとともに進めているプロジェクト。さまざまな仕事を並行で進めることが多いウェブ担当者のみなさんはタスク管理やスケジュール管理に悩まれることも多いと思います。私もよく悩みます。

GW前の記事になりますが、この記事では「メンバーのタスクを遅延させてしまうのは、メンバーではなくリーダーの責任」を前提として、なぜメンバーのタスクが遅れるのかをメンバーにヒアリングし解決していく中で、リーダーの「タスクの振り方」について言及しています。

ここまで考えてくれるリーダーがいるといいなぁ…と思う反面、改めてリーダーとしてメンバーの性格とタスクについてもっと考えなくてはいけないと感じました。

タスクをどんどん遅延させてしまう人に、何故遅延させてしまうのかヒアリングした時の話 | Books&Apps