Excel(Google スプレッドシート)の新規関数を使いこなして業務を効率化させよう
こんにちわ、クルーズ株式会社の鈴木です。
今回は開発の話というわけじゃないのですが、Excelやスプレッドシートの新機能を使いこなして業務の効率化をしていこうという話をしようと思います。
表計算ソフトは日々進化している！！
Excel今も昔も様々な会社で使われている超定番の表計算ソフトです。
昔の話過ぎて記憶がかなり曖昧ですが、自分も確かExcel97の時代から触っていて、一番初めに使ったときはVLOOKUP関数すら使いこなせず、数式のエラーに苦戦していた記憶があります。
確か当時のパソコンのOSはWindows 95だったはずなので発売が1995年…
と考えると、約30年近く使っていることになります。
Excel自体は1985年には存在していたようなのですが、PCがビジネスツールとして1人に1台まで普及するようになったのはWindows 95以降だと思うので、Excelがビジネスで使われるようになったのもおそらく約30年前くらいなのかなあと思います。そう考えると自分は相当な古参ユーザーだと思います。
余談ですがExcel以前は、Lotusというソフトと、ジャストシステムの製品で表計算ソフトがあったようですが、このあたりの歴史にはあまり明るくないです。
このようにExcelの歴史は長く、その中で様々な機能のアップデートがありました。グラフがリッチになったとか、リボンUIが採用されるようになった、条件付き書式の設定ができるようになった、拡張子が4文字になったなどわかりやすいものもありますし、各シートで扱える行数が増えたなど処理能力的なものや、関数が増えたなど機能的なものなどさまざまなものがあり、新しいバージョンが出るごとに日々ソフトウェアとして進化しています。
またGoogle スプレッドシートも主要のExcel関数が踏襲されていて、QUERY関数などのデータ抽出系の関数、REGEXEXTRACTなどの正規表現系の関数など独自のものもあり、表計算ソフト全般でみてもソフトウエアが日々進化しています。
一方で利用ユーザはそこまで進化していない？？
上記のようにExcelをはじめとする表計算ソフトは日々進化し便利になっているのに対し、そのExcelを利用している人間はどうなんだろう？？と改めて自分の周りにあるExcelファイルやスプレッドシートを見てみると、あまりアップデートで入った機能や関数などが使われていないものもそれなりに存在しています。特に作成日が新しくゼロから作ったものでも、Excel97のころからあったような関数で数式組んでるなあって、もっと楽に帳票作れるのになあって思うものが多々あり、実は利用者はそこまでソフトウェアのアップデートの恩恵を受けれていないのでは？と思っています。
もちろん私自身がエンジニアで、「この関数使いづらいからもっと効率的数式の書き方とかないの？」とか「この処理ってセルのコピペで絶対ミスるから再利用性の観点でこうやって数式書いたほうがいいんじゃないの？」という長年エンジニアやってるから懸念に気づきやすかったり、調べる癖がついているというもあると思うのですが、それにしても「いやあ、これもっと効率よくできるでしょ」みたいなものもあります。
じゃあなぜ、利用者が最新のExcelをはじめとするソフトウェアの進化の恩恵を受けられていないのか？
こちら、あくまでも私の私見ですが以下の複合要因だと思います。
- Excelというプロダクトの歴史が長く、よい意味で「完成された枯れたプロダクト」になってしまっていて、新しい機能や関数を使わなくても最低限のことはできてしまう。
- Excelの使い方を体系立てて学ぶ機会が多くの場合、社会人1年目か社会人になる直前である。
- 新しい機能や関数について情報をキャッチアップする機会がない。
まず1についてです。
Excelってどのレベルから使えるって言える？の会話でよく登場するVLOOKUP関数ですが、調べてみたところ1985年のリリース当初から存在しています。また条件付き集計関数のCOUNTIF関数はExcel97から存在しています。要するにビジネスツールとして1人に1台PCが支給される時代にExcelの主要な機能や関数はほぼ出来上がってるといえると言えます。
条件付き集計関数の話でいうと、複合条件下のカウントを行うCOUNTIFSという関数がExcel2007で登場しますが、この処理ってIF関数と、COUNTIF関数、あと真偽値(TRUE/FALSE)の概念が理解できていれば、新機能にキャッチアップしなくてもやりたいことはできてしまいます。このように基本的な機能に完成されていて、すでにある機能の組み合わせだけである程度の応用ができてしまうことが一因になっているのではないかと考えられます。
次に2についてです。
PCを使って業務を行っている人は多くの場合、Excelを学ぶ機会が入社直後の研修であったり入社直前の学校の授業かと思います。
通常の研修カリキュラムはその時点の最新版のソフトウエアのバージョンで行うものの、以降それ以降は体系的に学ぶ場が無いためそこで知識がストップしてしまいソフトウェアの進化の恩恵を受けれなくなってしまうと考えられます。
最後に3についてです。
これは本当に書いてあるとおりなのですが、1のExcelがよい意味で「完成された枯れたプロダクト」になってしまっているため、能動的にキャッチアップに動く必要性に駆られないからなのでは？と個人的には考えています。
表計算ソフトの進化でユーザが受ける最大の恩恵は「業務効率化」！！
上記に記載のとおりExcelは非常に優れたビジネスツールであり、そのことが故にソフトウェアの進化して機能が追加されても能動的にキャッチアップに動く必要性に駆られにくい側面はあると思います。
じゃあ、利用ユーザはツールの進化に伴い、ツールの操作方法や関数の使い方など知識をアップデートしなくてよいのか？
こちらは明確に「No」です。新機能を使いこなすことで利用者にも様々な恩恵があります。
では新機能を使いこなすこと最も利用者が受ける恩恵は何か？それは「業務の効率化」だと考えています。
ツールとしてみた際のExcel上での作業の効率化と、業務そのものの効率化の複数の視点で考えてみます。
反復操作が減れば作業の量が減るので、当然作業時間は短くなる
会社でExcelやスプレッドシートを使う業務の大半は集計や計算書の作成です。
その中でもよく使用される関数としてVLOOKUP関数があります。超定番の関数なのですが、いくつかめんどくさい点として
- 検索する値が、検索される表の一番左側にないと検索できない。
- 検索してセルに持ってきたい列が複数あると、列ごとにコピペで持ってきて参照列(第3引数値)を変更するしないとならない。
- 検索値が見つからなかった場合のエラー処理をIFERROR関数などで書かないとならない。
など考慮しないとならないことがあり、地味に手間です。特にめちゃくちゃ容量の大きいCSVファイルをインポートした際など、検索列をCSVファイルの先頭に持ってくるのですら処理が重くて待たされることもあります。
で、最近のExcel(パッケージ版ではExcel2021くらいから)はXLOOKUP関数という上記に列挙しためんどくさいことを行わなくてもよい関数が提供され、この関数を使用することで作業量が大幅に減ります。
XLOOKUP関数もそうなのですが、配列関数というものがあり、複数行や複数列を1つの数式で書くことができるので反復作業がなくなり作業量を減らすことができ、結果として作業時間が短くなります。
反復作業が減れば、数式ミスも確認も再作成も減り業務が効率化する
集計業務でめちゃくちゃ大事で、指導で手をやいていること。それは集計の正確性の担保です。
社内でヒヤリングしているとよくあるのが、新人が作成した集計やシミュレーションをもとにMTGしているとなんか数値おかしいぞってなり、その場でセルの数式を一つずつ確認をしたらコピペミスがあってMTG時間が無駄になった。また再集計とMTGを行い直す必要性が出るので、さらに時間が無駄工数が発生するというような話。
もちろん、表計算ソフトをちゃんと使えていない本人にも問題があるし、事前の研修制度にも問題はあるしOJTトレーナーにも問題はあるとは思うものの、一方でコピペミスが発生する根本要因として、コピペして数式代入しないとならないセル自体が多いからです。
こちらも上記で紹介した配列関数が適切に使いこなせればコピペ自体が減り、確認項目も減り検算も効率化するし、必然的に集計数値の正確性も上がり、業務全体で見た効率も上がります。
新機能を使いこなして業務を効率化させよう！！
このように新機能を使いこなすこと、業務が効率化するという大きなメリットがあります。
表計算ソフトは日々進化して便利な機能が次々と提供されています。そしてその恩恵は業務の効率化です。皆さんぜひ新機能について情報をキャッチアップしてみて下さい！
これだけは絶対に使ってみてほしい便利関数
長文になってしまいましたが、最後にこれ絶対業務が楽になるから使ってみてほしい関数を紹介します。
- XLOOKUP関数(Excel/ Google スプレッドシートで利用可能)
今回の業務効率化の事例として紹介した関数です。
検索作業がめちゃくちゃ楽になります。
- ARRAYFORMULA関数(Google スプレッドシートで利用可能)
こちらも配列関数のような振る舞いをするもので、複数行あった際に一番初めの
行に数式を入れてしまえば一番最後の行までコピペをせずに同じ数式を適用して
くれるという関数です。
コピペ自体が減るので表計算上での作業自体も減るし数値の計算が間違うリスク
が減ります。
他にもこの関数使うととても作業楽になるよってものがあったら紹介していきたいと思います。
ソースコードの品質メトリクス可視化のためにSonerQubeを導入してみた話
こんにちは。クルーズ株式会社CTOの鈴木です。
今回は、ソースコード品質の可視化を行う仕組みをとしてSonarQubeを導入してみようという話です。
きっかけ
ソースコードの品質の基準って何が適切なんだろうというところから話が始まっています。
私がCROOZ株式会社に入社した当時、Jenkins＋CheckStyle＋phpmdなど使って、規約違反や、重複やバグの疑いのあるコードを機械的に探してあげるというこ仕組みを構築し、運用していたことがあったのですが、運用に課題を感じていました。
理由としては、まずコーディング規約に違反があったからといってそれが一概に品質の悪いソースコードとは言えない点、そして疑いがあるものをリストアップしたところでそれが疑いなのかそうじゃないのかの切り分けは結局開発者になり、ある程度継続的デリバリーを提供するツール内でフィルタリングができないと業務効率が悪く、結局開発者もツールが提供する情報を使わなくなると感じたためです。
SonarQubeも基本的な考え方はCheckStyle＋phpmdなどと同じなのですが、大きく違うなと感じた部分については
・ソフトウェアの品質メトリクスとして客観的に判断できる指標があり、それを基準としてPDCAが回せそうであるから。
・PHP以外にAndroidのコードについても静的解析が行えるから。
・視覚的に分かりやすいから
の３点で、テスト的に私の横にあるデスクトップPCに一式インストールを行い実際のサーバサイドのソースとネイティブアプリのJavaのソースでデイリーで実行しまずは使ってみました。
所感
■GOODな点
・ダッシュボードが視覚的に分かりやすい。
・issuesもphpmdと比較すると分かりやすいの精度が高い。
■MOREな点
・日本語の文献の量が少ない。特にカスタマイズしようと思うとしんどい。
・現状のコードをそのまま解析すると膨大な検出件数となり、膨大なissuesが作成される。
基本的に日本語ドキュメントの量が少ないことが最も大きな問題だと感じています。特にQuality Profile周りの設定がよくわからず、結果として自分の中でいまいちな評価になっているのだと思います。
また、今の状況だとSonarQubeに頼らなくてもログファイル上のWarningでもっと先に対応しなければならない顕在化した品質の問題が見えているため、まずはログ上でWarning/Deprecatedが発生している箇所の修正を優先し、SonarQubeでソース解析を行った現実的にPDCAを回せるレベルのソースコードにすることを優先したいと考えています。
上記とは別にSonarQubeのQuality Profile設定周りに詳しい方がいたら是非教えてください！
円安によるITインフラコスト急増に対抗するためにここ1年間で取り組んだこと
こんにちは。クルーズの鈴木です。
昨今、円安がすごいですよね。
年末あたり1ドル150円にまでになった時はさすがに驚きました。
さて、皆さんがお勤めの会社ではドル支払のクラウドサービスは利用しておりますでしょうか？
AWSやGCPなどを利用されている会社はそれなりに多いのではないかと思います。
当社もAWSやGCPを利用しており、2022年ごろか急激に進み始めた円安の影響で当社でもドルで支払っているインフラコストは上昇し、ここ1年で約1～2割多く支払いをしている状況です。
今回は、この円安分の費用上昇分を削減すべく、ここ1年間で取り組んできたことについて紹介したいと思います。
個々の会社によってアーキテクチャや、エンジニアリングチームの体制、得意分野など異なるとは思いますが、同じ悩みを抱えている方で何かの参考になればと思っています。
まずは考え方を変えるところから
「円安でインフラコストあがっちゃってさあ。(省略)。でどうしようか？」
という話を数名としたのですが、リアクションとして「どうしようもなくない？」という反応が大半でした。
確かにエンジニアの視点からみれば、クラウドベンダーはここ1年間同じ性能のシステムリソースに対して同じ金額をドルで支払っていて、かつ原因は為替でありエンジニアとしては為替変動はアンコントローラブルだから、まあ言ってしまえば「どうしようもない」です。
ただ、我々は日本で商売をしていて、お客様から日本円で料金をいただいて、サービスに必要なインフラコストを含む料金を日本円で支払っているので、ドル支払いの金額が変わらなくても、円安になれば日本円での支払額は増えてしまいます。
なので
・為替レート云々ではなく、インフラコストは円換算で考える。
・要するに追加でコストを1～2割削減すればよい。
・為替レートはアンコントローラブルだけど、実装やサービス選定などはエンジニアでコントロールでき、ここで追加削減ができないかを考えればよい。
・上記が実現でき、かつ円安→円高に進めば何もしなくてももっとコストが勝手に下がる
という考え方に基づいてどこの費用減らせる？を考えて取り組んできました。
コスト内訳を細かく分析する
AWSやGCPをはじめとする各クラウドサービスにはコスト内訳の見れるダッシュボードがあります。
例えばAWS だとCost ManagementやCost Explolerなどです。
当社でも以前よりどのサービスでどの程度費用が発生しているか、各サービスのインスタンス毎のメトリクスや、ZabbixやPrometeusなどをはじめとする監視システムで性能的な余剰が無いかなどは確認し、問題があればリソース見直しを進めていました。
だだここも、今までと同じ運用をしているだけでは新たな削減余地が見つけられないため、コストカテゴリ毎や、インスタンスタイプ毎、APIの種類毎などディメンジョンを細分化して一体何の費用発生が多いのかを細かく見ていきました。
EBS料金、ネットワーク転送料金は削減余地あり
コストを分析していく中でEC2やS3、ECSといったサービス単位で分類して考えがちですが、細かく見ていくうえでEBSに対しての費用割合が多いことに気づきました。
当社の場合、ECSやRDSなどのPaaSも使用していますが、EC2の利用も依然あり、端的に言えば仮想サーバのSSDです。
なのでEBSの料金を抑制するために以下を実施、現在も進めています。
・インスタンスのスペックアップにより稼働インスタンス数(EBS個数)を減らす。
→結果としてインスタンス数が減るのでEBSのボリューム数も減る。
・DBを役割別に分ける＆インスタンスサイズの最適化＆稼働インスタンス数を減らす。
→前提の思想は上記記載と同じでスペックアップで台数を減らす。
→役割別に分けることで、１インスタンスあたりのEBSサイズを減らす。
→役割別に分けることで、役割毎に必要な稼働インスタンス数(EBS個数)を減らす。
またネットワーク転送については、細かく見てみると意図していない料金発生がありました。
具体的にはCDN上に配置できるような静的コンテンツに対して、EC2などへの直接参照や、CDN上に同一コンテンツがあるリソースなんだけどオリジンサーバを見ているケースです。
このあたりはコスト分析であたりを付けつつ、ソース上あたりを付け、参照先を差し替えるという地道な対応となるのですが現在進めています。
円安のタイミングにコスト削減を行う重要性
インフラのコストを削減は簡単にできるものばかりではなく、何かしらの作業工数がかかります。
例えば最小構成分をリザーブドインスタンスやSavingsPlans で購入するなど、「買い方」の工夫などは手間も少なく当社も既に取り入れています。
一方でインフラ構成変更やプログラム変更を伴うものもあり、そのような場合に開発、テストなどでそれなりの作業量が発生し、削減施策実施のタイミングや既存開発との優先度などでどちらを先にすべきかで議論になることがあります。
この議論の結論は私の考えとしてはどちらを優先にではなく、両方重要なものなので進めるが正しいと思っています。優先度の議論をすると進まなくなるからです。
当然エンジニアの人数には限りはありその中で何に注力するかという話は重要だと思っています。ただ注力しない = 全くやらないだけだと本当に進まなくなるので、できる範囲で。ただし1週間何もしないのではなく最低でもN時間はコスト削減に充てて少しずつでもよいので進めるという進め方にすべきだと考えて今進めています。
また為替レートはエンジニアから見るとアンコントローラブルだということは、今後上がるかもしれないし下がるかもしれない。であれば、円安のタイミングでコストの削減が行え、仮に仮に将来円高に動けば何もしなくてもさらにコストが下がる。そうすればその削減分でサービス向上のため投資ができる可能性があり、円安の今だからこそ改めてコスト削減余地が無いかについて見なおすべきだと考えています。
今回は具体的なインフラコストの削減事例としてEBS、ネットワークトラフィックに着目した部分について紹介しましたが、ほかにもプログラム的に実施している処理のインフラサービスへの外出し、プログラム改修によるシステムリソース消費量の削減など鯖ざまな施策を行っております。
これらの施策についても機会があれば紹介したいと思っております。
AWSのパブリックIPv4の有償化について
こんにちは。クルーズの鈴木です。
AWSより昨年7月に発表があったとおり、今月よりElastic IPアドレス以外のすべてのパブリックIPに対して課金が発生するような料金体系の変更がありました。
今回はこの話題について触れたいと思います。
Cost ExplolerでVPCの料金が今月急に上がった
実はパブリックIP有償化の件は、既に社内から報告を受けていたものの６か月前だったことで、Cost Explolerで請求内訳をみても「VPC料金急に上がったんだけどなんでだ…？？。最近VPC PeeringやVPC Endpoint新規で作ったっけ…？」
みたいな状況で、請求額が上がった理由がIP有償化だということにすぐには気づけませんでした。
ただ請求書のサービス別料金の内訳をよくよく見ていくと、以下のようにVPCの内訳として「IPv4 address per hour」の記載があり、それでパブリックIPv4の料金有償化の件とつながりました。
月当たりどのくらいの追加課金となったか
当社の場合ですが、前月比で概ね250ドルVPC料金が上がりました。
事前に発表されていたものなので見込んではいたもののせいぜい50～100ドル程度だと予想していたのですが、予想を大幅に上回る金額となってしまいました。
差異要因としては現在も調べているところですが、NATゲートウエイやALBなどのマネージドサービスの場合に複数サブネットにまたがる = 当然IPも複数必要になっている。
という部分の考慮が不十分だったのではないかと考えています。
パブリックIPv4の有償化について
サービス利用側としてIPv4の枯渇の問題は、私が大学に通ってた頃から言われていたことではあるものの今まで当たり前に使えていたものでかなり驚きました。
そして今月のVPC請求額の急増をみて改めてIPv4の枯渇に対する実感が沸いたというのが正直な感想です。
利用してるサービス全体のAWS料金で見れば今回の有償化によるコスト増は1%にも満たないですが、ALBの統合などでIPv4アドレスの利用を少しで減らせる余地が無いかについて今後取り組んでいきたいと考えています。また、続報を更新します。
新卒2年目で業務を通して学んだ重要な3つのことを紹介
こんにちは。新卒2年目のRYOBALです。
入社後1年間サーバーサイドエンジニアとして業務を行い、その後プロモーション部でプロダクト内のデータ分析や広告運用の業務を行っています。プロモーション部に異動し、これまでよりも数値を見る機会が増え、この部署にきて新たな学びもたくさんありました。
今回はそんな僕が業務を行っていく上で、特に為になったなと思った3つのことを実体験をもとに紹介します！
続きを読むエンジニアも外部のメディアに露出することの重要性
こんにちは。新卒2年目のKEN☆YAMAGUCHIです！
今回は「エンジニアも外部のメディアに露出することの重要性」というタイトルでお話をしたいと思います。
僕自身の話をすると、メディアというのはおこがましいですが、本ブログの執筆・Twitterアカウントの運用・イベントへの登壇を経験しております。
これらの経験をしていく中で、エンジニアの方がメディアへ露出している姿を目にすることが多くなりました。その中で感じた技術広報の重要性や実際に行っている広報活動についてお話しできればと思います。
駆け出しエンジニアの方はもちろん、エンジニアを目指している方、エンジニアでメディア露出へのご興味がある方にとってもためになるのではないかと思うので、最後まで読んでいただければ幸いです！
続きを読む