Advent Calendar の時期になりました。今年はイベントがあるので、今月だけ原稿をスキップしてもらいましたので、今月は執筆に関してはちょっと余裕があります。そこで、調子にのって多くのネタに参加してしまい、自分の首を絞めていることにさっき気がつきました。長くなりすぎて読み返していないので、誤字脱字やばいかもしれません。何か見つけたら、こそっと教えてください。
本日は、過去を思い出しながらのシステムエンジニア Advent Calendar 2016です。要求されているネタは次のとおりです。
SIerのSIerによるSIerのためのアドベントカレンダーです。
SIの現場でよくある課題・デザインパターンについて書きましょう。
SIerのためには書きますが、デザインパターンについては書きません。おそらくは老害が過去をふりかえる内容がほとんどです。実際、ちょっと SIってなんじゃらほいと振り返りながら、個人的な振り返りがほとんどです。時間がありましたら、どうぞお付き合いください。
伴わせて、次の記事もご覧ください。
「[インフラ] インフラエンジニアの将来は明るいのか：その1 [アプリ] – oshiire*BLOG」
「[インフラ] インフラエンジニアの将来は明るいのか：その2 [アプリ] – oshiire*BLOG」
SEについて
このカレンダーに「SE」ってつけたことを DISってるわけじゃないことを先に断っておきます。使いドコまちがえるんじゃないぞ、ってだけです。
SE = "Systems Engineer" = 「システムズエンジニア」 です。毎度毎度そこら中で書いていますが、この言葉は使いどころを選ぶ言葉です。個人的に、この言葉を使って良いケースは次の3つです。他にもあるかも知れませんが、適当にやり過ごすときにしか使いません。
- 素人さんに、適当に職種を伝えたいとき
- アンケートなどの選択肢に、コレしかなかったとき
- あまりにも専門性が多岐にわたり、どの定義にも当てはまりそうもなくてお茶を濁したいとき
毎度、「SE」という単語に警鐘を鳴らしながら生きているのは、一貫した言葉の定義がないことです。
日本で言う「システムエンジニア」「SE」は和製英語と考えられ、国際的に通じる言葉ではない。英語圏にもSystems Engineer[2]と呼ばれる職務があるものの、これは文字通りシステム工学（Systems engineering; システムズ・エンジニアリング）にかかわる技術者を指すものであり、日本で「SE」と呼ばれる人々とは一般的に重ならない[要出典]。言い換え表現として、ソフトウェアエンジニア、ソフトウェア開発者、プログラマー、ハードウェア技術者などが挙げられる[要出典]。また契約の形態を表す語として「システムエンジニアリングサービス契約」というものがある。 システムエンジニア(Wikipedia)
Wikipedia の出だしから怪しさ満載です。外資では「システム ズ エンジニア」と「ズ」の有無をよく問われました。まぁともかく、言い換えられている言葉を見ても、確固たる定義がないので、あやふやなときにテキトーに利用するか、やたら範囲が広く、なんとなくITエンジニアの総称的に軽く使う場合程度にしか利用用途がありません。にも関わらず、この言葉を大事にしている人が多いので、どんな仕事をしているかを見ていると、毛の生えたプログラマーが多いように勝手に感じてます。「プログラムも書いてんねんで!」という意志を強く伝えたい上流設計・開発者にこの傾向があるようです。設計のできるプログラマーも実際には アーキテクト の一員ですが、この言葉があまりはやっていないことから、「SE」が定着している傾向にあるのではと感じています。
ともかく、相手が ITエンジニアにおいては「 SE 」はあやふや感がすごいので、相手を見ながらうまく使っていただきたい次第です。
なお、今の私の職種は「SE」なんですけれども、「Sales Engineer」という Pre-sales ロールでして、みなさんの想像する「システムエンジニア」「システムズエンジニア」とは、まったく別のお仕事です。私も人のことは言えない、厄介者ですね。
本文に入る前から長いのは、私の文章の特性です。
そもそもSIビジネスとはなんぞや
SIビジネスの定義
SI とは、「システムインテグレーション」を略したものです。では、この「SI」ってなんでしょうか。いくつかのソースからパクってきます。
システムインテグレーションとは、企業の情報システムの企画、設計、開発、構築、導入、保守、運用などを一貫して請け負うサービス。これらの工程のうちのいくつかを請け負う場合もある。システムインテグレーションを行う企業をシステムインテグレータ（SIer：System Integrator）という。システムインテグレーション 【 SI 】 System Integration / SIサービス / SI事業 / SIビジネス
システムインテグレーション（System Integration：SI）とは、企業の情報システム（Information System：IS）の構築を請け負うITサービス（ITコンサルティング、ITソリューション）を指す[1]。またSI事業者をシステムインテグレーター（SIer）と呼ぶ。 システムインテグレーション
よく見かけるサービスでの定義を見てみると、「企業のITシステムを、企画から保守まで一貫して請け負うサービス」ということを示しています。ただ、不思議なことに、私が今の会社で使っている「System(s) Integration」で想像される日本語は「システム連携」なんですね。ここで、海外のWikipediaソースから「SI」を拾ってきます。
In engineering, system integration is defined as the process of bringing together the component subsystems into one system and ensuring that the subsystems function together as a system. In information technology, systems integration is the process of linking together different computing systems and software applications physically or functionally, to act as a coordinated whole.
The system integrator brings together discrete systems utilizing a variety of techniques such as computer networking, enterprise application integration, business process management or manual programming. System Integration
頭の良くなった Google さんに喰わせてみます。
エンジニアリングでは、システムインテグレーションは、コンポーネントサブシステムを1つのシステムにまとめ、サブシステムがシステムとして一緒に機能することを保証するプロセスと定義されています。情報技術において、システムインテグレーションは、物理的または機能的に異なるコンピューティングシステムおよびソフトウェアアプリケーションを連携させて、全体として機能するプロセスです。
システムインテグレータは、コンピュータネットワーキング、エンタープライズアプリケーション統合、ビジネスプロセス管理、マニュアルプログラミングなどのさまざまな技術を利用して、個別のシステムを統合します。Google翻訳
ホントに翻訳精度高くなりましたね、感心します。ということで、日本と海外では「システムインテグレーション」における意味合いが、どうも違っているようです。日本では丸投げでシステム構築を依頼するケースが多く、海外では、そもそもITエンジニアが企業に内製化されていて、不足している部分(主にシステム連携)に System Integrator が呼ばれるケースが多いことからではないかと推察します。
SIビジネスがなぜ生まれたのか
日本でこのようなSIビジネスが生まれたのは、IBMがこのようなビジネスモデルを作ったからだと言われています。1980年代から1990年代では、都市銀行の第三次オンラインシステムをきっかけに、内製化で実現していたシステム開発の仕組みがうまく立ちゆかなくなったことが、1つの原因としてみられています。他には、日本での情報システム部門の扱いは、コストセンターとして扱われており、自社での内製化よりも外部への丸投げ気質に合ったことも1つの要因とされています。後々述べていきますが、「いかにして責任を他社になすりつけられるか」という日本の慣習が根底にある気がしてなりません。
このように、企業がITエンジニアを確保して教育せずに、他社に丸投げすることによって、ITビジネスが成り立っていったことによって、日本的なSIビジネスが生まれ、流行するようになったと言えます。
SIビジネスにすると嬉しいこと
さて、日本国内におけるSIビジネスたるや、隆盛の極みとも言えます。多くのIT企業はSIビジネスを心のよりどころにし、多くのパートナー企業と連携して、大きなSI案件を取得していくことに躍起です。その大きな理由は次の 3点と考えています。
- 長期的なレベニューの担保
- シェアの確保
- 評価基準
長期的なレベニューの担保
SIビジネスは、企業規模に比例して大規模なシステム開発案件となります。きっかけは、ハードウェアやソフトウェアのサポート切れによるものであっても、予算を掛けられるタイミングがそこにしかないとみるや、新たな機能や、コストを大幅に削減する機能、運用が楽になるものなんでも突っ込んできます。それも安価に実現できるように。とは言っても、そもそも切替だけでもそれ相応の準備や、結局ほとんど新規開発に近い状態にもなり得ますので、必然的にプロジェクトは長期化します。政府や金融系など、そもそもシステム規模のおおきいものであれば尚更です。
このように企業規模のおおきい案件を狙って、SIビジネスをとりにいこうとするのが大企業SIer指向でしょう。また、小さなSIビジネスだといっても半年から1年程度といった長期化するもの、またサービスイン後の運用もスコープに入ってくれば、より長期的な案件となります。このように、長期的なプロジェクトになりますと、TCVもびっくりするくらいの金額になりますし、長期的なレベニューも確保することができます。わざと横文字並べてると言うよりも、日本語が分からないので横文字で書いていますが、要するにプロジェクト期間中は、「うまくいっていれば」毎月なのか四半期、一年ごとにある程度の決まったキャッシュがはいってくることが目に見えています。会社を運営するに当たり、将来的にキャッシュがはいってくることが見込めていることは嬉しいポイントです。自社の将来の経済基盤が予測できると言うことは、投資も行いやすいですし、攻めるも守るも考えやすいからです。
シェアの確保
日本流SIビジネスでは、最初から最後までの請負開発が主であると述べました。ということは、ある程度大きなシステムを任されることになると、該当するお客さまのシステムのシェアをその分確保することができます。一部であれ、システムの一端を担うことができれば、シェアを広げていくことは以前よりたやすくなります。0→1 よりも 1→10にしていくほうが楽そうだと言うことは想像できますよね。0から1を生み出すときは、IT企業も投資とみなして、他社よりも断然に安い金額で提案してくる企業を、そう言えば多く知ってますね。
まずとにかく、少しでもどこかのシステムのシェアをとることができたならば、そのシステムを盾にして、SIerのシェアを広げていく選択肢がたくさん出てくるわけです。ある意味、陣取りゲームのようなものです。ビジネスが陣取りゲームになってしまうと、お互いに疲弊してしまいますが、新しいことを生み出していくにも、とっかかりとなるシステムを持っていることは重要なポイントです。とにかく、いずれにせよ、シェアの有無は重要です。
評価基準
個人的な話と会社的な話の二つあります。
SI案件というと、一般的に単純な物売りではありませんし、難しい局面もおおく、もらった金額に見合っていないケースもあります。それでも、結果として嬉しいケースがあります。それは「経験」です。社内の経験事例となり、次に同様の案件が発生した場合に、同じような問題をくりかえす可能性を低めることができます。また、企業としては、該当する案件の経験「あり」ということで、実績を他社へ紹介することができるようになりますから、新しいビジネスへつながる可能性を高めることができます。この辺が会社的に嬉しいポイントです。
個人的な部分については、お客さまもSIerも担当した人の、社内的地位が上がる可能性です。難しい案件をクローズさせることによって、個人的なスキル・経験の向上もありますし、上司・会社からの評価が上がる可能性も高まるでしょう。その結果、社内での評判が上がったり、給与増に繋がるはずです。ならないような会社ははやく辞めたほうがいいです。
SIビジネスがうまく実現できないわけ
とは言え、こんな美味しいだけの話は世の中にはなく、某青い銀行の統合プロジェクトや、スルガ銀行とIBMの訴訟問題 (IBMからのニュースリリースはありませんでした)のように、うまいこといかないケースや、そもそもSI案件自体、きつくて帰れない、休みがない、のような実例もよく聞くことでしょう。それらについて、個人的に感じる課題は次の 3点です。
- 要員の過不足
- 各局面が長い
- 失敗できない
要員の過不足
そもそも作業者が適当でないことがほとんどです。案件の規模に対して、要員の数を見積もります。しかし、多くは次の2つの理由により、最適な要員数を維持できないのではないでしょうか。
- 予算が足りなくて要員を確保できない
- 単価が安すぎて工数に上乗せした所為で、人が多い
まぁそもそも大規模すぎて、そもそも人が多いケースというのもありますが、人が少ない場合と、人が多い場合とで対処の方法はがらっと変わります。個人的な対処法です。
要員が確保できない場合
実のところ、予算が無事に確保できても、要員を確保できないような残念なケースもありますが、そんな会社はSI案件をやるべきじゃありませんので、言及はしません。
さて、予算が足りなくて要員を確保できない場合、どうしましょう。
「 案件をとらない 」
お金くれないならやめましょう。その案件をやらないと会社が潰れてしまうような会社であれば、その会社はほっといても潰れます。会社は潰れても再生できるケースがありますが、人が潰れると再生できなくなる場合があります。お金くれなければ潔くやめましょう。IT業界自体、そんな考え方で生きて欲しいです。
人が多すぎる
単価が安いので、工数調整して、たくさん人を入れた振りをするという残念なケースがあります。これが厄介です。なぜなら「ホントに100人も必要なの。連れてきてよ」ってことになるからです。さらに、最近はセキュリティの関係で自社開発させてくれないケースもあり、お客さまサイトや専用のプロジェクトルームでの開発になります。ってコトになると、実際にそれだけの人数が常にいることをお客さまは望んでくるわけです。コレは厄介です。どのように見せるべきか。
と言ったことでなくても、人がやたら多い案件というのは散見されます。作業の内容にあわせて、工数を見積もって、WBS の指示通りにいくと、ある工程では 30人必要だったとしましょう。このように人が増えてくると、人を調整するためのマネージャも比例して増えていきます。また、マネージャが増えれば、マネージャ同士の連携も必要になります。上のほうになればなるほど、現場がなにをしているかを把握できません。お客さまも知り得ない事実はたくさん出てきます。こうなると不幸です。まずまちがいなく失敗します。
では、人が多い案件はどのように捌くべきか。
「 極限まで減らす 」
だけです。簡単にはいきませんが、とにかく人を減らします。どうしても人じゃないとできない部分ってのはありますが、その辺は最適化しましょう。そして、自動化を進めましょう。プロジェクトの最初の局面は自動化プロジェクトが走ってもいいくらいです。
と言うことはカンタンですが、実現は不可能でしょう。SIer でどうにかできる部分が実は少ないので、お客さま側に変わっていただきたいと個人的には考えています。協力体制で一緒に進めていこうという心理面や、技術的に理解の不足する部分を勉強して学んでいく向上心か、分からないままであれば、よけいな口出しをせずにベンダーに任せる胆力。気の持ちようだけで、プロジェクトはそこそこ廻るようになります。ジャマしないことが一番です。
各局面が長い
なんだかんだいっても、SI案件の(金額面で見た)大半はウォーターフォール型アプローチでしょう。自信を持って言えます。そして、各局面がやたら長くて、ついでに並行化してきます。
本来、ウォーターフォール型の場合、1つの局面が終わるときにExit Criteriaと照らし合わせて、その局面で成すべきコトを全て終了させたかどうかを判定し、終わっていない項目があれば、その部分をやり直すことになります。このように、各局面でのレビューによって、品質を維持していくことがウォーターフォール型での最適解です。例えば、要件定義では、「必要な要件が網羅されているか」ということを複数の視点からみて、どうして網羅されているのかを担保できなければ、やり直しとなるコトでしょう。機能要件と非機能要件に分離して、機能の階層がすべてUMLなどで表現されているかどうか、非機能要件項目が非機能要求グレードなどによって、すべてうまっているかどうか、などをクライテリアにすることでしょう。
しかしながら、予算に余裕がないのでスケジュールにも余裕がなく、前工程が終わる前に、次の工程が始まったことで局面毎に齟齬が発生することがあります。また、そもそも局面が長すぎて、局面の最初の段階で決定したことが、局面の終わり付近では認識が変わってきていたり、そもそも実現可能性のないものになってしまったりと、大規模な案件になってくると、整合性を担保すること自体が不可能な場合があります。お陰様で見切り発車で開発・構築がスタートすることはよくある話ではないでしょうか。むしろ、要件定義させてくれるだけマシ、ってコトも少なくないでしょう。一番難解な要件は「今動いているものと同じで良いよ」です。知るか、そんなの。
局面が長いことで、要件や設計に齟齬が出ることは否めません。大規模な案件ほど、内部をアジャイル化して、少しずつ機能を実現していき、最終的に必要なサービスができあがった段階でサービスインする方法も一つの策だと思います。が、これも大抵お客さまが「やったことがない」とか「局面毎にレビューがなければ、支払ができない」とか困った問題があって実現できなかったりするんですよね。SIerが変わっていくことも必要ですが、お客さまへの啓蒙活動も重要なポイントです。
失敗できない
前段と似たようなものですが、1つでも失敗を許されないケースがほとんどです。開発工程で設計のミスに気がついた場合、どうなるか。たぶん、設計の再見直しとやり直しになりますよね。全部。失敗すると、その失敗の根本的な原因の解析と、歯止め、再発防止策をあわててつくって提出して、新しいプロセスをつくってに度と発生させないようにする。言葉で書いてみると、なんとなく正論に感じますが、このお陰で成功裏のプロジェクト完遂が難しくなります。
人は誰しも失敗をします。仕方ありません。失敗を受け入れる土壌と、失敗しても安全な防止策をとっておくことが重要です。「設定をまちがえていました」なんてことはよくあることです。本番業務へ影響なかったら、笑って許しましょう。その為に「テスト」という局面があるんですから。「設計がまちがってた」なんてのも、大規模なシステムになれば、小さい問題は出てくることでしょう。多少は目をつむって、早い段階で発覚して良かったネ、って仏の心が必要です。
とは言えなんでも許せと言っているわけではなくて、根本的な基礎設計がまちがえているとか、本番サービスをことごとく停止させるだの、信じられないようなことが起きたらいろいろと考えましょう。そのベンダーを選んだことがミスだったのか、お金が足りなかったのか、自分たちが脳天気だったのか。
なぜSIビジネスはまだ続くのか
まだ話は続きます。日本固有のSIビジネスが、なぜ未だに続いていることになっているのか。個人的にははなはだ疑問です。「安くしたい」っていうから、安いサービス持っていっても「ダメ」っていう。その神経は一体どんな指向から来ているのか、次の3つではないでしょうか。
- ガラパゴス仕様
- 保守派
- 社内政治
これら3つの制約が緩和されない限り、日本国からはSIビジネスが減少の兆しとなるコトはないでしょう。サービスとして提供されている大半のものが、専用の仕組みに則っていないと実現できないケースが多いわけです。海外発祥の製品やサービスでは、日本固有の仕組みをわざわざ作るべきかどうかを、そのマーケットから感じ取っているはずですが、まぁなかなか実装されませんよね。日本に媚びなくても、その他大勢で売れるんだったら。
ガラパゴス仕様
日本国がガラパゴスと呼ばれて久しいですが、日本国でビジネスをすすめるにあたって、どうしようもないガラパゴス仕様が多いことは否めません。そのほとんどが、お国が決めたことです。
官公庁など政府機関では、日本国が決めた仕様に従ってでしか、システムを構築・運営することができません。某重要なデータは、日本国内でしか保管はしていけないとか、Internet を経由してはならないとか。そういったアレです。次に、国の管轄下にある企業です。特に金融庁の決めたレールに乗らないといけないのは、結構大変な事業です。
また、国が決めたこととは別に、古い商習慣や、過去の流れからなんとなくでの非機能要件も多いです。特にお金関係。某お金を取引する専用端末でのレスポンスタイムは 3秒以下でなければならないとか言うヤツです。絶対 Internet経由できないし、メインフレームでワークロード制御しないとムリやん、みたいなシステムアーキテクチャへの制約だけがきついものですね。大変です。どうやっても安くできません。
保守派
私を含めた老害たちは、新しいことをやらずに古いままでいたいのです。なぜなら、自分たちが上に立てるから。だんだんと年老いても仕事のできる社会が生まれてきていて、今だと65歳定年ですよね。まだ卒業しない人たちが多いわけです。
社内政治
一番の問題です。SIビジネスを続けていくことは、SIビジネスで生計を立てているベンダーとしては、美味しい話なのです。その為、大規模なSIシステムは安価なクラウドへ移行させずに、できるだけ今と同等かそれ以上のシステムへのアップグレードを望みます。運用費用を維持して、バージョンアップを先送りにするために、サポート期間を延ばしてくるような日本企業も知っています。また、現時点で稼働しているシステムに罠を仕掛けておいて、他のベンダーへの移行を阻害する要因を準備しておいたり、ベンダー固有の製品の機能だけを利用しての囲い込みなどは日常茶飯事でしょう。そして、利用者が増えてくることによって、システムのリソースが逼迫されてくれば、新しいハードウェアなどへのアップグレードを促すわけです。
システムを使った政治活動だけならまだしも、コンプライアンスに抵触するような話になってくるともっと厄介ですね。わたしは、コンプライアンスにはやたらめったら厳しい外資にいましたので、そういった機会には巡り会えませんでしたが、まぁそりゃ噂話だけはとんでもないことたくさん聞いてきました。人死にがなかっただけ良かったのかもしれません。
保守派も企業間政治も、変わるべきはベンダーというよりもお客さま側です。コンプライアンスの遵守と、新しい技術を取り入れること、技術的な不安要素を任せっきり、丸投げにするではなく、正しく理解して内製化を進めていくこと。ユーザー系企業の転換期に来ているんだと、個人的に感じています。
これからのSIビジネス
長くなってきましたが、コレでおしまいです。読む方も疲れますが、書く方はもっと疲れてます。だんだん手抜きになっているコトは否定しません。
わたしは2016年初冬まで、外資のSIerでお仕事をして、生活を営んできましたが、今では SaaS/PaaS系のクラウドベンダーにいます。PaaS基盤を持っているので、SI的なビジネスは多少関わりはありますし、何年もかかるようなプロジェクトもあります。とは言え、基本はクラウドのサービスを利用してもらっての従量課金制モデルです。
今のサービス系クラウドベンダーに来て思うことは、時間に進みが異常に早いと言うことです。以前も今もプリセールスエンジニアです。ただ、以前は規模がおおきすぎて、提案活動自体も数ヶ月から1年近いこともあります。同じお客さまを担当するケースがほとんどで、障害が発生した時には、昔取った杵柄で対応を求められることもあります。設計の手伝いもしますし、プロジェクトの御用聞きだってありました。ですから、1つの提案から、そのプロジェクトが終わるまでには、何年もかかるケースもあり、新しい技術を適用して提案できることは少なかったのです。
今では、数日から数ヶ月程度の提案活動で、かつ多くの提案がそこら中にあり、新しい技術を取り込んでは、それをデモするような生活をしています。クラウドだからと言うだけではなく、会社の特性でもあるのでしょうが、SIのようなお客さまのニーズからシステムを作り出していくような場合、新しい技術よりも枯れた技術が喜ばれていました。今では、新しい技術を取り込んで、新しいサービスを利用したいお客さまが多いことから、日々、新しい技術を学んで実装できることが何よりも必要です。1つの案件規模としては、大規模SI案件と比較しても 1/100にも満たないことありますが、それでもシェアを広げている実感がありますし、今後はこのようなビジネスモデルが広がっていくことと信じています。
さて、このような時間の早い案件を進めて行くに、SIビジネスはどのように変革していくことが望ましいか、個人的な想いは次の3つです。
- 縮小傾向
- スモールスタート
- サブスクリプション
言わずもがななポイントですが、「小さく始めておおきくする」ということを、日本の商習慣もふくめて変わっていくことが重要でしょう。どうしても、一般競争入札の必要な官公庁では、数年分の予算配分が必要で、難しいところではあるでしょうが、予算を使い切らずに少しずつ予算を分割して利用できるようにするだけでも、実現可能なのかなとか勝手に妄想しました。何度も述べてはいますが、変わるべきはSIベンダーというよりも、ユーザー企業側の心の持ちような部分が多いのでは無かろうかと考えています。
新しいこと、ものは確かに不安ではありましょうが、クラウドのサービスがこれだけ台頭してきて、10年以上データも漏洩していないようなメジャーなクラウドサービスがほとんどです。もはやチャレンジするには遅く、利用することが前提でも構わないくらいでしょう。クラウド化のメリットはコストカットというよりも、新しいビジネスをすぐに立ち上げることができて、いらなくなったらすぐに辞めることができることが最良のポイントです。失敗したプロジェクトを、お金を払ったぶん使い続けるではなく、すぐに他に転換できるよう、すぐに新しいことを始める。その為にも、スモールスタートによりβサービスをとっとと開始して、将来を予見していくことがこれからのビジネスでは重要ではないでしょうか。
さいごに
「客がわりいんだよ、てめーらの所為だ」というわけではなく、SIビジネスを主導する人たちも、同じ考えを抱いたまま如何に今のビジネスを継続しようかと考える人が少なくありません。そのために、ユーザー企業を洗脳して、ビジネスコントロールしているベンダーもいることでしょう。コンペと競り勝っていくことがこれまでのビジネスでしたが、これからはお互いに協調し、新しいサービスを生み出していくことが望ましい業界の姿ではないでしょうか。
結局のところ、どの製品もサービスも適材適所ですし、それに合わせるようにシステムの連携はどんどん容易になってきています。昔ほどベンダーロックインしにくい世界になってきましたし、えっあの会社が、なんていうチャレンジも増えてきました。みんなで新しいことをやって行けたらなぁって言うのが、私の根底の想いです。どうぞ、今後ともよろしくお願いいたしますネ。
※ こんだけ書いてると、各ポイントで言い足りないことがたくさんありますね。本が書けそうです。