iPad Pro 10.5を仕事で使っていますが、ブログを更新するときに極力iPad Pro 10.5で完結できるようにしています。
アプリを利用してコーディングを行なったり、打ち合わせのメモをApple Pencilを使ってみたりとしていますが、その中でブログでも利用している画像をiPadでどこまでできるかを試してみました。
結論としては、iPad Pro 10.5でも十分協力な画像編集ができ、日々の作業負担を減らすことができます。
RAW画像をiPad Pro 10.5で編集してjpgに書き出して、ブログの記事を更新してみました。

まずはデータの読み込み

最近のカメラはWiFi機能が付いているので、その機能を利用してiPadに画像を読み込ませる事ができます。
私が使っているのはCanon EOS 80Dですが、 Canonが提供するアプリを使ってカメラの画像をiPadに転送することができます。
ただ、WiFi経由なので速度が遅く、すぐに読み込みたい時にWiFiが繋がらなくなったりと不便な面もあります。
そのため、Apple純正の「Lightning SDカメラカードリーダー」を利用しています。

Lightningコネクタに接続して直接iPadに読み込ませる事ができ、速度も十分早いので複数ファイルを一括で読み込ませる時にも便利です。
また、iPadの広い画面でプレビューしながら、読み込ませたい画像を選択できることもメリットがあります。
カメラの勉強を兼ねて一眼レフカメラを利用しているのですが、記録形式としてRAW+JPEGで記録するようにしています。
後から編集したくなった時に、jpg画像では劣化してしまうのでRAW画像があれば劣化させずに編集できるからです。そのために、ファイルの容量が重くなり転送に時間がかかるので、SDカードリーダーで接続した方が読み込みも速くなると思います。

Lightroomを使ってRAWを編集して書き出し

iPhoneやiPadのカメラで撮影しても良いのですが、勉強のため一眼レフカメラで撮影することが多く、RAW画像から現像したイメージをwebサイトで利用したいと考えています。
TRIADではAdobe Creative Suiteを利用しているので、Adobe LightroomをiPad　Pro 10.5に入れています。
このLightroomでRAW画像を読み込んで編集する事ができます。

PCのフルバージョンほど細かな設定はできませんが、どうしてもjpg撮って出しの画像では気になる箇所がある場合、必要最低限の機能はあるのでRAWファイルから気になる箇所を修正して書き出す事ができます。
Adobe Creative Suiteではなくても、Photoshopとセットになったフォトプランや単体で購入することもできるので、写真をメインに作業内容しているかたも導入しやすくなっています。
各カメラメーカーが提供するRAW現像ソフトウェアもありますが、PCでの作業が必須になってしまいiPad Pro 10.5で作業を完結できないデメリットがあります。
もちろん、カメラの特性に合わせて作成されていると思うので、jpgの書き出しなどはより簡単に編集できるとは思います。iPad Proの機動力を活かして現像できるのであれば、汎用性のあるLightroomでも十分活用できると思います。

セルラー版ならでは

iPad Pro 10.5のセルラー版を利用していると、webサイトに画像をいつでもどこでもアップロードする事ができます。
当ブログも基本的にiPad Proのみで完結しようとしているので、ブログに利用する画像はiPad Proからアップロードしています。
ブログの記事を書いて、利用する画像を編集して、それらを管理画面からアップロードする作業はそれなりに時間がかかります。
その都度、PCを開いて作業してということを繰り返すと時間のロスが多くなり、手間が多くなってしまうので継続していくモチベーションが下がってっしまいます。
いつでもどこでも、隙間時間を利用して作業ができ、完了させることができる環境があるとモチベーションが下がることなく継続していけます。

TRIADがWordPressサイト制作で利用しているプラグインを紹介する第6弾「Really Simple SSL」です。
Really Simple SSLのダウンロードはこちらから
Webサイトの常時SSL化が必須になっていく最近のサイト構築で、WordPressサイトもSSL化にしなくてはならなくなってきました。
細かな設定をサイトごとにしていくのは、作業工数が増えて面倒ですしミスが起きたら管理画面には入れなくなったりしてしまいます。
このプラグインで簡単にWebサイトをSSL化することができます。

Really Simple SSLの使い方

Really Simple SSLをプラグインに追加して有効にします。

Really Simple SSLを有効にすると、SSLが反映されていれば設置が完了します。
※プラグインを有効化する前に、サイトにSSLが反映されているか確認してください。
設定が完了すると、管理画面の左メニュー「設定」に「SSL」が追加されます。

「SSL」をクリックすると設定画面に遷移します。

複雑な設定が不要

WordPressは、投稿や固定ページのディレクトリは存在せず、mod_rewriteを利用してページを表示しています。
そのため、SSLを利用するとなると、.htaccessにSSLに対応するために記述を追加したり、WordPressの設定からURLを書き換えたりする必要がありました。
ただ、設定が正しく反映されていないと、管理画面にログインできなくなって直接データベースの中身を書き換えないと復旧できなくなったりと、少しハードルが高くなっていました。
このReally Simple SSLプラグインを利用すると、プラグインの有効／無効で設定が完了できるので、ログインできなくなることもなく簡単に設定することが可能です。

常時SSLの時代だから

GoogleがSSLを推奨してから、サイトをSSL化する事が多くなっています。　　
サイトを設置する毎にSSLの記述をしたり、コピーして使い回すと改修も大変になってしまいます。　　
プラグインであれば、管理画面でクリック一つで設定でき、運用面でも細かな設定の負担を軽減できるようになります。
できるだけプラグインを使わない方が軽くて良い、という風潮がWordPressで構築するときにありましたが、最近のレンタルサーバー自体のスペックが高くなっているのでそこまで気にしなくても良くなったのもこれらのプラグイン利用を後押ししてくれています。

トライアドではデスクトップのMacではなく、メンバー全員がラップトップのMacを利用しています。
費用とスペックを考えるとiMacで揃えた方が安くスペックの良いMacを使えるのですが、様々な要件を満たすのがラップトップのためデスクトップ型のMacは導入しないという決断をしました。

場所が固定されて身動きができなくなる

デスクトップ型のMacだと持ち運びができなくなってしまうので、場所が固定されてしまいます。

リモートワーク

トライアドではリモートワークを採用していますが、全員がラップトップのMacを利用しているからこそ採用することができました。
メンバーの誰かがデスクトップ型で、オフィスに常駐しなければならなくなってしまうと、リモートワークも採用しづらかったと思います。

打ち合わせ

場所を固定されるとなると、社内ミーティングの時も自分のMacを持っていけないので、手書きのノートかタブレット、ラップトップを持つことになり、自分のMacの中にあるデータをすぐに抜き出すのが難しくなります。
常に自分のデータを引き出せるためにラップトップを持って参加することで、MTGをスムーズに行うことができます。

出張

遠隔地のクライアントさまに伺うときにも、場所が固定されないラップトップであれば持っていき、打ち合わせが終わったらその場で作業をしたり情報を他のメンバーに共有することができます。
スマホやタブレットを利用すれば良いのですが、USBメモリやDVDなどでデータを提供されれば、作業にPCが必要になってしまいます。
宿泊での出張であれば、宿で作業もできるので会社に戻るまで作業ができなくて時間をロスしてしまう事を防げます。

デスクトップ型とラップトップ型の同期が面倒になる

メインマシンをデスクトップ型で、サブマシンをラップトップにするという選択肢もあります。
その場合に、２つのマシンを同期する作業が必要になり、同期するのを忘れてしまった場合は非常に面倒なことになります。
例えば、オフィスのデスクトップ型でデータを作成して、gitにpushをし忘れた、dropboxにファイルを入れ忘れた、このような場合に、必要なデータを取りにオフィスまで行かなければなりません。
ただデータを取りに行くために、数十分〜数時間を掛けなければならなくなり、非常に時間を無駄にしてしまいます。
100%同期をしているから大丈夫と思っていても、万が一のリスクを考えるとあまり得策ではありません。
実際に、私も10年ぐらい前にデスクトップ型をメインに、ラップトップをサブとして使っていた時期もありましたが、今よりも同期が大変だったことを差し引いても、面倒が事が起きないとはいえないのでこの使い方はやめました。
クラウドのサービスを利用していて、同期忘れの問題をなんとか解決できないか模索をしましたが、ベストな解決方法が見つからず同期をしなくても良いのが現時点で最良の選択肢となっています。

常に仕事ができることと追われるストレス

メインマシンを持ち運ぶ事ができるので、いつでもどこでも仕事を続けられることができます。
会社で絶対終わらせないと帰れないことや、今よいアイデアを思いついたのに作業できないというストレスは軽減できます。
しかし、いつでもどこでも仕事ができる反面、いつでもどこでも仕事に追われている感じがしてしまうかもしれません。
慣れてしまえば割り切ってしまうことができますが、プロジェクトが進行中だったりすると、進捗が気になったり終わっているか不安になったりします。
いつでもできることとこれらの不安要素を比べたら、トライアドではいつでもできるラップトップのメリットを選択しました。
社内のルールとしては、極力営業時間内で作業を完了させることにし、時間外での対応を特別な時に限るようにしています。
リモートワークを採用したときと同じ考えで、メンバーの裁量に任せることで不安要素については解決してもらっています。
メンバーが増えても、現在のこのルールを守っていけるように日々調整をしていきたいと思います。

トライアドでは、メンバーにやりたい事があれば、会社として全面的に応援する体制を整えています。
もちろん業務に関わることが優先なのですが、新規に開拓したいことがあってチャレンジする意思があれば応援します。
誰もがチャレンジするときに、失敗したらどうする／どうなるのかが気になってしまいます。
この時に、責任を取らされてクビになったらどうしよう、給料を減らされたらどうしようと、失敗することを前提に考えるとチャレンジをやめてしまいます。
失敗して辛い思いや責任を取らされるのであれば、最初からチャレンジしない方が良いという考えになるのもわからなくもありません。
ただ、「失敗」や「責任」とは何でしょうか？

失敗は成功のもとだからチャレンジしたことを評価したい

失敗したというのは、何かを始めて成し遂げられなかった場合によく使われると思います。
トライアドでも、志し半ばでクローズしたサービスもあり、これを失敗と呼んでいます。
ただ、この失敗と呼んでいるものは、これ以上続ける気力や外部との連携をとる術を考えるのをやめたから続けられなくなって終わらせた、という経緯があります。
もしかしたら、成功をするということは、継続してやり続けていればいつか訪れることなのかもしれません。
トライアドのサービスも、熱い想いを持って継続できる道を常に模索し、チャレンジし続ければ失敗は訪れなかったかもしれません。
ただ、「失敗」は本当に悪いことなのでしょうか？
上手くいかなくてクローズしたら失敗かもしれませんが、サービスを提供した、外部と連携をした、という経験はチャレンジしたからこそ得られた素晴らしい経験です。
この経験を次のチャレンジに結びつければ、チャレンジしたサービスはネガティブな失敗だけにはなりません。
”失敗は成功のもと”と言われるように、原因を追求し次に活かせることを続ければ、失敗してもトライアドでは評価も下がらないし、むしろチャレンジした事を評価したいと思います。

責任は会社が取れば良い

よく「責任をとる」という表現が使われています。
この「責任」とは具体的にどういうことなのでしょうか？
社内で失敗をしたら、責任を取らなきゃいけないと考えてしまうかもしれません。
ただ、仕事でチャレンジした結果で、うまくいかなかったり、これ以上継続できなかった場合に、個人が責任を取らなければならないのでしょうか？
トライアドのような小さな会社で、このチャレンジをしなくなってしまうと会社の事業の広がりがなく、未来への発展が断たれてしまいます。
チャレンジした結果で、他社へ迷惑をかけたり、メンバーに負担をかけてしまったり、様々な問題が起きてしまうかもしれませんが、チャレンジした人が全ての責任を負わなければならないのでしょうか？
なんのために会社という組織があるかというと、何かあっても組織・チームで乗り越えていくために存在すると思います。
問題が起きて迷惑をかけてしまった方がいれば、社長が頭を下げ謝罪をしなければなりません。そのために、メンバーよりも高い給与をもらっているのです。
責任をとらなければいけないというプレッシャーは考えずに、いろいろなことにチャレンジしてもらいたいです。

チャレンジするのは楽しいこと

新しいことにチャレンジするのは、とても楽しいことだと感じて日々を過ごしてほしいです。
同じ作業を繰り返すことで習得できることもありますが、インターネット関連の世界では日進月歩で進化していくのですぐに古い技術になってしまうことがあります。
それであれば、新しいことにチャレンジして、常に新しいことを探求していくことも業界では大切なことかもしれません。
インターネットの世界では、スタンダードと呼ばれるものが廃れていくスピードがものすごく速いので、情報を吸収したら実践していかないとすぐに時代の流れに取り残されてしまいます。
トライアドは小さな会社でフットワークを軽くし、常に新しいことにチャレンジする環境を維持していきたいです。人数が多くなっても、いつまでもこの気持ちを忘れずに実践できるような会社でいたいと考えています。

JR和歌⼭駅ステーションビルMIOの5Fにある「メンタルクリニックおおや」さまのサイトリニューアルのお手伝いをしました。

担当：デザイン、コーディング（レスポンシブ）、CMS（WordPress）

TRIADがWordPressサイト制作で利用しているプラグインを紹介する第5弾「Media from FTP」です。
Media from FTPのダウンロードはこちらから

サイト制作をしていると、本番と開発環境が分かれている事が多いと思います。
WordPressはDBでメディアを管理しているので、開発から本番に移動するときにDBの情報も移動してなくてはなりません。
新規サイトであれば、DBの情報を丸ごとコピーすれば良いのですが、稼働中のサイトをリニューアルする場合はコピーする事が難しいです。
日々の更新を完全に止めてもらえれば良いですが、開発に数ヶ月かかる場合は止める事はできません。
その際に、このプラグインを利用すれば、メディアを簡単に開発から本番に移行する事ができるようになります。

Media from FTPの使い方

Media from FTPを有効にすると、管理画面の左メニューのメディアに「Media from FTP」という項目が追加されます。

ここで、mediaに登録したい画像を、FTPでサーバーのuploadフォルダにアップします。
設定画面の「検索 & 登録」をクリックして、画像をアップしたuploadフォルダを選択型します。

プラグインがメディアに登録していない画像を抽出した一覧を表示します。
一括で登録したい場合は、一覧の項目にあるチェックボックスを選択型して登録をしていきます。

フォルダの設定画面について

「設定」から画像を格納するフォルダの設定ができます。

上記の画面はデフォルトの設定値になります。
作業している日付のフォルダを作成してそこに格納するのがデフォルトになっています。
画像のタイムスタンプに合わせて、フォルダを作成して格納することも可能です。
投稿記事の中に埋め込まれている画像は、メディアのパスを書き込んでしまうので、日付ベースで管理していた場合はファイルの日付を元に登録した方が不具合がでません。
サイトの移設時にDBを丸ごとコピーできない場合などは、この方法でメディアに再登録すれば簡単に移設できます。

メディアを簡単に取り扱える

この方法が使えると、テストと本番環境を分けて構築した際に、データベースの取扱に慣れていないフロント側の人が、エンジニアの力を借りずにメディアを移設できます。
CMSを使う限りは、必ずDBを利用しなければならないのですが、非エンジニアの人にとってはデータベースを触ることに抵抗があります。
すると、エンジニアの細かな作業が増えてしまい、負担が大きくなってしまいます。
CMSにすることでエンジニアの力を借りずにサイトを構築できるはずなのに、細かな作業が増えてしまうのは本末転倒だと思います。
そのため、このプラグインを利用して、極力フロント側で対応できれば、エンジニアの作業負担も減り、フロント側で作業が完結できスピードもアップできます。

こんにちわ、@nihimoto です。
今回は弊社トライアドの開発環境について記載してみたいと思います。

 

弊社ではエンジニア向けの開発環境として、開発専用のサーバーをVPSサーバーで用意しています。開発サーバー内にapacheやmysqlやphpなど、開発に必要なツールを一式インストールして、SSHで開発サーバー内でvim等のツールを使って開発作業を行っています。

昔は手元のMac内の環境を整えて開発していたのですが、VPSが手軽に手に入るようになってきた時期に、現在の環境へ切り替えを行いました。今だとAWSも検討するべきかもしれませんが、ひとまず現在の環境のメリットについて書いてみたいと思います。

柔軟なカスタマイズ

手元マシンの開発環境の場合、大抵はMacやWinとなるかと思いますが、その場合、実際にサイトを公開する本番環境のUnix系サーバーとの間で環境を合わせるのが大変です。
apacheやphpなどのかなり普及しているものであればなんとかなりますが、あまり使われることのないソフトやmodだと、「Winだと使えない」「Macだと設定値が違う」など面倒が続出します。
しかし、開発環境を手元マシンではなく外部に求めるのであれば、本番環境でよく使われるUnix系OSと同じ環境を用意することが、比較的容易にできます。
特に受託開発を行なう企業ではお客様の本番サーバーの環境は様々です。そういった時に開発環境をうまくカスタマイズして本番と合わせて、いざ公開！というときに、本番と開発の細かい差で泣くことがないように、あらかじめリスクを減らしておくことができます。

壊れない（滅多に）

手元マシンに環境を構築すると、マシンが壊れた時はもちろんOSのアップデートやその他不具合によって作業環境が破壊されてしまうケースが多々あります。
Macの場合はOSのアップデート実施時にhttpd.confがリセットされてしまいますし、そうでなくてもマシンが壊れたら開発環境を失う事になります。もちろんバックアップなどがあればデータを失うことはないと思いますが、それでも面倒なことには変わりありません。
上記の問題は手元マシンではなく、リモートにある開発サーバー内で環境を構築することで全て回避することができ、安定的に長期間利用できる環境を確保することができます。
もちろんリモートサーバーもアップデートは行なうのですが、LinuxOSであれば手元マシンと違って破壊的な挙動は殆ど起こらないので安心できます。壊れる可能性もありますが、手元マシンよりは遥かにリスクが小さいはずです。

様々な端末からアクセスが可能

リモートサーバー上に開発環境があることによって、手元のどの端末からも同じ環境へのアクセスが可能となります。
メインの作業は会社のデスクトップマシンからゴリゴリ作業をするにしても、リモート環境で作業するときにはノートパソコンから行い、ちょっとした作業であればiPadから行なう、などと、全ての端末から同一の環境にアクセスをして作業を行うことができます。
これによっていつどんな状況でも仕事ができるという、大変便利な（時には迷惑な）環境を作ることができます。

また、表示確認をiphoneやandroidから行なう必要がある、というように開発環境と確認端末が異なるようなケースでも、確認端末から手元のマシンへアクセスできるようにするのは非常に面倒ですが、これも元々ネット上にあるサーバー内で作業している場合には、いつでもアクセスが可能ですので非常に楽です。

ネットワークへの負荷

リモートワークをしていていると4G回線や貧弱なwifiで作業を行う必要がよくあります。そんな時に巨大な案件のレポジトリをgit cloneしてしまったりすると、時間がかかりますし、4Gならキャリアの通信量を圧迫して通信速度に制限を掛けられてしまうかもしれません。
そんなときもリモートに開発環境があると、Github使うにしてもwgetでデータをダウンロードするにしても、通信は全て開発環境サーバーと各種サービスのサーバー間の通信になるので、通信容量の問題をクリアできます。

最後に

開発環境を自身の手でカスタマイズしていくことで、色々なサーバーに関する知識が体感として得られ、リスク無しで汎用的なスキルを身に着けていくことができます。私自身そうやってサーバーの基本を覚えました。
開発環境をお仕着せのマシンに任せず、リモートに自分の手で構築していく、というのはいい経験になると思いますので、サーバーに関して知識が足りないなーと思っているエンジニアさんこそ、ぜひチャレンジしてみてもらいたいな、と思います

トライアドでは、オンラインコミュニケーションツールとしてSlackを活用しています。
[Slackの公式ページはこちら]
チャットツールはいろいろあるのですが、開発案件も多いのでエンジニアの間で利用率が高く世界的に利用されているツールのため採用しました。
まずは無料のプランを活用してから、有料プランに切り替えることができるので、気軽に利用することができたことも採用した理由の一つです。
Slackはトライアド社内のコミュニケーションを改革してくれました。

メールの往復は時間の無駄

メールで連絡することは一般的だと思いますが、一方通行の連絡事項については有効かもしれません。
ただ、質疑応答の内容になってしまうと、メールでは時間の無駄になります。
受信設定は、利用しているメーラーによって様々ですが、受信間隔は大体15分〜30分というところでしょうか。
長い人だと1時間に1回という方もいると思います。
この状態でメールのやりとりをすると、1回の質問を送信してから戻ってくるのに15分以上かかってしまうことになります。
質問された人は、メールを書いたり調べたりしていればもっと時間がかかり、質問した人は回答をいつごろ返信してもらえるかわからず待ち続けます。
実際に面と向かって質問をすることができれば、回答ができれなければすぐに調べるから待ってほしいことを伝えられるので、質問した人も情況をすぐ把握できます。
メールはいつでも好きな時に開いて、好きな時に送信すれば良いのですが、内容によっては時間をかけることができません。
そこで、チャットを利用すると、リアルタイムに送受信を行え、実際に会話しているのと近い感じで質疑応答ができます。
わからなければ、わからないから少し時間をもらって調べるからことをすぐに伝えられるし、回答が欲しい人も時間がかかることをすぐ把握できます。
こうすれば、メールの無駄な往復がなくなり、時間を有効に活用できます。

強力なアプリの連携機能が魅力

Slackは様々なサービスと連携する機能があります。
[SlackのWorkflowについてはこちら]
チームの管理画面で、連携できるサービスを検索することができて、ボタンを押していくだけで連携ができるようになります。
トライアドでは、gitHub、Trello、Google Driveなどと連携して、それぞれの更新通知をSlackに集約しています。
いろいろなサービスがあって便利ですが、それらを管理していくとなるとあれもこれも開いてとなって結局管理することに疲れてしまいます。
メールで通知を送る機能はサービスによって提供はされていましたが、即時性という意味ではタイムロスが多くあまり使い勝手はよくありませんでした。
どのサービスでどのような動きがあるかを知ることができれば良いので、その通知をSlackで受けて確認できることはタイムロスもなく非常に管理が楽になりました。
それから、サービスによってはSlackから操作できるものもあり、わざわざ別のサイトに行って操作しなければならないことも減らす事ができます。
例えば、トライアドではTrelloを利用して案件を管理していますが、カードをSlackから作成する事ができます。
SlackでTrelloが提供するコマンドを入力すると、連携しているTrelloのボードにカードを追加できます。
Slackで会話している最中に、案件で必要なカードをSlackから作成できると、忘れることもなくすぐに反映できてここでもタイムロスがなくなります。

1対1から1対複数のコミュニケーションへ

メールでも複数人に宛てて送信できますが、内容のやりとりを複数人で行うのは非常に難しいです。
チャットの場合、会話形式で複数人と連絡をとる事が可能になります。
例えば、一人が不明点や理解できないことがあれば、チャンネルにいる複数の相手やリーダーに質問する事ができます。その時に、全員が理解できているかも確かめることができます。
会話の中で相手を特定したい時は、Slackの「＠メンション」機能を活用します。チャンネルのメンバー全員に告知したい場合は「＠channel」のメンションで、個人を特定する場合は「＠ユーザー名」でユーザーを指定して通知を送る事ができます。
誰に向けて話しているかも「＠メンション」を利用することでわかりやすくなるので、複数人での会話中でも誰に向けて何を話しているかがわかりやすくなります。
また、関係者をチャンネルに追加しておけば、細かなやりとりについても把握できるので知らなかったという状態を防ぐ事ができます。
メールでCCに関係者を追加するのを忘れ、1対1のやりとりに気づかず結論までたどり着いてしまって情報が共有できないことがよく起こります。
Slackでこの問題を100％解決できるわけではないですが、チャンネルを観ればやりとりが後からでもわかるようにしておけば、メールでのやりとりよりもずっと把握がしやすいです。

デバイスを選ばない

Slackは、PC、タブレット、スマホの全ての　プラットフォームで利用する事ができます。
インターネットに接続できる環境があれば、いつでもどこでもグループにアクセスする事ができます。
移動や仕事の合間のちょっとした時間に、チャンネルの会話を確認して現状の把握をする事ができます。常に確認していなければならないというよりも、どの端末からもSlackにアクセスできるので、集中したい時と確認するときを簡単にわけられます。
いつでも通知が受けられるといっても、深夜にスマホに通知が来るとどうしても気になってしまいます。通知を受ける時間をチームや個人で設定を変えられるので、何時から何時までは通知を受けないようにすることもできます。
こうすれば、四六時中仕事をしなければならないプレッシャーからも離れられるし、気になれば確認はできるので、自分のスタイルや案件の情況に合わせて運用ができます。

トライアドのチームとチャンネルの使いかた

Slackはチーム単位でURLが発行されます。
このチームの中に、チャンネルと呼ばれる会話を行える場所ができます。
デフォルトでは、「general」と「random」があり、チームを設定はするときに任意の名称のチャンネルを作成できます。
また、チャンネルの種類としては、「public」と「private」の2種類があり、publicは検索の対象になるオープンなチャンネル、「private」は招待しないと参加できないクローズドなチャンネルになります。
トライアドでは、案件ごとにチャンネルをpublicで作成します。
全員が閲覧可能な状態なので実際に関わっていなくても、興味があればチャンネルに参加して進捗を確認する事ができます。
案件以外で会社の経営に関することで、特に全員が閲覧する必要がないチャンネルはprivateで作成しています。
Slackを利用し始めた当初は、1つのチームで全てをカバーしようと考えてしましたが、チャンネルの管理が非常に手間になるので辞めました。
Slackの概念としては、チーム単位でURLが生成されるので、他社とのコラボレーションには、専用のチームを作成すればチャンネルの内容を気にせずにやりとりができるようになります。
トライアドの場合、「企業名（屋号）xtriad.slack.com」という名称でチームを作成しています。
アプリが複数のチームへのログインに対応しているので、連携するチームが増えても切替が簡単なので複数のチームを作るデメリットが感じられません。
社外の関係者とSlackでやりとりができるようになると、メール以外の連絡方法も確立できてコミュニケーションの中心的なツールとして活用できるようになります。

今後の課題

Slackを中心にと活用はしていますが、どうしても全てをSlackに集約するのが難しい現状もあります。
クライアントとのやりとりはメールが主流ですし、ソースコードの管理や書類の管理は他のサービスを利用していたりで、細かな機能を把握して活用する時間と習得する時間が足りないです。
ただ、これからもよりオンラインでのコミュニケーションは、素早く簡潔にできる事が重要になると思うので引き続き活用していきたいと思います。

トライアドでは、1年ほど前からリモートワークを採用しています。
PCとインターネットへアクセスできる環境があれば、いつでもどこでも仕事をすることができるので、思い切ってリモートワークを採用しました。

リモートワークを採用してからほぼ1年たったので、これまでを振り返ってみると、トライアドにとって非常にメリットがあると感じています。
トライアドのメンバーにお金で換算できない部分を時間という形で還元できたり、社内のコミュニケーションが円滑になったり、メンバーのライフスタイルに合わせた作業ができたりと様々なメリットがありました。

時間の使い方を考えるようになる

リモートワークにすると、自分で時間の管理をしなければならないので、以前より効率よく時間を使っているかを考えるようになりました。
リモートワークにするとオフィスに行かなくても良いので、オフィスで同僚と一緒に働く機会が少なくなります。
オフィスにいると時間の管理が会社の営業時間が軸になり、会社が決めた営業時間内にオフィスにいれば良いという意識になってしまいます。 そのため、やらなければいけない仕事が終わっているのに、帰れないのでインターネットをして無駄な時間を過ごしてしまうことも多々あると思います。
リモートワークにすると、基本は営業時間がベースになりますが、1日の作業の時間配分を自分で決め、気分がのらなければ気分転換をしたり作業を早く終わらせれば好きなことに時間を使えます。
すると、決められた時間とそれ以外という形ではなく、作業と勉強ややりたいことを上手に組み合わせて時間配分し、効率よく時間を使えるようになります。
もし、案件で戻しの待ち時間があれば、これまではオフィスで何か別の作業を探すかインターネットで時間を潰すかしていたのが、好きなカフェで休憩したり展覧会に行ったりすることができます。仕事において過程も重要ですが、まずは結果が出ないと意味がありません。上手に気分転換をしながら高いモチベーションで作業をしていれば、後から結果は必ずついてきます。
時間配分をコントロールできるようになれば、案件の管理も役立つので気づいたら実務にも役立っていると思います。

コミュニケーションが円滑か意識するようになる

トライアドは制作業務がメインなので、1日中PCと格闘していて帰るまで一言も発しないことがありました。

こんな状態で問題ないのだろうか。  
制作会社だから普通なのかな。

制作会社だからと言って、朝から晩まで会話がないことが良いとは言えません。
ただ、この環境だと話しかけることが難しくなり、同じ場所にいればいつでも質問できると思っていて、明日聞こう、今度聞こうと、先延ばしにしてしまうこともありました。

ところが、リモートワークにすると、会話が活発になりました。
これまでと違うのが「Slack」を利用したチャットコミュニケーションを導入したことです。社内で決めたチャットコミュニケーションのルールで、相手がどういう状況かは気にせず、とりあえず話しかけて返信を待つということにしました。
このルールであれば、オンラインツールだといつでもどこでも連絡がくるので、すぐに返信しなければならない緊張感を緩和できると思います。チャットにテキストとして残っているので、話しかけられた人は手が空いた時に返信することができます。ルールを決めることで、メンバー間でも意思を統一しておけば問題も起きません。
また、週一回は直接会うMTGの時間を設けています。
案件やメンバーの予定によって集まれない時もありますが、直接会ってリモートワークで感じた問題点について話しています。
スタートして間もないので全てが完璧というわけでもなく、オンラインだけのコミュニケーションの問題点もあるので、すぐに解決できるように直接会う機会もトライアドにはまだ必要でした。
ただ、今後はビデオチャットも積極的に導入して、テキストや音声だけでなく実際に顔を会わせている感じでコミュニケーションをとれるか試していきたいと考えています。

ライフスタイルに合わせて勤務ができる

リモートワークであれば、オフィスに行かないという選択肢もあるので、自分のライフスタイルにあった働き方ができます。
独身で自分の時間を全て好きに使えるようなスタイルから、家庭をもったりすると全ての時間を自分のために使えなくなるスタイルになります。
また、一般的に夜型・朝型と言われるように、仕事の効率があがる時間帯も変わってきます。
実際に私の場合は、朝早く起きて短い時間でも集中して仕事をし、家族と朝食を食べて子供を保育園に送っていき、夕方17：00までにある程度の仕事を終わらせ家族と一緒に夕飯を食べることも可能になります。
子供を寝かしつけた後、だいたい21:00以降は残務があればこなして、なければ自分の趣味の時間や勉強、ジムに行って汗を流したりしています。
毎日がこのタイムスケジュールではなく、多忙な時はもちろん変わってきます。
ただ、自分のタイムスケジュールを作ってから、プロジェクトや業務に照らし合わせてこなしていくかを考えられると、仕事だけに追われてしまう生活にはならないかと思います。
ライフスタイルは人によってそれぞれ異なるので、会社として細かなところで足並みを揃えることが難しいです。そのため、リモートワークにしてそれぞれのライフスタイルに合わせた勤務スタイルにすることが、トライアドでの勤務スタイルと考えています。

リモートワークの課題もある

課題としては、これから新しいメンバーが増えた時に、今と変わらず同じ体制を維持できるようにしなければなりません。
現状では、トライアドは小さい会社なので気心の知れたメンバーだけなので、コミュニケーションという面では問題ありません。
リモートワークだからというわけではなく、毎日顔を会わせても、人数が増えればその分だけコミュニケーションが難しくなります。
また、実際にどのくらいプロジェクトが進行しているかも、常に把握しておかないと実はできていなかったという事態になった時に、クライアントに迷惑をかけてしまいます。
これまでのプロジェクト管理に加えて、リモートワークでの管理のベストを見つけていく必要があります。

解決策として、オンラインツールを上手に利用してコミュニケーションを円滑にし、大事な局面では電話や実際に会う機会を設けたりと柔軟な形でリモートワークを続けられたらと考えています。
今後もリモートワークの取り組みについて、BLOGにまとめていこうと思います。

これまでWebサイトの制作依頼をいただいて、数多くのサイトを構築し納品させていただきました。
クライアントさまに喜んでいただきましたので、トライアドとしても責務を果たし安心していましたが、ある時ふと疑問に思ったことがありました。

そのWebサイトはビジネスに本当に役にたっているのか？

全てのサイトに当てはまるわけではないですが、初期構築やリニューアルよりも運用の重要性を理解すればビジネスに本当に役立つサイト構築ができると思います。　
サイトの種類にもよりますが、Webサイトには完成がなく日々改善を繰り返していくことが非常に大切だと感じています。

サイトの制作フロー

Webサイトを構築するまでの一般的な手順は下記のような流れになると思います。

• 要件のヒアリング
• 要件定義
• サイトの仕様決定
• ワイヤーフレームの制作
• デザイン
• コーディング
• テストアップ
• 公開

上記の各ステップの間に、必ず確認と修正が含まれるので、サイトの要件をヒアリングしてから実際の公開まではかなりの期間がかかります。
一般的なコーポレートサイトで、どんなに早くても2〜3ヶ月ぐらいはかかります。
各ステップで何度も修正が発生すれば、その分だけ公開までも時間がかかってしまいます。

これまでの制作フローの問題点

これまでの制作フローは、大きな問題を抱えていると思います。
理由は、ワイヤーフレームや静止画像のデザインは、実際に作られるものではなく、実際に公開するWebサイトではないものに対して修正をするからです。
最近のWebサイトは、動きがあるものが多く、それらをワイヤーフレームや静止画像で表現するのは非常に難しいです。
そのため、文章で説明したり参考サイトを提示したりしますが、それでは本当に理解をしていただけません。正確な意思疎通ができないので、各ステップごとに説明と修正が繰り返されます。
これでは、いくら時間があっても足りず、どんなに良いアイデアも公開するころには古くなり過去のものになってしまいます。

これまでの制作フローの改善点

制作フローとして、要件定義やワイヤーフレーム、デザインは必要ですが、確認と修正の内容やタイミングを改善する必要があります。
また、初期やリニューアルの公開タイミングで、完璧を求めることをやめるべきです。
これまでの制作フローのように、ワイヤーフレームや静止画像のデザインをみて確認・修正するのではなく、実働するモックアップを作成して確認・修正を繰り返したほうが効率よく公開まで辿り着けます。
実際にブラウザで確認できるモックアップがあれば、ワイヤーフレームや静止画像ではわからなかった動作の部分についても検証することができます。
こうすれば、静止画像のデザインや動きを文章で説明する無駄な確認・修正の時間をなくすことができ、本当に必要な検証の時間に当てることができます。より良いフィードバックを得られることで、よりビジネスに役立つWebサイトを構築できるようになります。

Webサイト運用の重要性

Webサイトはサーバーに置いて公開しておけば良いという時代は終わりました。
ユーザーが、PCでゆっくりネットサーフィンをする事はなくなり、スマートフォンで必要な情報を探します。
Webサイトがカタログとして置いてあれば良いということでなければ、ユーザーにサイトを閲覧してもらうように情報を発信したり、ユーザーがWebサイトに訪問することを妨げることはないかを確認・修正しなければなりません。
Webサイトにどんなユーザーが来て、どんなページを見ているのか、見てほしいページは見られているのかを、常に理解して改善をしないとあっという間に古くなってしまいます。
また、Webサイトの改善は一朝一夕にできることではないので、日々の細かな改善を繰り返すことが重要です。

これまでのように、綺麗なWebサイトであれば見てくれるというのは幻想です。
また、綺麗なだけのWebサイトは、一度見ればそれで満足して終わってしまいます。
変化がなければ、飽きてしまい、二度とWebサイトに訪れる事はないでしょう。
Webサイトの初期構築に多額の費用をかけるのであれば、毎月の運用費用を算出してから初期構築やリニューアルの費用を決定しWebサイトを制作する方が良いかもしれません。
Webサイトに完成はなく、一緒にビジネスに役立つようなWebサイトに育てていく運用が、今後は主流になっていくのではと考えています。