ホーム ブログ ページ 12

「管理系が事業に返せるものっていっぱいある」アピリッツ 取締役 CFO 永山亨 ロングインタビュー

0

「あの役員は誰だ?と思われている人も多いかも」と、2020年4月に入った執行役員 CFOの永山は冗談交じりで言いますが、全社会でおなじみの方が多いはず。入社の経緯と、CFOの役割についてたっぷり語ります! (2020年10月 取材)

永山 亨
取締役 執行役員 CFO
2020年4月入社
20代後半で会社を辞めて1年間バックパッカーの経験あり。旅の目的は自分探しではなく「体力のあるうちにペルーやエジプトを観光したかった」から。
理由はなんでもいい。

IRのTwitterはじめました!

責任者として上場を成し遂げ、「鐘」を鳴らしたい

―― 永山さんは2020年の4月にアピリッツへCFOとして入社されました。ご入社の経緯を教えて頂けますか?

まず、なぜ自分がアピリッツにいるかといいますと、上場準備の責任者として働くためです。当社の社外取締役である喜藤さんとご縁がありまして、ご紹介いただき入社しました。

前々職の求人広告会社で東証マザーズ上場から一部上場までの成長期を経験しました。そちらでなにをやっていたかというと、まずは経理メンバーとして一連の業務経験からキャリアを始め、経営企画として予算策定、IR、資金調達、東証一部への申請業務……つまり会社の数値に係るすべての仕事をやっていました。

その次に入ったスタートアップ企業でも上場申請にトライしていましたが、当時どうしても難儀な課題があり、その課題解決に時間を要することになってまったんです。その会社のことはとても好きでしたが、自身のキャリアを考えると、どうしてもある年齢までに責任者として上場を成し遂げたかった。その際に縁があってアピリッツに声を掛けてもらったんですね。

―― 「責任者として上場する」というのは、どういうことなのでしょう?

数値系の業務を一定経験すると、新しい分野の事にチャレンジするってなかなかなくて、そうなった際に責任者として上場を経験するなんてキャリアはそう多くの人が積めるものではないですし、ほら、上場するときに東京証券取引所で「カーン!」って鐘を鳴らしたり、会社の上場記念パーティーで大きな樽酒とかバコーンと割ってますよね? あれを体感したいんです。前々職では中心として動きましたけど、あれ役員しかやらせてもらえない。「ずるい! 俺が死に物狂いでやったのに」って(笑) 子供みたいですよね。

でもエンジニアさんとかってモノづくりだし、そのサービスが世の中で使われたり、営業の人だったら販売しまくって表彰されたりってスポットライトあたるじゃないですか? でも管理系ってどうしても縁の下の力持ちで、もちろんそれは素敵な事なんですけど、人生で1回くらいスポットライト浴びたいなって。高尚な理由じゃないですよね(笑) でも自分はやりたい。夜遅くまで必死で準備して、審査に臨んで、上場をはたすなら、自分の手であの鐘をカンカン鳴らしたい。

……ということで、自分はここにいます。

ちなみに、今年の4月といえば新型コロナウイルス感染症によって政府から緊急事態宣言がでて、当社も全社リモートワークを実施していた頃でした。なので入社したての頃はオフィスにほとんど人がいない状態で、和田さん(アピリッツ代表取締役社長)や管理部門の一部メンバーとしか顔を合わせてなくて。だから社内では「いつのまにか現れた役員」という印象になっちゃっているかもしれません。

管理系が事業系に返せる「付加価値」は沢山ある

―― CFOの役割はどういうものなのでしょうか。今は「IPOの舵取り役」という印象が強いですが……

そうですね、今は上場準備に注力しているので、何してるんだ?って思いますよね(笑) それと同時にもちろん、決算を締めることや、取引先へ支払いをしたり、資金調達したり、はたまた内部統制やコーポレート・ガバナンスの強化も役割としてありますが、そこは当たり前の話なんです。営業の人が営業すること、エンジニアの人が開発するのと同じ。

もっと重要なのは「会社がしたいこと」を実現するための手助けをする役割です。会社の事業側の人が何かをしたいときに、それを叶えるための「お金、モノ、人」をいかに準備するか。そこを考えて動くのが私達の仕事です。

たとえば、未来のことは誰にもわからないですが、過去はわかりますよね。過去は分析できる。つまり、過去の実績推移、市場関係の情報から当社がどんな状態だったのか?良かった点は何か?悪かった点は何か? ……こういう情報は、意思決定の指針になるんです。そこから未来を見据えて管理系からネタを提供して、事業系の役に立ちたい。

だからこそ、事業のことを一番理解しないといけないのが実は管理部だと思います。

なので、自分は社内との距離が近いCFOでありたいです。みんなのことを理解しないと。管理系から社内のみなさんに「お願い」することも沢山ありますし、お願いごとをする時って距離感が大事ですし。

距離感! (撮影のためにマスクをはずしています)

「あれっ? ケンカにならないぞ?」と思った

―― 入社して半年がすぎましたが、和田社長や社内の印象はいかがでしょう?

CFOや経営企画は、社長に近いところで仕事をするのですが、和田社長は物静かで優しい印象です。でも軸がしっかりあるのは話していて感じました。昔はとがってたんだろうなってわかります(笑) あと途中入社で社長って珍しいなと思います。

会社全体は、実は最初「あれっ? 待てよ、ひょっとして自分は今すごく気を遣われている?」と戸惑いました。上場準備中ってコンプライアンスやガバナンスのために今までやっていなかった事を事業部の方にお願いしないといけない場合が多くて、普通はケンカになるんですよ。忙しいときになんでそんな面倒なことをしなきゃいけないんだ、なんの意味があるんだよ、って。面と向かって「それはお前の仕事だろ。チッ」て言われたり(笑)よく前職や前々職では言い合いしてました(笑)

でもそういった取り組みって「上場するため」ではなく、「パブリックカンパニーとして会社をよくするため」に大切なことですし、それが実は後々「よい会社の土台」になるんですよね。それは前々職や前職ですごく経験しました。売上至上主義だった会社が上場準備をしていく過程で、だんだん働き方や環境整備やいろんな事を整備して、いわゆるホワイト企業になっていった経験をしたので、だからこっちも本気です。

ということで、カオスを覚悟して入社したんですが、蓋を開けてみると皆さんとても協力的。落ち着いてるし、強みと弱みをみんな冷静に捉えているなあって感じます。和田さんも執行役員や部長の方々もみんな優しくて冷静。ちゃんと会話ができるし、人の話を聞いてくれるし、誰もケンカ売ってこない! って思いました。

なんでもいいから「うちの会社で何かをしたい」を意識してほしい

―― アピリッツを成長させていくうえで、どんな人が必要だと思いますか?

いろんな人がいてOKな会社にしたいです。たとえば「定時で帰って合コン行きたい」って人だっているでしょ。いろんな働き方がありますから、そういうひとも会社には必要。

ただ、会社ってひとつの船だから、会社から求められた仕事をするのは大前提で、かつ会社のベクトルに沿ってないなら、それは考えないとですよね。会社がこっちに行きたいっていっているのに、そこには行きませんではバラバラになってしまいますから。もちろんベクトルを合わすために話をすることは必要です。そのベクトルがあっている前提であれば、どんな働く価値観でもよいと思っています。多様性って実は大事です。多様性がないと間違った方向にいった際に気づけないんですよね。

それと目的意識はあったほうが幸せだろうなと思いますね。目的ってなんでもいいんです、高尚な理由じゃなくて。よくキャリア本に書いてあるような「将来を見据えて点と点を繋げて~」なんて出来る人はそうそう居ません。そんなもの出来たら世の中の人みんな立派になってますよ(笑)目の前のことを一生懸命頑張るとか、やってみたいことをチャレンジするとか、それこそ「上場の鐘をカンカン鳴らしたい」とか(笑)それを繰り返した先に、やっていた点が繋がる時が来るんです。それが経験っていうんだと思います。これはジョブズもいってたから間違いないと思いますよ(笑)

ですから、「うちの会社で何かをしたい」を意識してほしいです。その目的を叶えるために、みんなで会社をそれが出来るように良くしていきましょう、って思います。自身のベクトルと会社のベクトルが同じなら、実は多少大変だったとしても目標に向かっている時って人間はつまらない事に捕らわれないです。

日々のささいな事が気になって、終わらない愚痴が続くのって、実は会社がどうこうじゃなく本人にとって不幸なことです。会社や仕事に費やす時間って人生で膨大なんですよね。であれば漠然と過ごすのではなく、目的もったほうがいいに決まってますよ。人生の2/3近くを漠然と過ごすなんてよく考えたら恐ろしい。

もちろん、仕事って楽しいことばかりじゃないですし、大変なことも沢山あります。でもその大変な事の先に達成があるわけで。ホントは「ありがとう」って言われたいけど、まあなかなか言われないですよね。だってその仕事任されてるんだからやるのは当たり前で。特に管理系にいたので、それはすごく体感しました。しかもミスなんてしたら逆にむちゃくちゃ怒られて酷いことをいっぱい言われる(笑) 

まあ後で「見てろよ!」って思ってましたけど。

永山さんが鐘をならすときは沢山写真をとろうと思いました。

ただ、大変だけど、目的のために突き詰めると面白くなったりします。ずっと体育会系でスポーツをしてきたんですけど、勝負事を楽しむには一定のレベルまでいかないと楽しめません。でも大変な中でいまやっていることは何に繋がる?って思うと意外に苦労に感じない。これって何の役にたつんだ?っていう人いますけど、実はそれって当人が決めつけてるだけなんですよね。または気づけてないだけ。無駄な事なんてひとつもなくて面白くするのは自分次第です。

業務でも人間関係も同様ですね。「苦手」や「きらい」を自分は否定しません。それは誰だってありますよ。相手の価値観否定したって何も変わらない。でも苦手な対象との関わり方は自分次第です。自分が折れると損した気持ちになるかもしれませんが、そんな意地を張って仕事がうまくいかないと結局自分にストレスがたまりますし。

そして、自分がやりたいことと、会社がやってほしいことが合致しているかどうか。求職者の方にはその目線で探していただきたいです。

相手がわかる言葉で「規程」を伝える

―― いま会社にいるメンバーに対して求めることは何ですか?

自分の思考を変えて仕事に取り組んでほしいなと思います。固定観念や過去に縛られて「どうせ無理」とか「以前からこうだから」、「ルールだから」や「NGを出されるのが怖い」といったマインドが少しあるかもなと客観的に思います。これは時間をかけてみんなでチャレンジする雰囲気を作っていきたいです。

年齢を重ねて思うのは、今まで自分が見てきた世界や会社なんてほんの一部だってことです。もっと沢山の世界はある。それに世の中も会社も常に変化しています。実際に当社だって上場準備するステージの会社になって、去年やっていなかった事をやってみたり、またやらなきゃいけなかったり。コロナだっていい例ですよね。コロナでいろんな事が変わってきてる。常に変化してる。

実は誰だって「変化」って大変です。めんどくさいことはめんどくさいですし、でも杓子定規に固定観念に捕らわれていてもうまくいかないことが多いです。じゃあそれを超えた先はどうなるんだ?って事をきちんと話をしながらやっていきたいですね。ちゃんと相手がわかる言葉で伝えて、腹落ちしてもらうことが大事です。

たとえば、規程を作って守ることは、実は社員だけじゃなく会社が法律違反しないためや、理路整然に動くためにはらなきゃいけないですけど、同時に、規程に興味を持ってもらわないといけないんです。「ココに、ルールが、書いてありますっ!」って言ったって、読むわけがないんですよ。だってみんな忙しいから。だから、どうしたら守ろうって思ってもらうか作戦や伝え方を考えないといけない。

規程を定めるのが仕事でなく、守ってもらうまでが仕事ですから。だから相手がどんな事を考えているのか?どんな状態なのか?じゃあそのために自分はどのような伝え方をしないといけないか?って考えて、伝えないと。そのためには自分が変化しなきゃですよね。自分の考え方に固執したって伝わらない。

だって考えてみてくださいよ、長く一緒にいる家族や恋人のことだって、なかなか変えられないし、分かり合うには話をたくさんするでしょ? それはみんな薄々気づいてるはずなのに、会社では不思議とやっちゃうんですよね、相手のこと見ないで、一方的に何もしないで「あの人、なんでわかってくれないんだろう?」って。そりゃ相手のことわかろうとしてないし、自分も相手にちゃんと伝えてないのだから実はそうなるのは当然なんですよね。

会社にいるのは、年齢も性別も経歴も育った環境も価値観も仕事もちがう、めちゃくちゃ赤の他人です。何もせずに「わかってくれる」なんてない。わかってもらうためには工夫が大切。そしてそれって実は巡り巡って自分のためになるんですよね。

会社って別に偉い人がどうこうしていくものではないです。みんなで一緒に作っていくものですよね。そしてその中でメンバー1人1人が目的を持てて活き活きしているのが会社も本人も幸せ。同じ会社で出会えたのだから、みんなでもっともっとよい会社にしていきたいです。その為には自分も含めてみんなが固定観念に捕らわれないでチャレンジする、相手の事を考えてコミュニケーションをとっていける環境にしていきたいです。もっとみんなを知りたいので声かけてほしいです。

―― ありがとうございました。最後に締めの一言を……!

「あの鐘を鳴らすのはあなた」(笑)

関連記事:アピリッツのその他の役員インタビュー

雲の呼吸 参ノ型~AWS設計の勘所:マネージドサービス・後編~

0

はじめに

データイノベーション部浅田です。

人気漫画「鬼滅の刃」に仮託して、「雲(クラウド)の呼吸」と題しまして、AWS(Amazon Web Services)を用いたアーキテクチャ設計の勘所を数回にわけて書いていきたいと思います。

なお、AWSに関するサービス名に関しては、この記事内で初出時は正式名称をつけ、以降は明確な場合は省略系を用いる方針で記述しています。

第三回目は「マネージドサービス・後編」です。

続・マネージドサービスの利用

前編で登場したハンニバルが戦った第二次ポエニ戦争(通称ハンニバル戦争)の前半のハイライトは何と言っても「カンナエの戦い」です。空前絶後の大勝利を納めたハンニバルですが、その後の戦況は徐々にローマ優勢に傾いていきます。原因の一つにローマの将軍スキピオ(大スキピオ)がカルタゴ優勢の要の一つであった「ヌミディア騎兵」を自軍に組み込んだということがあります。

「ヌミディア騎兵」は当時地中海世界最強の騎兵と目されていましたが、ハンニバルの騎兵戦術の要でもありました。スキピオはこれを味方に組み入れることで、歩兵戦術主体であったローマ軍に騎兵戦術を行える基盤をあっという間に整えました。そして、後半のハイライト「ザマの戦い」で、スキピオは攻守ところを変えて「カンナエの戦い」を再現、カルタゴ軍に勝利します。

AWSのマネージドサービスは、IT企業においてトップレベルにあると言っても過言ではないAWSの技術の粋が集められています。それらを利用することで、トップレベルの機能を利用することができるようになります。さらに、マネージドサービスを利用することで空いたリソース(手間・時間)を自社の独自の強みの構築に集中することができるようになります。

続・代表的なマネージドサービスとその用途

Amazon CloudWatch

CloudWatchはシステム監視向けのマネージドサービスになります。

CloudWatchは大きくわけると2通りのサービスになっていて、

  • メトリクス(プロセスの数やリソースの使用状況の収集)
  • ログ(アプリケーションのログの収集)

があります。

メトリクス

可視化によって、人間が現在のリソースの状況を把握するのにも使えますし、ある閾値を超えたら、Amazon SNSを経由してメールを送信したり、HTTPのエンドポイントにリクエストを投げたりするなどができます。また、Lambda経由でSlackに通知を行うことも可能です。第一回で出てきたAWS AutoScalingもこれらのメトリクスの値を元に、スケーリングを制御します。

サービスによって様々なデフォルトのメトリクスが提供されますが、CloudWatchエージェントを使用したり、直接送信することで好きなメトリクスを収集することもできます。たとえば、ある特定の機能の使用回数などをアプリケーションからCloudWatchになげることによってCloudWatchで一元管理を行うことができます。

ログ

アプリケーションのログの保存先として使用できます。コスト面ではS3にログを保存するほうが費用対効果は高いですが、検索が可能であったり、特定の文言の出現回数をメトリクスとして可視化できたり(もちろんその結果として通知などもできます)しますし、LambdaやAWS Fargateなどのサーバレスサービスをはじめとして、AWSのいくつものサービスのログの出力さきともなっています。

メトリクス同様、CloudWatachエージェントなどを利用することで、好きなログを収集することが可能です。

Amazon SES

メールによる通知は、会員登録であったり、メールマガジンであったり、はたまた障害通知であったり、ユーザへの連絡手段として昔から一般的に用いられています。

ですが、メール通知を行うためにメールサーバを運用することは、そう簡単な話ではありません。OB25問題に代表されるように、古くからある仕組みのために問題を抱えているので、迷惑メールの温床にならないように注意して運用する必要があります。

そこで、SESを使用することでメールサーバを運用することなく、システムからメールを送信することができるようになります。

AWSではメールサーバを運用して25番ポート(SMTP通信に使用するポート)でメールを外に送る際には、事前申請が必要になりますが、SESを使用することでその問題も回避できます。

SNSでもメール通知を行うことはできますが、SNSは事前にサブスクリプションを行う必要があるので、システム管理者への通知には使えますが、一般ユーザへの通知には向いていません。

Amazon EMR & AWS Glue & Amazon Athena

Hadoop、Spark、 Hive、HBase、Flinkなどの分散処理フレームワークの実行環境のためのマネージドサービスです。ユーザはアプリケーションの処理を作ることに集中できます。

タスクノードにスポットインスタンスを使用するよう設定できるので、コスト面などでメリットを受けられます。同時に、EMRFSを使用することで、処理結果などをS3に保持することができ、処理が必要ないときにはEMRクラスターを削除するなど、柔軟な運用を行うことができるようになります。

また、EMRはインスタンスなどをある程度意識する必要がありますが、分散処理フレームワークの技術をサーバレスにより利用できるサービスもあります。

例えば、GlueはSparkによるETLをサーバレスに実行できるサービスであり、AthenaはPrestoライクに、S3のデータをクエリで検索、加工することができます。

Amazon Kinesis Data Streams & Amazon Kinesis Data Firehose & Amazon Kinesis Data Analytics

大規模データをリアルタイムに処理するためのマネージドサービスがKInesisシリーズです。

ビッグデータの時代と言われるように、スマートフォン、IoTデバイス、各種センサーなどから絶え間なくデータが生成されています。それらを従来のバッチ処理の手法では処理しきれなくなり、常にデータが生成されるなら常に処理し続ける、というのがストリームデータ処理の考え方ですが、そのための基盤として利用できるのがKinesisシリーズになります。

Kinesis Data Streams

その中でもKinesis Data Streamsは、ストリームデータをもっとも柔軟に扱えるサービスになります。

データをストリームに投入するプロデューサーと、ストリームからデータを取得して処理するコンシューマーに分かれて処理を行うので、SQS同様にシステムを疎結合に保てるというメリットもあります。あと、コンシューマーを複数用意することで、一つのデータに対して複数の処理を行えるので、かたやデータ変換し、かたやS3にデータ保存し、みたいなことも可能です。なので、あとから機能追加が行いやすいというメリットにもなります。

Kinesis Data Firehose

リアルタイム性では若干劣るもののS3、Amazon Redshift、Amazon Elasticsearch Serviceへのデータ投入など、投げられたデータを保存する場合には、Kinesis Firehoseが威力を発揮します。Streamsがストリーム領域に応じて一定金額がかかるのに対し、Data FIrehoseは処理されたデータに対しての課金であるのに加えて、コンシューマの処理を実装する必要がありません。また、ビッグデータ処理のデータ形式としてよく使われるParquetやORCといったデータ形式にも対応しているので、ビッグデータ処理のためのデータ収集のサービスとしても優れています。

Kinesis Data Analytics

Kinesis Data Analyticsはストリームに対して、標準SQLでデータを集計、処理することができるサービスになります。Streamsがデータを逐次的に処理するのに対して、Analyticsはストリーム全体(および期間などで絞った一部)に対して、一括でデータ処理を行えるという点がことなります。「まさに今」のデータに対して、集計、可視化したいなどの用途に向いています。

最後に

以上、AWS上で設計を行う際に利用できるマネージドサービスの勘所でした。ここで紹介したのはマネージドサービスのごく一部で、この他にもAWSには便利なマネージドサービスがたくさんあります。それらを有効に活用することで、開発のコストも抑えつつ、スピーディにサービスを提供することができるようになるはずです。

関連:

雲の呼吸 壱ノ型~AWS設計の勘所:コスト編~
雲の呼吸 弐ノ型~AWS設計の勘所:マネージドサービス・前編~
AppiritsのAI研究者が『2020 APN AWS Top Engineers』に選出!資格取得に対する取り組みを紹介!

雲の呼吸 弐ノ型~AWS設計の勘所:マネージドサービス・前編~

0

はじめに

データイノベーション部浅田です。

人気漫画「鬼滅の刃」に仮託して、「雲(クラウド)の呼吸」と題しまして、AWS(Amazon Web Services)を用いたアーキテクチャ設計の勘所を数回にわけて書いていきたいと思います。

なお、AWSに関するサービス名に関しては、この記事内で初出時は正式名称をつけ、以降は明確な場合は省略系を用いる方針で記述しています。

第二回目は「マネージドサービス・前編」です。

マネージドサービスの利用

方法は見つける。なければ作る。(Aut viam inveniam aut faciam)」

古代ローマと戦ったカルタゴの名将ハンニバル・バルカは、当時不可能と言われていたアルプス越えを行って、ローマの度肝を抜きました。上記の言葉は、その際に部下から「アルプス越えが不可能である」と諌められた際に発した言葉とされています。

さすがはハンニバル、他の人間にはできないことをやってのける。そこに痺れますし憧れますが、彼の言葉の裏返しとして「方法がすでに存在するならば、それを利用すればよい」ということでもあります。事実、ハンニバルは地元の人がアルプスを越えている道があることを調査した上で、アルプス越えに挑んでいます。

AWSに限らず、クラウドとオンプレミスとの違いの一つとして数々のマネージドサービスがあげられると思います。実際、AWSが最初に産声をあげたとき(2004年)、提供されたサービスはAmazon Simple Queue Service(SQS)でした。SQSに限らず、現在にいたるまで色々なマネージドサービスが提供されています。AWSを用いてよい設計を行うということは、それらのマネージドサービスをいかにうまくつかうかということでもあります。

なぜマネージドサービスを積極的に利用すべきなのか

マネージドサービスを利用しない場合、同等の機能を自前で構築していくことになります。たとえば、SQSであれば自前でキューイングのシステムを構築するということになります。

確かに自前で構築を行えば、高度の柔軟性を維持しつつ臨機応変に対処することができるかもしれません。ですが、AにはAに向いた話、BにはBにふさわしい任務というものがあるはずで、マネージドサービスと同等に作り込めるような技能が必ずしもあるとは限りません。仮にあったとしても、相応の時間をかける必要があります。

しかも、必要な技能を身につけ、必要な時間をかけて構築したとしても、マネージドサービスより優れている点がなければ、マネージドサービスを利用しているユーザと同じ土俵にやっと立てた、ということにしかなりません。

マネージドサービスを利用することで、人的、あるいは時間的コストを削減し、競争優位を生み出す作業にリソースを集中することができるということが、マネージドサービスを利用する最大のメリットであり、クラウドを使うメリットでもあると言えるでしょう。もちろん、その方が楽でいい、ということもあるでしょう。

そして、多くの場合、コストも安く済む

AWSのマネージドサービスを利用することは、多くの場合コストを抑えることにも繋がってきます。それは、多くのマネージドサービスがサーバレスで提供されているからでもあります。第一回目のコスト編で述べたように、サーバレスの利用はコスト削減を図れる可能性が高くなります。

Amazon RDSや、Amazon ElastiCacheのように、起動時間で課金されるようなタイプのものは、Amazon EC2で作り込んだよりも運用費用が高く見えるマネージドサービスもありますが、冗長性を担保し、障害時に自動でフェイルオーバを行うように構築する手間や時間にかけるコストと費用とを天秤にかければ、結果的には安くなるケースが多いでしょう。

代表的なマネージドサービスとその用途

さて、前置きが長くなりましたが、AWSの設計を行う上で、代表的なマネージドサービスとその用途について、概観していこうと思います。

Elastic Load Balancing

ロードバランシングをおこなってくれるサービスです。デフォルトで冗長化されていますし、負荷に応じて自動でスケーリングしてくれます。

その名の通りアプリケーションの負荷を分散し、サービスの障害性を高めるというロードバランサー本来の機能に加えて、以下のようなメリットもあります。

  • AWS Certificate Managerとの連携によりSSL終端処理を行うことで、HTTPSでのサービス提供を容易にする
    • 無料でSSL証明書を取得できる
    • HTTP/2に対応しているので、サーバ側で何もしなくてもHTTP/2のメリットを享受できる。
    • HTTP to HTTPSなどのリダイレクトもリスナールールで提供できる(ALB)。
  • パスベース(L7)でのルーティングに対応(ALB)
  • 固定IPでのロードバランシングを提供(NLB)
  • AWS WAF & Shieldによるセキュリティ対策
  • AWS Lambdaの実行
  • スティッキーセッションによるセッション維持

なども利用できます。

冗長性を担保することをベストプラクティスとするAWS設計において、EC2を使用する環境においては、マストなサービスといえるでしょう。

ただし、スケーリングに関しては、スパイクアクセスに対応できない場合があるので、事前の暖気申請を行うなど対応が必要なケースもあるのは注意が必要です(NLB以外)。

Amazon S3

AWSにおけるストレージソリューションの第一候補にあがるといっても過言ではないS3は、代表的なマネージドサービスといっていいでしょう。

S3のマネージドサービスの利点としては、

  • 無制限の保存容量
  • 耐障害性(複数の箇所にデータをレプリケーション
  • データのバックアップとしてのレプリケーション
    • 同じリージョンへのレプリケーション海外リージョンへのクロスリージョンレプリケーションも設定可能
  • バージョニングによるデータの保護
  • ライフサイクルポリシーによるオブジェクトの自動削除
  • バケットポリシーによるクロスアカウントの利用

などを簡単に利用できてしまいます。

また、データレイクとして、数々のAWSサービスと連携する起点になっています。

Amazon RDS & Amazon ElastiCache

RDSやElastiCacheはよく使われるマネージドサービスでしょう。

RDSはMySQL、MariaDB、PostgreSQL、SQLServer、OracleといったRDBMSのマネージドサービスであり、RDBMSを利用するケース非常に多いでしょう。

ElastiCacheはRedisや、MemcachedのNoSQLのマネージドサービスになります。セッション情報や、キャッシュなど、レイテンシの低さを利用した用途や、あらかじめ構造化できないデータを保存するなどのように向いているので、これもよく使われるかと思います。

これらのマネージドサービスを使うと、

  • 可用性を考慮したMultiAZの構成および、フェイルオーバ
  • 定期的なバックアップによるデータ保全
  • 暗号化によるデータ保護
  • リードレプリカ 追加による読み取り能力のスケーリング

などをオプション一つで実現できます。

Amazon SQS

SQSはメッセージキューイングサービスのマネージドサービスになります。メッセージキューを使うことで、システムを疎結合にすることができます

例えば、あるシステムAからシステムBに処理を依頼するときに、直接AからBのAPIを実行してしまうと、BはAがどれぐらいAPI実行を依頼してくるかを想定して、リソースを確保したり、処理途中で失敗した場合などにエラーハンドリングをどうするかをA側も気にしなくてはいけなくなります。

ですが、間にキューを挟むことによって、B側のリソースの都合に応じて依頼(キュー)を処理することができるようになります。エラー時も再度キューを処理しなおすなどB側だけでコントロールが効くようになります。A側もキューに入れることだけを考えればいいので、Bのリソースや実装に依存しなくて済むようになります。

このようなメッセージキュを利用するにあたって、自動スケーリングによる拡張性と低コストの運用を行えるのがSQSになります。

同じメッセージが1度以上(つまり複数回もありえる)、メッセージの順序を保証しないなどの特徴がありますが、FIFO(First In First Out)というメッセージが重複せず、順序も保証してくれるタイプも出ています。

——————————

マネージドサービスはAWSの要でもありますので、一気に紹介すると多くなってしまうので、この辺で前編を終了したいと思います。
<= To Be Continued…

関連:

雲の呼吸 壱ノ型~AWS設計の勘所:コスト編~
AppiritsのAI研究者が『2020 APN AWS Top Engineers』に選出!資格取得に対する取り組みを紹介!

ロジカルシンキング~ピラミッドストラクチャーを使ってみる~

0

はじめに

業務システムやゲームアプリなど、何かしらのシステムを作るときは色々な話し合いをします。
仕様の調整や工数の見積もりなどエンジニアが説明や交渉を行う機会は意外と多いです。
また、設計段階での気付きから改善の提案を行う事もよくあると思います。

久しぶりにクライアントとの仕様調整会議などに出席する機会があり、「うまく説明が理解してもらえないな」と思う事がありました。
伝えたい事が伝わらない時は、だいたい伝える側に問題があるものだと思います。

数年前に受講したロジカルシンキングの研修を思い出し、ピラミッドストラクチャーについて再勉強したのでご紹介します。

ピラミッドストラクチャーとは?

ピラミッドストラクチャーはコンサルタントの育成や報告・文章能力の向上を目的に元マッキンゼーのバーバラ・ミント氏によって体系化されました。
論理的に提案や報告をする基本スキルとして世界中の企業や大学などに採用されています。

結論が論理的に妥当である事を説明するには、それを証明する複数の根拠が必要になってきます。
これを図にするとピラミッドの構造になるため「ピラミッドストラクチャー」と呼ばれています。
結論や仮説の妥当性を証明したり、他人への説明や説得に活用することができます。

うまく伝えられるようになりたいという目的があるので、今回は複数あるロジカルシンキング手法の中からこちらを再勉強することにしました。

ピラミッドストラクチャーのメリット

ピラミッドストラクチャーを活用するメリットとしては下記のようなものがあげられます。

  • 論理の妥当性が確認しやすい
    • 論理構成を図にすることにより、妥当性が確認しやすくなる
    • 論理が甘いと感じれば結論を見直し、再構築する事で精度が上がる
  • 主張に説得力がでる
    • その結論に至った理由を明確に説明できるようになる事で主張に説得力がでる
    • 頂点にある結論に常に立ち返る事ができるため、論点がずれたり、的外れな主張にならない
  • ロジカルな説明がしやすい
    • ピラミッドを頂点の結論から順に説明していく事でロジカルな説明をする事ができる
  • 会議がスムーズに進む、結論が出る

クライアントとの会議で上手く伝えられなかった提案を実際に当てはめて考えてみると、私の話には根拠が少なく具体例が欠けていると分かりました。

ピラミッドストラクチャーを使ってみる

実際にピラミッドストラクチャーを作成してみたいと思います。
エンジニアっぽく、今回は「クラウドで構築するか?」と言う題材にしてみます。

①結論を決める

まずはピラミッドの頂点にあたる結論を決めます。
曖昧な問いや結論になっていないか注意します。

下記のように決定しました。
 問:クラウドで構築するか?
 結論:クラウドで構築する

②設定した結論を補強するための根拠を挙げる

伝えたい相手が重視しそうな点を「根拠」として書き出していきます。
これは3つくらいが適当なのだそうです。
多すぎると話が長くなり、余計にわかりにくくなるからです。

③根拠を裏付けるデータや事実を3段目に追加する

根拠に対して事実と付き合わせ妥当性を検証していきます。
「たとえば〜」とはなせるような実例を2〜3つほど挙げていきます。

④全体的に整合性を確認する

ロジカルシンキングの基礎である「Why So?(なぜ?)」「So What?(つまり?)」の関係が成立しているかを確認していきます。
下に向かって「Why So?(なぜ?)」が成立しているか?
上に向かって「So What?(つまり?)」が成立しているか?
矛盾のない論理になっているかを確認します。

⑤実際に報告や説明をする

設定した結論に対する根拠が明確になりました。
このピラミッドに沿って説明する事で分かりやすく伝える事ができます。
ただし、説明する相手によって最終的に色々な配慮は必要になってきます。

  • リテラシーレベルを把握し、レベルにあった話し方をする
  • 専門用語はわかりやすい言葉に置き換える
  • ピラミッドの上から説明するか下から説明するか効果的な方を選ぶ

まとめ

ピラミッドストラクチャーを作成するのは意外と難しかったです。
つまり、相手にうまく伝えるということがそれだけ難しいことなんだなと実感しました。
事前の練習が欠かせないと書かれている解説も多く、実際にそうだと思います。

直近の案件で、実際にピラミッドを作って提案をしてみました。
いつもよりスムーズな説明になり、その案は無事採用していただくこともできました。

職種に関わらず、説明や説得・提案を行う機会は多々あると思います。
上手く伝えられないと思ったら、ピラミッドストラクチャーで思考を整理する練習をしてみてください。

(参考)
https://studyhacker.net/pyramid-structure
https://www.missiondrivenbrand.jp/entry/thinking_pyramidstructure
https://jobrouting.jp/257/

KUSANAGI環境でSSL(Let’s Encrypt)が自動更新されなくてspiritsがプライバシーエラーになってしまった件について

0

2020年10月14日、9時42分頃から12時頃まで、SSLの期限切れによって当サイトが『プライバシーエラー』という閲覧しづらい状態になっておりました。本件の原因調査と対応をOSDN室の青井室長に依頼し、無事解消いたしました。お騒がせしました。「せっかくだからこの話を記事にして共有しましょうよ!」とアピリッツの社内からも声があがりましたので、青井さんが今回の原因と、それをどうやって解決したかについて即まとめてくれました。(アピスピ編集部 白石)

本件の発生時刻は本日(2020年10月14日)、午前9時42分から11時43分で、後述しますがKUSANAGI移設作業の90日後にあたります。

この事象はKUSANAGIを利用されている方すべてに起こり得る内容であり、またWordPress・KUSANAGIの構成に限らずLet’s EncryptによるSSL証明書を利用している方のお役にたてるかもと思い記事公開するものです。

まず、原因はLet’s Encryptが「自動更新されていなかった」ことによるSSLの期限切れ。
「手動更新による解決」を実施の上、改めて「自動更新を設定」した事で同じ理由での再発は防げるかと思います。

原因:「自動更新されていなかった」は本当か?

元々spiritsはAWSの弊社開発環境の片隅を間借りして細々と動かしていましたが、「元気玉作戦に向けて管理画面のレスポンスを高速化しないと書いてくれる人に無用なストレスを与えてしまう」との理由で高速化する事になりました。

高速化の手法はEC2から『超高速CMS実行環境 KUSANAGI』への移設に決まり、7月の中頃にその移設作業を行いました。

移行作業時のチェックに『自動更新の設定』がなされているかを確認したはずなのにおかしいな……。
さっそくコンソールに入って確認しました。

[root@ip-XX-XX-XX-XX log]# crontab -l
#* * * * * /root/.kusanagi/provision-check.sh > /dev/null 2>&1
07 03 * * 0 /usr/bin/kusanagi update cert

やはり自動更新の設定はしてありました。

自動更新設定してあるはずが……

では、cron自体が実行されていないのでしょうか。確認してみます。

[root@ip-XX-XX-XX-XX log]# less /var/log/cron
Oct 11 03:01:01 ip-172-31-43-185 run-parts(/etc/cron.hourly)[8069]: starting 0anacron
Oct 11 03:01:01 ip-172-31-43-185 run-parts(/etc/cron.hourly)[8078]: finished 0anacron
Oct 11 03:07:01 ip-172-31-43-185 CROND[8422]: (root) CMD (/usr/bin/kusanagi update cert)
Oct 11 03:10:01 ip-172-31-43-185 CROND[8789]: (root) CMD (/usr/lib64/sa/sa1 1 1)
Oct 11 03:20:01 ip-172-31-43-185 CROND[9303]: (root) CMD (/usr/lib64/sa/sa1 1 1)

cronは動いている……。

OKOK、ワカッテキタヨー! kusanagi update cert で調べたらいっぱいエラー報告出るモンネ!

[root@ip-XX-XX-XX-XX log]# /usr/bin/kusanagi update cert
完了しました。

ん?何事もなく通った。

更新されたSSLを見て絶望する自分

アイエエエエ!? クロン!? クロンナンデ!?

という事で調査でわかったのは「自動更新は設定されていたが、失敗し続けていた。しかも手動実行では成功した」という事実でした。

手動で実行して通るものが、2ヶ月あまり失敗しつづけた原因とは……。

困った時はやっぱりアピリッツ

そうだ、困った時はアピリッツに頼んでみよう!ということでWebシステム開発部隊に相談してみることに。

すると、数分でトップエンジニアの浅田さんなど、数人のエンジニアから様々な救いの手が!

一瞬で返ってくる的確なアドバイス

cronのログ、rootへのメール、letsencryptのログそれぞれを一緒にチェック。

ログから次々と読み解かれる情報

という訳で cron の設定を変更することにしました。

[root@ip-XX-XX-XX-XX log]# crontab -l
#* * * * * /root/.kusanagi/provision-check.sh > /dev/null 2>&1
07 03 * * 0 /bin/bash -lc "/usr/bin/kusanagi update cert"

総括

というわけで、総括です。

  • KUSANAGIを(特にAWS上)利用している皆様。cronでPATHが読めていない恐れがありますので、crontabを見なおしてください。
  • KUSANAGI側の修正を祈ります(後ほど報告予定)
  • 困った時はアピリッツ!

以上!ご迷惑おかけしました。

蛇足

浅田さんの今回の名言です。

オススメの記事です。是非読んで浅田さんのチャーミングさを感じてください。

脆弱性診断ツール OWASP ZAP について

0
Owasp ZAP

エンパワーメントサービス部所属セキュリティエンジニアの綾城です。
今回は、オープンソースの脆弱性診断ツール OWASP ZAPについて極々簡単に紹介していこうと思います。

はじめに

OWASP ZAPは、使い方によっては攻撃とみなされますので、取り扱いには十分に注意してください。

OWASP とは

“OWASP – Open Web Application Security Project とは、Webをはじめとするソフトウェアのセキュリティ環境の現状、またセキュアなソフトウェア開発を促進する技術・プロセスに関する情報共有と普及啓発を目的としたプロフェッショナルの集まる、オープンソース・ソフトウェアコミュニティです。The OWASP Foundationは、NPO団体として全世界のOWASPの活動を支えています。” OWASP Japanウェブサイトより

OWASP Japan
https://owasp.org/www-chapter-japan/

OWASPというのは団体なんです、そしてOWASP Flagship Projectsというのがありまして、OWASPが特に力を入れているプロジェクト群です。日本でも有名なものがいつくかあると思います。ASVSやTop 10、チートシートシリーズなどがあります。
(なので、OWASP ZAPやその他プロジェクトなどを、OWASPって略さないでほしいですね。)

ボランティアで成り立っているので、スポンサーや会員になって支援することができます。
人気のイベントに優先的に入場できたり、メールアドレスがもらえたり特典もありますよ。
https://owasp.org/membership/

OWASP ZAP とは

正式名称は、OWASP Zed Attack Proxyです。ザップと読んだりしてます。
フリーでオープンソースのウェブアプリケーション脆弱性スキャナーです。
Javaアプリケーションなので、Windowsでも、macOSでも問題なく動作します。
クライアントとサーバ間の通信を、アプリケーションレベルで確認することのできる、ローカルプロキシとして動作します。

ローカルプロキシは、Fiddler EverywhereBurp SuiteCharlesmitmproxyPacketProxy などがあります。
それぞれ一長一短があるので、用途や目的、プラットフォームなどによって選ぶとよいでしょう。
ちなみに、アピリッツのウェブアプリケーション脆弱性診断では、Burp Suiteがメインで使われています。

OWASP ZAPは、IPAの文書にも登場したことがあります。
IPAテクニカルウォッチ 「ウェブサイトにおける脆弱性検査手法(ウェブアプリケーション検査編)」
https://www.ipa.go.jp/security/technicalwatch/20160928-2.html

OWASP ZAP のインストール

OWASP ZAPは、Javaアプリケーションです。現在は、JREが付属していないので、別途導入しましょう。
インストール時や、アドオン導入時など、ウィルス対策ソフトが反応することがあるので、あらかじめ対処しておきましょう。

無料Javaのダウンロード
https://java.com/ja/download/

OWASP Zed Attack Proxy
https://www.zaproxy.org/

少しわかりにくいところにあるのですが、メニューの[ヘルプ] [アップデートのチェック]、[マーケットプレイス]タブから、各種アドオンを投入することができます。release、beta、alphaの表記で、そのアドオンの完成度合いを知ることができます。目的や好みで入れてみてください。

下記の画面は、導入済みになってますが、マーケットプレイスのタブを選択し、そこから必要なもの導入してください。

インストール自体は普通のアプリケーションとあまり変わりません。体系的に学ぶ 安全なWebアプリケーションの作り方Webセキュリティ担当者のための脆弱性診断スタートガイド などの書籍でもOWASP ZAPのインストールに触れていますので、わからない場合は参考にした方がよいでしょう。

OWASP ZAP の簡単な使い方

自動診断

一応、紹介はしますけれど、推奨はしません。プロテクトモードにして、スコープを定めないと、この機能自体を使えないように指導している方もいます。気軽に始められる分、デフォルトの診断範囲、クローリングやスキャンの速度、スキャンの強度で診断を始めてしまいますし、自動のため意図しない診断になる場合もあり、事故が起こる危険性があるため推奨していないわけです。なので自己責任でお願いしますね。例えば、ローカルに立てた自分のウェブアプリケーションなどに対して、お試しでやってみる程度にしてください。下部のアラートタブの中に、誤検知を含め検出した脆弱性が表示されているかと思います。

即クローリングが始まり診断が開始されるので注意してください。

手動診断

本格的に脆弱性診断やるためには、ブラウザを複数プロファイルに分け、それぞれのブラウザにローカルプロキシの証明書をインポート、プロキシ切替用のアドオンを導入します、FirefoxならFoxyProxy Standard、chromeならSwitchyOmegaなどが有名です。

今回は、HUDを切ります。(私が使い方に慣れていないだけ)HUDのボタンをオフにして、隣のFirefoxアイコンを押すと、各種設定済みのブラウザが立ち上がります。

そのブラウザに診断対象のURLを入力すると、下部、履歴に通信の状態を見ることができます。これに対して、再送を設定などしてパラメータを改変などして送信しなおしたり。手動診断を始めることができます。(今回は詳しく触れられなくてすいません。)

OWASP ZAP 多彩な使用方法の紹介

私は主に脆弱性診断にしか使わないのですが、OWASP ZAPは、APIを使用することができます。Jenkinsと連携してCIツールとしても利用することができます。(Official OWASP Zed Attack Proxy Jenkins Plugin)また、OWASP ZAP Docker版もありますので、組み合わせで多彩なことが可能になります。

弊社内の方で、こんな使い方してみたよとか、こんな使い方をした実績がありますとかあれば、社内Slackの #security でお知らせいただくと、いいナレッジにもなりますし、私が喜びます。

また、初心者から高度な使い方まで、脆弱性診断研究会の脆弱性診断ええんやでというOWASP ZAPの勉強会が定期的に開催されています。(新型コロナウィルスの影響で中断中)和気あいあいとした雰囲気で参加しやすいですが、多少緩いところがあるので、複数回参加してみるとよいかと思います。

OWASP ZAP の日本語訳

私は、微力ながらOWASP ZAPのローカライズ作業に参加してます。
https://www.zaproxy.org/docs/desktop/credits/#zap-localization

本体の方も修正を入れようかと思ったのですが少し難しかったです。
起動時やぱっと見でわかるメニュー類などちまちまと日本語化していきました。
現在は、スキャン結果など長めの英文がまだ残ってるので、協力してくださる方を待ってます。

おわりに

アピリッツでは、セキュリティに興味があり脆弱性診断をやってみたいセキュリティエンジニアを募集しています。興味ある方は、下記の採用情報からセキュリティエンジニアの職務内容・応募資格を確認してみてください。またコミュニティ活動やOSS活動に積極的な方、オープンソースを活用して開発をしてみたいWebエンジニアを歓迎します。下記ボタンからぜひ確認ください。

アピリッツの「社内公募制度」、実際に挑戦した人に話を聞いてみました

0

アピリッツには「社内公募制度」という人事制度があります。アピリッツに所属する社員にむけて、アピリッツの各部署が人材募集の情報を開示し、社員自らの意思でこれらに応募する制度です。”社内転職”とも呼ばれるこの制度を利用して新しいキャリアを築いている2名の方に、今回匿名でお話を伺いました。(2020年 9月取材)

「やってみたい」「環境を変えたい」 勇気を出して応募

ーー 「社内公募制度」に応募したキッカケを教えてください。

Aさん:自分が「やりたい」と思う仕事が募集されているのを見つけて、そこでまず社内公募制度に興味をもちました。もともとゲーム系の仕事に興味があって、そちらを志望していたんです。でも当時はゲームではない開発の仕事に携わっていました。そして当時の上司との定期的な個別面談のときに、思い切って「ゲーム開発に挑戦したい」と相談しました。

私が応募した職種は「上司の許可」は不要だったのですが、とても迷っていたので、思い切って相談したんです。とても親身に相談に乗ってくださいました。今でも感謝しています。

求められるスキルに自分があっているか、どういう仕事の進め方になるのか、仕事の詳細……そういった不安を上司に聞いてもらって、気持ちの整理をつけて応募しました。

ーー 勇気を出して「社内公募制度」に応募されたのですね。Bさんはいかがでしたか?

Bさん:私の場合は、公募のリストのなかに自分が携わったことのある業務があったので、応募することにしました。実はそのとき転職も視野に入れていたんです。当時携わっていた仕事と自分は、マッチしていないのではとかなり悩んでいたので……。

そういうときは、仕事へのモチベーションやコンディションにも影響が出ます。だから、今のままで自分はいいのだろうかと考えていました。

社内公募制度に挑戦しようと決めたときはもちろん緊張しました。でも「ダメでもともと。採用されたらラッキーくらいに考えよう」と言い聞かせて、気負わず応募できたと思います。用意されている応募フォームに申し込むだけで始まりますし。

とはいえ、自分の状況や環境を変えるチャンスでしたし、その後の選考フローは全力で臨みました。

社内にいながら転職の面接

ーー 面接はどのような雰囲気ですすみましたか?

Aさん:面接は、応募した部署の部長や役員が担当します。社内の知っている方々との面接なので、とても和やかな雰囲気で進みました。こちらの意図をくみとり、真摯に話をきいてくれるので、改めて「安心できる職場だな」と感じました。

Bさん:私の場合も同じです。査定面談よりもうんとフランクですね。

見知った方々との面接なので、緊張しすぎず、自分の思いや熱意をよりダイレクトに伝えることができたと思います。だから「あなたのスキルなら、この職種もいいかも。興味はある?」と逆に提案をいただいたり……。私のキャリアを一緒に考えてくれているなと感じました。

ーー 人事とのやりとりもスムーズでしたか?

Aさん:はい。「次のステップはこういうものです」と説明していただいたので、不安を感じずに面接を受けることができました。

Bさん:サクサクと次に進むイメージでした。応募そのものも、フォームに記入してクリックひとつで始まりますし、すべてがスムーズでした。

ーー 転職活動との違いはなにでしょう?

Aさん:正式な履歴書は不要ですし、転職活動の準備よりはるかにラクだったと思います。選考にあたって、自分のスキルを説明する資料を作りました。

Bさん:私の場合は課題提出がありました。今までの仕事の経験も活かせる内容でしたし、「いつかやりたい」と思っていたことだったので力が入りました。

転職活動と違って移動時間も必要ありませんし、社内の会議室に行くだけです。心身の負担はだいぶ違いますし、そのぶん選考に全力をかけることができました。

転職の一歩手前、今の半歩先の挑戦

ーー 新しいお仕事はいかがですか?

Aさん:仕事に対する姿勢は少し変わったと思います。自分で選んで、自分で勇気を出して飛び込んだ世界なので、モチベーション高く働けています。

じつは、ちょっと転職を考えていたので、よいタイミングで挑戦できたなと考えています。

こういった機会が用意されているのは、自分のキャリアデザインの選択肢が増えるということです。だから良い制度だなと思いますし、最初はかなり迷いましたが、自分の意志を自分の人生に反映させることができてよかったです。

Bさん:前向きに穏やかに仕事に集中できています。守秘義務がかなりしっかりしているので、周囲にも「社内公募制度を利用して異動した」ことはわからないですし。

それに、社内公募制度で採用となっても、会社が変わるわけではないので、大きな手続きもありません。なんならPCの設定もそのままです。ですから、人生の大きなイベント感は少ないです。なめらかに環境を変える感じです。

もちろん選考はありますし、簡単にパスできるものでもないようです。応募までにいろいろ悩むこともあります。でも、転職で見知らぬ人に自分をアピールするよりも、自分の良さを知ってくれている会社に改めて自分をアピールできるのは、会社だけじゃなく自分にとってもメリットが大きいと思います。

もしまわりに自身のキャリアや仕事について悩んでいる同僚がいたら、転職の一歩手前の選択肢として、現状から半歩先の挑戦として、社内公募制度への挑戦を考えてほしいです。

サイト内検索のコレジャナイ候補”すし”と”ロースしょうが焼き”問題に迫る

0

サイト内検索ASP AdvantageSearch(以下、AS)のテクニカルサポートを担当している高橋です。全文検索で起こりやすい問題とその対策について、ECサイト内検索を例に記載します。

まず、多くのECサイト内の検索では商品名や商品説明などのテキストに対しては部分一致でヒットするようになっているかと思います。特に、弊社サービスのASでは、検索キーワードの入力が中途半端な状態でもフレーズが一致していればヒットするようになっています。

例えば「おいしいロースしょうが焼き」という商品名に対して「おいしいロース」「ロースしょう」とかで検索してもヒットします。これにより検索ユーザーが欲しい商品を途中までしか覚えていなくても、入力が面倒になっても、検索結果から漏れずヒットしやすいようにしてなっています。

すし・ロースしょうが焼き問題

一見普通の仕様ではありますが、懸念点もあり、「すし」で検索しても「おいしいロー”スし”ょうが焼き」がヒットしてしまいます。それだけでは問題にはならないのですが、悪い場合、検索結果一覧が寿司商品ではなくロースしょうが焼きで埋もれてしまう可能性があります。本来寿司商品が一覧に表示されてほしいのに、もしロースしょうが焼き商品が先に表示されてしまうと、使いにくい検索となってしまいます。

このようにキーワードの中に別の意味のキーワードが含まれていると、両方のキーワードがヒットしてしまい、検索結果が荒れてしまう原因となります。特に日本語は英語みたいに単語ごとに文章が分かれていないので、意図しない結果が起きやすいです。この問題の対策として、キーワードを分解してつながりをなくすことで関連度を調整する方法があります。

関連度

関連度とは、検索キーワードとヒットした商品がどのくらい関連しているかを表す指標です。この関連度が高いと検索結果の上位に表示されるようになります。関連度を上げる方法は様々ありますが、その1つとして検索キーワードを含むテキストの量を増やす方法があります。

単純な例ですが、「すし」というテキストが1つしか含まれていない商品と、9つ含まれている商品では、9つ含まれている商品の方が関連度が高くなりやすいです。(もちろん様々な観点から評価されますので必ずしも上がるわけではございません。)

キーワードを分解し関連度を調整することで対策

この計算方法を利用し、「ロースしょうが焼き」を「ロース」と「しょうが焼き」に分解して「すし」に一致しないテキストを作成します。一方「寿司」はこれ以上分解できないため「すし」のままとなり「すし」で一致するテキストが作成されます。これらの関連度を並び順に反映すると、検索結果の上位に寿司商品、下位にロースしょうが焼き商品が表示されやすくなり、使いやすい検索となります。

ASではこれらの”テキストデータの分解・抽出を自動で行う”機能(キーワード抽出機能)が備わっており、簡単に検索結果の改善を行うことができます。

パン・フライパン問題

キーワードを分解することで「すし」「ロースしょうが焼き」問題は解決できましたが、「パン」「フライパン」問題は解決できておりません。「フライパン」はこれ以上分解することができない単語なので「フライパン」のまま抽出されてしまい「パン」でヒットし関連度が上がってしまうためです。この場合は「キーワード抽出機能」と「完全一致型」を使用すれば対策可能です。

キーワード抽出機能+完全一致型による対策

先に完全一致型とは、登録されたキーワードと検索キーワードが完全に一致しないとヒットとならない型です。例えば「フライパン」が登録されている場合「パン」などで検索しても一致しません。「フライパン」と検索した時のみヒットし、関連度が上がります。

これを利用してキーワード抽出機能と組み合わせることで、パン商品には「パン」、フライパン商品には「フライパン」というテキストを完全一致型で作成し、「パン」で検索しても”フライパン”の関連度は上がらず、”パン”商品のみ関連度を上げることができます。

宣伝

最後に宣伝となりますが、このようにサイト内検索は問題点は目に付きやすいですが改善には様々な技術や対応が必要となります。改善コストの軽減の一つとして、AdvantageSearchをご検討いただければ幸いです。

ANGEL Dojo Season2 アピリッツチーム 成果発表

0

前書き

デジタルビジネス部所属の渡邊と申します。

私は2020年6月12日より、AWS 主催のエンジニア向けイベント ”ANGEL Dojo Season2″ にアピリッツチームとして参加しており、2020年9月4日に最終発表を行いました。そこで発表をした、私たちが企画から開発までを行ったサービスについてを、本記事で紹介します。

ANGEL Dojo についての詳しい概要は、過去の記事を参照ください。

関連:出てこい!AWSネイティブ世代 ~若手エンジニアがAmazon Web Services 主催 ANGEL Dojoに参戦!~

関連:新卒も参加中! AWS主催 “ANGEL Dojo Season2” 若手エンジニアインタビュー

関連:AWS主催イベント“ANGEL Dojo Season2” 最終成果発表会 レポート


会社に入りたての頃、困ったときに誰かに相談できましたか?

皆さんは会社に入ったばかりの時に、困ったことがあった場合に気軽に誰かに相談できる環境があったでしょうか?

例えばエンジニアであれば、プログラムでエラーが発生し自分では解決できなさそうだけど、いつも相談している先輩が忙しそうで聞きづらい。また、会社のルールについてわからないときに誰に聞けばよいのかがわからず無駄な時間を過ごしてしまう、なんて経験したことのある方々も多いのではないかと思います。

弊社では社内コミュニケーションツールとして Slack を利用しています。仕事中にわからないことが出てきた場合は、社員全員が参加しているチャンネルや部署のチャンネルで相談を投げれば解決するのかもしれません。

でも、発言とともに自分の名前が出ると思うと「こんなこともわからないの?」と思われてしまうのでは…と身構えてしまったり、個人的な内容を全体チャットに投げてみんなに通知が行ってしまい迷惑になるのではないか、と不安となってしまったりなど、入りたての頃は正直恥ずかしくて気後れしてしまいますよね(勿論、そんなこと無いって方もいるかもしれませんが)。

また、相談する側だけでなく回答する側にとっても、多くの人が見える中で間違った情報を伝えてしまうと恥をかくリスクがあったり、発言するハードルは低くはないはずです。

このように、相談する側と回答する側のお互いがチャットでの発言を遠慮をしてしまった結果失われる時間は非常にもったいないと私たちは考え、課題と捉えました。

そこで、私たちはこのようなサービスを考案しました。

こまっち 【困っている社員と相談できる社員をマッチング!】

名前を明かさずに相談を投げ、相談に乗ってくれる人が居たらマッチングするというSlackbot、その名もこまっちです。

こまっちを使えば、困っている人は気軽に相談を投げることができるし、誰に聞けば良いかわからないような内容でもこまっちが相談相手を探してくれます。また、相談を受ける人も1対1での会話になるので人目を気にせずアドバイスをすることができます。

また、今まで話したことのない社員同士がつながるきっかけとなる可能性も生まれます。

それでは、こまっちの仕組みを説明していきます。

マッチングするまでの流れ

まず、困っている人はこまっちに相談を投稿します。

すると、こまっちは投稿された文章から特徴的なキーワードを解析・抽出し、それを元に答えられそうなユーザを数人探します。その後こまっちは探し出したユーザに対し、相談投稿者の名を明かさずに相談内容のみを送ります

相談内容が送られたユーザーは、相談に乗ることができる場合はOKを、そうでなければNGを選択できます。

OKを選択したユーザーは、こまっちによって投稿者とマッチングし、相談投稿者に対して Slack アカウント情報が伝えられます(この時点ではまだ相談投稿者の名は明かされません)。

あとは相談投稿者から DM でやりとりしたり、直接会って相談するなどアクションを起こし、自由に連絡をとることが可能です!

実際の見た目はこのような感じです。こまっちのAppを追加し、こまっちのホーム画面を開くと「相談相手を探す」ボタンが表示されるので、押して出てくるフォームに相談の概要を書いて投稿します。

アーキテクチャ紹介

ANGEL Dojo は AWS 主催のイベントということで、Slack 以外の部分は全て AWS のサービスによってこまっちを作り上げました。

こだわったポイントは、保守運用を簡単にするためにフルサーバレスな構成としたところです。今回、サーバーレスなアプリケーションの構築のために、AWS サーバーレスアプリケーションモデル、通称 SAM ( Serverless Application Model )を用いて開発しました。

相談が投稿されてからマッチングするまでの処理ごとにどのような動きになるのかを具体的に見ていきます。

1) Slack で相談が投稿される → 他のユーザーへ相談内容を通知する

Slack で相談が投稿されると、 Amazon API Gateway からリクエスト受付AWS Lambda が起動します。

リクエスト受付AWS Lambda は、リクエスト情報から次に実行する AWS Lambda の振り分けを行いますが、リクエストが相談投稿の場合は、相談投稿を処理するための、内容解析相談登録相談相手取得通知、の4つの AWS Lambda 群を管理する AWS Step Functions が実行されます。

1つ目の内容解析 AWS Lambda では、 Amazon Comprehend を用いて投稿された内容からキーワード抽出を行います。

例えば「EC2について教えて下さい。」といった相談投稿がされたとします。すると、「EC2」のようなキーワードを抽出し、2つ目の相談登録AWS Lambda に、抽出したキーワードを渡します。

この相談登録AWS Lambda では、渡されたキーワードや相談概要、また相談投稿者の情報を、まとめて Amazon DynamoDB に登録します。

相談登録の処理が終わると、3つ目の相談相手取得AWS Lambda が呼ばれて、キーワードをもとに通知を送るユーザーを5人ランダムに選び、4つ目の通知AWS Lambda に情報を渡します。

最後にこの通知AWS Lambda で、選ばれたユーザーに対してこまっちから Slack のメッセージを送信します。

2) マッチングが成立する

選ばれたユーザーに対して送られる Slack のメッセージには「OK」と「NG」のボタンが表示されていて、「OK」を押すと、リクエスト受付AWS Lambda からOKした人を通知する AWS Lambda が起動します。

この AWS Lambda では、「OK」を押したユーザーの情報を相談投稿者に対して、こまっちから Slack のメッセージを送信します。

3) 相談が解決する

相談投稿者に対して送られる、「OK」を押したユーザーの情報のメッセージには、「解決」ボタンも含まれています。相談投稿者が解決したと判断した場合にはこの「解決」ボタンを押してもらいます。すると、リクエスト受付AWS Lambda から解決処理AWS Lambda が呼ばれ、相談が誰によって解決されたのか、また、解決したユーザーに、最初に相談概要から抽出されたキーワードを紐付け、 Amazon DynamoDB に登録します。

つまり、相談が解決されればされるほど、解決した人がどんな分野に長けているかの特徴付けがされていくという仕組みです。

その他) Slack ワークスペースのユーザー情報の取得

相談概要を他のユーザーへ通知するために、前提として Slack ワークスペースの全ユーザー情報を Amazon DynamoDB に登録しておく必要があります。そのため、 Amazon EventBridge を用いて、ユーザー登録AWS Lambda を1日に1回実行させ、 Slack から取得できるユーザー情報をもとに Amazon DynamoDB へ登録をしています。


後書き ~ ANGEL Dojo で学んだこと ~

ANGEL Dojo が始まる前は、様々な AWS のサービスに触れることが主な目的と捉えていました。しかし本当は、 AWS という会社がどのようにサービスを生み出しているかのノウハウを吸収させてもらえる場ということがわかりました。実際に私たちのワークショップは、具体的に実在しそうな人物象を設定し(ペルソナ設定)、その人がどんな課題を抱えていてその課題を解決するにはどんなものが必要か、という設計から始まりました。これは今までやったことない経験であり、ほかチームよりも難航してスケジュールが遅れるほど苦労しましたが、「ただ要件通りにシステムを作るプログラマー」ではなく、「今、どのようなシステムが求められていて、そのシステムを当初の要求から逸れずに完成させる」、という流れに触れた経験は非常に大きかったと、私は思います。

また、もちろん技術的な面でも得られるものは大きかったです。私はこれまでの業務の中で AWS に触れる機会はあったものの、アプリケーションサーバーとマネージドデータベースとクラウドファイルストレージの構成といったものの経験しか無く、今回サーバレスなアプリケーションに挑戦したことにより、サービス構築時のインフラストラクチャーの選択肢を広げることができたと思います。

この場で恐縮ですが、 ANGEL Dojo を主催してくださった AWS の方々、また、 ANGEL Dojo に参加できるように手配してくださった社内の方々にお礼を申し上げます。

現時点でまだまだこまっちは完成したとは言えない状態です。例えば、最初相談を投げてから誰も相談相手が見つからなかった場合の考慮や、よくされる相談はデータとして蓄積しナレッジツールとしても使えるようにしたいなど、課題が残っています。ただ、こちらに関しては、 ANGEL Dojo は終了したもののチームメンバーは引き続き完成させることを目標に動くことが決まりました。また、ゆくゆくはチームメンバー以外で有志を募り、実際に運用していくことを目指しています。続報があれば本ブログにてお伝えしていければと思います。

最後に、 ANGEL Dojo の最終発表時のプレゼンテーションファイルを添付して本記事は以上とさせていただきます。

最後までご覧いただきありがとうございました!

アピリッツ_ANGEL_Dojo_2nd_最終発表

Kali Linux 使い方 書籍紹介

0
Kali Linux 使い方

エンパワーメントサービス部所属セキュリティエンジニアの綾城です。
Kali Linuxは初期セットアップが完了すると、膨大なツールが用意されているためできることが多数あり、その後どうやって使っていけばよいか初心者などは迷いがちです。高額なセキュリティの講習会などで時間をかけて教えていたりもしますが、今回は、Kali Linuxの使い方を日本語で学べる書籍をいくつか紹介いたします。英語が問題ない方は、複数の書籍やサイトがありますので、そちらを参考にしてください。

各書籍の初期セットアップは、書籍の内容が多少古い場合もありますので、Kali Linux 2020.3 導入と日本語化を参考にしてください。

はじめに

Kali Linuxは、セキュリティ診断ツールを含むLinuxディストリビューションです。利用の仕方により不正アクセス行為と判断される可能性があります。書籍の注意書き等をよく読んで、不正に使用しないようにしましょう。

書籍紹介

ハッキング・ラボのつくりかた

Kali Linuxの使い方を習得するにはまず、安全な環境の構築が大事です。下でも紹介してますが、ハッカーの学校や暗号技術のすべてなど、セキュリティ関連書籍を多数出してる著者IPUSIRON氏の書籍です。正直、これ一冊でいいのではないかという程の濃い内容の書籍です。前から順に沿って読み進めながら実行していくと、仮想環境内に攻撃実験ができる環境が出来上がります。分量が多いので挫折しがちですが完走できたら相当力がついていることでしょう。また、『ハッキング・ラボのつくりかた 仮想環境におけるハッカー体験学習』サポートサイト FAQなど、サポートにも尽力されており、そのナレッジは大変助かります。私は物理本と電子版両方買いました。会社の本棚にもあります。これは、ぜひ入手してください!

https://www.amazon.co.jp/dp/4798155306/

サイバーセキュリティテスト完全ガイド

この書籍は、サブタイトルにKali Linuxと入っているので、見つけやすいと思います。Kali Linuxを使った解説になってます。洋書を翻訳したものですが、THE HACKER PLAYBOOK 2になっているのは、翻訳されていない第1弾があるからです。どうやらアメフトの試合を模した流れで説明されているのですが、正直そのあたりのネタがよくわかりません。ラボのセットアップ、ネットワークのスキャンから始まり、侵入、権限の奪取などを行い、最後にレポートを書いて、その後の学習を続けていくところまでが記載されています。第4章のスロー 手動によるWebアプリケーションのテストが、Webアプリケーションの脆弱性診断の参考になります。

https://www.amazon.co.jp/dp/4839959552/

サイバーセキュリティ レッドチーム実践ガイド

上記のサイバーセキュリティテスト完全ガイドの続編です。より実践的な内容で難易度が上がってます、より高度な、Kali Linuxの使い方を知ることができます。新しい内容が反映されている部分もありますが、前作から読んだ方がよいと感じます。こちらも前作同様、一連の作業の流れに沿った解説になってます。

https://www.amazon.co.jp/dp/4839967571/

ハッカーの学校

もう一冊、IPUSIRON氏の書籍です。Kali Linuxを導入する内容や、そのツールを使用しますが、ネットワークのハッキングのみの清い内容です。データハウスの本は分厚いのですが、電子書籍が出ていないので、持ち運びに難があります。

https://www.amazon.co.jp/dp/4781701973/

サイバー攻撃の教科書

セキュ塾で講師もされている中村行宏氏の書籍です。他のハッカーの教科書とはなんだか少し雰囲気が違う気がする書籍です。Kali Linuxを使いながら幅広い内容をとてもやさしく説明してます。

https://www.amazon.co.jp/dp/4781702384/

Hacker Japan 2013年 07月号

以前出版されていたハッカージャパンです。古いですが、Kali Linuxのツールの紹介を簡単な使い方がメインなのでそれほど問題にならないです。入手しにくいかもしれませんが、この時期のハッカージャパンはDVDに前号のPDFが入っているので、次の刊でも電子版を読むことができます。

https://www.amazon.co.jp/dp/B00CRLRDN2/

ハッキングの達人

上記、ハッカージャパンが入手しにくいので、こちらは今でも簡単にkindleで入手できるのでお勧めです。ただし、Kali Linuxの前身のBack Trackについてですので、ツール解説メインで読みましょう。内容の半分ぐらいが、ツール類の簡単な紹介になってます。Nmapの割と詳しい解説、Webサイト攻略の達人として、Burp SuiteやMetasploitなどを使った脆弱性診断のようなものの解説やSQLインジェクションのチートシート、そしてちょっとした漫画付きのパスワードクラックの解説などの内容になってます。

https://www.amazon.co.jp/dp/B00J7JKW4Y/

続・ハッキングの達人

上記の続編、こちらもBack Trackベースの書籍ですが、kindleで入手できます。こちらは無線LAN、デジタルフォレンジック、WiresharkとWindowsのツール類について、詳しく書かれてます。またNmap、Metasploitの解説もあります。この記事を書くために読み返していたら、セキュリティ業界の技術職紹介インタビューが5名分掲載されており、辻伸弘氏のインタビューなどなかなか興味深いものも。

https://www.amazon.co.jp/dp/B00J7JKW3K/

さいごに

Kali Linuxの使い方は、洋書が読めるともう少し選択の余地が生まれそうです。日本語の書籍は貴重なので、入手して内容をしっかり身につけたいところです。
弊社アピリッツでは書籍購入制度があり、このような書籍も要望を出すことによって購入してもらえます。ぜひ私たちと一緒に高度なセキュリティ技術を身につけてサービスに生かしませんか?
アピリッツでは、セキュリティエンジニアを募集しております。興味ある方は、下記の採用情報からセキュリティエンジニアの職務内容・応募資格を確認してみてください。もちろん、Webエンジニアも募集中です。下記ボタンからぜひ確認ください。

Ruby on RailsエンジニアがGraphQLを使うと簡単に最強のWebAPIを作れる話。(デモもあるよ!)

0

API、好きですか?!

データイノベーション部 AI-labo所属の吉岡です。
私は今入社3年目で、入社当初からRuby on Railsを使っていました。
入社2年目から配属してるプロジェクトでは、Rails + GraphQLでバックエンド開発をしております。
過去に自分は趣味で色んなWebAPIを触ってきましたが、GraphQLはすごく画期的です。
Railsに慣れたエンジニアがWebAPIを開発しようと思ったとき、GraphQLを使うとこういう利点があるよ!というのを伝えたいと思います。

こういう人に読んでもらいたい!

主に以下に当てはまる人は、より楽しめる記事になっているかと思います!

  • Ruby on Railsのフロント・バックエンドの開発をした経験があり、controllerやmodelの概念がある程度わかっている人
  • Web APIやREST APIについてある程度どんなものかわかっている人
  • バックエンドをAPIにして、フロントエンドをReactやVueなどを使ってスマホアプリを作ってみたい人

GraphQLについて

GraphQLとは、Facebook社が開発したAPI向けのクエリ言語です。
……といっても私自身が言葉的にそんなに深く理解しているわけではないので、実際何ができるかを中心に説明して行きたいと思います。

例えばこういうことができる

以下のようなカラム構成のテーブルがあると想定します。
users テーブル

  • id
  • name
  • created_at
  • updated_at

articles テーブル

  • id
  • user_id
  • body
  • created_at
  • updated_at

comments テーブル

  • id
  • article_id
  • user_id
  • text
  • created_at
  • updated_at

もし、あるページであるuserのname、そのユーザに紐づいたarticlesのbodyとcreated_at、さらにそのarcitlesに紐づいたcommentsのtextを取るページがあったとき、どのようにAPIを実装・取得しますか?

この条件で取得できるようなAPIを、例えばRESTで実装するとき、いくつか懸念点が出てくると思います。

  • users、articles、commentsを取る時にそれぞれリクエストを投げるか?
  • 1回のリクエストをするとして、そのためのエンドポイントを新たに作らなければいけないのか?
  • articlesやcommentsの全カラムを取得するAPIはあるが、使わないカラムのデータも受け取らなければいけないのか?
  • もしこのページで他のデータが必要になったときに、どう対応するか?

Railsでフロント込みの開発に慣れていると「N+1にならないようにしなきゃ……」くらいの懸念点になるかと思います。
しかしフロントエンドを別物として開発する場合、フロント側にはmodelという概念はないため、APIにする場合は上記のようなことも重要になってきます。

そんなとき、GraphQLは以下のようなqueryを書けば1発で解決できちゃうんです。

query {
  user(id: 1){
    articles{
      body
      createdAt
      comments{
        text
      }
    }
  }
}

「えっそんな簡単にできるの?」「実際どう投げるのか教えてもらわないとよくわかんない」「queryって何?」っていう人の為に、もう少し詳細に説明したいと思います!

どう使うの?

APIを使う上で最初に知りたいのってやはりエンドポイントですよね。
GraphQLのエンドポイントは、以下のようになります。

〇〇.com/graphql

「え?これだけ?これで情報どうやって取るの?」って思うかもしれません。
実は、やってる内容的にはGETなのですが、GraphQLの場合は全部POST形式で投げています。
1つのエンドポイントは固定で、リクエストbodyに上記のqueryを入れてPOSTで投げます。
リクエストに含まれるqueryをrails側で解釈し、queryに指定されている内容をレスポンスするという形です。

メリット

ここまで軽くGraphQLについて説明してきましたが、上のことを踏まえると以下のようなメリットが見えてきます。

  • エンドポイントが1つで済む。
  • 欲しい情報だけを取得することができる。
  • テーブル構成が複雑な場合でも1回のリクエストで様々な情報を取りきることができる。

中でもエンドポイントが1つで済むのは一番の利点だと思っていて、バックエンド側から返す情報が変更もしくは新しく増えたときでも、フロントエンドではGraphQLのqueryの記述を変更すれば良いだけになります。

ローカル環境・本番環境での確認に役立つツールがあって便利!

GraphQLには、ローカル環境での確認に便利な GraphiQL という機能があります。
これはローカルでサーバを立ち上げ、 localhost:3000/graphiql/ にアクセスすると、queryを試せるという機能になっています。(urlは初期設定で、変更もできます。)

また、chromeの拡張機能に Altair GraphQL Client というものがあります。
こちらはGraphiQLと同じ機能を本番環境等で実際に試すことができます。
また、Altairではリクエストヘッダの設定もできますので、ヘッダの情報が必要な場合にも対応できます!

RailsでGraphQLを動かしてみる!!

GraphQLが便利なことはわかった……けど、実装が難しかったら使いたくないですよね。
Railsに触れてたユーザがGraphQLを使用するのに必要なことは以下の4つです。

  • gemが追加できること
  • controllerを作成して、ルーティングできること
  • modelが作れること
  • hashが書けること

はい、これだけでできます。
Rails チュートリアルで学習する内容さえあれば完ペキにAPIを作ることができます。

1. まずは環境構築する

どのような形でも良いので、まずはRailsのアプリケーションを立ち上げます。
gemさえ入れれば既存のRailsプロジェクトでも動きますので、とりあえず立ち上げについては省略します。
rails s が動作する状態にしてから以下の手順を実行してみてください。

Railsのアプリケーションのディレクトリに入り、Gemfileに以下を追加します。

gem 'graphql'          # <- 追加
group :development do
  gem 'graphiql-rails'  # <- developmentのgroup内に追加
end

インストールを実行します。

bundle install
bundle exec rails g graphql:install

そうすると以下が追加されているかと思います

app/graphql
├── {アプリケーション名}_schema.rb
├── mutations
└── types
    ├── mutation_type.rb
    └── query_type.rb

また、config/rountes.rb に以下のような記述が追加されているかと思います

  if Rails.env.development?
    mount GraphiQL::Rails::Engine, at: "/graphiql", graphql_path: "/graphql"
  end
  post "/graphql", to: "graphql#execute"

これでGraphQLを使う準備が出来ました!
試しにrails sを立ち上げ、 http://localhost:3000/graphiql を立ち上げると先ほどのGraphiQLの画面が出てくるかと思いますので、以下のqueryを記述して実行してみてください。

{
  testField
}

以下のようなレスポンスが返ってきたら成功です!

{
  "data": {
    "testField": "Hello World!"
  }
}

エラー注意!

rails・graphqlのバージョンによっては app/assets/config/manifest.js を以下のように修正する必要があります。
もし Sprockets::Rails::Helper::AssetNotPrecompiled in GraphiQL::Rails::Editors#show のようなエラーが出たら修正してみてください。

//= link graphiql/rails/application.css
//= link graphiql/rails/application.js

2. queryの構造についての説明

早速queryを書いていきますが、先にqueryについての説明をします。
queryは基本以下の構造になります。

query queryの名前 {
  fieldName1
  fieldName2(arg: argument)
  fieldName3 {
    fieldName3-1
    fieldName3-2
  }
}
  • query: queryかmutationを指定します。
  • query: 情報を取得するためのもの
  • mutation: 情報を更新するためのもの(本稿では説明しません)
  • queryの名前: queryを書く人(フロント開発者など)が分かりやすくするためにつけるもの
  • fieldName: 何の情報を取るかを指定する(階層構造にできる)
  • arg: 引数指定ができます。

注意!

以下でrailsから定義していきますが、rubyファイルでの定義はスネークケース、queryの記述ではローワーキャメルケース(先頭だけ小文字のキャメルケース)で書きます!
ごっちゃにならないように注意してください!

筆者もよくqueryをスネークケースで書いてエラーに苦しんだりしてます。
エラーが出たら、まずは書き方を疑ってみてください。

3. とりあえず何かを返すqueryを作る

とりあえずGraphQLを導入したので、まずは簡単なqueryを作成してみたいと思います。
以下のような情報を返したいとします。

query todayInfo {
  currentDate       # 今日の日付
  todayWeather {    # 今日の天気
    weather            # 天気
    temperature        # 温度
  }
}

先ほど作成された app/graphql/types/query_type.rb に以下の行を追加します。

module Types
  class QueryType < Types::BaseObject
    ### (省略) ###

    ##### ここから追加
    field :current_date, String, null: false, description: '今日の日付'
    def current_date
      Date.today.strftime("%Y年 %m月 %d日")
    end

    field :today_weather, WeatherType, null: false, description: '今日の天気'
    def today_weather
      { weather: '晴れ', temperature: 60 }
    end
    ##### ここまで追加
  end
end

そして、 app/graphql/types/weather_type.rb を作成し、以下のコードを書いてください(丸コピで大丈夫です!)

module Types
  class WeatherType < Types::BaseObject
    field :weather, String, null: false, description: '天気'
    def weather
      object[:weather]
    end

    field :temperature, Int, null: false, description: '温度'
    def temperature
      object[:temperature]
    end
  end
end

上記のコードの解説です!
まず以下の1行でfieldの定義をします。

field :query名, 型, null: nullを許可するか, description: 'クエリの説明'

そして、query名と同じ名前で定義されたメソッドを リゾルバ(resolver) といい、このメソッド内の内容を実際にqueryで返します。

def query名
  返す値を記述
end

つまり、current_dateは以下のように解釈されます

  • field名はcurrent_date(GraphQL上では currentDate )
  • String型
  • nullは許可していない
  • 返ってくる値は Date.today.strftime("%Y年 %m月 %d日") になる

続いて、todayWeatherの解説です。
最初の方でも述べましたが、GraphQLは階層構造で返すことができます。
これを実現するためには、fieldの中にfieldがあって……という構造にする必要があります。
先ほど、型はStringで指定していましたが、自分で作った型を指定することもできます。
以下の1行ではWeatherTypeを指定しています。

field :today_weather, WeatherType, null: false, description: '今日の天気'

WeatherTypeは weather, temperature という2つのfieldがありますので、 todayWeather のfieldでは weather, temperature という情報を取ることができます。

また、作った型を指定したときは、リゾルバの内容が型に渡されます

field :today_weather, WeatherType, null: false, description: '今日の天気'
def today_weather
  { weather: '晴れ', temperature: 60 } # <- この値がWeatherTypeに渡される
end

渡されたリゾルバの内容は、 object という変数に入っています。

field :weather, String, null: false, description: '天気'
def weather
  object[:weather] # <- objectの中身は { weather: '晴れ', temperature: 60 }
end

この状態でrails sでサーバを立ち上げてGraphiQL( http://localhost:3000/graphiql )にアクセスします。
左側に以下の記述をして、画面上部の実行ボタン(右向き三角のボタン)を押してください。

query todayInfo {
  currentDate       # 今日の日付
  todayWeather {    # 今日の天気
    weather            # 天気
    temperature        # 温度
  }
}

そうすると以下のようなレスポンスが返ってきます。

{
  "data": {
    "currentDate": "2020年 09月 30日",
    "todayWeather": {
      "weather": "晴れ",
      "temperature": 60
    }
  }
}

これがGraphQLの基礎になります。

余裕があったら!

today_weatherのリゾルバ内の記述を変えてみてください!

def today_weather
  { weather: '雨', temperature: 10 } # <- この値がWeatherTypeに渡される
end

レスポンスが以下のように変わるはずです!

{
  "data": {
    "currentDate": "2020年 09月 30日",
    "todayWeather": {
      "weather": "雨",
      "temperature": 10
    }
  }
}

4. 引数と複数件の情報

情報を取るのに配列や引数が必要になってきます。
以下のようなqueryを想定しましょう

query monthInfo{
  month(monthNum: 1) { # 月の情報(月指定で1件)
    name                  # 英名
    days                  # 日数
  }
  months {             # 月の情報(全件)
    name                  # 英名
    days                  # 日数
  }
}

こちらのqueryは、現在日と月の英名およびその月の日数を返す想定です。

先ほど作成された app/graphql/types/query_type.rb に以下の行を追加します。

module Types
  class QueryType < Types::BaseObject
    ### (省略) ###

    ##### ここから追加
    field :month, MonthType, null: false, description: '月の情報(月を指定して1件)' do
      argument :month_num, Int, '月の数字', required: true
    end
    def month(month_num:)
      month_hash_array[month_num - 1]
    end

    field :months, [MonthType], null: :false, description: '月の情報(全件)'
    def months
      month_hash_array
    end

    # 返すためのデータ
    def month_hash_array
      [
        { name: 'January',   days: 31 },
        { name: 'February',  days: 28 },
        { name: 'March',     days: 31 },
        { name: 'April',     days: 30 },
        { name: 'May',       days: 31 },
        { name: 'June',      days: 30 },
        { name: 'July',      days: 31 },
        { name: 'August',    days: 31 },
        { name: 'September', days: 30 },
        { name: 'October',   days: 31 },
        { name: 'November',  days: 30 },
        { name: 'December',  days: 31 }
      ]
    end
    ##### ここまで追加
  end
end

そして、 app/graphql/types/month_type.rb を作成し、以下のコードを書いてください(こちらも丸コピで大丈夫です!)

module Types
  class MonthType < Types::BaseObject
    field :name, String, null: false, description: '英名'
    def name
      object[:name]
    end

    field :days, Int, null: false, description: '日数'
    def days
      object[:days]
    end
  end
end

引数の付け方

まずは引数の付け方の解説です。
fieldに augument を定義します。(ブロック内で指定しています。)

field :month, MonthType, null: false, description: '月の情報(月を指定して1件)' do
  argument :month_num, Int, '月の数字', required: false
end

引数の指定については以下のようになっています。
Stringを指定すれば文字列にできますし、引数用の型を定義すれば複雑な引数指定もできます。(本稿では省略します。)

argument :引数名, 型, '説明', required: 必須にするか

続いてリゾルバについてです。
引数を指定したfieldについてはキーワード引数としてリゾルバを定義すれば、引数の内容が取得できます。
(※ 1月と指定した場合、1月の情報はmonth_hash_array[0]にあるので、 month_num - 1 になっています。)

def month(month_num:)
  month_hash_array[month_num - 1]
end

配列を返す

続いて配列の返し方です。
複数件のレスポンスになるfieldは、以下のように型指定時に [] で囲むだけで、配列として返すことができます。

field :months, [MonthType], null: :false, description: '月の情報(全件)'
def months
  month_hash_array
end

上記の例だと、 { name: '月名', days:日数} の塊が、いくつもある形のレスポンスができます。
また、全ての型を配列化ができます
例 )

  • [‘いぬ’, ‘ねこ’, ‘アルパカ’] -> 型を [String] で指定する。
  • [10, 23, 37] -> 型を [Int] で指定
  • [{ weather: ‘晴れ’, temperature: 40 }, { weather: ‘雨’, temperature: 10 }] -> 型を [WeatherType] で指定( WeatherTypeについては前項を参照 )

実行してみる!

先ほどと同様にrails sでサーバを立ち上げてGraphiQL( http://localhost:3000/graphiql )にアクセスします。
左側に以下の記述をして、画面上部の実行ボタン(右向き三角のボタン)を押してください。

query monthInfo{
  month(monthNum: 1) { # 月の情報(月指定で1件)
    name                  # 英名
    days                  # 日数
  }
  months {             # 月の情報(全件)
    name                  # 英名
    days                  # 日数
  }
}

以下のようなレスポンスが返ってくると思います。

{
  "data": {
    "month": {
      "name": "January",
      "days": 31
    },
    "months": [
      {
        "name": "January",
        "days": 31
      },
      {
        "name": "February",
        "days": 28
      },
      {
        "name": "March",
        "days": 31
      },
      {
        "name": "April",
        "days": 30
      },
      {
        "name": "May",
        "days": 31
      },
      {
        "name": "June",
        "days": 30
      },
      {
        "name": "July",
        "days": 31
      },
      {
        "name": "August",
        "days": 31
      },
      {
        "name": "September",
        "days": 30
      },
      {
        "name": "October",
        "days": 31
      },
      {
        "name": "November",
        "days": 30
      },
      {
        "name": "December",
        "days": 31
      }
    ]
  }
}

これでqueryはバッチリですね!

余裕があったら

引数を変えてみてください!
情報が変わります!

query monthInfo{
  month(monthNum: 5) { # <- 変えてみる
    name
    days
  }
  months {
    name
    days
  }
}

6. モデルの内容を返すqueryを書く

※ 本稿ではモデルについての詳細な説明は省略します。modelやデータは自分で作ってみてください!

例えば、以下のようなモデルがあったとします。
Userモデル(id以外はstring)

  • id
  • last_name
  • first_name
  • profile
  • created_at
  • updated_at

そして以下のようなqueryを作りたいとします。

query {
  user(id: 1) { # Userモデルのデータ1件取得
    full_name     # last_name と first_nameを半角スペースで繋げたもの
    profile       # profileのデータをそのまま
    created_at    # created_atの年月日までの情報
  }
  users {       # Userモデルのデータを全部取得
    full_name     # last_name と first_nameを半角スペースで繋げたもの
    profile       # profileのデータをそのまま
    created_at    # created_atの年月日までの情報
  }
}

その場合、以下のようにTypeを定義します。
app/graphql/types/query_type.rb に以下を記述します。

module Types
  class QueryType
    ### (省略) ###

    ##### ここから追加
    field :user, UserType, null: false, description: 'ユーザ情報(id指定で1件)' do
      argument :id, Int, 'ユーザid', required: true
    end
    def user(id:)
      User.find_by(id: id)
    end

    field :users, [UserType], null: false, description: 'ユーザ情報(全件)'
    def users
      User.all
    end
    ##### ここまで追加
  end
end

app/graphql/types/user_type.rb に以下を記述します。

module Types
  class UserType
    field :full_name, String, null: false, description: '姓名'
    def full_name
      object.last_name + ' ' + object.first_name
    end

    field :created_at, String, null: false, description: '作成日時'
    def created_at
      object.created_at.strftime("%Y年 %m月 %d日")
    end

    field :profile, String, null: false, description: 'プロフィール'
    def profile
      object.profile
    end
  end
end

解説!

先ほどはhashで指定しましたが、リゾルバから型に送るもの(object)はhashでもインスタンスでもActiveRecord::Relationでもいけます!
以下の2つのリゾルバを見てください。
このように指定すれば、1件の方には User.find_by(id: id) したレコードを、全件の方には User.all のRelationを入れることができます。

field :user, UserType    ### 省略 ###
def user(id:)
  User.find_by(id: id)
end

field :users, [UserType] ### 省略 ###
def users
  User.all
end

Userインスタンスについても、objectに入ります。
なので以下のリゾルバではobjectの中にはUserのインスタンスが入っています。

field :full_name, String, null: false, description: '姓名'
def full_name
  object.last_name + ' ' + object.first_name
end

実行してみよう!

以下のqueryを実行してみましょう!
成功したら、成功です!(細かいレスポンスは省略します)

query {
  user(id: 1) { # Userモデルのデータ1件取得
    full_name     # last_name と first_nameを半角スペースで繋げたもの
    profile       # profileのデータをそのまま
    created_at    # created_atの年月日までの情報
  }
  users {       # Userモデルのデータを全部取得
    full_name     # last_name と first_nameを半角スペースで繋げたもの
    profile       # profileのデータをそのまま
    created_at    # created_atの年月日までの情報
  }
}

7. 便利な術!

GraphQLの記述を書くのに当たって便利な技を紹介します。

処理しなくて良いものはリゾルバが不要!

例えば先ほどのWeatherTypeをご覧ください。

module Types
  class WeatherType < Types::BaseObject
    field :weather, String, null: false, description: '天気'
    def weather
      object[:weather]
    end

    field :temperature, Int, null: false, description: '温度'
    def temperature
      object[:temperature]
    end
  end
end

weatherのfieldでは object[:weather] を返していますが、hashまたはインスタンスで何も成形が不要なときはリゾルバの定義が不要になります。

なので、WeatherTypeは以下のように書き換えることができます。

module Types
  class WeatherType < Types::BaseObject
    field :weather, String, null: false, description: '天気'
    field :temperature, Int, null: false, description: '温度'
  end
end

スッキリしていいですね!

UserTypeいついても同様です!

module Types
  class UserType
    field :full_name, String, null: false, description: '姓名'
    ## 成形しているため、省略不可能
    def full_name
      object.last_name + ' ' + object.first_name
    end

    field :profile, String, null: false, description: 'プロフィール'
    ## 成形していないため、省略可能
    def profile
      object.profile
    end
  end
end

profileは何も成形していないので、以下のように書き換えることができます。

module Types
  class UserType
    field :full_name, String, null: false, description: '姓名'
    ## 成形しているため、省略不可能
    def full_name
      object.last_name + ' ' + object.first_name
    end

    field :profile, String, null: false, description: 'プロフィール'
  end
end

ちなみに、 full_name をUserモデルのインスタンスメソッドにした場合は object.full_name という形にできるので、 full_name のリゾルバも省略することができます!

module Types
  class UserType
    field :full_name, String, null: false, description: '姓名'
    ## full_nameをUserのインスタンスメソッドにした場合は、full_nameも省略可能
    # def full_name
    #   object.fullname
    # end

    field :profile, String, null: false, description: 'プロフィール'
  end
end

いいですね!!

Loaderを使って、N+1問題を解決!

最初に挙げたこのテーブル構造を思い出してください。

users テーブル
- id
- name
- created_at
- updated_at

articles テーブル
- id
- user_id
- body
- created_at
- updated_at

comments テーブル
- id
- article_id
- user_id
- text
- created_at
- updated_at

これを実装する場合、 user.articles の中で article.comments を普通に呼んでしまうと、N+1問題が発生します。
いくら1回のqueryで呼べたとしても、N+1が発生しては意味ないですよね?

そんなときにはLoaderを指定します。
loaderには association_loader.rb というhas_manyの子レコードに対するloaderと record_loader というbelongs_toの親レコードに対するloaderの2つが存在します。

本稿では詳しく説明しませんが、 graphql-batch というgemを入れ、 graphql/loader/ 配下にそれぞれのファイルを入れれば使えます。
複雑なテーブル構造で、データを呼びたいときは試してみてください。

これでもう最強ですね!

最後に

Railsを使ってきた人ならきっとgraphql-rubyを使いこなせると思います。
GraphQLは「AWS AppSync」というAWSのサービスでも採用されていて、主流なクエリ言語になりつつあると考えています!
RailsエンジニアでWebAPIやスマホやタブレットなどのアプリケーションを作りたいと考えている方、その知識を使って便利なAPIを作ってみませんか?

PlantUMLを活用しよう

0

紹介

みなさんも業務上作図する機会が大小あるとおもいますが、下記の問題からなるべく避けたい事象ではないでしょうか。

  • 本質的でないレイアウト作業に手間どるのが嫌、更新も手間
  • 図の差分管理が困難で品質が保ちにくい。

そこでオススメなのがPlantUMLというシステムです。

  • ルールに沿ってテキストを書くだけなので任意のテキストエディタで作図できる。
  • 図の要素とつながりや順序を定義するだけでレイアウトは自動で行ってくれる。(レイアウトを指定することも可)
  • テキスト表現なので差分も明確なため、プログラムコードと同様のバージョン管理を適用できる。
  • とっかかりの学習コストが低い。デモサーバもある。
  • オープンソース(GPL)なので周辺システムが充実している。
  • 名称にUMLとあるがその用途を超越してるので気にする必要はない。
  • デメリット: ローカルでJava実行環境かどこかにJava処理サーバを設ける必要がある。(デモサーバでもええけど)

つらつら書きましたが正確なところは公式サイト他をご覧ください。

とりあえずデモ

  1. ローカル環境の構築
    • Java実行環境
      • 明示されてないが無難に8以上で
    • Graphviz
      • バージョンで相性があるので最新でダメなら適宜下げる。(公式forum)
    • VSCode
      • PlantUML拡張
      • 設定でPlantuml: Export Formatsvgにする。
  2. vscode上で下記のテキストファイル(*.plantuml)を作成
    • 編集中にPlantUML: Preview Current Diagramの実行でプレビュー表示できます。
  3. vscodeから書き出し
    • PlantUML: Export Current Diagramの実行で画像を出力します。
# *.plantuml
@startuml spirits
title PlantUMLを活用しよう

actor Me
participant OS
participant VSCode
participant "任意のVCS" as VCS

== 初期設定 ==
Me -> OS: Javaの導入
Me -> OS: Graphvizの導入
Me -> VSCode: PlantUML拡張の導入
|||
== 作図 ==
loop
  Me -> VSCode: テキスト編集
  Me -> VSCode: 画像プレビュー(自動)
end
Me <- VSCode: 画像で書き出し
|||
== バージョン管理 ==
VSCode -> VCS: テキスト表現のままコミット

@enduml
画像出力結果

おまけ

周辺ツールの紹介

雑感

  • 過去には同種のツールblockdiagを使用していましたが、表現能力がだんちに高いので乗り換えました。SphinxやJupyter用にも拡張があるためほぼ困らないはず。(Python可Java不可な環境以外)
  • 作図に特化したdraw.ioなどは自動配置の仕組みやテキスト書き出しもありますが、ピクセルで調整できる反面テキスト書き出し結果がどうしても煩雑になってしまう。
  • 実際のところ要素が増えてくるとグループ化や個々の配置の調整を行わないと意図したレイアウトにならないのですが、同等のことをGUIで行うよりかは明確で楽です。

その人の「熱量」に「伸びしろ」を感じる。リードエンジニア 高倉利明 インタビュー

0

コンテンツデザイン部のリードエンジニア 高倉さんに「若手に伝えたいことは?」と尋ねると「いきなりスーパーエンジニアになるわけじゃないんですよね」という答えが返ってきました。ベテランのエンジニアになって感じていることを語っていただきました。(2020年 9月 取材)

コンテンツデザイン部 高倉 利明(たかくら としあき)
2007年 3月 アピリッツ入社
趣味はゲーム全般(PS5&RTX3080予約済)、サッカー観戦(天皇杯決勝15年連続。ジダン在籍時のクラシコ現地で見たのがちょっと自慢)

アピリッツ最古参エンジニア

―― 高倉さんがアピリッツに入社された経緯を教えて下さい。2007年にご入社されたのですよね?

そうです。2007年の3月に中途採用で入りました。アピリッツに今いる人で自分より古いメンバーは10人いないんじゃないですかね。入社のきっかけは「技術者が大事にされている会社だ」と感じたからです。あとは良い椅子を全員使っていたことですね。腰痛はプログラマの職業病なので(笑)

もはやすっごく昔の話ですけど、もとは金融系システムを開発する会社にいたんです。で、そういうところになると「プログラムを書くのは若手だけ。さっさと卒業して技術者ではなく管理職になれ」って文化で。自分はエンジニアとして成長したかったし、ここにいたらコードが書けなくなっちゃうぞと思ったんです。

アピリッツに入ったあとは、5年ほどWebサイトの開発や業務系サービスを開発する仕事をしていました。6年目からはブラウザゲーム開発のチームに呼ばれて、今に至ります。

―― ゲーム部門に移ったきっかけは何でしょうか?

声がかかったってのもありますが、自分はちょっとずつ改善することが性に合っているんですよ。たとえばWebSI開発で一括請負契約で開発した場合、保守フェーズに入ると機能改善の機会は少なくなります。

でも自分は改善したくてウズウズするわけです。保守契約にないからやっちゃダメなんですけど「なんなら俺がサービスで修正するよ!? 」って思ってました。

これがゲーム開発だと、運営と改善がより密接に結びついています。ずーっと作って、育てて、改善が続く。だからこっちのほうが自分に合ってるだろうなと考えました。

もちろん子供の頃からずっとゲームは大好きでドラゴンクエスト&ファイナルファンタジーで育ち、大人になってからもオープンワールド、MMO、DTCGなどいろんなジャンルをずっと遊んでますね。最近だとゴースト・オブ・ツシマが面白くてチーム内外で布教してました(笑)

―― Web開発とゲーム開発で思考や仕事のスタイルはちがいますか?

ゲーム系って、アクセスする人数が尋常じゃなく多いんですよ。一般的なWebサイトと比べてアクセスが3桁も4桁も違うことも普通にありえます。これは実際に携わって度肝をぬかれましたね。ですから、大規模アクセスに耐えられる設計が非常に重要になります。

自分の場合は専門性を高めるために、クライアント側よりもバックエンドシステムに特化していきました。もちろんAWSやGCPといったクラウド技術の知識も重要ですので日々勉強しています。

継続的な改善と開発を主導する

―― ゲームの“リードエンジニア”の役目は何だと思いますか?

まず「いきなりマジックが起こってリードエンジニアになる」とか「最初からスーパーエンジニア」なんてミラクルは起きません。どんなエンジニアも積み重ねで徐々に強くなっていく。それは、若手や、なりたてのリードエンジニアにも伝えています。

そして「リードエンジニアに必須のスキルはこれ!」というのはないと考えていますが、求められる役目は「継続的な改善と開発を主導する」ですね。

プロジェクトの問題や、クライアントエンジニアやプランナーが困っていることは何なのか? そういったことを常に把握して、PDCAを回し続けます。それでいて、新しい技術を取り入れていく。

でも、サービスが始まってから新しい技術を入れるのはリスクが高い場合もあります。だから新しいことがやりたいなら検証を重ねないといけない。地道なんですよ。その検証をへて「これは次のプロジェクトで入れよう」と判断することもあります。

「次のプロジェクトでリベンジしてやる!」って気持ちを燃やすエンジニアは多いんじゃないですかね。たとえば今同じチームにいるクライアントのリードエンジニアも改善を重ねる執念がすごいです。だからほんと、すべて積み重ねなんですよ。いきなりスーパーでスペシャルなことができるわけじゃないと思う。

―― 開発中はいろんな職種のメンバーと関わりますよね。どんなふうに仕事をすすめていますか?

自分が今やっているのは大規模プロジェクトです。そしてサーバーサイドエンジニアは、とりわけテストチームとの関わりが多いです。

テストチームは様々なクオリティを保つ大切な存在ですが、テストは開発フェーズの最後にある関係でスケジュール遅延の割を食うこともあります。しかもサービスが始まってからバグが見つかると一番責められることも多い。

個人的にテストチームには本当に感謝していますし、チームメンバーにも常にその気持ちを持つことを心がけてもらってます。だから、テストチームの仕事が円滑に進むように、常にヒアリングしてデバッグ機能やツールを作ったり、事前にテストの手順をまとめたりしています。

君の「熱量」が聞きたいんだ!

―― エンジニアのお話にもどります。「この人、いいなあ」と思う後輩はどんな人ですか?

まず自分の嫌いな言葉に「最近の若いやつは」というものがあります。デジタルネイティブの若い世代は、自分たちの若い頃と比較するとみんな本当に優秀ですよ。自分が30代中盤にヒーヒー苦労してたことを彼らはアッサリ乗り越えてます。

そして自分が最重要だと思うのは、現在の実力よりも情熱がある人。新卒でも中途でも「熱量」が気になるんです。「会社に入って何がしたい?」と質問されて受け身の答えの人より貪欲な人のほうが伸びますし。あと、ゲーム開発者の熱量って意外とユーザーに伝わるんですよね。

―― なるほど。これから一緒に働きたい人も、そういう人たちですか?

はい。あと「いいなあ」と思うのは、自分のビジョンを持ってる人です。伸びる人は上からの指導は関係なく勝手に伸びてくものですよね。そして、そういう人はビジョンが明確。たとえば「リリース前でも定時帰り」を目標に掲げて、日中帯に人一倍集中して仕事をする若手がいます。自分は「リリース前なら終電帰りや休日出勤も辞さない」みたいな古い感覚が抜けないので、そういった発言は刺激になりますね。

人間関係の貯金でチームの強度を上げていく

最近はプロジェクトが大きくて50名近くのメンバーで開発することもあるのですが、大事なのはお互いリスペクトを忘れないことです。人間関係は貯金みたいなものだと思ってます。これも日々の積み重ねです。そしてトラブルがおきたときのチーム強度に関わってきます。持ちつ持たれつの関係って重要です。

チームで働くにあたって、趣味や好きなものは「積極的かつ具体的に」アピールすることも重要だと感じます。人間は他者への共感を持つことで仲間意識が芽生えるので、チームでの仕事がしやすくなる。

最近のエピソードで言うと、「趣味はサッカー鑑賞です」って大まかな回答をするメンバーがいたので「どこの試合行くの?」って聞いてみたわけです。そしたら「鹿島アントラーズです。地元なので」って。「そういうのが会話のタネになる。アピールしなきゃイカン!」って熱く伝えました。

また「どういうタスクをふれば、このひとは燃えるかな?」って采配は本当に大事です。チーム全体が最適化されるようにタスクをアサインするマネジメント領域です。人はそれぞれ得意なことが違う、という意識を持つことも大切ですね。

「メンバー全員が積極的でリーダーシップを持つチーム」って、理想的ではあるが現実的じゃないと言うか。例えば「自分の意見を出すのは苦手だが振られたタスクは必ずこなす」ってメンバーに対して「積極的にやらないから悪だ!」って空気になったら不健全ですし、チームのパフォーマンスは落ちるので。

マンネリズムを防ぐことも重要で、大規模プロジェクトになると1年以上の長期間に渡り開発することもあります。そうなるとどうしてもパフォーマンス落ちることもあるはずです。自分にもそういう時期はありましたし。

「好きなこと」と「得意なこと」を見極めよう

―― 高倉さんにも停滞する時期があったんですね。どう克服したのですか?

違うプロジェクトや環境に飛び込むことがいいキッカケになりましたね。新しい環境で尊敬できるエンジニアに出会えて、触発されて成長できたんです。

停滞していたのは「場」を変えなかった自分の責任だと思ってます。

だから「場が人を作る」って考えに自分は賛成します。自分の得意なことを「場」で見つけられたら、人って生き生きするんですよね。アピリッツに転職する前に、勉強会で知り合ったエンジニアに当時の環境を愚痴ったら「転職しなさい」ってアッサリ言われて「ああそっか」って思いましたもん。自分が輝ける職場って絶対にある。

あと自分が「好きなこと」と「得意なこと」と「苦手なこと」を見極めるのも大事です。「好きで得意な」仕事があれば良いですが、そうでない場合は「あまり好きではないが得意な」仕事をやると、周りも喜ぶし比較的うまくいくなーと思っています。

逆に「好きだけど苦手なこと」ってのもあって。その方向を選んでしまうと、うまく行かずに周りから評価もされづらくしんどくなるかと。

―― 高倉さんにとってアピリッツってどういう場だと感じますか?

エンジニアの裁量権が広い会社だと思いますね。たとえば「AWSのこのツールを使ってみたい!」っていうエンジニアの熱意と好奇心から始まって「じゃあこれ使ってなんかゲームシステムを考えよう」ってこともあります。

だから目的意識がクリアな人こそ楽しめる環境でしょうね。

定年までずっと現役エンジニア

―― いま心がけていることを教えて下さい

「俺が教えてやる」って上から目線な態度を取らないように心がけてます。その態度が出て勉強することを怠ったらエンジニアとして現役でいられないかなと。

勉強会をやるとしても、初回は自分がやるけど、二回目は他のメンバーにもやってもらいたい。自分も教わりたいです。自分は定年までずっとエンジニアリングの前線に立ちつづけたいと思っているので、勉強はずっと続けます。

とはいえ、個人的には体力が衰えてきて集中力は落ちたなと自覚してます。だから体を鍛えるって超大事で、筋トレやロードバイクなどで少しでもパフォーマンスが落ちないように気をつけてます。流行のエンタメに触れるのはゲームを作る側として重要なので、可能な限り流行っているゲームや漫画などは抑えるようにしていますね。

――  アスリートと同じ感覚ですよね。最後に、高倉さんがコードを書く際に集中力を上げる方法を教えて下さい!

とあるシューティングゲームのサントラを聴くことです。ちょうど再生時間が30分なので、聴きながらウワーっと集中力を上げて全力でやって、5分休憩を入れて、また30分聴きながら全力でやる。自分の仕事のテーマソングですね。

――  つまり、仕事中以外はその音楽を聴かない?

聴けないですね、だって仕事モードになっちゃうから(笑)

――  「場が人を作る」「チームの強度を上げる」という言葉が印象的でした。高倉さん、ありがとうございました!

CEH認定ホワイトハッカーの紹介

0
CEH

エンパワーメントサービス部所属セキュリティエンジニアの綾城です。
CEH(Certified Ethical Hacker)に合格したので、CEH v10の紹介と受験体験記を書きます。

はじめに

CEHは、EC-Council社が実施しているグローバルなセキュリティ専門家の認定試験です。日本の代理店はGSX社です。Certified Ethical Hackerを認定ホワイトハッカーとしています。(ホワイトハットとか、そのままエシカルハッカーとかの方が、個人的には好みです)特に攻撃側に特化した内容になっており、攻撃者の視点でシステムを検査することなどができるようになったりします。5日間の講習の後、試験を受けることで合格となります。

経産省の情報セキュリティサービス審査登録制度、情報セキュリティサービス基準で、脆弱性診断サービスの提供に必要な専門性を満たすとみなすことができる資格としてCEHが例示されています。

しかし日本ではあまり知名度がないのか、名指しでの求人情報は少なさそうでした。試しにindeedで検索したところ、年収350~2500万円のものがヒットしました。グローバルナレッジが毎年出してる資格の年収ランキング15で、2019年まで掲載されていました。(2019年は、11位で、年収11万6306ドルでした。日本円で年収1200万円ぐらいでしょうか)

あとアメリカ合衆国国防総省のなんかです。各種セキュリティの資格の説明によく出てくるのですが、私はよくわかってません。日本でいう情報処理安全確保支援士のような感じでしょうか?調達要件みたいなものでしょうか?

セキュリティの資格試験は、一般的にマネジメントかテクニカル寄りか、攻撃側か防御側かの性質の違いがあったりするのですが、CEHの位置づけは、攻撃側のテクニカル寄りの資格になります。CISSPのようにマネジメント寄りではないですが、OSCPみたいな実技試験でもないので、物凄くテクニカル寄りでもないです。
同じ攻撃側の試験ですと、ConpTIA PenTest+がありますが、CEHには契約や報告書を書くなどといった要素はありません。EC-Councilでは、SOCやCSIRTなどの防御側の資格として、CND(認定ネットワークディフェンダー)があります。CompTIAの資格ですと、Cysa+がそれに相当します。

講座を受けすに独学で試験を受けることをできますが、問題文が英語の試験を受けることになります。私は詳しくは知りませんが、学歴や経歴の提出が必要かもしれません。

EC-Councilセキュリティエンジニア養成講座
https://www.gsx.co.jp/academy/ceh.html

情報セキュリティサービス審査登録制度
https://www.meti.go.jp/policy/netsecurity/shinsatouroku/touroku.html

稼げるIT資格はどれ?―米グローバルナレッジが2019年版のトップ15を発表
https://hrzine.jp/article/detail/1553

アメリカ合衆国国防総省(DoD)のなんか
https://public.cyber.mil/cw/cwmp/dod-approved-8570-baseline-certifications/

CEH受講概要

公式ウェブサイトには、下記のように記載されています。

■下記の内容が理解できれば問題ありません(予習推奨)
 1)CCNAレベルのネットワークに関する内容
 2)LPIC Level1程度のLinuxに関する内容
 3)企業で導入されているFirewallなどネットワーク・セキュリティ機器の構成に関する内容
 4)下記ツールの使い方
   ・Wireshark や tcpdump
   ・nmap
   ・ローカルプロキシ(Burp Suite、Owasp Zed Attack Proxy、Fiddler)

■下記の実務経験があると講座内容がより理解しやすい
 ・プログラミング(C/Perl/Java/PHP)
 ・ネットワーク構築
 ・ネットワークトラブルシュート
 ・パケット解析
 ・ペネトレーションテスト

個人的に受けてみての感想だが、ネットワークの知識は必要だがCCNA程度に達してなくても問題ない。同様に、Linuxの基本的なコマンドを知ってる必要があるが、LPIC Level1程度に達していなくても問題ない。プログラミングとの表記に恐れをなしている方が割といるが、簡単なシェルスクリプトを理解する程度で大丈夫だと思う。

速いテンポで講習は進みますが、かなり基本的なことから教えてもらえるので、そんなに心配しなくてもいいと思いました。
あと特にウェブサイトには書いていませんが、受講者契約をよく見ると、18歳未満の方は受けられないかもしれない。

CEH講習

5日間みっちり講習を受けます。下記の20モジュールに分けられてます。
v9で、モバイル・プラットフォームのハッキング、クラウド・コンピューティングの追加。
v10で、脆弱性解析、IoTハッキングが追加されています。全体的にリファインもされているようです。

ホワイトハッキングのご紹介システムハッキングセッション・ハイジャックワイヤレスネットワークのハッキング
フットプリンティングマルウェアの脅威IDS、ファイアウォール、ハニーポットの回避モバイル・プラットフォームのハッキング
ネットワークの診断スニッフィングWebサーバのハッキングIoTハッキング
列挙ソーシャル・エンジニアリングWebアプリケーションのハッキングクラウド・コンピューティング
脆弱性解析サービス拒否(DoS攻撃)SQLインジェクション暗号技術

受講前の契約書ぐらいで、倫理面の内容があまりなく、攻撃側にかなり偏ってるので、新人教育などに使う場合は注意が必要かもしれません。全体的に各種ツールの紹介が多めでした。

脆弱性診断を行っている身としては、脆弱性解析の追加は嬉しいですね。自分の講習を担当した講師1人が、現役で脆弱性診断をやってる方で、少し脱線気味の話も割と有益でした。

脆弱性としてSQLインジェクションが1つのモジュールとして独立してて、少し踏み込んだ内容でした。IDSやファイアウォールの回避方法など普段あまり考えたこともなかったので新鮮でした。モバイルはAndroid、iOSもありましたが、なんだか一昔前のBlackBerryを意識した感じでした。

CEH講習教材

物理テキストを希望すると日本語のスライド資料の印刷版が2冊、英語のiLabsのマニュアル1冊の計3冊を入手することができます。厚さだけでいうと、CISSP(スライドではなく文章)より厚く、SANSの5日間のものより薄いぐらいです。

電子版は、かなり強力なプロテクトがかけられていて、印刷はできないどころか、ビューアーも特殊なものが要求されています。(PDCViewerというもので、なんかチラチラして、スクロールするとラグがある。書き込みがしにくい)2つのデバイスまでで1年間閲覧することができます。1台は、大きめのスマホか、タブレット端末で閲覧できるようにした方が便利だと思います。

CEHラボ実習

iLabsと呼ばれるラボ実習は、下記のようなことを行いました。
環境は、Windows Server 2006,2008,Windows 8,10,Kali Linux,Android,Ubuntuの仮想マシンが動作してます。

ラボ環境は、日本語化されていませんが、解説部分がブラウザの為、chromeの翻訳機能やコピーアンドペーストで翻訳にかけることができます。
SANSの講習と違って環境がオンライン上にあるので、ローカルマシンが多少プアでもネットさえ繋げれば、半年間いつでも実習することができます。

Firebug を利用したターゲットウェブサイトに関する情報の収集
HTTrackWeb Site Copier を使用したウェブサイトのミラーリング
hping3 を利用した UDP パケットと TCP パケットの作成手法
Nmap を使用したネットワークスキャンについて
さまざまなネットワークスキャン手法について
SuperScan を使用したネットワーク列挙の実行
Hyena を使用したローカルマシンでのリソースの列挙
ターゲットマシン上のサービスの列挙
Nessus を使用した Web サーバの脆弱性確認
Nikto を使用した Web サーバの脆弱性確認
クライアント側脆弱性を利用して権限を昇格させる
Spytech SpyAgent を用いてユーザーシステムを監視し、サーベライスする
OpenStego を用いた画像ステガノグラフィ
HTTP Trojan を構築し、HTTPRAT を使用してターゲットマシンを遠隔操作する
njRAT を使用して標的マシンの制御を獲得する
Wireshark を使用したパスワードのスニッフィング
Cain & Abel を使用した中間者攻撃の実行
SET を利用した Facebook の証明書情報のスニッフィング
hping3 を使用したターゲットホストの SYN フラッド
HOIC を利用した分散型サービス拒否攻撃の実行
Zed Attack Proxy (ZAP) を使用したセッションハイジャック
Snort を利用した侵入検知
HTTP/FTP トンネリングを利用してファイアーウォールをバイパスする
Metasploit を利用して ファイアーウォールをバイパスする
httprecon を使用した Web サーバのフットプリンティング
辞書攻撃を行い、 FTP 認証情報をクラックする
Web アプリケーションに存在するパラメータ改ざん及び XSS 脆弱性の利用
WPScan と Metasploit を使用した Web アプリケーションの列挙とハッキング
さまざまなセキュリティレベルでファイルアップロードの脆弱性を悪用する
MySQL への SQL インジェクション攻撃
Aircrack-ng を利用した WEP ネットワークのクラッキング
Aircrack-ng を利用した WPA ネットワークのクラッキング
Kali Linux を使用して Android をハッキングするバイナリペイロードを作成する
ownCloud でのユーザーアカウントの作成とユーザー権限の割り当て
ClamAV を使用した悪質なファイルアップロードからの ownCloud の保護
Kali Linux を使用して ownCloud AV をバイパスしてホストをハッキングする
HashCalc による一方向性ハッシュの計算
VeraCrypt を使ったディスク暗号化

CEH試験概要

私は難易度はそれほど高くないと感じましたが、落ちると受験料8万円で再試験となります。試験会場は、浜松町のGSXで受けました。

問題の中には、シチュエーション問題のような体裁で、ただの知識問題もあるので、恐れないでよく読みましょう。おそらく時間は余るので、選択肢から読むとかいう時短テクニックは必要ないと思いました。SANSのGIACと違い日本語で試験を受けられるのは嬉しいですね。あまり変な日本語はありませんでした。

CBT選択式125 問
制限時間 4 時間
70%以上合格

CEH試験勉強

試験対策で、iLabsの演習をやり込むのはあまりおススメできません。私は当初スライドをすべて見直そうとして、講習中に講師がここは後で読んでおいてとか言っていた場所などもじっくり読みながら進めていたらとても時間がかかってしまい挫折しました。5日間みっちりやったものプラスアルファを再度やるのにかかる時間をあまり考えていませんでした。

アプリPocket Prepに課金してやってみましたが、問題が簡単な気がして、やるのをやめてしまいました。その後、勉強会に参加して教えてもらった下記の無料の問題集サイトをやりながら、Udemyを見て復習、書籍を買うとアクセスできる問題サイトをこなしてから試験に挑みました。

CHE向け解説動画

【情報セキュリティ】Ethical Hacking:ホワイトハッカー入門
https://www.udemy.com/course/ethical-hacking-jpn1/
実際CEHの講師をやってる方が作成した、Udemyの動画。予習にも復習にもいいと思います。
普段は高いので、キャンペーンのときに買いましょう。

CEH問題集サイト

Certified Ethical Hacker – Online Practice Exam
https://ceh.cagy.org/
おすすめの無料サイト、chromeの翻訳機能を使って隙間時間に解いてました。
解説があまりないのと、たまに解答が間違っている感じがするのが少しイケてない。

CEH試験対策書籍

私は勉強会に出るまで、何から手を付けていいかわからなかったので、新旧やみくもに書籍を購入しまくりました。実際有用だったものを紹介します。


こちらは、参考書なので問題が275問と少なめですが、解説もしっかりあって、難易度もいい感じに高めなので、一通りやりました。購入すると、問題集のサイトにアクセスできるようになるので、chromeの翻訳機能を使って日本語にして問題を解きました。


上記の問題集版、現在まだv10が発売されていないので、脆弱性解析、IoTハッキングの問題がないですが、625問と量があるのでやり込みたい人にはおススメ。私はSybexの本が好きみたいです。


こちらは、v10に対応した問題集です。こちらもウェブで問題が解けるのですが、chromeで翻訳できなかったので、私はやらなくなってしまいました。

CEHアプリ

CEH Pocket Prep
https://play.google.com/store/apps/details?id=com.pocketprep.ceh&hl=ja
こちらスマホのアプリです。課金するとウェブで問題が解けるようになります。chrome翻訳もできます。
Android、iOS版で価格が違ったり、課金方法が複数あるみたいでした。私は、一番安そうだったAndroid版のプランに入りました。問題数もたくさんあり解説はあるものの、なんだか問題が簡単な感じがして違和感を覚えたのでやらなくなってしまいました。
基礎からやりたい人や時間がある人にはいいかもしれません。

CEH勉強会

CEH StudyGroup
https://ceh-studygroup.connpass.com/
以前は、GSXに場所をお借りして行っていたようです。現在は、不定期でTeamsを使ってオンラインでやってます。私はここで、いろいろと情報交換して試験に挑みました。CEHに限らずセキュリティのことを気軽に聞けてよかったです。

合格しましたが、私は今後も何かお手伝いできればなと思っているので、参加は続けようと思ってます。また合格したらSlackもありますので、参加していただけると嬉しいです。何かありましたら、勉強会やSlcak、下記のメールアドレスへお願いします。

CEH合格後

グローバルな資格にありがちな継続教育ポイントを貯めないと資格を維持できないシステムです。私はまだ受かったばかりなので未知の部分が多いです。
紙の認定証は有償です。PDFは無償でもらえるので、自分で印刷すればよいと思います。

さいごに

弊社では、セキュリティエンジニアを募集しています。Webセキュリティについて学んだことを活かしたい、セキュリティの資格にチャレンジしてみたい方など歓迎します。興味ある方は、下記の採用情報からセキュリティエンジニアの職務内容・応募資格を確認してみてください。もちろん、Webエンジニアも募集中です。下記ボタンからぜひ確認ください。

【成果発表会】「読みやすいコードのために、すぐに伝わる命名を」以心伝心

今回は社内の成果発表会「P-Review ’19」にて発表した、エンジニア H.Fさんの資料を紹介します。
※この記事は個人の研究発表で、会社としての見解ではございません。
こちらに載せられているプログラムは、すべて資料のために作成されたものであり、実際のプログラムとは異なります。

P-Review19hf

H.Fさん
2018年7月アピゲー部エンジニアとして入社。
入社後は主に自社開発ゲームのゲームエンジニアを担当。

早速ですが皆様にお聞きしたいことがあります。この2人は誰でしょう?

「すずきさん」と「たなかさん」かな……?

正解は……

右側にいる鈴木という表記の人は「テリー大隅さん」。田中Tシャツを着ている人の名前は「牛山牛子」さんという名前だそうです。

!?!?

意味わからないですよね……?
それでは、「以心伝心」発表を始めたいと思います!

以心伝心とは

• いしん-でんしん【以⼼伝⼼】
ー⽂字や⾔葉を使わなくても、お互いの⼼と⼼で通じ合うこと。
▽もとは禅宗の語で、⾔葉や⽂字で表されない仏法の神髄を、師
から弟⼦の⼼に伝えることを意味した。「⼼こころを以もって⼼
こころに伝つたう」と訓読する。(参考:google辞書)

まず以心伝心とは、文字や言葉を使わなくても……などと意味は色々と書いてありますが、つまりお互いがわかりあっている状態のことだと自分は解釈しています。

目的

コーディングでの機能拡張や改良や諸々の対応をしている時に、そのコードが自分が対応したものとは限りません。書いてあるコードが読みやすいと、実装が早くなって作業効率が上がったり、その日は途中で終わっちゃった場合であっても、次の日すぐに把握しやすくなります!

こういう経験ありませんか?

そもそも、コードを読む際に一瞬でも思考が止まるようなコードは好まれないと思います。

では、一瞬でも思考が止まるようなコードとはなんなのか。
エンジニアの方、こういう経験はありませんか?

①名前と内容が一致しない

※こちらに載せられているプログラムは、資料のために作成されたものであり、実際のプログラムとは異なります。

メソッドや変数の名前が一致しない
例えば、「A」のコードだったとして、メソッド名はなぜか「B」だったとか……謎ですよね。

②全てが繋がっている

コードの流れがすべて繋がっている状態
改行とかがなく、コードの処理がすべて繋がっていて読みにくい状態ですね。

③処理に行くまでが長い

次に、ネストが深すぎて処理に行くまでが長いという状態。

④肯定された後に否定をされる

次にif文の条件とかで肯定されている文の後に、否定をされている状態が連続されているという状態です。

コードを読むのが嫌になってきます……。
なので、今すぐできる相手への伝え方についてのポイントをまとめてみました。

● 名前
名前の命名をちゃんとすることにより、処理の把握自体がすぐにできると思います。

● 美しさ
先ほど言った処理の流れが繋がっている状態ですと、どこに何の処理があるのかわからなかったり、一度思考が止まった時にどこから見直せばいいのかいまいちわからなくなってしまうことがあります。

● ネストの深度
処理に行くまでが長い状態、if文がたくさん並んでいる状態ですと、見直す時に最初から見直さないとちゃんとした見直しにならないというところですね。

● 肯定文と否定文の混在
今すぐにでも相手に伝えられるような効率になるかと思います。

それでは、ひとつずつ説明していきたいと思います。

名前

• な‐まえ【名前】
• ① ある⼈や事物を他の⼈や事物と区別して表すために付けた呼び⽅。名。
• ② ⽒名。またその名字を除いた部分。「ここに−を書いて下さい」
( 参考:⼤辞林第三版)

僕が検索した中だと、2種類の意味がありました。
今回に適する意味は「①ある⼈や事物を他の⼈や事物と区別して表すために付けた呼び⽅。名。」です。
つまり伝わらない名前は、名前としての役割を果たしていないということになります。

なので最初に、名前に必要な情報を詰めます。
アバウトすぎるので、少し分解して説明していきます。

明確な単語を選択

まず明確な単語を選択します。
広義的には間違っていないけれども細部を表せていない単語を選択することを、今回問題に取り上げています。
改善点としては、広義に間違っていない単語の解釈を一つ掘ることで、明確にできるのではないかと思います。

例えば「stop」という名前を付けている場合、取り消しが不可能な処理であれば「kill」をつけたり、取り消しや「stop」を解除できるようなものであれば「pause」にするとかですね。

抽象的ではなく具体的な単語を選択する

2つ目、抽象的ではなく具体的な単語を選択する。
名前に属性の情報を付け⾜すと、「何をしたいのか」などを瞬時に明確に理解できるようになります。

こちらに関しては、日にちが経った後でも変数名を見るだけで、どんな値が格納されているのかをすぐに確認ができるようになると思います。例えば「delay」っていう変数があったとしてその「delay」に入っているのは何か↓

• delay -> delay_msec, delay_min
• size -> size_mb
• limit -> max_kbps, min_num

このように置いてみましょう!

誤解が⽣まれない単語を選択

3つ目、最善な単語というのは誤解が⽣まれない単語のことです。
逆に⾔えば、誤解が⽣まれない単語は最善な単語になる。

例えば、 エンジニアですと名前の頭に「is」や「has」を付けると、「bool」を返すメソッドだったり変数だと思います。なので、「bool」の値を返すようなメソッドじゃないのに、「is」や「has」を付けると誤解が生まれるということです。

省略から始まるミステリー

4つ目、できる限り省略をしない
ポピュラーな単語のポピュラーな省略の仕⽅であれば問題ないと思いますが、これがプロジェクト単位での固有名詞や、あまりポピュラーではない単語の省略になると、急に翻訳も利かなければ検索しても出てこないようなミレニアム懸賞問題レベルの難問になってしまいます。なので基本は省略をしないのをオススメします。

でも、エディターの横幅の関係上で省略をしたい場合は、コメントなどでメモを残しておいた⽅がいいでしょう。

否定の副詞が⼊ると頭は⼀旦停⽌する

5つ目、否定をしないこと。こちらは英語の⽂法にすると分かり易いと思います。

a.「 This is the pen I used」
b.「 This is the pen I didnʼt used」

a.とは違って、b.⽂では「didnʼt 」の部分で、一瞬だけ処理を把握するためのプロセスに「”usedを否定して~” 」というプロセスが追加されませんでしたか?

⼀単語が増えることによって考えることが増えて、そこで⼀瞬思考が⽌まることが多くなるのであまりオススメしません。

名前が⻑過ぎると読む気が失せる

6つ目、名前の長さです。名前が長すぎると、とても読む気が失せます。

一番最初にある変数の宣言は、この長さが続くと、この後の変数を使う部分のように、とてもとても読みにくくなると思います。

おまけ~メソッドの命名について~

名前の命名について、先ほど6つくらいのポイントを上げました。処理の内容を具体的に表せていると良いと提⽰しましたが、メソッドの命名が処理の内容を具体的に表せていると、名前と処理の⽐較をしたときに逸脱した処理を⾏っていた場合は、そのメソッドは機能を持ち過ぎという⼀つの判断にもなると思います。

美しさ

コーディングによる美しさとは、見た目の問題としてコードが整理整頓されていること、コードの縦線が揃えられていること、エディターの横幅を越えないようにされていることがあげられます。

こちらのモデルを例にして説明していきたいと思います。

コードを整理整頓する

先ほど全部羅列されていたコードを処理ごとに分けてみました。この4つを分けることによって、どの処理がどこで何をしているのかわかりやすくなっていると思います。

コードの縦線を揃える

コードの縦線を揃えられてることによって、変数だったりメソッドがどこでどんな値を入れているのかが見やすくなると思います。

エディターの横幅を越えない

先ほど見せたコードですが、エディターの横幅を超えたことにより、改行されている部分があります。

こちらの部分をメソッドの引数に合わせて改行するのと一緒に、引数の縦線を合わせるのを加えることによって、こちらのメソッドの処理が何を引数にして何を返しているのかが分かりやすくできたと思います。

ついでに、個⼈的な趣向も追加

最初の羅列されているコードのをさっきのポイントを含めて、なおかつ個人的な趣向を含めて直しますと……

このようになります。

コメントを足しただけなのですが、これをすることによってどういう処理なのかをレイヤーで把握するのが早くなります。

ネストの深度

始めに、ネストについて説明していきます。

ネスト【nest 】⼊れ⼦/ ネスティング/ nesting
ネストとは、あるものの中に、それと同じ形や種類の(⼀回り
⼩さい)ものが⼊っている状態や構造のこと。ITの分野では、
コンピュータプログラムやデータ構造において、ある構造の内部に同じ構造が含まれている状態のことを指す。

調べたら難しいことばかり書いていますが、つまりこういうことです!

ひとつのスコープの中に、また処理が入っている状態のことです。

ネストの深さは闇の深さ

条件が複数になったことによって、これが続いていきますとどんどん深くなっていきます。ネストの深さは闇の深さとも言われているほどです。

これもそうですが、コードから不吉な匂いがしてきます……。

こちらのコードの問題点は、ネストの深さによりメンテナンス性が落ちていること。というのも、条件が複数になることによって、一つ処理を戻ってこれがどうだったのかを把握するときに、またその条件に対して思考をしなくてはいけなくなるので、把握の時間が伸びることでメンテナンス性が落ちてしまうんです。

そして、何よりも読みたくなくなる。こちらの改善⽅法は2つあります。

①例外処理はreturnする( ガード節)

「return」をすることによって1つネストを浅くしております。
ここでは「next」にしているんですけども、実際やっていることは「return」とほぼ一緒なので同じです。

②メソッド化して、処理を細分化する

同じような処理がたくさんあったりするとメソッド化をしますが、ネストの深い部分を一つ一つ分解してメソッド化をするというのも一つの対処だと思っております。

おまけ

• 現状ボス判定のないエネミーの、「kind」が1で「attack_pattern」が1のものだけのユニークな処理になっている。

• ここから何かを拡張しようと思うとif⽂の分岐を⽣やしたりとどんどん汚くなるのが⽬に⾒えているため、個⼈的には
– ボス⽤の「update」メソッド
– 親メソッドにも少し⼿を加えて、「kind」と「attack_pattern」の種別とそれに合わせて係数が変更されるようなメソッドを作成しておくと、プランナーのマスター操作だけでコード側の変更がなしでできるようになるから良いです。

肯定⽂と否定⽂

if文のところ見ていただきますと、最初の「master.i==1」の部分が肯定文です。

次に「!」がついているところが否定文になります。

また次の肯定文がきて、否定文となっています。

このように否定と肯定文が混在することによって思考のプロセスが止まることになると思います。

問題点

● 肯定⽂と否定⽂を混在させると、知りたい処理にたどり着くまでが遠くなり思考が止まる要因になったり、誤認をさせる可能性が⾼くなります。

• if文の条件式に肯定⽂と否定⽂を混在させてネストを深くされると、読む側は戻った時に同じところをまた考えなくてはいけなくなるので脳内メモリをガリガリ消費されていくような気がします。

改善⽅法

これらの改善方法については先ほど説明しました「例外処理は早い段階でreturnする。(ガード節) 」「メソッド化をして処理を細分化する。」に加えて、「⾔語によっては勝⼿に⽤意してくれてたりする。」ということもあるのでそちらについて説明していきます。

Ruby の場合

Rubyの場合ですと、「nil?メソッド」だったり、「empty?メソッド」というものがあります。
先ほど言った「true」を返すメソッドです。

Ruby on Rails の場合

「blank?メソッド」、「present?メソッド」の2つがあります!

C# の場合

調べたところ、「null合体演算子」というものがあるそうです。
例文を書きましたが、「hoge ?? ”Null”」「hoge 」が「null」 なら、「”Null”」 が返されるものだったりとか、「HasValue」というメソッドがあったりするそうです。

まとめ

名前
⼀⽬で⼊ってる値や処理が推測できる命名をする。

美しさ
処理毎に⼀⾏空けたり縦線を揃えたりして、綺麗に魅せる努⼒をする。

ネストの深度
例外処理は早い段階でreturnして弾いたり、メソッド化をする。

肯定⽂と否定⽂の混在
肯定⽂と否定⽂の混在は混乱の元。
できるだけ否定形は使わないようにして、混在しそうになったら⼯夫する。

こちらのポイントを押さえることより、他のエンジニアが見てもわかりやすいコードが書けるようになると思います!

最後に

この4つの中で今すぐにでも変えられることは「名前」だと思います。

皆さんも以心伝心のようにすぐに伝わる命名を意識して、一緒に効率化を目指しましょう!

名前って大事ですよね~!アイコもほかの人が見ることも考えて、ファイル名などを気を付けることから始めてみようと思います!

雲の呼吸 壱ノ型~AWS設計の勘所:コスト編~

0

はじめに

データイノベーション部浅田です。

人気漫画「鬼滅の刃」に仮託して、「雲(クラウド)の呼吸」と題しまして、AWS(Amazon Web Services)を用いたアーキテクチャ設計の勘所を数回にわけて書いていきたいと思います。

なお、AWSに関するサービス名に関しては、この記事内で初出時は正式名称をつけ、以降は明確な場合は省略系を用いる方針で記述しています。

第一回目は「コスト」です。

コストは設計の考慮事項でも最重要事項

今から遡ること2000年以上前、紀元前3世紀のギリシアにあったエピロス国のピュロス王は戦術の天才と呼ばれ、イタリア半島を統一しようとしていた古代ローマと戦い二度勝利を収めました。ただ自軍の損害も大きく、三度目の戦いでローマに敗れました。この故事から「割に合わない勝利」のことを「ピュロスの勝利」と言ったりします。

営利企業であれ、非営利法人であれ、組織が事業を展開するにあたってコストの問題は常に付きまといます。どんなに優れた設計であっても、コストがかかってサービスの継続が難しくなってしまうとするなら本末転倒になります。ピュロスの勝利になってしまっては元も子もないわけです。

クラウドの利用が加速しているのは、コスト面でもメリットがあるからですが、漫然と利用していては、そのメリットを最大限に生かすことはできません。

コストを削減するための設計心得

では、コストを抑える設計のポイントはどういったものがあるでしょうか。私が思うに、以下のような点がポイントになるかと思います。

  • Amazon EC2 Auto Scalingで必要な時に必要な分だけ起動する
  • 安価なストレージを利用する
  • 割引オプションを利用する
  • 要求される可用性を見極める
  • サーバレスを積極的に利用する

Auto Scalingで必要な時に必要な分だけ起動

クラウドを使うメリットの一つは仮想化されたCPUやメモリを自由に追加、削除できることです。代表例はAmazon EC2のAutoScaling設定です。Auto ScalingはAmazon CloudWatchの任意のメトリクス(例えばCPU使用率)の指標をもとに、EC2インスタンスの台数を増減させる機能です。

多くのワークロードにおいて、長期間に渡って常に一定のリソースが必要ということはあまりないでしょう。Webサービスであれば、利用者の増減がありバッチ処理であれば、データの増減があります。なので、Auto Scalingによって負荷の増減に対応して、EC2インスタンスの台数を増減させることは有力な基本方針の一つです。

基本と書いたのは、Auto Scalingはサーバの起動時間が数分かかるのでスパイクアクセスには有力な選択肢とならないことや、Auto Scalingを運用するには、サーバ自身には重要なデータを置かない(ステートレスにする)必要があるなど、注意点もあるからです。

安価なストレージを利用する

基本的にはAmazon S3にデータを保持するようにした方が良い場合が多いです。

S3

保存コストが安いということもありますが、耐久性もすぐれています。S3にデータを保存することで、EC2をステートレスにしてAuto Scalingの適用を可能にする利点もあります。

データの耐久性を少し落とした低冗長化ストレージのオプションも存在するので、ワークロードに合わせて、検討すると良いと思います。

ただし、ブロックストレージを代替するものではないので、読み書きを頻繁に行うファイルの保存先には向いてません。また、キャッシュなどの低いレイテンシを求められる用途にも向いてません。

Amazon S3 & Amazon S3 Glacier Deep Archive

S3よりさらに安価な保存携帯がGlacier、およびその派生のGlacier Deep Archiveです。

アクセス頻度が稀で、長期的に保存しておきたいデータの保存先として候補になります。例えばログデータであったり、監査用のデータなどです。

ただし安価である代わりに、取り出しに時間がかかります(標準で3〜5 時間、Deep Archiveであれば12時間以内)。

Amazon EBS

EC2やAmazon RDSにはEBSというブロックストレージを必ず使用します。アプリケーションでデータを保持する上で、一番シンプルに利用できるますし、レイテンシも低く利用できます。ですが、コスト観点で見ると必ずしも最適な選択肢とは言えません。また、複数のEC2サーバから読み書きするような用途には向きません。基本的にEBSには必要最小限のデータだけを持つのが良いでしょう。

Amazon EFS

NFSサーバのようにファイルを共有できるEFSというサービスがあります。単純なストレージコストとしてはEBSより高くなってしまいますが、複数のサーバからファイルを共有したい場合には候補となります。

どれを使えばいいの?

基本的にはデータの格納先としては

  • S3を第一候補とする
  • アクセスが稀であればGlacierおよびGlacier Deep Archiveを検討
  • ファイルシステム上で共有したい場合はEFSを使用
  • それ以外はEBS

という選択が良いでしょう。

割引オプションを利用する

AWSには、起動しているEC2などの料金を節約するためのオプションがいくつか存在します。

Amazon EC2 リザーブドインスタンス & Savings Plans

ある程度長期間サーバを起動することが見込まれる場合には、リザーブドインスタンスを検討すべきです。ある程度予測がきくワークロードであれば、最初から検討しても良いでしょうし、ある程度サービスを運用してみて、あたりが付いた時点で導入しても良いかと思います。

長期間利用することを約束する代わりに、割引を受けられるというのがリザーブドインスタンスのメリットではありますが、Availavility Zone(以下、AZ)を指定したリザーブドインスタンスは、インスタンスを起動する権利(キャパシティ)を確保することができるのもメリットの一つです。

というのも、通常の起動(オンデマンドインスタンス)や、後述するAmazon EC2 スポットインスタンスの場合、AWS上に対象の余剰リソースがない場合には起動できない可能性があります。そのため、確実に指定した台数のインスタンスを起動したい場合はキャパシティ予約を行う必要がありますが、AZのリザーブドインスタンスを購入すると同時にキャパシティの予約ができます。

※なお、キャパシティ予約はリザーブドインスタンスなしでも可能ですが、リザーブドインスタンスと組み合わせたほうが安くなります。

リザーブドインスタンスに加えて、最近追加されたオプションがSavings Plans です。リザーブドインスタンスは、インスタンスサイズやリージョンやAZなどを指定して割引を受けますが、Savings Plansはその制限がなくコンピュータ処理能力に対する課金額を対象とするので、
EC2だけでなく、AWS FargateやAWS Lambdaにも適用できるなど、より柔軟な割引を受けることができます。

スポットインスタンス

AWS上の余剰リソースを格安で利用できるオプションがスポットインスタンスです。

利用期間や利用額を前提とすることなく、通常よりもかなり安くインスタンスを利用できるオプションですが、注意点があります。

まず、余剰リソースを利用できるオプションなので、対象のインスタンスタイプに空きリソースがない状態では起動することができません。

加えて、サーバが勝手に停止されてしまう可能性があります。そのため、途中で停止してしまっても、リカバリが可能なワークロードでのみ使用するほうが良いでしょう。例えば、Amazon EMRに代表される分散処理基盤上のタスクノードとしての利用は最も適した利用法です。Hadoopのような分散処理基盤のフレームワークには、ノード故障などに対してリカバリーをする仕組みが備わっているので、意図しないタイミングでいくつかのノードが停止されても処理をリカバリーすることができるようにデザインされています。

また、停止される場合に、通知を受けられるので、通知を受けたらELBから切り離すなどの仕組みを作ることで、APIのバックエンドサーバとしても利用することも可能です。

ただし、全てをスポットインスタンスのみでアーキテクチャを組んでしまうと、余剰リソースがない時にすべての処理が停止してしまうことになってしまうので、最低限欲しいリソースについてはリザーブドインスタンスを組み合わせて利用するなどしたほうが賢明です。

要求される可用性を見極める

PoC(概念実証)用の環境など、高い可用性を要求されないケースはあると思いますが、本番用の環境であっても可用性を多少犠牲にして、コストを抑えることも戦略の一つとしては考えられます。

例えば、大規模災害を想定して、BCP(事業継続計画)のためのDR(ディザスタリカバリ)として、
別リージョンにデータなどを配置することはよく行われますが、その際にも、いくつかの戦略が考えられます。

  • 別リージョンに同様の可用性をもった環境を起動しておき、常に冗長構成(Active/Active)で稼働させるマルチサイト
  • 別リージョンに最低限稼働する環境を起動しておき、障害が発生したタイミングで切り替えるウォームスタンバイ
  • 別リージョンにデータベースのレプリカを起動しておき、障害時に他の環境を構築してサービスを継続させるパイロットライト
  • 別リージョンにデータベースのスナップショットを定期的に送っておき、障害時に他の環境を構築してサービスを継続させるバックアップ/リストア

などです。

上から順番に可用性は低下しますが、かかるコストは低くなっていきます。

ただし、
ベストプラクティスとしてはサーバなどのリソースを冗長化させることで可用性を確保するのが推奨されます。「障害の可能性が低いから大丈夫だろう」という希望的観測で可用性を犠牲にするのはやめたほうが良いでしょう。「発生する可能性があるものは将来必ず発生する」という前提のもと、対処策を考えた上で、可用性とコストを天秤にかけるべきです。

サーバレスを積極的に利用する

クラウドならではのコスト削減策の極意はサーバレスです。

AWSに限らず、クラウドベンダーは従量課金をメリットにあげていますが、EC2/RDSなどのサーバを起動している場合、サーバを起動しておくだけで処理を行っていなくても料金がかかってしまいます。もちろん、それを100パーセント常に使っているのであれば良いでしょうが、常時余分にリソースを確保するケースが大半でしょう。サーバレスなサービスを利用することで、その余分なコストを最適化できます。

サーバレスの明確な定義は難しいですが、特徴としては、

  • 実行基盤としてのインフラ管理を意識しない(サーバがないわけではなくサーバを意識しない)
  • 使用料に応じた柔軟な課金体系

が挙げられると思います。

その典型がLambdaです。Lambdaはイベントドリブンな関数実行サービスなので、実行に応じて課金されます。なので、リソースを余分に確保するためのコストを削減できます。

Amazon API Gatewayを利用すれば、RESTなAPIのバックエンド処理としても実行できます。EC2をAPIのバックエンド処理として利用する際には、冗長性を考慮するとELBも基本セットになりますが、
API GatewayとLambdaとを利用して構築することで、EC2のコストだけでなく、Elastic Load Balancing(ELB)のコストも削減することができます。

Lambdaと組み合わせて使うのに最適なサーバレスなNoSQLデータベースがAmazon DynamoDBです。DynamoDBは、RDSやAmazon ElastiCacheと違って、インスタンスという概念がありません。キャパシティユニットという性能を決めるための設定値とデータの保存量に応じて課金されます。キャパシティユニットやテーブルのキー構成などをワークロードに合わせて適切に検討すれば、コストメリットを享受できます。

また、オンデマンドキャパシティという事前にキャパシティユニットを指定する必要がないオプションやリザーブドキャパシティという最低限の使用量を約束する代わりに安くなる割引サービスもあるので、合わせて検討すればよりコストメリットを高めることができます。

もちろん、なんでもかんでもサーバレスがいいかというと、決してそうではありません。

Lmabdaは実行時間などいくつかの制約もあるので、ワークロードでLambdaの利用が適切かよく検討する必要があります。DynamoDBもRDBMSや他のNoSQLを代替するものではないので、用途の向き不向きがあります。

とはいえ、基本的な考え方としては、
「サーバレスな構成にできないか」をまずは検討することで、コストの削減をできる可能性は高いと思います。

最後に

以上、AWS上でコストを考慮した設計を行う際の勘所でした。もちろん、この他にもAWSにはコストを削減するための便利なサービスや設定がたくさんあります。それらを有効に活用することで、多くのコストメリットを得られることでしょう。

連載第二回はこちら:雲の呼吸 弐ノ型~AWS設計の勘所:マネージドサービス・前編~

浅田さんのご紹介: AppiritsのAI研究者が『2020 APN AWS Top Engineers』に選出!資格取得に対する取り組みを紹介!

【お前ならできる!】人生を自分の思うがままにする方法

0

株式会社アピリッツ データイノベーション部の佐藤と申します。

今回私からは技術系の話ではなく、

人生を自分の思うがままにする方法

についてお話しさせていただこうと思います。

※決して怪しい情報商材の類ではありませんので、どうぞ暖かい目でご覧ください。

関連:「チャレンジし続けてさえいればきっと成功する。私が証明します」TECH CAMP(テックキャンプ)出身、佐藤さんの場合


 

はじめに…

私は、アピリッツに2020年5月18日に入社した新人エンジニア(30才)です。

前職では某パン屋で店長として勤めており、
当初はプログラミングの"プ"の字も知らない程の人間でした。

そんな私はどうしてプログラミングを1から勉強してまでエンジニアを目指そうと思ったのか、
また転職をするまでの学びから、
“人生を自分の思うがままにする方法”についてお話ししていきたいと思います!


 

飲食での働き方が私をエンジニアの道へと導いた!

前項でも記しましたが、私は前職パン職人をしておりました。

みなさんはパン屋さんにどんなイメージを持たれているでしょうか?

  • 「毎日美味しいパンの香りを嗅げて幸せ」
  • 「人に幸せを届ける仕事」
  • 「制服が可愛い」

などなどキラキラしたイメージがあると思います。

確かにこれら全て間違っていることはありませんが、
業界の裏は結構泥臭いものです。。。

毎朝4時に出社して、生地仕込みから始めて、7時には開店。
営業中はひたすら製パンと接客に追われ、
手が空けば新商品の考案や、材料発注などの事務業務。
それに加え店長は店舗と従業員のマネジメントも行って気付けば帰宅は21時近く。。。
もちろん休日も気が休まることなどなく…と、
別にパン屋のネガティブな一面をつらつらと言いたい訳ではないので割愛。

私はそんな激務であってもパン業界が好きでした!
製パンは楽しいですし、
自分の作ったパンでお客さんが喜んでくれた時の喜びは一入です!

しかし、そんな想いも日々蓄積された疲労やストレスには抗えませんでした。
私を含む従業員は華やかなパン屋のイメージからどんどんかけ離れていきました。。。

パンを通じてお客さんに幸せを届けるはずの我々が幸せでなくてどうする!?
このままではいけないと、

“この働き方を変えたい”

そう思いました。

 

じゃあ働き方を変えるにはどうするか?と普段の業務を振り返った時に、
もっと人が考えることや、動くことを減らせれば良いのでは?と考えました。
人生初私がITソリューションを考えた瞬間です。

「世間は様々な分野で自動化が進んでいるのに、
うちのパン屋めっちゃ人力じゃん!?」と気付いたのです。

今考えるとその時の私は時代に取り残された猿だったのだと思います。。。

 

「あいてぃー化、これで勝つる!!」

と思ったのも束の間、

「でもあいてぃー化ってそもそもどういうもので、どこから始めれば良いんだ??」

という疑問で頭がいっぱいになりました。

 

手立てが見つかっても、それを駆使できなければ意味がない。

ショックでした。。。

「こうしたい!」という想いを、自分のチカラではどうすることもできない事実に。

 

そんな時ふと人生の師である上司の言葉が頭を過ぎりました。

「お前ならできる!」

その方は私が仕事で失敗して挫けそうになった時や、
新たなことに挑戦する時に、いつもそう言い続けてくれました。

私は単純なので、そう言われる度に挫けそうな心を再起させては

「自分ならできる!」

と更に自分に言い聞かせて苦難を乗り越えてきました!

 

そしてその時も違わず私はこう考えました。

「今回だってできるのでは?自分がITを操作することも!」

不思議と根拠なくそう思って、気付けばパン屋を退職し、
プログラミングスクールに入校手続きを踏んでいた自分がいました。

 

「おいおい!そんな急展開ありかよ!?」って声が聞こえてきそうです。
自分でもそう思います。

何も当てがある訳でもありませんでした。
それなのに急に退職を申し出て、身内にはかなり心配をかけたし、
同僚にもかなり迷惑をかけてしまいました。。。

でもこの行動こそが、今回の話のきっかけに繋がるのです!


 

他責思考は想像以上に人生を生きづらくする

前置きが長くなってしまい、すみません。
ここからが本題です。

この記事の主題である

“人生を自分の思うがままにする方法”についてですが、それはズバリ…

“自責思考を持つこと”です!

自分で決めたことによる結果、その責任を全て自分が持つ。
ただそれだけ。でもこれって意外と難しいです。

人は結構無意識に他責思考になってしまっていること多いです。

では、他責思考とはどういうことでしょうか?

(また私の過去話になってしまいますが、、、)

パン屋に就職したばかりの頃の私は、製パン学校に通っていた訳ではないので、
先輩にパンの作り方を1から教わり、私はそれを忠実に守っていました。

だけど焼けて出てくるパンはどれも失敗ばかり。。。

何度やっても何度やっても同じ結果でした。

その度に私は店長に怒られていて、正直不服でした。

「こっちは言われた通りにやったのに!教え方が悪いんだろ!」って思ってました。

そんなこと考えながら仕事していた中で、
店長にある時こう言われました。

「こうしなさいと先輩に言われたかもしれない。
だけど、それを”その通りにやる”と決めたのは佐藤くんだよね?
だからその結果の責任はあなたにあるんだよ。」

この言葉を聞いて、最初は理解ができず少しモヤッとしました。

でも、次第にこの言葉の意味に気付いてきたんです。

 

私はパンの作り方を教わる時に見ているはずなんです。
先輩がパンを作る一通りの動作を。
それなら素人なりにも考えることができたはずなんですよね。

どうすればもっとうまくできるのかを。
ただ教わった通りにやるのか、
失敗する度により良い方法を考えて行うのかは私が選択してきたことなんですよね。

だから「言われた通りにやったから責任問われないよね」なんていうのは、
子供の言い訳に過ぎなかった訳ですね。

 

誰かにこうしなさいと言われたから。

これが良いとみんながそう言っていたからやった。

だからその結果は私の責任ではない。

これが他責思考です。

 

他責思考であるということは、

他人に決められた人生を歩むということ

他人の「こうしなさい」「これが良いよ」という言葉に反射的に反応して、
結果失敗すると「〇〇さんがこう言ってたから」と着地する。

これでは人生を思うがままになんてできません。

 

誰かに言われたから” やった”。

しかし、それを”やる”という選択は自分で決めたものであること。

その結果、責任は全て自分で負う気持ちで在る。

これこそが“自責思考”です。

 

この思考があってこそ、

自分がやりたいことを選択し、自分で考えて行動する。

結果“人生を自分の思うがままにできる”に繋がるのです!

 

私がエンジニアを目指した時もそうでした。

周りからどんなに反対されようと、
私は自分の進みたい道を自分で選択して、全て自責思考で行動してきました。

技術的にはまだまだな面が多くありましたが、
その中でも私の熱意を真摯に受け止めてくれたのがアピリッツでした。

結果今アピリッツでWebエンジニアとして仕事しながら、
自分の目標に向かって走っています!

 

これは結果上手くいっただけのほんの一例に過ぎないかもしれません。

時には自責思考でも失敗を招くことは大いにあると思います。

でも、

自分で決めて、考えて行動した結果なら
きっと失敗であっても納得のいくものになると思います

 

大体の大人が仰います。

「人生なんてそう上手くいかない…」

確かにその通りです!!

 

でも、

“上手くいくこと”=”人生を思うがままにする”のではありません。

失敗も含めて全部、自分が招いたことと納得できることこそが
人生を自分の思うがままにする“ということです!!

 

先にも話しましたが、
自責思考はそう簡単なことではありません。
責任を負うことは正直恐いです。

だからこそ自責思考を持ち続けようとする人を私は心から応援したい!

自分の人生を生きようと奮起する、

そんな輝く読者に私はこの言葉を贈りたい。

お前ならできる!

過去のキャリアを全部活かす!WEB業界を新たなジョブで走り始めた女性コンサルのチャレンジとは

0

「この先ずっとWeb業界で活躍したいから」そんな意志を持ってアピリッツに転職したDB部 嶋廻さんは、それまでの仕事とはちがった領域に挑戦中です。転職のいきさつや今の仕事について教えてもらいました。(2020年9月 取材)

デジタルビジネス部 嶋廻 愛子(しままわり あいこ)
2020年3月 アピリッツ入社
サッカー観戦とビールが大好き

過去のキャリアを活かし、未来のスキルを会社と一緒に考える

―― 嶋廻さんはもともとは営業職だったのですよね。アピリッツに興味をもったきっかけは何だったのでしょうか?

前職ではWeb広告の営業をやっていました。そこでの私の仕事は、売り切りのセールスや新規開拓が中心でしたので、次のキャリアではお客様とじっくり長期的にお付き合いをしてビジネスをサポートしたいなと考えていました。つまり、営業に加えてコンサルタントの仕事もできるようになりたいなと……。

ちょうどその頃に、知人の紹介でアピリッツのことを知りました。私が転職を考えていることを少し話すと「嶋廻さんはどんなキャリアをお持ちですか?」「うち(=アピリッツ)でコンサルタントやマーケティングの仕事をやってみませんか!?」と熱烈なプレゼンが始まって(笑)

人生設計や仕事のことをたくさん教えていただきました。※ 写真撮影のために一時的にマスクをはずしていただきました

コンサルタントはまさに私が希望するポジションだったので、話を聞いてみることにしました。それに、中にいる人がこれだけ熱心に自分の仕事や会社をすすめられるって、良いことだなと思ったんです。

―― たしかに、自信を持って「おいでよ!」と言えるっていいですよね。面接はどんな雰囲気で進みましたか?

いかにも「採用面接!」というような形式張った雰囲気ではありませんでした。そして私のキャリアについて真剣に考えてくれる面接でした。アピリッツの今後のビジョンや事業展望を共有していただき、そのなかで私は何ができるか、どう成長していけるかを明確にイメージすることができたんです。

たとえば「こういう事業をアピリッツでは考えているから、嶋廻さんのこのキャリアが活かせますね。そして身につけるべきスキルはこれがいいかもですね」と逆算から組み立てる感じです。私のキャリアプランを一緒に考えてくれているなと感じました。

―― 面接を経て、アピリッツに転職を決めた一番の理由は何だったのでしょうか?

チャレンジできる環境がある、これが最大の理由です。コンサルタントやマーケティングにとどまらず、自分のスキルをいろんな場面で活かせるなと思いました。私の場合、特化型というよりは幅広く色んな仕事ができるようになりたかったんです。アピリッツならディレクターにもマネージャーにもなれるなと考えました。

キャリアに向かって突き進みたい人を応援し、サポートしてくれる良い環境だなと感じました。

Web業界で生き残るキャリアデザイン

―― 嶋廻さんは「営業もコンサルタントもできるように」と仕事の幅を広げていますよね。このキャリア志向の理由をお聞かせいただけますか?

まず、私はこの先ずっと働きたいなと考えています。つまり、ライフステージに関わらずキャリアを積んでいきたい。そしてWeb業界自体が肌に合いますし、とても好きなんです。

そうなると、私の「営業」というスキルだけでは、この先キャリアの道が細くなるだろうと考えたんです。いま私は20代です。これから先、30代から40代になって、育休を取ることもあるかもしれません。そのときに営業一本だけで自分がWeb業界で働ける気がしなかったんです。

ですから、今のうちに仕事の幅をひろげ、あらゆる形で自分が活躍できるキャリアデザインが必要だとここ数年意識するようになりました。

こちらの写真は嶋廻さんと同じチームに所属する新卒の小泉さんが撮ってくれました。

―― まさに「目的から逆算して」いまのキャリアを選んでいるのですね。

そうですね、逆算してプランを練る行為は、ちょうど今私が新しく挑戦している「アートディレクター」の職務と似ている部分があります。スケジュールや目的を常に念頭に置いて、ゴールを逆算しながらタイムラインを組み立て、仕事をすすめる感覚を磨いている最中です。

そして、仕事の流れの中では、マーケティングの仕事で数字の分析を一日中おこなう日もあるんです。なので分析能力についても今後さらに伸ばしていきます。「いつか身につく」なんて悠長なことは言っていられないので毎日緊張感がありますね。

―― 充実していますね。入社して半年経ちましたが、アピリッツのチームメンバーはどんな印象ですか?

「引き継ぎ」がとても丁寧なので驚きました。だから新しい仕事にもチャレンジしやすかったです。新卒の子も案件に加わりはじめていますが、コミュニケーションを丁寧とって進めている印象です。「いっぱいいっぱい」になる前に周囲が声をかけています。

こちらも小泉さん撮影です。たのしそう。

仕事の幅が広がればずっと働ける

―― これからどんな仲間と一緒に働きたいですか?

「素直」な人がいいなと思います。これは自分自身への戒めもこめて……のイメージですね。「やってみない?」とチャンスが目の前にあらわれたときに、「やってみよう!」と思える人と働きたいです。苦手意識のあることを一度だけでもいいからチャレンジする人がいいなと思います。

私の場合、ディレクションには最初から抵抗がありませんでしたが、ずっと数字をみて分析をおこなうことには苦手意識が少しありました。

―― 苦手意識のあることに実際に挑戦して、いかがでしたか……?

幸い、前よりは苦手じゃないです! 仕事の幅が広がったなと感じています。やっぱり仕事の幅を広げるって、男女問わず、キャリアを考える上でとても大切なことです。もともとの営業のスキルや経験の貯蓄だけでは、数十年先まで自分が第一線で働ける気がしなくて。だからアピリッツへの転職はよいタイミングだったと思います。それに、今のコンサルとマネージメントの仕事はとてもおもしろいんです。

――「Web業界で私がずっと働くためには?」を冷静に自問自答してキャリアを築いていく嶋廻さんの笑顔がとても素敵でした。アピリッツは挑戦したい人を応援します!

AWS主催イベント“ANGEL Dojo Season2” 最終成果発表会 レポート

0

AWS主催のエンジニア向けイベント”ANGEL Dojo Season2″の最終成果発表会が先日おこなわれました。アピリッツからは新卒を含む若手エンジニア5人が参加し、3ヶ月間、疑似プロジェクトの立ち上げから開発までを体験しました。最終発表の様子と、3ヶ月の振り返りをお伝えします。(2020年9月 取材)

あらためて”ANGEL Dojo Season2″とは?

AWSが主催する若手エンジニアを対象とした開発イベントです。クラウドを活用したモダンなシステム開発手法やAmazonの文化を実体験できます。企画の立案から開発、そしてプレゼンまでを参加者のみで行います。

アピリッツが今回”ANGEL Dojo Season2″へ参加した経緯やメンバーの選出基準については、西脇執行役員の記事を御覧ください。

関連:出てこい!AWSネイティブ世代 ~若手エンジニアがAmazon Web Services 主催 ANGEL Dojoに参戦!~

参加者は、通常の業務を進めつつ、AWSによる週2回の講義を受け、毎週金曜の10時から18時をワークDayとし、疑似プロジェクトに取り組みました。

関連:新卒も参加中! AWS主催 “ANGEL Dojo Season2” 若手エンジニアインタビュー

こちらの最終成果発表会が9月4日に実施されました。今回の発表会はオンライン開催。カメラに向かってメンバー全員が「どんなものを作ったのか?」「なぜ作ったのか?」「どう作ったのか?」を、スライドとデモを交えつつ伝えました。

発表当日のアピリッツはこんな感じでした

アピリッツのチームは参加メンバーの5人全員でパートをわけて、それぞれが発表しました。

最初に「ばばーん」と盛り上げたほうがよくない? もう一回練習する? デモ画面の大きさはこれで伝わる? わかりやすいプレゼンにむけて、本番までにブラッシュアップを重ねました。

AWSのメンターの方からもアドバイスをいただきつつ、プレゼンに臨みました。

アピリッツの5人が作ったサービスは “こまっち”

アピリッツはトップバッターとして発表しました。

5人が企画・開発したのは“こまっち”というマッチング質問サービスです。サーバレスで動作するシステムで、「誰に質問したらいいんだろう?」と困っているシャイな人を助け、業務とコミュニケーションをより良くします。

開発の経緯については、彼らの実体験も込められています。参加メンバーで新卒入社の小林さんが「入社後すぐにリモートワークになり、先輩や仲間の顔もまだ知らない状況だった。だから、こんな質問していいんだろうか? と、どこか遠慮してしまっていた」と説明していたのが印象的でした。誰かの遠慮する気持ちを後押ししたい! というメンバーの思いが伝わるプレゼンでした。

開発者ではない人にもわかりやすい、とてもフレンドリーで、優しい内容でした

AWSの方からは「こまっち良い! 名前も良い! プレゼンもGoodでしたね!」という感想をいただきました。

質疑応答タイムでも「質問のデータ蓄積」や「相談相手が見つかるまで探し続ける機能」について質問をいただきました

こまっちの開発にまつわるトピックスは、今後アピスピで “ANGEL Dojo Season2” の開発者自らがご紹介する予定です。お楽しみに!

開発者の渡邊さんのレポートはこちら!
関連:ANGEL Dojo Season2 アピリッツチーム 成果発表

「自分たちがやりたいことは、課題を解決すること」

今回、惜しくも受賞は逃しましたが、この3ヶ月で得られたものはたくさんありました。ずっとプロジェクトを見守ってきた西脇執行役員と、アドバイザーとして参加したAI Laboのエンジニア 浅田さん、そして参加メンバーの五人に話をききました。

―― アピリッツにとっての “ANGEL Dojo ” 、いかがでしたか?

西脇:まず、限られたスケジュールとリソースの中で、きちんと着地しきっているので良かったなと思います。

浅田:そうですね。限られた時間の中でうまく折り合いをつけて「ユーザが持つ課題を解決する」という実現すべき価値に取り組めたのではないかと思います。

最初はWebアプリケーション想定だったのを、途中からSlackのBotに切り替えたというのも、ユーザが使いやすいインターフェースで、課題を解決するために最適な手段は何かを考えた結果だったと思います。

つまり、みなさん「自分たちがやりたいことはアプリケーションを作ることではなくて、課題を解決することなんだ」という思いを持って取り組めたんですよね。

そういう意味では、AWS(Amazon) が大事にしているWorking Backwordsという考え方をうまく吸収できているんじゃないかな、と思いました。

DI部 吉岡:今回、Amazonが提唱する価値観のうち、 ”Ownership”、”Learn and Be Curious”、”Deliver Results”を大切にしてほしいと教わりました。この3つは、開発の経験を積むうちに重要性がわかります。まだ経験の浅い若手が、ごく早いタイミングでプロジェクトを通して実感できるのはよかったと思います。

―― アドバイザーから見て、ANGELsのみなさんは開発中どのような印象でしたか?

浅田:一人ずつ言っていきますね。まず柴田さんは技術センスが素晴らしいと思いました。本人は謙遜してますが、StepFunctionsをさくっと組めたのは素晴らしいと思います。

渡邊さんはリーダーシップが素晴らしかったです。ふだん持っている業務がバラバラのチームメンバーをうまくまとめあげていたと思います。

そして吉岡さん。プレゼンの資料作成や、プレゼンの仕方が素晴らしかったです。

小林さんは、(大久保さんもそうですが)新卒でほとんど開発経験もない中で、うまく開発に協力できていたと思います。本番発表で「ばばーん!」と一発かませる胆力がすごいです。

そして大久保さん。「EC2で構築する」という流れができつつあったなか、「本当にそれが最適な構成なのか?」と疑問をもって、切り込んでいった姿勢が素晴らしかったです。あれがなければ、いまの”こまっち”は別の姿になっていたと思います。

「次もあるならアドバイザーなど何かしらの形で関わりたい」

発表後すぐに「このあと、どうしたい?」という話になりました

西脇:このプロジェクトが終わって、みなさんがこれから先の仕事でどう関わっていくかが聞きたいですね。個人的には、社内外のエンジニアとつながれる人となってほしいです。

DB部 渡邊:5人全員が「実際に使える、売れるプロダクトを完成させたい」と思っています。

MS部 大久保:自分たちでゼロから作った企画なので親心のような気持ちが芽生えました。私ももっと開発に携わりたいですし、今後もしSeason3があるなら、アドバイザーや何かしらの形で参加したいです。

DI部 小林:AIの力を借りてマッチングを最適化できれば、“こまっち“はもっと魅力的なアプリケーションになると思いますし、そこを考えるのが面白い。そして、先輩3人がやってくれていたところを、大久保さんとキャッチアップしたい。

西脇:みんなをまとめる仕事とかもね、はやいうちに経験するといいですよ。

DI部 吉岡:このサービスをいつか使ってもらいたい、とにかく、その気持ちが本当に強いです。

DI部 柴田:もし続けられるなら、ゆくゆくはいろんな人に参加してもらって社内の技術向上にもつながるプロジェクトにしていきたいです。

西脇:実現できるといいですよね。全力で応援しますよ!

……ということで、”ANGEL Dojo Season2″は無事閉幕しましたが、いつか続報をお伝えします! 参加者のみなさん、本当におつかれさまでした。

「組織もスキルも自分自身の壁をも超える。求ム、突破型DX人材」 執行役員 兼 DB部部長 長谷亘インタビュー

0

アピリッツの執行役員 兼 デジタルビジネス部・部長の長谷さんに、これまでの自身のキャリアと、これからアピリッツをどう成長させていきたいかを語っていただきました。どちらにも通じるキーワードは「垣根をこえようとする意志」です。(2020年 9月 取材)

エンジニアの会社にアナリストとして2008年新卒入社。0からのスタート

―― 長谷さんは新卒でアピリッツに入られたのですよね?

はい、2008年にアピリッツ(当時の会社名はKBMJ)に新卒で入社しました。当時は「Web2.0」といった言葉が流行った時代でした。懐かしいですね。SNSやブログ、ロボット型の検索エンジンなどのサービスが生まれては消えていく……慌ただしい時代だったなと思います。

私のキャリアですが、1~2年目は「アナリスト」です。アクセス解析ツールの環境を整備し、Webサイトの分析レポートを作成する職種です。その頃はアクセス解析ツール自体が有料で高価だったので、会社に導入するハードルが高く、珍しい職種でした。

さらに、当時の弊社はエンジニアによる開発業務がメインでして、アナリストは社内で私1人。つまり、サービスも、育成も、キャリアデザインも、何をするにも自分で考える必要がありました。

―― 会社初のアナリストとして、キャリアパスをゼロから考える必要があったのですね

そうですね。お客様のニーズに応え続けるために、周辺スキルの何を学び、実践し、ノウハウとしていくか。これを繰り返し考えるわけです。

で、次は「マーケター」を目指します。データを駆使することはアナリストと同じですが、お客様の課題や市場を理解し、Webマーケティング全般の知識と技術を活用してお客様のビジネス価値を上げるのがミッションです。

当時の時代背景を考えると必要な職種でした。ちょうどリーマンショック後で、IT・システム開発への投資に対して慎重な風潮だったのです。ですから、マーケティングの視点で費用対効果を示し、継続的に使えるシステムとして柔軟性や拡張性が問われていました。

そのため、理想論を提言して終わりではなく、お客様のニーズに合わせ、自社のリソースを使って実現可能かつスピード重視の提案を心がけていました。その流れで次の工程であるWebデザインの設計、進行管理・品質管理・制作などの「ディレクター」としての業務も担うことになります。

入社2~4年目の間は「マーケター」と「アートディレクター」を主な職能としていましたね。

マーケティングからデザインまでを繋ぐ一連のサービス提供が十八番

プロフェッショナルとゼネラリストの2つの道が交錯するキャリア

―― そこからは、現場の中心をはなれてマネージャーになったのでしょうか?

いえ、そうでもなくて。これが私のキャリアの少し複雑なところなんです。いわゆる職能(プロフェッショナル)といわれるスキルを積むことと、組織を作る(ゼネラリスト)としての経験が並行で進んでいました。

これは1年目のアナリスト時代から始まっていまして、同期2名を自分のチームに加え、サービスメニューを作り、営業を行い、同時にチームメンバーへの教育も行いました。事業の苗を育てていたのです。

―― あらゆる方面を同時進行で進めていたと?

そうですね。私のキャリアの強みはそこだと考えています。「縦と横の動きが激しい」。つまり、プレイヤー、ゼネラリストという「縦軸」。そして営業、マーケター、ディレクター、デザイナーという「横軸」。このすべてと関わってきました。

マーケターとしての仕事ではデザインの制作と設計が施策として一番実行しやすい。そうなると「デザインの仕事もアピリッツに発注したい」と言ってくださるお客様も増えてきて、デザインの仕事も増えます。

当時のアピリッツでは、デザイナーは、あくまでプロジェクトに点在しており明確なチームはありませんでした。そこでマーケティングの観点をデザインに込めることを強みとしたデザインチームを作り、そこの営業とディレクターを担当、入社4年目に部長代行、5年目からは部長、といった感じで動いています。

当時はがむしゃらで、とにかくお客様のニーズにお応えするために、そしてIT業界で自分がやりたいことを実現するために、気が付いたらチームメンバーが増えていきました。そして、多くの方にご協力頂きました。縦軸と横軸を行き来していたからこそ得られたチャンスだったと思います。

マーケティング・デザイン・エンジニアを繋げることが自社の強さを引き出す

―― 縦と横に広がるので、仕事の幅がどんどん大きくなるのですね

そうですね。今も昔も共通する私のスタイルは、お客様のニーズに応えるために必要なスキルを学び、サービス化し、チームを作り、営業をすることです。お客様のミッションをまっとうするために必要なプロフェッショナル集団を作ることでもあります。

例えば、お客様がWebで作りたいビジネスを実現するためには、「抽象的な要望」を「具体的な要件と仕様」に翻訳していくことが大切です。ここが難しく、ゆえに市場価値の高い工程です。

この翻訳ハードルが下がれはプロジェクトは効率化し、ミッション達成率も高くなりますよね。では、どうすればいいのでしょう?

答えはシンプルで、①ビジネス要件はマーケターが支援、②それをサービスとして目に見えるデザインにして翻訳、③システム側が読み取り、本来の力を十分に発揮してもらう

とてもシンプルです。ただ、これが簡単にできない。プロジェクトマネジャーの経験値や業務スキルも重要ですが、一番必要なのは「垣根を越えようとする意志」です。マーケティング・デザイン・エンジニアを繋げるパーソナリティが大切だと私は考えます。

長谷さんのキャリアパスをご自身で図解してもらいました

自分の役割を限定せず、別の職種のこだわりに興味を持つ

―― そういった素養はどうすれば身につくのでしょう?

とにかく「自分の役割を限定しない」ことが大切です。また、その職種や個人が持つ「こだわり」を理解し、コミュニケーションを行う能力も必要です。

極端な例を出しますと、「営業だから受注したら役目は終わり」、「デザイナー(エンジニア)だから、お客様のビジネス要件にはタッチしない」、「自分の考えたマーケティング施策が最上。あとは実現せよ」という姿勢では、お互いがけん制したり、言わなくてもわかっていると思っていた等、プロジェクトがミスコミュニケーションの巣窟になります。

そういうときは、自分も成長しづらく、プロジェクト内の課題も霧がかかったように見えづらい。一方で、そういう時ほど他人のミスは目につく……よくある負のスパイラルですよね。

―― 長谷さんご自身もそういった課題をもっていたのでしょうか

はい、もちろんです。私自身も垣根を突破しきれていません。

部長になった後(5年目~9年目)、次第に案件が増え、規模が大きくなり、コンサルタントとして提案できる幅が増えました。ただ、デザインまでの提案が多かったんです。開発の提案を加えることが少なかった。

これは意図的ではないですが、プロジェクトの中で、自分が把握できない業務が存在することに慎重になっていたのだと思います。つまり、自分のチームしか考えていなかった。会社に所属しているようで、会社の長年の実績や強さに背を向けていたのですね。

しかし、この課題は解消しつつあります。社内には多様な経験を持つ経営陣やプロジェクトマネージャー、ビジネスプロデューサーがいます。見本となる方々の思考と仕事に触れることで視野を広げることが出来ました。

もともと、会社の特性上エンジニアと一緒に仕事をする機会は多く環境はそろっていました。あとは自分自身の悪癖を理解し、突破するだけでした。

過去の自分らしさを捨てていける勇気が、DX時代では求められる

―― 自問自答の結果が現在のデジタルビジネス部でしょうか?

はい、まさに。開発チームをデジタルビジネス部に加え、お客様のミッションを共に達成するパートナーとしてのあり方を1つ実現できたと思っています。

ただ、まだまだ組織づくりの半ばではあります。2020年から担当している自社プロダクトであるSaaS事業の加速はこれからです。

10年目の2018年からは執行役員として職種の垣根を超えて、開発との融合といったミッションも担っています。自部署内での経験が、社内のマーケティング、デザイン、システム開発を一体化させたプロジェクト推進の架け橋となるべく動いています。

―― 他のメンバーにも長谷さんと同じような「縦と横を行き来する人」となってほしいですか?

はい、急募してます。正直、Web業界では様々なスタイルで働くことができるとは思いますが、会社のスローガンでもある「セカイに愛されるインターネットサービスをつくり続ける」を実現するために必要です。

もちろん、ひとつを深めていくことが自分らしさという人もいます。良いと思います。ただ、「過去の自分らしさを捨てていける勇気を持ったヒト」と働くとワクワクしますね。

なぜか。自分の仕事だけじゃなく、隣の仕事に興味をもって、色んな人と話せるようになると、プロジェクトの霧を晴らすことができるんです。自己成長のチャンスも訪れるはず。結果、それが自分らしさを更に引き立てることになる。素敵だなと。

私たちの会社を求職者の方に説明する際は「垣根をこえてチャレンジできる環境です」と言います。それは、自分自身が体現出来ているため自信をもって話せますし、社内で活躍する方もこの特徴を備えていますので事実です。

ですが、環境だけでどうにかなる話でもないんです。環境に加え、自分自身のパーソナリティと向き合い、それをどう克服するのかを自問自答することが大事かなと。

―― 長谷さんの「未来に向けた自分らしさ」はどのようなところだと思いますか?

悩みますね(笑)…そうですね、「この変化の激しいIT業界の荒波を悠々自適に乗りこなして楽しむ!」ってのができたら自分らしいかもですね。

業界として一般的になって長い「UX=ユーザーエクスペリエンス」という言葉があります。この魔法ワード、実は必要なスキルは明確なのです。それは、ビジネスとデザインとテクノロジーが重なり合ったところにあると言われています。

ですから、ビジネスに限らずデザインにも興味を持つ、テクノロジーでビジネス要件をどのように解決するかを考える、デザイナーがフロントエンドエンジニアの技術領域もできるようになる……。

こんなふうに垣根をこえて、2つ以上の専門ジョブを持つことができる方は、Web業界で需要が高い。と、同時に近年ではDX推進(デジタルトランスフォーメーション)を行う人材に求められていることでもあります。バイタリティをもってこの業界を渡り歩く武器となりえます。

どの時代においてもそんな人物像であることを確信しながら日々を楽しめると「自分らしい」と言えるかもしれません。

ビジネスとテクノロジーとデザインの重なる領域について触れたダイアグラム
引用:Oliver Reichenstein | flickr

社内のあらゆる壁を突破し、アピリッツのビジネスをデザインしたい

―― 執行役員として今後どのようなビジネスを形にしたいですか?

前提として、アピリッツにしかできない強みを社内に作り、世の中に向けて表現・提供することで企業価値を高めていくというのがあります。それを実現するために、業務の垣根を超え、組織のセクショナリズムを突破することでしかできないビジネスをデザインしたいですね。

いくつかある1つに、ゲームデザインの要素をWeb業界のビジネスに転用することを経営陣で考えています。「ゲーミフィケーション」といった概念の活用です。オンラインゲーム内でユーザーのモチベーションを向上させるといったゲームデザインのノウハウをサービス展開するのも良いですね。

社内外、事業、職種といった垣根を超えた先でしか表現できないサービスやプロダクトのアイデアは、周りに転がっている。こういったビジネスの種を仲間たちと一緒に企画・設計して、サービスページや営業媒体を作って、ビジネスに関わるデザイン全般を支援していきたい。

―― 最後に、長谷さんの思い描くビジネスを、どんな仲間と達成したいですか?

時代の変化も加速してきており、DX推進(デジタルトランスフォーメーション)がより一層求められてきています。そのため、スピード感をもって世の中の変化に追いつけるようなマインドを持った方と歩みたいですね。周りがガンガン動いているときって自分もやらなきゃって思いますよね。そういった相乗効果のあるチームを作っていきたいです。

また、チームリーダーの方には、自分でサービスを作る面白さを知ってほしいですね。アピリッツの職位にあるグループマネージャは中間管理職なんですが、弊社の環境も相まってとても面白い仕事です。自分が先頭に立って、やりたいビジネスを実現できて、現場で体験できるんです。そういうチャンスを一緒に掴む人を求めます。

社内アイデアをビジネスとしてデザインし、世の中に広げていければ、もっとアピリッツは成長しますし、意欲のあるメンバーのキャリアも築いてゆけます。組織、スキル、そして自分自身の壁をも突破して、横断的な動きでアピリッツの強みをつくり、発信していきたいですね。

―― 「自分らしさを捨てていける勇気」という言葉が印象的でした。アピリッツにはチャンスがたくさん待っていることを考えると、大切な姿勢ですね。またお話を聞かせてください。今日はありがとうございました!

長谷 亘(Wataru Hase) 
執行役員 兼 デジタルビジネス部部長
2008年にアピリッツに新卒入社。アナリスト、マーケッター、アートディレクター、営業、セミナー講師を経てマーケティング・デザイン事業を立ち上げる。300サイトを超えるデータドリブンに尽力し、ビジネスデザイナー、マーケティングコンサルタントとしてお客様のビジネス拡大に従事。 趣味はロードバイク(東京湾一周、琵琶湖一周など)と、エンタメ料理(キャンプ場でラーメンの麺からこねて、ガラと背油でスープをつくる)。

関連記事:アピリッツのその他の役員インタビュー

Unity作業が捗る便利設定3選 ~ちりつも作業をなくしたい~

0


はじめに

初めまして。コンテンツデザイン部の松村と申します。
現在は新規プロジェクトの開発に携わっています。

〜この記事を書こうと思った理由〜
現在のプロジェクトに移動してから、コードを書くことよりもオブジェクトを操作してUnity上で画面を作っていく作業が多くなり
知っているのと知らないのとでは作業効率に影響しそうなUnityの設定」を先輩エンジニアから色々と伝授していただいたのがきっかけなのですが・・

この記事を読んで下さっている方の中で、Unity作業中、気付けば何度も何度も同じ作業をしているということはありませんか?
・・・恥ずかしいことに私はたくさんありました。


その作業自体は1分で終わるような簡単な作業でも、「塵も積もれば山となる」というように
毎日していれば月単位で数十分、年単位では数時間、またはプロジェクト単位で考えると数日分
時間を取られてしまっている、なんていう可能性もなくはないと思います。

  ちりつも作業をなくしたい(願望)。

個人的には時間だけでなく、「なんか仕組み化できそうなことを、何回も一から繰り返しながら作業する」という事実にモチベーションまで削られていました。
実際に使ってみて作業効率が体感倍くらいに上がったのはよいのですが、
効率が上がれば上がるほど、「もっと早く知ってたらな、気付けてたらな」という気持ちが大きくなっている気もするので
この先、自分のように「もっと早く知ってたら」と思ってしまう人を出来るだけ増やさない為にもここにまとめていくことにしました。

中にはもう知ってた、使ってる、そんな方もいらっしゃると思いますが
興味のある方いらっしゃいましたら、今後の業務にきっと役立てることができると思うので是非軽く目を通してみてください。

どういう時に使えるかという説明 & 簡単な図解を添えて「参考にした・または参考にできそうな記事」をシェアしていきたいと思います。

〜こんな方を対象に書きました〜

どちらかというとVisualStudioCodeなどのコードエディタよりもUnityEditorとにらめっこしている時間が多い初心者〜中級者の方
× どちらかというとUnityEditorよりもVisualStudioCodeなどのコードエディタと向き合っている時間が多い方
なんとなく分けてみましたが、Unity使う人だったら対象です。

1.プリセット作成

使用シーン:コンポーネント追加時、オブジェクト作成時
参考記事 :【Unity】uGUI のオブジェクト作成時に Raycast Target をデフォルトでオフにする方法
対象バージョン :2018.4, 2019.4, 2020.1, 2020.2
公式ドキュメントhttps://docs.unity3d.com/ja/2018.4/Manual/Presets.html

Unityで作業する際に使われないことはないであろう「Add Component」(もしくはオブジェクト作成)。
例えばTextコンポーネントを新しく追加した時に、Unityがデフォルトで色々と値を入れてくれたりチェックしてくれてたりしますよね。

UI>TextでTextオブジェクトを生成した際に、デフォルト値が入っている。

この時

「フォントサイズがよく使うサイズにデフォルトで変わってたらいいなー」

「フォントスタイルが勝手にBoldになってたらいいなー」

と思ったことはありませんか?

その思い、プリセットを作成することで実現できます。

図解:プリセットの作り方。簡単に作れます。

プロジェクトでの作業は特に、デザイン規則に則って画面デザインが出来上がっていくと思うので
毎度毎度違うフォントサイズになることの方がめずらしく、よく使うフォントサイズがあるはずです。

そのよく使うフォントサイズが、Textコンポーネントを使用する時、既に設定されてたらいちいちフォントサイズを変更する手間が省けます。
もちろんフォントサイズだけでなく、フォント、フォントスタイルなどなど、今までいちいち変更しないといけなかった分だけ省けるわけです。

一回の作業量はわずかな時間でも、積み重ねると結構な時間の削減になりそうではないですか?

特に、今のプロジェクトでやってよかったなと思ったのはImageコンポーネントのRaycastTargetのチェックをデフォルトで外したことでした。

RaycastTargetのチェックを外しておく。

Imageコンポーネントを追加した時、デフォルトではRaycastTargetにチェックが入っていますが
このチェックは必要なImageだけにあればいいコンポーネントのはず。
少なくとも今のプロジェクトではRaycastTargetが必要なImageは限られていて、不要になる(=デフォルトでついたままにしていると無駄な負荷がかかってしまう状態になる)ことがほとんどでした。

メンバー各々が「不要なImageにRaycastTargetはつけないようにしよう」と意識することももちろん大事ですが、
最初から外しておく→必要な時はつける、というにシステムにしておけば「忘れてた」ということが防ぎやすくなると思います。

2.カラーパレット(スワッチライブラリ)作成

使用シーン:Imageカラー、Textカラーなどのカラーを変更したい時
参考記事 :Unityでカラーパレットを使う

対象バージョン :2018.4, 2019.4
公式ドキュメントhttps://docs.unity3d.com/ja/2018.4/Manual/PresetLibraries.html

1で触れたことに近いのですが、プロジェクトで使うカラーバリエーションもデザイン規則に則って限定されていませんか?
その為何回も同じカラーを使うことってよくあると思います。
(少なくともその時のノリでイメージカラーがコロコロ変わるということは稀なはず・・。)

フォントやイメージのカラーを変える際に、デザイナーさんから指定していただいたカラーコードが書いてあるメモを探して、そのコードをコピペして・・・という時間、ちりつもです!

ちりつも警察

カラーパレットを作成して、必要なカラーを選択するだけの状態にしてしまいましょう。

図解:カラーパレットの作り方

ついでについてくるいいこと:カラーコードを微妙に打ち間違える、という事態も回避できる。

3.リファレンス検索設定

画像は参考記事から引用しております。

使用シーン:アセット削除する時、どのアセットがどこで使われているかを知りたい時
参考記事 :Unityでアセットの参照を高速に調べるツール【ReferenceViewer】
対象バージョン:ツールによって異なる


「このPrefab(またはTexture)使ってなさそうだから消しちゃおう」


そうやって気軽に消したものの
実は知らないところで使われていてエラーが出る、ゲームが動かなくなるなんていう経験ありませんか?

私はあります。

そんな時に使えるのがリファレンス検索機能なのですが、現プロジェクトで使われている機能は独自に開発されているものだった為、図解等の詳細は大人の事情でこちらで公開するのを控えさせていただきます。
検索してみると色々あるみたいなのでプロジェクトに合ったものを是非探してみてください。

ただ、どの拡張ツールを使うとしても目指しているものは同じ。
「安全に作業を進める」ということです。


プロジェクトに開発初期から携わっているとか、途中から参加したとか関わらず
何のアセットがどこで使われているのか、全てを把握出来ている人ってほとんどいないと思います(多分)。記憶力があるないとかの問題ではないと思うからです。

プロジェクトが進んでいく中で
「デザインが変わってこの素材は使わなくなった」「prefabを作り直した」
→削除
そういうことってよくあると思うのですが
何かを削除する際に最も大事なことは、消した影響がどこに及ぶのかを把握することだと思います(私調べ)。ですので、一発でリファレンスがわかるようにPluginを入れて拡張してしまいましょう。

少なくとも、「消しちゃったけど本当に大丈夫だっただろうか・・」「ゲーム止まらないだろうか・・・」
そんな不安が無くなります(大事)。

まとめ

先輩から伝授した知識を我が物顔でまとめてみましたが、
きっとこの仕組みを知っているだけで
何回も同じ作業をする手間が省け、無駄な時間を削減できるはずです。
浮いた時間でブラッシュアップするもよし、みんなでご飯に行くもよし、早く帰るのもよしだと思います。

もし気になった方いらっしゃいましたら是非活用してみてください。
ご一読いただきありがとうございました。

最近人気な記事