先週まで勉強を兼ねて、PythonとGoogleの機械学習API「CLOUD NATURAL LANGUAGE API」の連載を行っていましたが、
おかげ様で何とか感触を掴めてきました。
しかし「勉強の為の勉強」だと、どうもピントがぼやけた調査になってしまうのが現実のところ。
そこで「社内システムの開発」を想定して、ちょっくらPythonで社内で使えそうなシステムを作ってみようと考えるに至り、ようやくある程度の形になってきたところです。
そこで、今回より新シリーズ「Pythonで社内システムを作ってみた」を始めていきたいと思います。
着想
テーマとして選んだのはＳＥならみんなお馴染みの、「業務経歴書」です。
弊社の業務経歴書はＩＴ界で悪名高い神エクセルの類です。
エクエルに各自書き込むという方式なので記述粒度が人によって合ってなかったり、印刷してみると微妙に見切れちゃってたり、
とか細々とした問題が多いという感覚が現場の実感としてありました。
私の業務経歴書はこんな感じ。（ちょっとだけお見せします）
一見すると綺麗ですが、これがエクセルで、実は問題もあるんですよ。
デザインの改善点の指摘もあるのですが、何せ全員が各自個別にエクセルファイルを持っている形ですから、
デザイン変更したくても全員が同じようにレイアウト変更作業をやるのは大変だから二の足を踏んだりとか、
やっぱり「個別管理」「エクセル形式」というのは、手っ取り早いのは良いですけど長期的管理体制には不向き。
そこで私は「これをＷｅｂシステム化して一元管理したら業務改善になるんじゃないかな？」と考えるに至ったわけです。
今後はシステム構築に至るまでの過程やノウハウの連載を始めていきたいと思います。
システム全体としては色々と詰め込まれていますが、それぞれ非常に疎結合となっています。
「ベンダーロックオン」と言いまして、クラウドの話をすると以後ずっとそのクラウドから抜け出せなくなることを気にされるケースがありますが、作ってみたところ、別にそんなことは無さそうでした。
ログ出力の設定とか多少のことはありますが、「作ったアプリのインフラを別のところに引っ越したいんだけど？」となった場合でも、特に問題にはならない規模です。
従って、連載を進めていく上で「インフラ編を読んだ後じゃないと実装編の意味が分からない」とかにもならないと思います。
連載は、システム規模が
なので、まずは手短な帳票出力API編から始めていきたいと思います。
エクエルに各自書き込むという方式なので記述粒度が人によって合ってなかったり、印刷してみると微妙に見切れちゃってたり、
とか細々とした問題が多いという感覚が現場の実感としてありました。
私の業務経歴書はこんな感じ。（ちょっとだけお見せします）
一見すると綺麗ですが、これがエクセルで、実は問題もあるんですよ。
デザインの改善点の指摘もあるのですが、何せ全員が各自個別にエクセルファイルを持っている形ですから、
デザイン変更したくても全員が同じようにレイアウト変更作業をやるのは大変だから二の足を踏んだりとか、
やっぱり「個別管理」「エクセル形式」というのは、手っ取り早いのは良いですけど長期的管理体制には不向き。
そこで私は「これをＷｅｂシステム化して一元管理したら業務改善になるんじゃないかな？」と考えるに至ったわけです。
課題
「Ｗｅｂシステム化する」と言うだけなら簡単ですが、それをソリューションとしてビルドアップするのは中々ハードルが高いです。
開発進行過程で課題になった点をご紹介しましょう。
言語はPython
これは課題と言うより「前提」ですが、言語は最初からPythonにしようと思っていました。
そもそもはPythonの勉強から始まっている、というのも大きいですが、もう一つの理由としては「優遇」があります。
プログラミング視点では「小規模Ｗｅｂシステムなんてどんな言語使っても対して変わらん」というのが実際のところですが、環境面だと意外にそうでもないです。
過去の連載で私はGoogleAppEngineを使用し、ネタバレになりますが今回はAWSを使用しましたが、その所感としてPythonはクラウド界で優遇されています。
クラウドサービスは言語を指定されている製品がありまして、「この製品はPythonは使えるけでRubyは未対応」など、クラウド製品の都合で言語が縛られるケースがあります。
そんな中、Pythonは常に対応していました。
- とりあえずPythonならばクラウドはＯＫ
私は寄らば大樹の陰という主義のエンジニアですが、Pythonは寄って安心の大樹だと思います。
基盤
基盤は「クラウド＋サーバレス（従量課金制）」しか無いと最初から思っていました。
この業務経歴書管理システムは、その性質上、業務経歴が書き換わるタイミングしか出番が来ないものです。
個人単位だと数ヶ月～数年に一度しか使いません。
そんなシステムの為にサーバを常駐させておくなんてのはコスト的にあり得なくて、システムを使うときだけ費用が発生する従量課金制のクラウド・サーバレスサービスしか無いというのは自明の理でした。
サーバレスサービスは、やはり以前に連載していたGoogleAppEngineが業界代表格でしょう。
この連載の中で別のシステムを作っていましたから、「サーバレスとはどういうものか？」「どういう時に出番が来るのか？」という知見はありました。
今回は同じサーバレスでも別製品、AWSのサーバレスを使うことにしました。
GoogleではなくAWSにした理由は、弊社の方針ですね。
今後、弊社ではAWSに力を入れていこうという方針があるので、そこに乗っかることにしました。
特にAWSの方がGoogleより向いている何かがあったわけではありません。
しかし、あっちこっちの技術に手を伸ばしていると片手落ちになってしまうので、合わせられる部分は合わせよう、とAWSにすることにしました。
Ｗｅｂシステム・フレームワーク
「PythonでWebシステムを作るとしたら、フレームワークはどうしよう？」と思いました。
調べてみると「django(ジャンゴ)」というフレームワークが見つかったのでコレにしました。
と言うか、PythonのWebシステム界ではdjangoが支配的地位です。
django以外の選択肢なんかありません。
帳票出力
最大の問題点。
業務経歴書は印刷して面談に持って行くという紙媒体が運用上絶対に外せない要件です。
- Ｗｅｂだけなら誰でも出来る。
- 印刷はどうすりゃいいんだ！？
帳票出力は技術的最大のハードルです。
- Yahooの時刻表印刷みたいにWeb画面を印刷する。
- 現在と同じくExcelを出力する。
- PDFで出力する。
色々考えて検証しましたが、これらにはそれぞれ問題点があって解消出来ませんでした。
- Web画面印刷⇒ブラウザ依存でどうしても微妙に見栄えが変わってしまう。
- Excel印刷⇒印刷時の見切れに対応出来ない。
- PDF⇒柔軟性が無さ過ぎる。例えば営業が「ちょっと急ぎ手直ししたい」という状況が発生した時に書き換えられない。
これらを踏まえて、最終的に「Wordで出力する」という仕様に結論付けました。
Word出力もこれはこれで難しくて。。。
最初はPythonでやろうとしましたが、どうしても実現不可能なケースがあったので、Pythonは諦めてココだけJavaでやることにしました。
Word出力の奮闘記は後の連載でご紹介します。
システム構成
そんなこんなで試行錯誤した結果、以下のようなシステム構成図でまとまりました。
大きく「Ｗｅｂシステム」と「帳票出力ＡＰＩ」に二分割されています。
終わりに
- Ｗｅｂシステム実装：Python&Django編
- Ｗｅｂシステムインフラ：AWS Elastic Beanstalk編
- 帳票出力API実装：Apache POI編
- 帳票出力APIインフラ：AWS Lambda編
システム全体としては色々と詰め込まれていますが、それぞれ非常に疎結合となっています。
「ベンダーロックオン」と言いまして、クラウドの話をすると以後ずっとそのクラウドから抜け出せなくなることを気にされるケースがありますが、作ってみたところ、別にそんなことは無さそうでした。
ログ出力の設定とか多少のことはありますが、「作ったアプリのインフラを別のところに引っ越したいんだけど？」となった場合でも、特に問題にはならない規模です。
従って、連載を進めていく上で「インフラ編を読んだ後じゃないと実装編の意味が分からない」とかにもならないと思います。
連載は、システム規模が
- Ｗｅｂシステム＞＞＞帳票出力API
なので、まずは手短な帳票出力API編から始めていきたいと思います。
0 件のコメント:
コメントを投稿