プログラマやってるアキゾラです。
なんかふと思い立ったので、書いてみることにしました。
システム開発vsシステム保守。
それぞれ、どんなことをやってて、どんな問題が起こりやすいか、どんなスキルが必要でどんな人が向いているのか？この業界で15年目のアキゾラの経験から語ってみます。
なんか、やっぱり仕事の話ってたまに吐き出したくなるもんですわねぇ。
なお、ここでは、できるだけこの業界に入りたいと思っている人やこの業界のことを知らない人に向けた書き方をしたいと思いますので、この業界の人には回りくどく逆に分かりづらいところもあるかもしれませんが、あるあると思っていただける部分も多いかも。
システム開発とシステム保守とはそれぞれ何なのか
一口に「開発」「保守」といっても、正直携わるシステムやプロジェクトの性質により結構違うこともあると思います。
小さなプロジェクトだと、この二つが明確に分かれていないことも多々ある印象。
逆に大きなプロジェクトでは、しっかり分かれていることもあり、それぞれのメンバーがあんまり交わらないようなところもあると思います。
自分の実体験でしか語れないので、あくまでアキゾラが経験してきた中での話、ということを前置きとさせていただきます。
まぁでも、大筋はそんなに外れることないんじゃないかな、しらんけど
システム開発ってどんなことするの？
システム開発は、文字通り、新しくシステム（アプリケーション）を一から作っていく作業です。
システム（アプリケーション）としましたが、そもそも、システム開発とアプリケーション開発って、厳密にいうとちょっと違うんですよね。（とアキゾラは思っています）
システムって、「こういうことがしたい」というものに合わせて作る、サービスとか仕組みの全体像的な感じだと思っています。
自分でもわかる、すごい分かりづらい。
例えば、ECサイトのシステムとか、在庫管理システムとか、自社の会員システムとか、、そういう仕組みの全体像みたいなもの。
それに対してアプリケーション開発というと、もう少し小さな単位というか。
そのシステムの中で動く一つのアプリケーション、部品みたいなイメージでしょうか。
スマホのアプリとか、PCのソフト（画像処理ソフトとか音楽再生ソフトとか）、それ単体で動いてるものありますよね、そういうのもアプリケーション開発にあたると思います。
アプリケーション自体がシステムの一部のこともあるんですけど、そうじゃないものもありますね。
まぁそういった違いはあれど、「開発」という括りでいえば、まぁ大体同じようなことします。
開発の仕方ってウォーターフォール開発、アジャイル開発などいろいろあって、それぞれ開発の流れが違うんですが、そこは今回置いておいて、できるだけ「作業」単位でお話しします。
アキゾラはどちらも経験がありますが、古い人間なのでウォーターフォール開発の方が多く、どっちかというとそっちに寄った話の流れになってるしまってると思いますが、ご了承を。
要件定義設計
開発は、まず要件定義します。
これは、これから作るシステム（アプリケーション）を「どういうシステム（アプリケーション）にするか」を決める作業です。
いわゆる、上流工程と言われる作業ですが、こういう考え方するのはウォーターフォール開発の時だけなのかな。
システム開発では、顧客（クライアント）からの要望、例えば「自社の製品を自サイトで新しくオンライン販売したい」とかがあって、それを吸い上げて要件定義するパターンが多いと思います。
こっちのパターンはいわゆるみなさんがイメージするSEさんが活躍するイメージじゃないかなー。
それに対して、アプリケーション開発の場合は、「研究開発」といって決まった顧客がいるわけではなく、世の中の状況を見て、自分たち発信、例えば「今こんな画像処理ソフトがあったら売れるはずだ、フフフ」というところから新しいものを作ることもあります。（もちろん、「システム」自体をこういう風に作ることもあるんですが）
機能設計、詳細設計
そして、要件定義から、さらに細かい仕様に落とし込んでいきます。
一応、ここまでが上流工程と言われるんですかね、おそらく（適当ｗ）
一つのシステムの中には、Aという機能、Bという機能、Cという機能と、色々な機能に分けられるわけですが、この機能ごとそれを「具体的にどういう機能とするか」を決めて（機能設計）、それをさらにプログラミングに落とし込めるよう細かいことを決めていきます（詳細設計）。
機能設計は、プロジェクトによっては、基本設計というところもあると思います。そのほか、基本設計→機能設計→詳細設計と、3段階だったり、まぁ色々です。
なんであれ、大きな単位から、小さな単位へ落とし込んでいくんですね。
アキゾラの経験では、基本設計→機能設計→詳細設計が多いですね。
ここでのアウトプットは「仕様書」です。言い方はプロジェクトによりますが、基本設計仕様書、機能設計仕様書、詳細設計仕様書みたいな感じ。
プログラミング、テスト
次に、仕様書をもとにプログラミングしていきます。
プログラミング以下がいわゆる下流工程です。
仕様書通りにプログラミングしますよ、プログラミングが終わったら、それが仕様書通りに動くかどうか、テストします。
テストは、仕様書通りに動くかを確認するものなので、仕様書に沿ってテスト項目を作成します。プログラムを見ながら作っちゃだめですｗ それだとバグが発見できない。
バグがあれば修正してまたテストします。この繰り返し。
テストにもいろいろ種類があって、機能仕様書レベルの確認、詳細仕様書レベルの確認みたいな、各仕様書ごとにテストのレベルがあります。
Aという機能の中の、一部分をしっかり確認し、Aという機能全体の確認をし、AとBとCと、それぞれの機能全体を合わせての確認、システム全体での確認・・。
ここでのアウトプットは「ソースコード（プログラム）」「テスト結果」です。
テストでバグが出なくなれば、出来上がり。
PMとかまとめの人になると、品質見解書とか書いたり、バグの分析したり、ペーパーワークも多くなりますがここでは端折ります。
そして、開発の手から離れ、たいてい品質保証部のようなところで品質の最終チェックが入るんですが、そこでNGがでると、またバグ対応、なんなら仕様書まで戻って作り直し、ということを繰り返し、だんだん納期ギリギリとなって炎上したりします。
プログラムは仕様書をもとに作るので、仕様書がしっかりしていないと、死にます
ざっくりいうとこんな感じですね。
新規機能の追加なんかも、開発の作業
一から新しくシステムを作るだけじゃなくて、そのシステムにさらに新しい機能を追加したりするのも、開発の作業です。
この場合も、基本は前述の工程を踏んで作業をします。
システム保守ってどんなことするの？
では、システム保守は、何をするのか。
システム保守は、開発が作ったシステムが実際に世で使われだした後の、保守作業です。
これもプロジェクトによって結構やる範囲が違うかもしれないんですけど、大きくは以下。
お客様からの問い合わせ対応
「なんか、○○したらこんなメッセージ出たんですけど、なんで？」とか、「○○したいんだけど、いまのこの状態でやって平気ですか」とか、「急に動きが遅くなったんですけど」とか、「あんたんところのアプリ入れてるマシンの調子が悪いんですけど、アプリのせいじゃないのこれ？」とか、「アプリが起動しません」「至急、障害発生」とか、とにかくいろんな問い合わせが入ってきますので、それに答えます。
それ、マニュアル見てくれてます？っていうレベルから、いやそれうちに聞かれても・・マ○クロソフトに聞いて？、という謎質問、なんでこんな動きすんねん！！という嫌な予感のもの、「障害発生」・・・、と本当に様々です。
この辺は、そのシステムの保守契約の内容とも絡んできたりするんですけどね、細かいこと言うと。
お客様からの状況ヒアリング、システムのログファイル（動きを記録したもの）などを用いて、そのシステムで今何が起きているかというのを把握し、問題があればその原因を突き止めるのが主な作業。
ということは、お客様からの問い合わせがなければ、暇なんじゃね？という疑惑を持たれる方もいるかもしれません。
あ、YESですね。
広く使われているシステムとか使われだしたばかりの新製品だと、とにかくひっきりなしに来ます。そんな暇ではない。でも波があるのも事実。
問い合わせの多さは、そのシステムの品質の良しあし、ユーザビリティなどに左右されるところがあると思いますけどね。
逆に対して売れてないアプリだったり、使っているのがその特定のクライアントだけであり小さな規模のシステムなんかだと、暇かも・・・なんだけど、そういう場合はシステム保守とシステム開発が分かれていないこともありますね（開発が片手間で対応できちゃったりするんで）
なお、なんでこんな動きすんねん！系は嫌な汗が出るし、明確な障害発生はもうまじでやばいです。
不具合対応、改善対応
これは、問い合わせで発覚した不具合、いわゆるバグと認定したものを、直します。
基本的には、開発中に出た不具合は、開発で直してリリースまでもっていきますが、いったん外に出た後の不具合は、保守が対応します。
バグじゃなくても、もっとこうあるべきだよねっていうような改善にあたるようなものも、保守で対応することが多いと思います。
なお、いったん外に出た後の不具合は、お客様に迷惑をかけていることが多いため、結構大変なことになります。
システム開発とシステム保守でありがちな問題
どんなことをするのかをざっと説明したところで、ではシステム開発とシステム保守で、それぞれどんな問題が起きやすいか、ありがちな問題を挙げてみます。
システム開発でありがちな問題
開発途中で仕様が変わることがある
これは、特にウォーターフォール開発でダメージのでかい問題。
要件定義して、機能設計、詳細設計、プログラム作って今テスト中ですよ～順調ですってところで、仕様が変わるという大人の事情が発生したりします。
仕様が変わると、場合によってはまた1から作り直しです。
でも、納期は変わらないことが多いです、そんなの、軽微な変更だと思ってますから、変更をかけてくる人は・・・。
そもそも、納期まで日程がない、思ったより作業に時間がかかり追いつめられる
まぁこれ、どこが悪いかっていうと、いろんな場合があると思うんですが・・。
○○なら、これくらいでできるでしょと勝手に上の方で決められていて、そんなわけないやんという、そもそも無理ゲーな場合もあれば、「こういうことをするなら、これくらいかかりますよ」と実際開発する側がきちんと見積もりをしたんだけど、問題ばっかりでて期日に間に合いそうにないことも。
作業量の見積もりは大事なんですが、開発経験が少ないとその見積もりが甘く、あとあと自分の首を絞めることになったりもします。
進捗の遅れが発生するのはテスト工程が多いかなーと思います。
いつまでも不具合がおさまらない、不具合が解決できない、こういう状況下で発生するAという不具合を直そうとするとBがうまく動かなくなるが、今の作りでは他にどうしたらいいのか・・（→仕様設計から作り直し）
その他、特定のテスト環境などの問題で、他の開発者と環境のシェアを行わないといけないこともあったりして、そのせいで当初の予定通り進まなかったり。
品質保証部のOKがもらえない
これは、問題っていうか普通のプロセスなんですけど、品質保証部のチェックで依然として不具合の指摘がおきていると、いつまでたってもOKになりません。
なんなら、この段階で発覚した不具合が、それ以前の開発側のテストでやればでるような問題であった場合など、そもそもちゃんとテストやってるの・・？（超疑惑の目）という話になって大幅な類似不具合の見直しなどを課されたりして、これが結構大変です。
その場合でも、当然そう簡単に納期は変わりませんよ。
でも、品質保証部は、世に出るそのシステムの品質を最終的に保証するわけですから、厳しいのは当たり前。ここが緩かったら品質保証自体が機能していないわけですね。
だが現実問題として品質保証部とはあまり仲が良くないケースが多いと思うｗ
デグらして冷や汗
機能追加などは既存機能との関係も事前にしっかりと調べないと、デグレードといって以前は動作していたものが動かなくなるなどの問題も発生します。
デグレードの不具合は、新規の不具合よりも深刻度が高いです。
ありがちなことにあげるか迷いましたが、やっぱり、ありがちなんですよねぇ。
でも、リリース前に気が付けばいいんです。
まさか全くそこに影響すると思わなかった、みたいなものだと、それに関するテスト項目もそもそも作ってないし、品質保証部でのチェックもすり抜けてしまうことは考えられます。（これはとてもやばいです）
システム開発での問題は、納期に関するものが多い
システム開発での問題は、やはり多くは納期に関するものだと思います。
特にウォーターフォール開発では、上流工程で仕様をしっかりと決めないと、プログラムはグダグダになり、大幅な進捗遅延が発生します。
アキゾラは開発でそこまで死ぬほど苦労したことはないというか、あったかもしれないけどすぐ忘れちゃうｗ、でもリリース直前というのは2徹夜したりしたこともありました。
そう聞くと大変なように思うかもしれませんが、それでも、リリース前です、今ならまだ直せる、問題はまだあくまで社内で閉じている、ということで、精神的な緊張感は保守に比べると低かったと今になっては思います。今になっては。（あ、でも休職2回してますｗ）
システム保守でありがちな問題
よく知らん機能のことを調べようにも仕様書がない/古い
問い合わせ内容に回答するため、その機能の仕様、あるべき姿を調べたいんですが、そもそもどうあるべきなのかがよく分からない、という、改めて文章にするとなかなか残念な状況というのは割とあります。
仕様書探したけどないし、見つけたとしても書いてあることが今のプログラムといまいちあってない・・・これどっちが正しいの？とか。
自分が開発してきたわけじゃないものなんかは、特に何が正しいのか分からなかったりします。
有識者ももういないしさー。
ほんとにでっかいシステムで、しかもそのシステムに関してそもそも知識がないと、今問題になっている機能ってどのソースコードの話？と、仕様書も発見できないしよく分からないからとりあえずソースだけでもみたいのにそれすらもままならないという場合もまれに発生します。
初めて見た謎現象なのに、回答期限は本日中
突発的に目の前に振ってきた問題に、早急に対応しないといけません。調べても、そんな動きになるはずがないだろという謎の現象にぶち当たることも沢山あります。
泣けてきますが、泣いても期限は変わりません、お客様は困っています。このせいでお客様の業務が止まっているんです、早急に解決しないとまずいです。
そもそも何を見ればいいのか分からない、見ても分からない
こんな問題が起きてる、という問い合わせに対して、まず何を見ればいいのか分からない、見ても分からない、ということもあります。
Aという機能で問題が起きた、Aっていう機能はどのログファイルに情報残してる？情報がどこにもない。
ログファイルは見たが、なんかエラーっぽい文言出てるけど、このエラーは今の問題と関係しているのかしていないのか、、、。なんか判断つかないな～ここ突っ込んでると時間ロスかなぁーあーどうしよう。
正常時のログ状況を知らんのでよく分からんぜこれ。（ログ少なすぎだんまり系）
明確に○○というエラーが出ているんだけど、そこまでは分かるんだけど、結局なんでこのエラーが出るのか分からないｗ
あとは、ログファイルって延々と情報書き込んでいたら容量がどんどん増えてしまうので普通ラップアラウンドして上書きしていきます。なので、見たときにはもう情報残ってないｗｗというのも割とある。（どうでもいいログ出しすぎ系）
など。
お客様先で起きている現象が、こちらの環境では再現しない
何だか分からんものは、再現試験をして確認することがあります。
お客様からもらったログファイルだけでは何が起きているのわからない場合など、さらに詳細な情報が出るように修正を加えたシステムで、同じ操作を行ってその現象を再現させ、何が起きているのか調査します。
でも、うちでは再現しない・・・。できる限りの条件をそろえても、まー再現しない。環境依存あるある。
問題が再現できないというのは、結構致命的で、それを不具合と断定するのにとても時間を要しますし、お客様先の情報だけで不具合だと断定できても、それを修正してテストで確認するときに、「不具合が直った」と言い切れません。そもそもうちじゃ起きないから直ったという現象を確認できない。
お客様環境で実際にデバッグさせてもらえればいいんですが、それができることは少ないです。てかほぼないです、アキゾラの経験では。
あと、お客様先が海外、とかね。そう簡単にいかんですよ、はい。
不具合か、改善か、もめる
超内輪事情って感じですが、「何か不具合（バグ）っぽい微妙なもの」があった場合、やはり設計側（開発、保守を含めた作っている側の人間）としてはバグとは認めたくなく、直すなら改善扱いです、という心理が働きます・・・ｗ
明らかなバグはバグですよ、そりゃ。でも、微妙なものってあるんです。例えば、仕様の不良（もともとそれで合意を取ってるのにそれじゃだめじゃんとなる）とか特定の環境下でしか起きない問題とか、そういうのになりがちです。
バグとか改善とかって、ポンポン勝手に直せるものじゃなくて、いろんなところと合意を取って直します。
バグか改善かって、結構違うんです、重みが。。プログラムに修正を入れるっていうところは一緒なんですけど。
作ってる側としては、いろんな事情がありそれはバグじゃないんですけどというものもあったりしますが、使う側としてはさくっとバグでしょ、となるわけで、社内でも役割として使う側に近いところにいる人は「バグ」、設計側は「改善」と主張が食い違います。
大抵は、バグに収まります。
システム保守の問題は、スキルと経験、そのシステムに関する知識に左右される
システム保守での問題は、スキルと経験、そのシステムに関する知識に大きく左右されます。
とにかく回答期限が短期間、明らかな障害であればASAPなので、悠長に仕様書調べて～とか、こんがらがったソースを机上トレース（処理を読み解きながらそのプログラムの動きを把握する）して～とかやってる暇なかったりするんです。
該当のことが書かれている仕様書を探り当てるのだけでも時間がかかります。
システムによりますが、仕様書って大なり小なり合わせて100以上は余裕であります。大規模システムだと数百ってレベルじゃないの？知らんけど。
おんなじ仕様書が何個もあったりしてリビジョンでも判断できないとか、どれが最新の仕様書なんだよという管理になっていることも、残念ながら多いんです。特にながーいこと続いている大規模システム。
しかも、探り当てても、知りたいことは書かれていないこともありますっていうか、大抵仕様書見ても得られるものはなかったりします。悲しいかな。
机上トレースはぱっとみて、ああこれ時間かかるやつだ。となると、心にドーンと重いものが押し寄せます。
時間かけてる時間ないんだよー涙
でも、多分こうですとか、あいまいな回答はできません。推定要因として回答することは多々あるんですけどね・・。
こうですよ、と回答した内容が実は解析ミスってたりすると、やばいです。
例えば、以下のような流れで進みますね、うちの場合は。「運用保守」って一緒だったりすることもありますけど。
運用SE（バックにはお客様）「●●が起きました。業務が止まって困ってるのですぐに回復したい！」
保守「なにこの現象初めて見た。えーログも全然出てない手掛かりがないよー。この機能作った人とっくにいなくなってるし仕様書もない。ソースもこんがらがってて解読には時間を要する。過去に類似事例もないみたいだ・・。あ、でもこういうシステムログが出てるな、ということはこれまでの経験から多分××のせいだろう・・・。」
保守「××の可能性があるため、▼▼してください。」
運用SE（バックにはお客様）「▼▼しても回復しなかった！▼▼するのに、どんだけかかると思ってるの？業務止まってんの、早く回復して！」
運用SE「実際に現地で作業してるこっちの身にもなってよマジでちゃんとやってよ、怒られるのはこっちなんだよ（これは運用SE自体の声）」
保守「・・・」
なので、「それを知っている人依存」になりがちなんです、保守作業はどうしても。
「人依存」はよくないです。
これを解消するために、おそらくどこでもいろんなことをやってると思うんですけど、なかなか難しい。
また、そのシステムのプログラムだけを見ていて問題が解決することは少なく（そういう問題はそもそも開発段階でのテストで摘出され潰されている）、システムが動作するマシンの性能や他のアプリとの関係、メモリの使用状況などの環境問題が絡むことも多いです。
システム開発とシステム保守、それぞれどんなスキルが必要？どんな人が向いてる？
なんか、マイナス面の強調ばかりしてしまいましたが、システム開発とシステム保守、それぞれどんなスキルが必要で、どんな人が向いているのか、アキゾラ目線で。
ここでは、あくまでそれぞれの対比での話で、一般的にSE/PGとして必要なスキル/技術力云々というところは少し割愛します。
システム開発に必要なスキル、向いている人
これは、うーんなんでしょうね。
クライアントの要求を正確に吸い上げ、それを要件定義落とし込むってところは、プログラミングなどの技術力云々よりも、コミュニケーション能力というか、人の話をきちんと理解する力、相手が何言ってるか分からないような場合は、それをかみ砕いて「こういうことですよね」とまとめる力が必要だと思います。
ただ、実はアキゾラはどっちかというと研究開発系のものにしか携わったことがないので、これあんまりよく知らないんですねーｗ
あとは、ガッツがあれば・・・（まじかｗ）
この業界の経験の少ない人でも作業しながら技術力をつけて成長していけるのは、システム開発だと思います。
いわゆる技術力があるに越したことないんですけど、ない場合でもできる仕事があるのはシステム開発。
経験者でも新規参入で作業がしやすいのもシステム開発。
基本は、新しく機能を追加するわけなんで、そんなに既存のシステムについて熟知していなくても作業に入れます。
（もちろんデグレードの問題とかあるから、きちんと既存機能の動きも調べたりして作業することになるんですけどね）
そして、新たに作り出すわけなので、クリエイティブさがあり、そういうのが好きな人は向いてると思います。
こういうことを実現するためには、こういう設計、こういう処理をするとスマートだなぁとか、こっちのやり方の方が保守性が高いなとか、いろいろ経験するうちに自分のレベルも上がります。
作る製品や機能によってやることは違うので、そのたびに新しい発見、新しい経験ができるのも開発です。
アキゾラは、自分が開発に携わった製品が、多くの人に使われているというのは嬉しいし、誇りに思うところもあります。
また、会社の中で評価が高いというか注目されるのも、開発部隊でしょう。
システム保守に必要なスキル、向いている人
システム保守は、前提としてある程度のIT知識（何かに特化、というより全般的な知識）、そのシステムに関する深い理解が必要です。
時間をかければ分かる、では難しく、時間をかけられないのですぐに状況を理解し、考えられる要因にあたりをつけられないとキツイことが多いです。
問い合わせ内容は多岐にわたるため、まずこうする、みたいな決まった作業があるわけではありません。そのため、システム保守では例えば新人さんなどの仕事を振るっていうのも結構難しい。
たいてい、新人さんに任せる仕事は余裕をもって説明をし、最悪何かあっても自分がリカバれる範囲で徐々にお任せしたりしていきますが、システム保守でそれをやるのは難しいですね。
その場その場でやることは違うんです。
まずはAをみて、結果が××だから今回は次にBを確認し、次にCを確認し、総合的に考えて●●である、と期限内に結論を出すことができないと仕事になりません。
ある程度の経験がないとつらいかもしれません。
先ほども少し触れましたが、ログとソースコード見るだけで問題が解決するような簡単なものは少ないです。
そのため、保守するシステムの規模や複雑さにもよりますが、基本的にはそのシステムのことを全く知らない新規で入った人がいきなり携わるようなものではない、とアキゾラは思っています。（でも現実はあるんですけどね、こういうこと。）
向いている人は、問題解決するのが好きな人、責任感のある人、かな？
開発に比べて、仕様書を書くとか、プログラミングをするというような作業は少ないです。（不具合対応/改善対応するので、やりますけどね）
圧倒的に「調査」が多い。
アキゾラはなんか問題があると、なぜか？を解明するまでのプロセスが楽しいというか判明できるとめちゃめちゃ嬉しいですｗ 謎解きみたいｗ
そして、自分の解析一つに重い責任が伴います（と思います）。言ってしまえば、それがそのまま会社、組織としての回答になります。自分が責任をもってこの問題を受け持って解決するのだ、という心意気、結構大事かもしれません。
しかし、保守は基本問題が起きたら動く部隊。何も起きなければお金がかかるだけの部隊ですｗ（これは言い過ぎか）
新しい仕事が立ち上がるところではありませんので、注目度は低く、評価も低めというか、評価しづらいんでしょうね。結局。華々しい成果を見せるってことが難しいですから。
また、保守は開発に比べたら人数が少ないんで、一人がいくつもの案件を抱えて優先順位を確認しながら作業することが多いです。
開発では、基本は一つの担当を自分で進めていくということが多いので、仕事の進め方も違うかなと思います。
まぁ開発は、細かいこと言うと、上流工程にしか携わらない場合、下流工程しか携わらない場合、全部やる場合などでも結構違うんですけどね。
まとめ
システム開発vsシステム保守。それぞれの違いは？、でした。
一口にシステムに携わっている人と言っても、開発と保守では結構やることが違います。
アキゾラ的には、どっちも経験するといいと思います。たいていは開発に携わるほうが多いと思うんですが、保守もやってみると、そこで感じたことを開発に生かすことができます。
開発だけしていると、特に研究開発の場合ってお客さんが実際にどう使っているのかとか結構遠い話だったりするんですね。
声が聞こえてこないから。
でも保守はお客さんの声がそのまま聞こえてきます。あーこういう風に使われているんだなぁとか、え、こんな使われ方想定してないｗｗとか、なんか色々新鮮だったりします。
まず開発で経験をつみ、保守を経験し、それからまた開発で活躍！こういうのが結構いいキャリアなんじゃないかなと思ったりするアキゾラです。
なお、以下のような記事書いたことがあるんですが、こちらもどうぞ。
ではでは！
コメント