Briswell Tech Blog

ブリスウェルのテックブログです

ExcelファイルからPDFファイルの変換で右往左往した話

こんにちは。このコロナ状況下みなさまどうお過ごしでしょうか?
私、kobayashiこと略名kobaと申します。
今日は駆け出し社員のkobaが実際に起きたExcelの出来事を紹介したい
と思います。
みなさまはExcelファイルからPDFファイルに変換されることはあるでしょうか?

私は、最初「ExcelファイルからPDFファイルにして」と上司に言われた時
Excelってそんなことできるの?すごいじゃん、
と思ったくらい何も知らない状態でExcelを使い始めた状態でした(笑)
最近の出来事でExcelファイルをPDFファイルに変換する作業がありました。

ExcelファイルをPDFファイルにするには

f:id:briswellyuki:20200715183809j:plain PCの上部のExcelの右のファイル押下→名前を付けて保存
→ファイル形式をPDFにして保存
f:id:briswellyuki:20200715183912j:plain

はい、これで終わり........これ終わったらお昼ご飯買いに行こう〜♪
と思ったらPDFファイル変に右端と下が見切れて改ページされてる。。。。
1ページで出したいのに。。。。
f:id:briswellyuki:20200715184212j:plain 色々思考錯誤してみましたが、どうにもできない
しょうがない。。。最終奥義を使うか。。。

チャットを起動して先輩にご教授賜る
改ページ設定結構適当だから自分で調整してとのこと

改ページの設定

改ページの設定はExcelの表示タブの改ページレビューで変更できます
f:id:briswellyuki:20200715184259j:plain 見たら途中で改ページされてました~_~;
改ページの設定終了〜変換したらお昼だ〜♫
名前をつけて保存っと.........あれ?なんで?前と同じく見切れる
そこから30分ぐらい色々調べて格闘。。。わからん
見かねた先輩が大丈夫か聞いてくれた
修正したファイル送ったら見切れないPDFファイルで変換できたとのこと
なんで?なんかの設定?Excelのバージョンが違うせいなのかなぁ。。。
とりあえずは先輩が送ってくれたPDFファイル使えばいいですが
これから変換する作業あったらどうしよう、と思っていると

上司がPDFへの変換方法が原因ではないかとのチャットが入る。
あぁ。。そういえばプリントからPDFで保存できたことを失念してました。

プリントからPDFで保存

f:id:briswellyuki:20200715185311j:plain プリントからPDFで保存したら1ページのPDFファイルできました〜
どうやら名前をつけて保存するPDFへの変換方法は
勝手に改行変えてくることがあったりするらしいです。
ExcelからPDFファイル変換作業は
プリントからPDFで保存しようと心に誓うkobaであったのでした。

ささっと作れたDockerのMySQL5.6

はじめまして。コロナの影響により2020年4月に中途入社してから3ヶ月間フルでリモートワークとなり、7月に初めてオフィスに出社したid:rosoneです。

リモート歓迎会、リモート入社手続き、リモート引き継ぎ、と数年前には想像もしていなかった働き方が日常となりつつあります。

はじめに

Macで開発していく上でローカルにデータベースを持ちたくなりました。

ローカルにデータベースを作成するための様々な手法が存在している中、私にとってDockerがベストな選択肢となったので、その一連の流れを紹介します。

以前試したことがある他の方法の所感をまとめます。(3~4年前の記憶なので、今は状況が変わっているかもしれません)

  • Macにグローバルインストール:home brewでささっと導入はできるものの、複数DB(異なるバージョン)の切り替えが面倒
  • vagrantvagrant起動中はPCリソースを多めに使用しているのか、全体的にPCが重くなってしまった(仮想環境上でOSが動いているのでしかたない)

Dockerなら上記で抱えていた問題を一挙に解決してくれそうだが、Dockerでmysql環境を作るのは初めてなので構築に時間がかかってしまうかな…と尻込みしていました。

しかし思いのほか簡単に作れたので、作成の手順を紹介します。

0.事前準備

Docker Hub

上記からDocker Desktop for Macをダウンロードし、インストールを行います。

インストールが完了するとDockerコマンドが使用できるようになるので、下記のコマンドを実行してversion情報が表示されていれば成功です。

$docker version
Client: Docker Engine - Community
 Version:           19.03.8
 API version:       1.40
 Go version:        go1.12.17
 Git commit:        afacb8b
 Built:             Wed Mar 11 01:21:11 2020
 OS/Arch:           darwin/amd64
 Experimental:      false

Server: Docker Engine - Community
 Engine:
  Version:          19.03.8
  API version:      1.40 (minimum version 1.12)
  Go version:       go1.12.17
  Git commit:       afacb8b
  Built:            Wed Mar 11 01:29:16 2020
  OS/Arch:          linux/amd64
  Experimental:     false
 containerd:
  Version:          v1.2.13
  GitCommit:        7ad184331fa3e55e52b890ea95e65ba581ae3429
 runc:
  Version:          1.0.0-rc10
  GitCommit:        dc9208a3303feef5b3839f4323d9beb36df0a9dd
 docker-init:
  Version:          0.18.0
  GitCommit:        fec3683

1. イメージのpull

イメージを Docker Hub から取得します。

$docker pull mysql:5.6

今回の開発ではmysql5.6を使用しているので、ローカルも同じバージョンで作成するために mysql:5.6 を指定しています。

バージョンを指定せずに実行すれば最新版のイメージを取得できます。

$docker pull mysql

5.6以外のバージョンも指定可能です。

$docker pull mysql:5.7

2. コンテナを作成する

コマンドを実行してコンテナを作成します。

コマンドの末尾に先程pullしたイメージを指定します。今回はmysql5.6で作成したいので、mysql:5.6を指定しています。

$docker run --name お好きな名前をつけてあげてください -e MYSQL_ROOT_PASSWORD=お好きなルートパスワード -e MYSQL_USER=お好きなユーザー名 -e MYSQL_PASSWORD=お好きなパスワード -p 3306:3306 -d mysql:5.6

実行結果

$docker run --name onamae -e MYSQL_ROOT_PASSWORD=rootpass -e MYSQL_USER=admin -e MYSQL_PASSWORD=pass -p 3306:3306 -d mysql:5.6
4b6970430841f4f4d9aef5602dfd8fd1a36766c73da2307006d45e09123fbbbb

今回はonamaeという名前で作成しました。

コマンドが成功したら、Docker Desktop上で下記のように表示されており、起動済みの状態で作成されていることを確認できます。

f:id:rosone:20200708193407p:plain
step2-2

3. 作成したデータベースに接続する

すでに2.の手順でコンテナは起動済みなので、アクセス情報を入力して接続します。

接続ツールはお好きなものを使用して問題ありませんが、今回はSequel Proを使用します。

ユーザー名とパスワードは作成時のものを指定するので、今回は下記を指定します。

  • ユーザ名:admin
  • パスワード:pass
    f:id:rosone:20200708193828p:plain
    step3-1

接続のテストをしてみると、疎通に成功しました。

あとはそのまま接続すれば、データベースにアクセス出来ます。

f:id:rosone:20200708193837p:plain
step3-2

おわりに

今回はイメージのpullからコンテナの立ち上げまでを紹介しましたが、Dockerにはまだまだたくさんの機能があり、奥が深いです。

本記事では紹介できませんでしたが、Dockerfileというファイルに設定を記述することで、コンテナの構築を自動化することもできます。

コンテナの構築を自動化することで、チームメンバーに配布して同等のローカル環境を構築してもらう、Amazon ECS等を利用して本番環境も構築しちゃう、など嬉しいことがたくさんあります。

私はまだコンテナの構築自動化はやったことがないので、実際に試してみて良い感じだったら記事にまとめようと思います。

社員旅行 動画のご紹介!!(過去の)

どうもこんにちは。 ブリスウェルのとしと申します。

東京都では新型コロナウィルスの感染者数が再度増加傾向にあり、中々お外に出れない日々が続いてますね...
私はこの土日、旅行に行きたい気持ちを抑えるために、過去の社員旅行動画をみてニヤニヤしてました。

弊社では、毎年11 ~ 12月頃に社員旅行に行ってます。
国内の時(昨年は熱海旅行でした)もあれば、ベトナムメンバーと合流し、ベトナムの観光地に行くこともあります。

過去に2回、社員旅行の動画を作成したので、今回は社員旅行動画をご紹介いたします!


2016年 ベトナム フーコック

www.youtube.com

www.google.com

場所は真上がカンボジアです。
4年前ですが、2日目に行った遊園地がとても印象的でした。
遊園地の中に、水族館と巨大なプールがついてました。
プールサイドで昼間から飲むビールはとても美味しく、直角落下するウォータースライダーに泣きそうになりながら乗った記憶があります。 (代表と取締役、ベトナムの代表と4人で乗りに行って、「とし、最初行け」と言われた記憶があります。パワハラではないです。代表などもみんなで一緒に楽しみましたという意味です。)
宴会といえば
「モッハイッバー ヨォー!!!!!!(Một Hai Ba Vô!!!!!!)」と言い何度も何度も乾杯をします。
Một → 1
Hai → 2
Ba → 3
なので、「1,2,3 ダー」的な感じかな?

とても楽しかった思い出なので、また行きたいな〜。

2018年 ベトナム クイニョン

www.youtube.com

www.google.com

今度は中の方の地域です。
本当はダイビングなどが計画されていたそうですが、天気に恵まれず...(雨もありましたが、かなり風が強かったです。)
割とのんびりとした旅行で、海をみながらココナッツジュースを飲み、とても癒された記憶があります。

どちらの動画にも登場しますが、2日目の夜はみんなでパーティーをしています。
チームに分かれ、特定のゲームを行い、勝者は景品がもらえるような物でした。

日本だと結婚式でビンゴを行ったりしますが、あまり社員旅行でこういったゲーム的なのはやらないですね。
とても新鮮で、言葉がわからなくてもチームで団結して、盛り上がれることができたのでとてもおすすめです。


2019年 熱海旅行

最後に、これは昨年の熱海 社員旅行の画像です。

f:id:Toshi_bw:20200713165352j:plain
熱海旅行
この時はビンゴ大会を行い、1等は「ディズニーランド」のペアチケットでした。
その後、弊社 AI & IoT 担当 大澤先生によるマジックショーがありました。
間近でマジックを見るのは初めてでした... どんなに近くでみても全くわからず、AI & IoT もできてマジックもできるとても稀有な存在です。


今年は社員旅行に行くことは難しそうですが、またみんなでいける日を待ちながら日々、良いシステム開発を行い、お客様に貢献して行こうと思います。

社内のディジタル・トランスフォーメーション

f:id:brix:20200708182201j:plain Photo by Jezael Melgoza on Unsplash

こんにちは、加藤です。 さて、最近はDX、ディジタル・トランスフォーメーションというキーワードが百花繚乱ですが、ブリスウェルはお客様のDXを支援しているので、このあたりについて書いてみます。

コロナによるソフトウェアの活用、オンライン化の加速

今回の新型コロナウィルスで、リモートワーク関連のシステム、ツールの注目度が一段と上がりました。 弊社ブリスウェルは業務システム、SaaS、モバイルアプリ、IoT、AIなどのソフトウェア開発をかれこれ10年以上やっているのですが、これほど急速に市場の環境が変わった事は記憶にありません。

ソフトウェア企業である弊社が、クライアント企業のIT化・デジタル化を提案・推進していく中で、最も難しいことの1つに、 業務プロセスや意思決定プロセスのデジタル化による効果を事前に予測する、あるいは定量的に概算すると言う点があります。 誰もが効果が大きいことは分かっているのに、それがどれくらい大きいかという規模感になると、クライアントのメンバー間でも元にするデータや意見がわかれ、精緻に予測出来ないことも多いかと思います。 一方で、大まかな方向性を決めて一気呵成にDXできる企業は、その俊敏さで今まで大きなアドバンテッジを得て来ました。

ところが、今回のコロナ渦によって、ディジタル化は多くの企業にとって死活問題であるということが明らかとなってしまいました。 例えば、オフィスワーカーにとってオンライン会議ツール、チャット、ワークフローツールがマストであるというレベルの説明は、全く不要となりました。

note.com

コミュニケーション領域ではどの会社も新たにZoom、GoogleMeet、Slack、Teamsなどを取り入れて、メールと電話からの脱却、代替がなされたと思います。 積年の課題だった「脱エクセル」が急に加速してきたという話も聞きます。 結果、こういった施策ではもう差別化にならなということなのかと思います。

オンラインツールを利用するからオンラインファースト、ソフトウェアドリブンへ

僕はここ数か月はもう一歩踏み込んで、オフラインからの脱却、代替ではなく、オンラインベース、オンラインファーストの業務への転換をご提案しているところです。

そもそも、僕たちのようなソフトウェア開発会社は、従来から開発タスクのほとんどをオンライン上で管理してきたという経緯があります。 PJTのマスタスケジュール、人材リソースのアサイン、WBS管理、Q&A・ターミノロジーなどのKM機能程度は、数年前から非エンジニアの利用を含めてほとんどオンラインのチケットツールに一元化されています。 エンジニアチームはgit、CI/CD環境を使って、ソースの管理したり、テスト・デプロイ自動化を進めています。 このあたりのレベルはもう一般的ですね。

ブリスウェルではもう一歩踏み込めるかどうかというところで、エンジニアチームのやり方を全社的に取り込んで、 例えば、設計チームが作成するドキュメントも徐々にgit管理に移行したりなんてことも起こっています。

もう少し時間がかかりそうですが、このままツール間の連携が進めば、オンラインツール側がPJTをドライブしてくれるようになるかもしれません。 例えば、プロジェクトマネージャが行っている進捗管理タスク程度なら、ソフトウェアが巻き取ってくれることになると思います。(というか既にほとんど巻き取っています。)

考え方としては、

・旧来の「オフライン業務をベースとして、オンラインで出来ることはオンラインにする」から、 ・今後は「全部オンラインに載せて、ソフトウェアベースでのオペレーション最適化を図る」

になるのかなと。

僕たちソフトウェア開発企業の場合

我々のバリューチェーン(古いですね)というか、業務フローでは、妄想、構想、計画、要件定義、設計、開発、検証、導入・・・とあるのですが、 後半になるほど管理が仕組み化できて、ソフトウェアドリブンになっています。

・人が、プロジェクトをタスクに分割し、 ・ソフトウェアが、タスクを人にアサインし、 ・人は、タスクをこなしpushする。 ・ソフトウェアが、検証・マージ・デプロイし、・・・ ということがなるんだろうなと感じています。

そうなれば、プロジェクトマネージャは重要な意思決定、ビジネスやプロジェクト全体の成否を左右するディシジョンに、より時間を使えることになります。 設計担当者は、UIや機能の仕様詰めの際に、PoC、R&Dにもっと時間を使ったりできるかもしれません。

開発チームへのインパクトはさらに大きくなります。 技術的な難易度の高い領域、例えば最近のアーキテクチャではBFF(Backend For Frontend)レイヤーの設計難易度が上がっているので、 こういった付加価値の高い部分に腰を据えて議論できるようになると思います。

ただ、聞こえようによっては、「オンラインツール・ソフトウェア・プラットフォーム側がマネッジし、人側がそれに沿って動く」と言うのは、ちょっとディストピアな雰囲気がします。 僕はそういう意図ではなく、どちらかというと、人が本当にクリエイティブなところ、差別化できる所により多くの労力をかけられるようになるのではないかと言う側面に期待しています。 Software Driven(ソフトウェア・ドリブン)ではなく、Software Inspired(ソフトウェア・インスパイアード)のような感じです。 当面、社内ではこういったDXはどんどん進めていきたいと思っています。

思想、手法、ツールについて、なかなか全部を書くことが出来ないのですが・・・、ぜひ他のソフトウェア開発企業の方の話を聞いてみたいです。

SaaS・サブスクサービス開発が増えています

f:id:brix:20200629204044j:plain
Photo by Tai's Captures on Unsplash

今、SaaS・サブスクサービス開発が増えています。

背景はほとんど言い尽くされていると思いますが、システム開発側の観点を書いておきたいと思います。

①新型コロナウィルスによる働き方への影響

新型コロナウィルスによって世界的にも日本でも(特に東京でも)デスクワーク職種のリモートワーク化が急に進んでいます。 日本では緊急事態宣言が終わったあとリモートワーク解除になった会社もあるようですが、そもそもWork From Anywhereがデフォルトになった会社もたくさんあります。

わかりやすい所で言えば株式市場へのインパクトは絶大で、医療製薬創薬などのコロナに直接関係する業界と並んで、リモート関連企業、オンライン関連企業、SaaS関連企業と括れるようなソフトウェア企業への期待があがっています。

市場でなくても、Zoom、MicrosoftのTeams、Slack、Docusignのような企業・サービスは、ほとんど毎日のようにどこかで名前が上がってるような気がします。

②ビジネスモデルへのインパク

ブリスウェルの本業ではないが、SaaS製品の導入に関するアドバイスを求められることが文字通り激増しています。 (うちは代理店でもないので客観的な意見を言っていると思います。)

それに伴って、我々のB2Bソフトウェア受託開発事業(顧客企業向けのソフトウェア開発事業)に対する問い合わせ内容もかなり大きく変化してきました。

例えば、クライアント企業内で長年滞っていたようなSaaS事業が動き出したり、オフラインの伝統的なコンサルサービスを畳んでオンラインのコンサル、ナレッジシェアサービスを始めるなどと言う話もあったりします。

もちろんチャージの方法も、売り切り・都度課金から、サブスク・継続課金・前払いを想定した話に変わってきています。 肌感で言うと、今までオンラインサブスクでの収益に無頓着だった伝統的な企業が、より急速に頭を切り替えてチャレンジされてるように見えます。 一方で、もともとサブスク型のビジネスを運営していた企業は、やっと波が来たと言う会社もいらっしゃったり、周りも始めちゃったので更に差別化が必要なんて会社もあったりです。

③ソフトウェア開発へのインパク

旧来の保守・メンテナンスから、やっと文字通りのDevOpsになるチャンスな気がします。

旧来の保守と今のDevOpsとの大きな違いは、ざっくり言えば「継続的にサービスの向上を図ると言う前提」にあると思います。

ブリスウェルが開発しているシステム、サービスは数年前からかなりメンテナビリティ重視だったのですが、ここへきてクライアント企業からも当領域への細かな要望が出てくるようになったのかなと。

アプリケーションアーキテクチャへ理解・要望がどんどん細かくなり、大まかに行ってマイクロサービス化、疎結合化の流れが加速していると思います。

ブリスウェルのような顧客向けのソフトウェア開発業は、アプリケーションアーキテクチャに関して弊社側から提案し、クライアント側が合意してくれると言うようなステップをとることが多いのですが、

足元数ヶ月ではもう1歩進んでクライアントがビジネスを構想する段階で前もってそういった考え方が共通認識となっていることが多いように思っています。

本題に入る前に既にかなり長くなってしまったので、技術的な詳細は次の機会に譲ろうかと。。。

なお今回のブログは、すべて音声入力で書いてみたのですが、かなり多くの口語が入ってしまうので、この辺もテクノロジーで文語調に直してくれたらいいなと。

コロナ時代のサブスクサービス開発はこちらへ。https://www.briswell.com/news/remote-online/

以下、DeepL

ーーー

Translated by DeepL

Right now, SaaS and subscription development is on the rise.

I think most of the background has been said, but I wanted to write about the perspective of the system development side of things I think.

(1) Impact of the new coronavirus on the way we work The new coronavirus has led to a worldwide increase in the number of people with remote, desk-bound jobs, both in Japan (and especially in Tokyo) and around the world. The shift to remote work is progressing rapidly. In Japan, there are companies that have lifted the restrictions on remote work after the declaration of the state of emergency. There are many companies that defaulted on Work From Anywhere in the first place.

To put it in plain English, the impact on the stock market has been tremendous, directly into the corona of medical and pharmaceutical drug discovery, etc. Along with related industries, you can group them together as remote stocks, online stocks, and SaaS stocks. The stock prices of software companies like

For example, Zoom and Docusign seem to be mentioned almost every day. I feel like I'm a good candidate.

(2) Impact on the business model. Although it's not Briswell's core business, I've been asked to advise on the implementation of SaaS products It's literally increased dramatically. (We're not an agency, so I think I'm being objective.)

With that, our B2B software contract development business (software development business for clients The nature of the inquiries we have received from clients (for example) has changed quite significantly.

For example, we've seen SaaS projects that have been stalled for years within our clients start to take off, and we've seen offline to start an online consulting and knowledge-sharing service by folding the traditional consulting services of And so on.

And, of course, the method of charging, from selling out and charging at a time, to assuming subscriptions, ongoing charges, and payment in advance. The story is changing. In a skin-deep sense, traditional companies that have been indifferent to online subs revenue are now more rapidly It looks like they're changing their minds and taking on the challenge. On the other hand, some companies that originally operated a subscribed business say they're finally seeing a wave of There are some companies that need to differentiate themselves further from others because they have started to do so too.

3) Impact on software development I feel like this is an opportunity to finally go from old-school maintenance and upkeep to literal DevOps.

The big difference between old-school maintenance and today's DevOps is that, to put it crudely, "We're going to continuously improve our service I think it's in the "assumption that we will figure it out".

The systems and services that Briswell develops have been quite maintenance oriented for several years now, but I think we are starting to receive more detailed requests for this area from our clients.

The understanding and demands for application architecture are becoming more and more detailed, and I think the trend toward microservices and loosely coupled systems is accelerating.

However, in recent months, we've seen a lot of clients go one step further and come to a common understanding in advance when they start to think about their business.

I've already gone on quite long before I get to the main topic, so I'll leave the technical details for the next time. .

In addition, I tried to write this blog entirely in voice input, but it contains quite a lot of spoken words. So I'm hoping that technology will fix this area to a literary tone as well.

To see the development of subscription in the Corona era, go to https://www.briswell.com/news/remote-online/

Here's a link to DeepL

Translated with www.DeepL.com/Translator (free version)

Pythonで江戸パワポ作成

江戸の古地図

夜な夜な江戸の古地図をながめるのが最近の和みです。

ふと、古地図で移転前の弊社オフィス(@恵比寿)周辺を眺めていると、ドラマの撮影でよく使われる「タコ公園」前を流れる渋谷川は、当時も同じように流れていました。

渋谷川を調べてみると

春の小川は さらさら行くよ〜♪

この歌のモデルになっているらしい。その昔、歌のように川の水はとてもきれいで、蛍もいたようです。

また、タコ公園周辺には、大きなお屋敷(森越中赤穂藩下屋敷)もありました。恵比寿駅東口の五差路も当時から存在しています。何かワクワクしませんか?

江戸庶民の生活

さて、江戸時代の地図に想いを寄せていると、その当時の生活はどのようなものであったのか気になってきました。

www.php.co.jp

こちらの本を今読んでいるのですが、江戸庶民の生活模様が、収入やモノの値段からうかがい知れてとても興味深いです。宵越しの銭を持たず物事に執着しないのが「江戸っ子」の美学と言われています。隣近所が一つの家族のようにワイガヤで楽しく助け合いながら暮らしていたのでしょう。当時の情景が目に浮かんできます。

江戸パワポ

と、ここでテックブログなので... 一つPythonネタをご紹介します。

下図のように、Microsoft PowerPointのテンプレファイルに、新しいスライドを追加し

  1. タイトルテキスト
  2. 円グラフ
  3. テキストボックス

を挿入することができます。

f:id:KenjiU:20200628204157p:plain

データ引用:
中江 克己(2003/8/1) | お江戸の意外な「モノ」の値段 物価から見える江戸っ子の生活模様(PHP文庫) | 位置No.176/2899

1. ライブラリの定義
from pptx import Presentation
from pptx.chart.data import ChartData
from pptx.enum.chart import XL_CHART_TYPE, XL_LEGEND_POSITION, XL_LABEL_POSITION
from pptx.util import Cm, Pt

以下の「python-pptx」ライブラリを使用します。 python-pptx.readthedocs.io

2. テンプレとするパワポを指定
prs = Presentation('edo_expenses_template.pptx')
3. 空のスライドの挿入
title_only_slide_layout = prs.slide_layouts[1]
slide = prs.slides.add_slide(title_only_slide_layout)
shapes = slide.shapes
4. タイトルテキストの挿入
shapes.title.text = '江戸時代のある大工さんの家計'
5. 表の挿入
# 表のデータを定義
name_objects = ['支出項目','匁']
name_expenses = ['家賃', '飯米', '塩・味噌・油・薪炭', '道具・家具', '衣服費', '音信・祭礼・布施']
val_expenses = [120, 354, 700, 120, 120, 100]

# 表の行数と列数
rows = 7
cols = 2

# 表を挿入する位置
top_table = Cm(6)
left_table = Cm(3)

# 表の幅と高さ
width_table = Cm(14)
height_table = Cm(7)
table = shapes.add_table(rows, cols, left_table, top_table, width_table, height_table).table

# 表のヘッダーの定義
table.cell(0, 0).text = name_objects[0]
table.cell(0, 1).text = name_objects[1]

# 表のボディの定義
for index in range(len(name_expenses)):
  table.cell(index+1, 0).text = name_expenses[index]
  table.cell(index+1, 1).text = str(val_expenses[index])
6. 円グラフの挿入
# グラフを挿入する位置
top_graph = Cm(14)
left_graph = Cm(5)

# グラフの幅と高さ
width_graph = Cm(21)
height_graph = Cm(12)

# グラフのデータを定義
total = sum(val_expenses)
def calc_double(n):
    return n / total
val_expenses_percent = list(map(calc_double, val_expenses))

chart_data = ChartData()
chart_data.categories = name_expenses
chart_data.add_series('Pie', val_expenses_percent)

graphic_frame = slide.shapes.add_chart(
    XL_CHART_TYPE.PIE, top_graph, left_graph, width_graph, height_graph, chart_data
    )
chart = graphic_frame.chart

# グラフのプロパティを定義
chart.has_legend = True
chart.legend.position = XL_LEGEND_POSITION.BOTTOM
chart.legend.include_in_layout = False
chart.plots[0].has_data_labels = True
data_labels = chart.plots[0].data_labels
data_labels.number_format = '0%'
data_labels.position = XL_LABEL_POSITION.OUTSIDE_END
7. テキストボックスの挿入
# テキストの定義
text = '※銀一匁は現代で約1,250円です。'

# テキストボックスを挿入する位置
top_text = Cm(14)
left_text = Cm(3)

# テキストボックスの幅と高さ
width_text = Cm(5)
height_text = Cm(2)

# フォントサイズ
text_font = 20

# テキストボックスの定義
text_box = slide.shapes.add_textbox(left_text, top_text, width_text, height_text)
text_box.text = text
text_box.text_frame.add_paragraph().font.size = Pt(text_font)
8. ファイル保存
prs.save('edo_expenses.pptx')

以上です。
AI学習モデルの予測精度やデータ分析の報告書作成などにも利用できそうです。

株式会社ブリスウェル

行き先掲示板IoT化計画(仮)

こんにちは大澤です. こちらの記事(クラスタリング勉強会 - Briswell Tech Blog)でAI勉強会を実施した大澤です.

  • 特技はマジック(クロースアップ)

  • 好きなものは紅茶とチョコレート(チョコレートスペシャリストの資格保有)

  • 苦手なものは犬・猫

  • 最近の趣味はカリグラフィの動画を見ること

・・・

さて,新型コロナウィルスの騒ぎがあり,ブリスウェルでは3月からリモートワークを実施しています.7月からは様子をみながら徐々に出社(時差出勤)の方向性になっていますが,引き続きリモートのメンバーもいます. 通勤時間が0になるという最大のメリットを享受していましたが,4ヶ月も続くと不便な点も出てきます.

例えばリモートだと相手の状態がわかりません.

出社してれば「今MTG中かな」「もう帰っちゃったかな?」というのが分かります.(わからないときもあります)

昼休憩に入るときも,リモート時はチャットで休憩に入る旨を伝えています.

なんとなぁく不便だなぁと感じていたので,ブリスウェルのIoT担当として何かソリューションを考えようと思い立ちました. これはつまり,古き良き「行き先掲示板」をIoT化してあげたら良いのかも知れません.とするとこんなものはいかがでしょう.

f:id:kyoshi0000:20200627202610p:plain

ステータス管理ボックスと名付けました.決してふざけているわけではありません.

説明しますと,これは手のひらサイズの箱(or ブロック)のデバイスです.例えば「出社」の面を上にするとその人のステータスは「出社」となり,「MTG」の面を上にするとステータスが「MTG」となります. このデバイスを各メンバーが持ち,それぞれのステータスデータをサーバに送ってあげることで,各メンバーのステータスを確認できるじゃないか!というわけです. これを実現するためには,どの面が上になっているかを知る必要があります.これは加速度センサをデバイスに仕込んであげればできそうです. また,データをサーバーに投げるので,ネットに繋いであげる必要もあります.

なんとなくできる気がしてきたので,早速作ってみました.

【用意したもの】

  • 押し入れに眠っていたWiFiモジュール「DSP-WROOM-02」(ESPr Developer)
  • 早速買った3軸デジタル加速度センサモジュール「ADXL345」

ESP-WROOM-02arduino IDEを使用して開発できるので非常に楽です.

また,加速度センサはアナログ出力ではなく,デジタル出力でないといけません. (ESP-WROOM-02にはアナログ入力ポートが1つしか無いので,3軸のアナログデータを取得するのが難しいためです)

【作ってみる】

こんな感じで接続して,arduinoIDEでプログラムを書き込んであげると… f:id:kyoshi0000:20200627204941j:plain

なんと加速度が取得できます.X軸,Y軸の値は小さいですが,Z軸の値が大きく出ていますね.つまりデバイスは上向きであることがわかります. f:id:kyoshi0000:20200627205049p:plain

次にESPをWiFiに接続してセンサデータをサーバに投げます. PHPで受け手側のプログラムをなんとなく書き,ローカルサーバを立ち上げ,センサデータを投げるプログラムをESPに書き込みます. ブラウザを立ち上げて,作ったデバイスの向きを色々変えてみます.すると… f:id:kyoshi0000:20200627205433p:plain

出社!



この向きだと… f:id:kyoshi0000:20200627205533j:plain

f:id:kyoshi0000:20200627205742p:plain

お昼!  …ん??

f:id:kyoshi0000:20200627205840p:plain

うーん,向きに応じて異なるデータを送ることはできていますが,表示の仕方に工夫が必要ですね…この辺りは他のメンバーの方が得意そうです.

表示はどうにかしたいですが,やりたいことはできました. こういうのは未完成でも基本的な機能ができた時点で人目につく場に出してフィードバックをもらうべきだと偉い人に教わりました. いかがでしょうか.

ステータスを管理してメンバーで共有するだけならそういうWEBサービスを使えばいいだけですが,リアルの世界の動作と紐付けられるのはIoTの強みだと思います.

なかなか外出できない土日を有意義に過ごすことができました.

システム開発プロジェクト成功の秘訣 ー 提案編 ー

東京は梅雨入りしてジメジメしてますが、いかがお過ごしでしょうか?

新型コロナの感染者もまだまだ収束していないため、ブリスウェルではリモートワークを継続しているメンバーも多いです。

さて、今日はシステム開発プロジェクト成功の秘訣と題して、書かせていただきます。

私自身、システム開発の仕事に携わって20年以上経ちますが、とても難しく奥深い仕事だと未だに感じています。

今までの経験から、システム開発を成功させるために重要だと考えていることについて、提案編と題して私の考え方をご紹介させていただきます。

ブリスウェルの主力事業はシステム開発サービスで、お客様からシステム構築の依頼を受けて、システムを開発して納品する仕事をしています。

システム開発を外部の会社に委託する場合、発注サイドと受注サイドがいて、システムの完成まで両者が協力し合い、完成後もより良いものに育てていく必要があります。

単に売って終わりというわけではなく、契約後も協力してアウトプットを創り出していく必要のあるビジネスです。

ブリスウェルのような受注者サイドとしては、

・お客様のビジネスや業務の流れ

・既存システムの仕組みやデータの流れ

・関連する外部システム

など様々な情報が不足した状態でお客様との最初のコンタクトとなることがあります。

そのような状態でもなんとか競合他社との戦いを勝ち抜き発注をいただくために色々と努力をすることになります。

受注サイドがどのような観点で提案を作成していくのかという情報は、発注サイドにとっても良い開発会社を選定する上での助けになるのではないかと思っています。

それでは具体的に見て行きましょう。

1)お客様の見えない要求を嗅ぎ分ける

f:id:yamagoochi:20200622130445j:plain
見えない要求を嗅ぎ分ける

ヒアリングやRFPを元に、過去の経験から機能一覧を推測で策定する

この能力が会社の提案力ということになると思います

全体の流れを押さえるためのQAや詳細なQAを繰り返しながら、お客様のビジネスや業務、既存システムや外部連携システムとの連携の仕組みなどを想像していきます

限られた時間で100%を把握することは不可能なので、根拠を持った上で必要だと思われる全ての機能を洗い出すことが重要です

2)要求を数字に変換する

f:id:yamagoochi:20200622130552j:plain
要求を数字に変換する

重要なのは画面数、機能数、帳票数、IF数など数字や難易度に基づいて工数を見積ることです

お客様からのハイレベルな要求を具体的な数値レベルに落とし込めることがシステム開発を請け負う上でとても大切な能力だと考えています

ふわっとした営業トークではなく、具体的に完成形をイメージできるレベルまで詳細化できることが付加価値だと思っています

また、お客様になぜそのような実装方針なのかを質問された場合に、根拠をすぐに回答できる状態であることがとても大切です

3)工数と金額を明示する

f:id:yamagoochi:20200622130623j:plain
工数と金額を明示する

開発規模から考えられるリスクを考慮した見積を算出する

ある程度機能単位での工数や費用を提示することで、価格感をお客様と共有できることになります

これはその後のスコープ変更時やリリース後の追加改修時の見積根拠が発注者と共有できるため無用な価格交渉や不信感を排除できると考えています

逆に言うと、不明確な部分が多い場合は開発会社側はある程度リスクを積むことになります

発注者側はできるだけ詳細な情報を提供して見積金額のバラツキが出にくくなるように配慮することがとても大切です

一定規模以上の案件の場合、リスク要因を把握しきれないことが多いため、要件定義終了後に開発フェーズ以降を再提案する旨を合意した方が良いと考えています

4)差別化

f:id:yamagoochi:20200622130647j:plain
差別化

提案時には自分たちが差別化できるポイントをセールストークの中心に据えることが重要です

顧客のことを深く理解することができることが伝わるととても良いですし、逆に顧客に懸念されているポイントを強みに変えられるとアピール力が高まります

例えば弊社では、あるプロジェクトの提案の際に以下の3つのポイントを差別化ポイントとして提案をしたことがあります

1 豊富な過去の経験(大規模プロジェクト実績や発注者側のプロジェクトリーダー経験がある)

 ⇒発注者の立場を理解できるという安心感

2 業界向けパッケージの活用(業界ノウハウがある)

 ⇒担当者の要求を正確に吸い上げられるという信頼感

3 オフショア開発(徹底した品質管理体制)

 ⇒ただ安いだけではなく品質もしっかりしているという安心感

お客様やプロジェクトの内容によってセールスポイントの中心をどこに持っているかは変わりますが、基本的な部分は共通していると考えています

5)プロジェクトリーダーが全てを背負えること

f:id:yamagoochi:20200622130712j:plain
プロジェクトリーダーが全てを背負えること

最終的にお客様がパートナー選定という大きな決断をする場合、やはり信頼できる人なのかどうかがとても重要だと感じています

いかなる質問にも誠実に回答する姿勢がとても大切です

金額交渉においても上司にお伺いを立てるような姿勢はできるだけ控え、オーナーシップを発揮できることを示した方が信頼感がアップすると思います

プロジェクトリーダーとしてオーナーシップを発揮できるレベルになるには相当の努力と経験と覚悟が必要です (まだまだ私自身も一人前とは言えないのですが)

そういう人が世の中に増えると良いな そのきっかけをブリスウェルで作れると良いな と思いながら経営をしています

また、業界的にはとても重要な感覚ではあるのですが、リスク回避的な態度はできるだけ見せない方が良いと思っています

とはいえ、お客様とリスクの存在を共有し、できればリスクに対する対策案を提示できると尚良いです

以上がシステム開発案件の提案を行う際に、私が大切にしていることになります

いよいよプロジェクトがスタートした後の流れ、要件定義編についても近いうちに記事を書こうと思っています

皆様のお役に少しでも立つことができたら幸いです!

音声データのノイズ除去

時間や場所にとらわれずに柔軟な働き方を実現する「Web会議」。すっかり身近になりましたね。

Web会議は、必要な時にその場ですぐに会議を開催することができるので、情報共有や意思決定を迅速に行うことができます。日程調整もしやすいので、参加者の予定を合わせやすいですね。ただ、ブレストのような自由に意見を出し合う類いの打合せは、ちょっと向いてないかなと最近感じます。座ったままPCと睨めっこ状態だと、なかなか良いアイデアも生まれてきません。これも慣れなのかしら。

ここでWeb会議あるある、です。

1. ミュートしたまま話続ける
相槌や意見を言い続けたのに、ミュートだったと気付いた時は虚しさ半端ないです。

2. 思わぬ来客
宅配便でーす!ご飯まだー?にゃあ。
日常が見えて、微笑ましいですね。

3. 雑音トラブル
カタカタカタ…ガタンゴトンガタンゴトン…どんがらがっしゃーん!
なかなか自分では気付かないことが多いです。

などなど...
どうでしょう。みなさんも思い当たるふしがあるかと思います。

さて、今回は「3. 雑音トラブル」をPythonで解決してみましょう!

ノイズ除去処理の流れ

  1. 高速フーリエ変換FFT)を用いて、ノイズデータの周波数成分を取得。あるアルゴリズムにより、ノイズと見なすしきい値を計算する。

  2. 高速フーリエ変換FFT)を用いて、ノイズを含む音声データの周波数成分を取得。1のしきい値によりノイズの部分をマスクする。

  3. 音声として復元する。

が大まかな処理の流れとなります。 pypi.org 今回は、こちらの「noisereduce」ライブラリを使用します。簡単にノイズ除去を試すことができます。

1. ライブラリの定義

import IPython
from scipy.io import wavfile
import noisereduce as nr
import soundfile as sf
from noisereduce.generate_noise import band_limited_noise
import matplotlib.pyplot as plt

2. 音声データの読み込み

data, rate = sf.read('voice.wav')
fig, ax = plt.subplots(figsize=(20,3))
ax.plot(data)

f:id:KenjiU:20200607215236p:plain
音声データ

3. ノイズデータの読み込み

noise_data, noise_rate = sf.read('noise.wav')
IPython.display.Audio(data=noise_data, rate=noise_rate)

fig, ax = plt.subplots(figsize=(20,4))
ax.plot(noise_data)

f:id:KenjiU:20200607215240p:plain
ノイズデータ

4. ノイズを含んだ音声データを生成

snr = 2 # signal to noise ratio
noise_clip = noise_data/snr
audio_clip = data + noise_clip
IPython.display.Audio(data=audio_clip, rate=noise_rate)

fig, ax = plt.subplots(figsize=(20,4))
ax.plot(audio_clip)

f:id:KenjiU:20200607215247p:plain
ノイズを含んだ音声データ

5. ノイズを除去し音声として復元

なんと以下のたったの一行でノイズ除去が実現できてしまいます。

noise_reduced = nr.reduce_noise(audio_clip=audio_clip, noise_clip=noise_clip, verbose=True)

f:id:KenjiU:20200607215254p:plain
ノイズ
f:id:KenjiU:20200607215257p:plain
ノイズと見なすしきい値を計算
f:id:KenjiU:20200607215312p:plain
入力音声データ
f:id:KenjiU:20200607215318p:plain
ノイズの部分をマスク
f:id:KenjiU:20200607215333p:plain
音声として復元

IPython.display.Audio(data=noise_reduced, rate=rate)

どうでしょう。完璧とは言えませんが、雑音トラブル無事解決!?

fig, ax = plt.subplots(figsize=(20,3))
ax.plot(noise_reduced)

f:id:KenjiU:20200607215336p:plain
ノイズ除去済み音声データ

今回は以上です!
1/fゆらぎのBGMを聞いていたら眠くなってきました( *˘ω˘)スヤァ…

Elastic Beanstalk config ファイルでどハマりしたお話

お疲れ様です。
みなさまいかがお過ごしでしょうか。

コロナウィルスにより、大変な世の中になってしまい、今後どうなっていくのか不安に思っています。

弊社は2月末よりテレワークとなりました。
一部は出社している日もあるようですが、基本的にはもうみんなの顔を忘れている頃だと思います。
私はお家時間が増えたので、FODを契約し、のだめカンタービレのドラマと映画を一気にみました。
今クラシックを聞きながら書いています。
一曲もわかりません。

本題です。
私は2 ~ 3年ほど前からElasticBeanstalk + CircleCI or GitLabCI or GitHubAction という構成を多く使用しています。
色々な構成内容をconfigファイルに記載しておき、
developとproductionをブランチによって自動で切り替えたり、環境構築を人依存しないようにしております。

近頃スタートしたプロジェクトの開発環境を構築しようと、以前のプロジェクトから色々コピーしました。
ハマりました。
今回はNode.js + nginx 環境です。

http → https のリダイレクトを nginx で設定しています。

files:
 /etc/nginx/conf.d/redirect.conf:
 mode: "000644"
 owner: root
 group: root
 content: |
# Redirect HTTP To HTTPS
 server {
 listen 81;
 rewrite ^ https://$host$request_uri permanent;
 }

こんな感じのファイルを
.ebextensions/redirect.config

として置いておけば、あとはElastic Beanstalk君がやってくれていました。

...ところが新しく作った環境だとリダイレクトされない...  

...ファイルの記載方法が悪いのか...  

...ログみても何も残っていない...  

...とりあえず、SSH Key作って接続して中身みてみよう...

あれ...
/etc/nginx/conf.d/redirect.conf
作られてねーじゃん。

なんで無視するの?嫌われた?
という壁にぶち当たりました。

色々調べていくと...
https://docs.aws.amazon.com/ja_jp/elasticbeanstalk/latest/dg/platforms-linux-extend.html

どうやら Linux
というプラットフォームでは nginx などの設定は

.platform/nginx/conf.d

にそのままの記載方法

server {
 listen 81;
 rewrite ^ https://$host$request_uri permanent;
}

これを custom.conf などに記載するように共通化されたみたいでした。

確かに元々のプロジェクト達は
Node.js running on 64bit Amazon Linux/4.14.1

今回は
Node.js 12 running on 64bit Amazon Linux 2/5.0.1

 でした。
これか!
となりました。(何かログ出してくれると助かったけど...)

AWSの進化は早いので、統一して全てのプロジェクトあげていこう!
と思いました。

他の困った方の役に少しでも立てれば幸いです。