読者です 読者をやめる 読者になる 読者になる

Gaiax Engineers' Blog

Gaiaxの技術者ブログです. 社内の様子をありのままにお伝えしていきます.

YAPC::Kansai 2017 OSAKに参加してきます。

YAPCに参加といってもたくさんの参加方法あります。

  1. 前夜祭に参加
  2. YAPC::Kansaiに聴講者として参加
  3. YAPC::Kansaiに登壇者として参加
  4. YAPC::Kansaiにスタッフとして参加
  5. YAPC::Kansaiにスポンサーとして参加
  6. 後夜祭に参加

こんなところですかね。 あっ、重要なものを一つ忘れてました。

  1. YAPC::Kansaiに運営として参加

運営委員会の方、いつも開催までの準備ありがとうございます。

今回、Gaiaxのメンバーは、前夜祭に参加し英気を養い、聴講者として参加し刺激と技術を補充し、登壇者として参加して発表し、スポンサーとしてYAPC::Kansaiを応援し、後夜祭に参加して当日の疲れを癒してきます。

Gaiaxは、プラチナスポンサーとベストトーク賞スポンサーとして、応援しています。

今週末が楽しみですね~。

xtetsujiさんが登壇しますので、ご期待ください!

twitter.com

エンジニア勉強会を開催しました。を久しぶりに公開

ガイアックスが永田町に移りました!

本ブログを見ている人は、ご存知の方も多いと思いますが、ガイアックスが永田町のGRIDビルに移りました。
GRIDビルって何?ってかたはこちら

移ったからどうしたっていうと、今までバラバラだったガイアックスのグループ会社が一緒のビルになったのです。 (五反田のオフィスに残ったチームもあるわけで、全グループが同じビルになったわけではないですが。)

グループ会社がどんなサービスを提供しているかは知っていれど、どこでどんな仕事してるか知らなかったグループ会社の人たちが階は違えど、同じビルで働いている状況。

ということで、グループ会社や各事業部の人に声をかけて、勉強会をしました。

非公開資料が多く、発表内容の多く公開できませんが、今話題のWordPress脆弱性を実際に再現してみたり、インセプションデッキを公開したりと多種多様な発表がありました。

その中から、公開できるものと、印象的だったものをピックアップして紹介します。

いつも自主的に資料公開してくれるhoto氏の発表は「ステージング環境のつくりかた」

f:id:gaiax-tech:20170216144935j:plain 元の画像はこちら

ネットワーク回りは詳しくないので、説明できないのだけど、1台で、LBとプロキシサーバを兼ねたものを自作した感じなのかな。
開発環境にCentOSを入れるとき、いつもiptablesはoffにするのだけど、理解すれば良い機能なんだなと思った。

続きを読む

エンジニア交流会 ~大掃除済み!俺のこだわりデスク公開 10本勝負~

エンジニア交流会 ~大掃除済み!俺のこだわりデスク公開 10本改め4本勝負~を開催しました。

先日、1月30日(月)に、エンジニア交流会を行いました。 2016年12月にも同様な交流会を開催しましたが、これから継続して、開催していきます。

その交流会がどこで行われたかというと、2016年末に永田町にできたGRIDのB1Fです。 (弊社及び弊社グループのオフィスと、コワーキングスペースを運営するmidori.soが入っています。) f:id:gaiax-tech:20170202180101j:plain

B1Fと6Fは、セミナーやイベントを開催できる設備と広さが準備されています。 詳細については、別の機会に説明させていただくとして、ご興味がある方は、以下のページをご確認ください。

「ON THE GRID OFF THE GRID
つながろう、自由になろう。」

がコンセプトの永田町GRIDビルの説明はこちら

今回は、準備中の様子からご紹介。

そんなのいらねーよと言わず、写真だけでもみてください。
スクリーンに向けて、椅子を設置。 f:id:gaiax-tech:20170202180406j:plain 準備中の打合せ。 f:id:gaiax-tech:20170202180445j:plain マイクの調子を調べたり。 f:id:gaiax-tech:20170202180543j:plain ハンモックに座って休んだり。 f:id:gaiax-tech:20170202180556j:plain

と会場の準備を整えて、俺のこだわりデスク公開LT大会が開催されました。 10本勝負のはずが、打診した人に外せない仕事の打合せが入ったり、当日風邪で発表できなくなったりと、発表者が4人になってしまい、申し訳ありません。

1番手 xtetsujiさん

デスクの紹介なのに、59枚のスライドを準備した強者! f:id:gaiax-tech:20170202180830j:plain

マグネットの活用術が素晴らしい。100均アイテムの活用術などなど。

www.slideshare.net

続きを読む

エンジニア交流会~マル秘?!こだわりの社内ツール大公開!~ 2016/12/21

Gaiax Technical Meetups

マル秘?!こだわりの社内ツール大公開!

さる12月21日にGaiaxセミナールームにて、「マル秘?!こだわりの社内ツール大公開!」というイベントを行いました。

f:id:gaiax-tech:20161222203321j:plain

それでもLT発表者を含め二十数名の方にご参加いただきました。

年末の忙しい中、また寒い中、多数の方にご来場いただきありがとうございます。

発表内容

発表内容は以下のようになります。
通常発表(10分)
1. 発表の場をコミュニケーションの場に変えるツール「flourish」@hoto17296
2. JSONファイルでE2Eテストが行えるツール「Jsonlenium」@"Ryuichi TANAKA"
3. 外部サービスのWebhookをローカルで扱うサービス「Primus」@papix
LT(5分)
4. 簡易な業務のWeb化に使えるツール「プリザンター」 @Implem_
5. タグ判別Chrome Extension 「リスト君」 @yaggytter

タイトルだけじゃ、どんなツールか、ほとんど想像もつかなかったのですが、聞くとなるほど~となるツールばかりでした。


発表の場をコミュニケーションの場に変えるツール「flourish」

一人目の発表者、弊社ガイアックスの新卒(?)3年目エンジニアのhoto179296さん。 f:id:gaiax-tech:20161222204427j:plain
新卒といって良いのか疑問に思うようになってきたhoto179296さんの発表

社内ツールだからとぱぱっと3日で作ったら、そこからバグとか結構あって、業務中に対応しながら、完成まで足掛け2か月くらいかかったとか、社内ツール開発あるある。
質疑応答で、オープンソース化の質問がありましたが、コードが汚くて出せませんって、正直な回答が印象的でした。

JSONファイルでE2Eテストが行えるツール「Jsonlenium」

続きを読む

総務のかんばんについて

Advent Calendar

ガイアックス総務部のishihamaです。 この記事は、Gaiax Advent Calendar の12月17日の記事です。

総務って何してるの?

まず、総務のお仕事を簡単にお話したいと思います。 総務では、日々の業務でオフィスの備品管理、設備管理、受付対応、電話対応、郵便物の配布、社内行事の企画運営、などを幅広く担当しています。
その他に突発的な業務も入ったりします。こんな感じで多岐に渡って、いろいろな業務をしています。

問題が多発

人数が増えると共にお互いの業務量、タスクの進捗状況が全く見えなくなり、どんどん俗人化をしていき、お互いが何をやってるかわからないというような、とても雰囲気が悪い状況になってしまいました。
このタスク管理をどうにかしたい、総務内や会社内に総務の業務を公開したいと思いツールを探していました。

タスク管理ツールの利用

最初はタスク管理ツールを使って、個々に自分の業務をタスク管理していました。
タスク管理ツールを使うことで、以下のことを総務内メンバーで共有していました。

<共有していた内容>

  • 誰がどの業務を担当しているのか
  • 業務がどれくらい進んでいる(どんな状況か)を把握する

これで総務内の共有は大丈夫!と思っていたのですが・・・ 実際使ってみると、次の問題点が発生しました。

<問題点>

  • タスクの量が多く、気づけば担当者でないとタスクの状況が分からない
  • タスクの長期化などもあり、どれが優先タスクかが分からない
  • ちょっとした連絡事項を共有するのには向いてない

まず、タスクの量が多く、そのタスクの長期化もあったりで、タスクがどんどん埋もれていきました。
都度、検索しないとタスクを探せないこともありました。もっと効率よく管理できる方法はないのかな?
とまた新たな施策を検討

総務かんばん化

ちょうどその頃総務でスクラムをやっていて、その中の『かんばん』を教えてもらえました。
付箋でタスク管理をするなんて初めてのこと。どうなることかとおもいましたが、、総務のタスクが見える化されて、タスク管理がもっと分かりやすくなる!とかんばん化を決定。
導入当時の総務の『かんばん』はこんな風に使っていました。

<総務かんばんルール>

  • 担当者ごとに付箋紙の色を決める。←色を見れば、誰が何をやっているか分かる!
  • ToDo/Doing/Doneのところは、ToDo:今日やること Doing:保留中 Done:完了

 【最初の総務かんばん】

f:id:norinux:20161220113933p:plain

実際に使ってみると・・・

<よかったこと> ・誰がどんなタスクをしているかが、明確になった

<問題点> ・優先順位が分からず、次にどのタスクを進めればいいか迷った ・付箋紙の量が多すぎて、気づいたらタスクが埋もれていた ・ちょっとした連絡も付箋紙の量が多い時は埋もれていた

総務オリジナルのかんばん

かんばんを使って、総務メンバーのタスクの見える化はできたけれど、その他の問題点は残ったままでした。総務で使いたいかんばんとは?を改めて考え以前、ヴァル研究所さんへ見学に行ったときにいろいろなかんばんのスタイルを勉強させていただきました。
どのチームも自分たちの業務に合った、かんばんを作られていたのを見て、総務も総務に合ったかんばんを作って使えばいいんだ!というのに気づきました。
総務に合った看板とは・・・
1ヵ所にメンバーが知りたい内容(メンバーの予定、タスク、連絡事項など)が全部載っているかんばん!

<総務新かんばん>

  • 担当者別にタスク管理できるように表を作成した
  • 優先度を付箋紙の色で分けて、分かるようにした
  • タスク以外にメンバーの予定、連絡事項を貼る場所を作成
  • KPTもこのかんばんに一緒にまとめた

 【総務新かんばん】

f:id:norinux:20161220113906j:plain

総務新かんばんを使ってみて

突発的な業務が同時多発的に増えると、頭の中だけで組み立てることが難しく、タスクの優先順位が 整理しきれなくなり、混乱してしまうことがありました。リニューアルされた新かんばんは、とっても使い勝手がよくなり、タスクの整理・優先順位が組み立てやすくなって、楽しくなりました。
また、ふせんの色を人別ではなく、優先順位や重要度、突発業務なのかで色分けして使うことで、優先順位が見える化されて、整理・組立てしやすくなりました。今まではつい付箋が手元に溜まってしまい、重く感じることもありましたが、意識的に状況に合わせてかんばんに移動することで、終わった達成感と、タスク進捗がわかりやすくなったのが実感できるようになりよかったです。

スクラムを始めて2年、現在のプロジェクトの形

Advent Calendar

こんにちは。Gaiax 技術開発部の菊池です。
この記事は、Gaiax Advent Calendar 2016 - Qiitaの15日目の記事です。

はじめに

今回は自分がスクラムマスターとして活動しているプロジェクトでのスクラムについて紹介をしたいと思います。
スクラムマスターとしては3つ目のプロジェクトです。初めてスクラムを知った時から、2年ほど経過しようとしていて、その間にCSM(認定スクラムマスター)とCSPO(認定スクラムプロダクトオーナー)の研修を受講し、認定を受けています。
現在のプロジェクトでは、スクラムの形がほぼ出来上がってきたと感じていて、今の所のスクラムへの取り組みの答えなのかなと感じています。そんなプロジェクトを紹介したいと思います。


開発しているプロダクト

開発しているプロダクトはTRUST DOCKという本人確認のサービスです。

trustdock.io

身分証をアップロードし、その身分証に不正がないか確認したり、本人のものかなど包括的に確認を行うサービスです。個人の信用が重要となるWEBサービスにおいて、広く展開をさせていきたいと考えています。


チームの構成

チームの構成は開発者が二人、プロダクトオーナーが1名、スクラムマスターが1人の4人体制です。
開発チームは経験豊富なエンジニアと2年目の若手エンジニアです。プロダクトオーナーは開発の経験があり、開発者と技術的な会話もすることができるプロダクトオーナーです。
そしてスクラムマスターが自分です。自分の役割としては、スクラムマスター以外に、サービスのUXを設計したり、開発の経験を通して開発チームの相談役などもしています。
スクラムマスターとの兼務は、できれば避けたいところではありますが、帽子をうまくかぶりわけ活動しています。


開発で利用しているツール

開発の中で使っているツールは次の2つです。開発で利用しているテストなどのサービスなどもありますが、スクラムのお話なので今回は割愛します。

GitHub

みなさんご存知、ソース管理はGitHubで行っています。スクラムにおけるストーリーも、trustdock-issuesというレポジトリを単独で作成し、こちらで管理しています。

Slack

チーム内のチャットでのコミュニケーションにはSlackを利用しています。共有、相談などのチャンネルのほか、フィードバックの通知チャンネルや、アラートなどの通知もSlackに流れるようになっています。
対面で話せるような座席に配置しているので、何か課題があった場合などは、すぐ後ろを振り返ってその時々解決しています。チャットツールを介して議論を行うとエビデンスとして残るメリットもありますが、そういう内容の場合は、対面ですぐさま解決しつつ、必要があればissueに記載するようにしています。


スクラムイベントとそのサイクル

スクラムで実施しているイベント(タイムボックス)は次の通りです。

スプリント:1週間

開発のひと回しです。プランニングから始まり、実装、レビュー、振り返りまでを指します。

スプリントプランニング(計画):2時間

スプリントの計画を行います。水曜日の午前中に実施しています。

朝会(デイリースクラム):15分

毎朝10:00に実施しています。「昨日実施した内容」「今日の実施予定」「スプリントゴールに向かって障害になること」「ニコカレの顔確認」「レトロスペクティブの内容再確認」を実施しています。

プロダクトオーナーレビュー:1時間

プロダクトオーナーへデモを実施し、受け入れ条件をクリアしているか確認します。

スプリントレトロスペクティブ:1時間

スプリントの振り返りを実施しています。振り返りの内容を次スプリントへ活かしています。

プロダクトバックログリファインメント:1時間

優先度順に並べられたストーリーに対して、開発チームとプロダクトオーナーが完了条件などの合意をとり、さらに優先順位が正しいか確認します。

相対見積もり会:1時間

開発により実施されています。リファインメントでプロダクトオーナーと完了条件の合意が取れたもののうち、見積もりされていないストーリーに対して相対見積もりがされます。

スクラム以外で実施していること

インセプションデッキ

事業としてのチーム内での合意形成にはインセプションデッキを利用しています。合意のとれたインセプションデッキは印刷していつでもチームが確認できるよう貼り出しています。変更などがあった場合はメンテナンスを実施します。

がんばった会

何かを成し遂げた、しんどくなった時はみんなで夕ご飯を食べに行き元気を出します。


イベントごとの様子や工夫

それではもう少し詳しく各イベント毎の状況や工夫を紹介します。スプリントは現在28(28週)まできています。

スプリントプランニング:2時間(水曜午前中)

スプリントプランニングでは、これから始まるスプリトでどこまで実装できるか検討します。今回のプロジェクトでは、ストーリーの見積もりを相対的に見積もっています。相対見積もりとは、実時間での見積もりではなく、実装の大きさを基準となるストーリーからどれくらい差があるかという観点で見積もりをします。
前スプリントで実装できた相対見積もりのポイント数(実績)から、今回のスプリントでどのストーリーまで実装できるかプロダクトバックログからおおまかに割り出します。
その後、ストーリーを実装のタスクレベルまで落とし込み、実時間見積もりをおおよそでしています。このとき、どうしても発生してしまうプロジェクト外のタスク(例えばこういう記事の執筆や、勉強会など)も同時に洗い出し、スプリントの計画をたてます。洗い出された開発タスクはGitGubのissueで管理されているストーリーの詳細に転記し、実装もれなどないようチェックリストとして機能します。
この時プロダクトオーナーも参加して、内容の確認を行いながらチームでの合意を取ります。 f:id:sohismyson:20161215130314j:plain

朝会:15分程度(毎朝)

朝会では、「昨日実施した内容」「今日の実施予定」「スプリントゴールに向かって障害になること」「ニコニコカレンダーの顔確認」「レトロスペクティブの内容再確認」を実施しています。
完結に共有相談できるよう、各自が事前に考え「真剣に参加する」よう促しています。スクラムのTipsにある、障害になることは別に時間を切り出して、関係者だけで議論することはしていません。小さなチームですので、課題があればその場で解決しています。タスクの実装は基本的に個人で行いますが、成果はチームとして出す意識を持ち、遅延などあれば積極的にフォローしあいます。 f:id:sohismyson:20161215112433j:plain
ニコニコカレンダーも取り入れていて、各自の今日の体調や気持ちの表情シールをスプリントバーンダウンチャートに貼り付けています。チーム内の雰囲気も把握できますし、お互いフォローもし合えるのでよい取り組みです。 f:id:sohismyson:20161215125447j:plain
また、レトロスプクティブであげたトライすることもできる限り確認しています。
最後に「今日も1日、宜しくお願いします!」と声をだし(オフィス内なので大声はだせません)メリハリをつけて1日のスタートを切っています。

プロダクトオーナーレビュー:1時間(火曜午後)

スプリントで実装されたストーリーが完了条件を満たしているか、開発からプロダクトオーナーに対してデモがされます。開発は円滑なデモができるよう、デモを想定したデータ作成やデモの順番などを事前に準備しています。スクラムマスターは進行だけを行い開発がメインで実施します。
完了条件を満たしたものはDoneとし、万一足りなかった場合は差し戻し、追加の要素が出てきた場合は、別のストーリーとして切り出し、プロダクトバックログに追加されます。
Doneにできた時は、チーム全員で喜び小さい音でですが拍手をし、達成感をしっかり感じるようにしています。 Doneできなかった時は、後のレトロスペクティブで原因などを考え対策を検討します。

スプリントレトロスペクティブ:1時間(火曜午後)

スプリントの振り返りです。KPT法を用いて実施しています。
Keepではスプリントないで良かったことや、継続して続けていきたいことを考え付箋に記載し貼り出して行きます。続けて発生した課題をProblemとして貼りだします。このProblemから特に解決したいことをピックアップし解決策をチーム全員で検討します。次回のレトロスペクティブの冒頭で、このTryとしてあげた解決策が実施され、課題が解決されているか確認を行います。 f:id:sohismyson:20161215125654j:plain
レトロスペクティブの時間は、チームに向き合うとともに、自分へも矢印を向け振り返りを行います。自分の課題を他のメンバーの前で発表する事はとても勇気が必要なことですが、しっかり共有されています。これはとても素晴らしいことだとチーム全員が感じていて、チームでアイデアをだしたり課題解決に向けて活動をします。 スクラムの自己組織化と振り返りを通じた自分たちの活動の最適化のコアになる活動であり、とても重要なイベントです。
ただ、形骸化もしやすいのもあり、おやつや飲み物を用意して雰囲気をコントールしたり、振り返りすることの意味を改めて考えるなどして活動を続けています。

プロダクトバックログリファインメント:1時間(月曜午前中)

プロダクトバックログ(PBL)のメンテナンスをする時間です。PBLは実装するストーリーが一意の優先度順に並べられたものです。この順番に変更が無いかと、完了条件の合意が取れていないストーリーについて、プロダクトオーナーから説明をうけ、チームで完了条件を作り合意して行きます。
おおよそ3スプリント先くらいまで分のストーリーをストックできるよう、リファインメントを実施しています。余裕がある際は、優先度に変更がない時に限りスキップもしています。
プロダクトオーナーから提示された内容を鵜呑みにするのではなく、当事者意識をもちチーム全員で整合性などを検討します。

相対見積もり会

リファインメントで完了条件の合意が取れたストーリーに対して相対見積もりを行います。相対見積もりする際にチーム内で意見をすり合わせ、だいたいの実装方針がきめられます。この時、お互いフォローできるような体制が出来上がります。プランニングポーカーを用いて実施しています。この見積もりに時間をかけすぎるのも好ましくないので、時間を気にしながら実施しています。


まとめ

現在のこの形は、プロジェクトのチームがスクラムを通して改善してきた積み重ねの結果です。紆余曲折ありながらも、真摯に向き合った結果、今があると考えています。
開発チームも、サービスを自分たちのものと捉え積極的に活動しますし、チャレンジや改善活動を重ね、技術的にもエンジニア的にも成長を続けています。プロダクトオーナーも、初めはプロダクトオーナーの役割がわからず勉強してもらい、多くのディスカッションを重ねてきました。いろいろなスクラムの事例を見ていますが、今の所自分の中では最強のプロダクトオーナーだと感じています。
ただ、まだ改善できる余地はあると思うので、ダッシュして息切れしない程度に走り続けたいと思います。スクラムという手法に関していうと、数ある開発手法の1つだとは思っていて、課題もあるとは感じますが、よい仕組みだと感じていますし、これまからも続けていきたいと思います。スクラムについてなど、何かお話したいことがあればお気軽に声をかけていただければと思います。

サービスがより多くの人に利用していただき、世の中に価値を届けられるよう引き続きチームで頑張っていきたいと思います。
それではみなさま、良いお年を。

事業部制の組織形態と今思う大事にしたいこと

ガイアックスの技術責任者のhidehigoです。
Gaiax アドベントカレンダー Gaiax Advent Calendar 2016 - Qiita の8日目です。
昨年も1人1エントリで完走することができましたが、今年は、もう少しラインナップを広げて完走を目指します。お楽しみに!

今日は、少し組織寄りの話、思想寄りの話をします。
Gaiaxでは、全社の組織を、2015年から事業部制組織という形に切り替え運営しています。
昨年のエントリから少し引用します。

Gaiaxというのは、なかなかにボトムアップな風土の会社でして、事業の裁量を広げさらに加速すべく、この形態に移行しました。 私の考えですが、機能組織がいいか事業組織がいいか、は時によって最適が変わるものだと思っています。エンジニア/エンジニアリングは「機能」を担う面が強いため「機能か、事業か」という問題はエンジニアにとって実は大きな影響があります。 事業組織への移行の判断時、それから約1年経った現在、今のGaiaxには事業組織がベターと考えています。

Gaiaxのエンジニア組織について - Gaiax Engineers' Blog

今年1年では、事業が、子会社化してさらに自立度高く運営する、という選択をできる制度を作り、事業部制をさらに推し進めています。

上に引用した昨年のエントリでは触れませんでしたが、’エンジニアにとって実は大きな影響’というのは、一部のエンジニアにとって所属の部署が変わる、ということに留まりません。
事業部制において、事業所属のエンジニアは、事業の実現したいミッションにコミットし実現に全力を注ぐことになります。必然、エンジニアリングとしては、事業のサービスやアプリケーションの機能、ユーザーインターフェース、あるいはその実現スピードに重点を置くことになります。(もちろん何かをやらない、という話ではありません)。
一方で、技術開発部所属のエンジニアは、一段後方から事業を、また事業の開発チームを支える、たとえば共通のサービスを提供したり、開発プロセスや手法の強化のための支援、全社のセキュリティのルール整備などのように、支援の要素が増えます。
一つの会社に所属するエンジニアに、貢献方法に大きく2つのパターンができるということになりますし、マインドも必要なスキルセットも少し違うという状態になります。

ここのところ、そんな事業部制組織を運営する上で大事だと思うことを少し表現できるようになってきました。

キャリアパスと評価の仕組みをどうデザインするか
分散しがちなノウハウを集中するために、技術選択を集約するか
薄れていく全社の横のつながりをどう作るか
などいくつも大事な論点はありますし、制度や運用として整えられていくべきです。

一方で、メンバーひとりひとりがそうあってほしい、と願うところもあって、
それは、技術でもなく、心もちでありメンタリティについてなのですが、

自分と違うOOをリスペクトする

この点が重要だと考えています。

たとえば自分と違う職種
たとえば自分と違うキャリアの志向
たとえば自分と違うスキル
たとえば自分と違う価値観

さらにいうと、AかBかという二元論になる要素である場合に、自分でない他方をリスペクトするというのが絶対的に重要。

上記した、貢献の2つのパターンは二元論になりがちな要素です。
しかし、エンジニア人生通じてどちらかの貢献方法を決めなければいけないわけではないですし、 その時その時の興味や、伸ばしたい領域、取り組みたいことなどで変わるものですし。
たとえば、チームの誰かが、別のキャリア、ステップを希望するようになった。それは全力でリスペクトし、応援したい。

こうして書いたら、ほとんどの人は反論も感じないと思います。
でも、これと同じ構造の話がそこここにあるんじゃないかな。
それが、事業部制のデメリットとして表出し、感じられている一因じゃないかな、と考えています。

極端なケースでは「みんなと違う、わたし(たち)」という形でアイデンティティを保とうとしてしまうことさえ。
得てしてこれは、ネガティブなスパイラルを助長します。

最後に、

自分とは異なる考え方を受け入れられないのも、暴力のひとつの形です。それでは真の民主的精神は、一向に育たない。

これは、マハトマ・ガンジーの言葉ですが、ダイバーシティについての考え方として多く引用されています。
他者との違いを尊重し、応援しあえる。それが一体感やシナジーと呼ばれる行為・思いやりにつながる、そんな組織を目指したいと思います。