deadbull式プログラミング言語選択ガイド単語

デッドブルシキプログラミングゲンゴセンタクガイド

1.3万文字の記事
  • twitter
  • facebook
  • はてな
  • LINE
主張を扱う記事 この記事は一部(今のところ一人)の方々のを取り扱った記事です。
秤はですがニコニコ大百科および大百科ニュース社の見解・ではないことにご留意ください。

同様の趣旨で検索すればいくらでも類似の記事が見つかるのに今更感があるが、どのような視点プログラミング言語を選択するべきか記しておく(個人の感想です)。異論は認める

まとめ

駄に長くなったのでまとめを書いておくと、

もちろん異論は認める

その幻想をぶち殺す!!

プログラミングは、入門書で文法を一通り覚えればゲームだろうがExcelのような高度なアプリケーションだろうが何でも作れるようになる、というようなものではない(TASレベルの意味で理論上可かもしれないが、現実的ではない)。

プログラミングマスターしたと言えるためには以下のようなものを全部とまでは言わないが習得する必要がある。文法よりもそれ以外の習得事項のほうが多いかもしれない。後述するようにアルゴリズムの習得は他の全てを合わせたよりもが深いが、そこまで極める必要はない場合も多い。

多くの言において、「コンソール上でHello Worldする」のと、「Hello Worldと書かれたウィンドウを表示する」との間には大きな隔たりが存在する。前者は知っての通り初心者が最初に書くプログラム(Haskellを除く)後者は並列処理あたりまで理解した中級者がGUIフレームワークの勉強を始めるときに書くプログラムである。

希望を打ち砕くようで申し訳ないが、入門書を読んだくらいでは「Hello Worldと書かれたウィンドウを表示する」ことすらおぼつかないのが現実である(例外: Javascript, PHP)。

プログラミング言語? そんなことより英語だ!

プログラミング言語以前の問題として、あなたは英語に自信はあるだろうか。多くのプログラミング言語英語圏出身である以上、プログラミングに関する情報英語が原文で提供される。

もちろんWeb上には日本語で書かれたリソースも存在する。しかしそれもメジャーな言に限られ、マイナーな言公式ページ英語チュートリアル一の情報ということもしくない。メジャーな言でも、マイナーライブラリフレームワークになると同じような状態になる。バグなどのように非常にマイナー話題は、メジャーな言でも英語掲示板にしか情報がないことが多い。

とはいえ、日本語情報である程度勉強すれば、英語全に読めなくても(サンプルコードを参考にして)どうすればいいか見当がつくこともあるので、それほど悲観しなくてもいいかもしれない。

数学力…たったの5か…

コンピューターの計算の上昇はすさまじいものがあるが、それでも限界はある。1万件の単純なデータの処理はすぐに終わっても、1万件の個々のデータに1万個ずつ項が入っていていたら1億の処理をすることになり結構な時間を要する、その1項にさらに1万ずつの小項が存在したら、1兆の処理をしなければならなくなり、合理的な時間で終わらないケースも出てくる。

こういった問題を解決するにはアルゴリズムを工夫する必要があるが、アルゴリズムの理解・応用にはかなりの数学が必要になる。ここでいう数学は「数学は70点だったけど国語は55点だったから得意科を強いて言うなら数学かな」と言ったレベルではなく、「明問題は解けない問題はなかった。可算無限と非可算無限が違う? そんなの当たり前だよね。」といったレベル数学である。

あなたが中高生ならともかく、文系大学生社会人だったりするならば、スーパーハカーになろうと思っても既に越えられない壁が出来てしまっている可性がある。学校の勉強は将来役立たないって言ってた出てこいwwww

もっとも、手作業でやっている定パソコン操作を自動化したり、IT土方仕事をするレベルでは関係のない話だと思われるので、気にしなくていいのかもしれない。

それでも、マニュアルに「以上、以下」を調べる機だけ記載されていて、「より大きい、より小さい」を調べる機がないときに「より大きい」=「以下ではない」、「より小さい」=「以上ではない」と内変換する程度の機転はめられる。

「これをやる」と心の中で思ったならッ!その時スデに選択は終わっているんだッ!

まずは、あなたがプログラミングで何を実現したいのか思い浮かべよう。

何がしたいか(具体的に)決まっている人は幸いである。的に一番近い機を有したライブラリ(あるいはフレームワーク)を探せばよい。そのライブラリが対応している言が、あなたの使うべき言である。選択の余地がないという意味では不幸かもしれない。

Excelなどメジャーなファイル形式での出力を目的とする場合

Excel形式が的なら、ExcelVBAマクロしなければと考えてしまいがちだが、Excelを介さずにExcelファイル形式(.xlsx, .xls)を直接読み書きするライブラリが存在する言も結構ある。そういったライブラリを用いれば扱いづらいVBAマクロに頼らなくても柔軟なプログラミングが可になる。

その他 .pdf, .docx, pptxなどのメジャーファイル形式についても、そういったライブラリが存在することもある。

調べやすさで選ぶ?

実際に開発を行う段階になると、ライブラリの細かい使用方法をドキュメントなどを調べながらプログラミングするということはしくない。しかし、英語の項でも述べたように、マイナーライブラリになると情報ライブラリ公式サイトのみということもしくなく、その公式サイトさえも英文のチュートリアルがあればいい方で、

などといったことは日常茶飯事である。

使用法が書かれていない優れた設計のライブラリよりも、設計はまあまあでもドキュメントが充実しているライブラリの方が実用的であったりすることがある。

使用人口が多い言ライブラリは、ドキュメントが充実する傾向にあるし、ドキュメントがない場合でも他の使用者が、ブログなどに使用例を投稿している可性が高くなる。

ライブラリを選択した後に、使い方を調べるにはソースコードを読むしかないと知って絶望することのないように、ライブラリ紹介文をみにするのではなく、実際に的の機の使い方がしっかり書かれているかまで確認した方がいいかもしれない。

他言語対応の罠

「甲言で使うライブラリから使える丁ライブラリ」のように、ライブラリを本来の言とは別の言から利用できるラッパーライブラリ(wrapper: くるむものという意味 cf. ラッピング)というものがある。ライブラリメジャーだが丁ライブラリマイナーであることが多い。

一見、「甲言を勉強しなくてもライブラリが使えるから便利」と思ってしまいがちだが、以下のようなデメリットがあり、最終的には甲言に回帰せざるを得なくなることもあるのでご利用は計画的に。「言」を「ハードウェア」や「OS」に置き換えても似たようなことが言えるが、冗長になるので省略する。

ライブラリ開発者が有名どころの企業だったりする場合は、上記の一部はかなり善されるが、ドキュメントが未整備でライブラリを使用したことがないと理解できない点は相変わらずなことも多い。

2010年代以降GAFAMと呼ばれる巨大企業たちでも、鳴り物入りで始めたプロジェクトを「やっぱやーめた」と気で中止することがしくなくなったので、ライブラリ開発中止リスクは常に織り込んでおいた方が良いだろう。

開発環境で選ぶ?

プログラミング言語の記事でも述べているが、プログラミング言語の良し悪しは、言仕様以外の要素で逆転してしまうことがしくない。ライブラリの有が言選択する上で一番大きいことは既に述べたので、ここでは開発環境について述べる。

統合開発環境があるか?

プログラミングというとソースコードを書くことだけをすこともあるが、実際にはコンパイラをはじめとするSDK(Software Development Kit)やエディタ、その他もろもろのインストールが必要になる。

その言統合開発環境がある場合は、統合開発環境を入れるだけでエディタを含めて一通う。操作もコンパイルから実行までボタン一つで行えて便利だが、有償のものや本格的に使用するとなると有償になるものも多い。

マイナーな言には(特に償で使おうとすると)統合開発環境はないことが多く、テキストエディタソースコードを書いてコマンドラインから実行という手段しかなくて不便極まりない場合もある(玄人になるとこのスタイルの方が好ましいと思えるようになるとか)

エディタ

仕様が悪い場合でもエディタの機が欠点をカバーしていて不便を感じさせないという場合もある。

プログラミング用のエディタ提供する機には以下のようなものがあるが、メジャーな言でないと提供されていない機も多いので、選択する際には注意されたい。

エディタも高機化が進み、エディタから実行やデバッグが可になるなど統合開発環境との界は曖昧になりつつある。

その他の開発ツール

その他にもデバッガや、ビルツール、さらにはUMLからコードを自動生成するツールまで存在する場合もあるが、相当メジャーな言に限られる。

プログラミングとはミスとの闘いである

プログラミングをすると必ずと言っていいほどプログラミングミス(バグ)が発生する。プログラミング言語進化歴史は、いかにこのミスの発生を防ぐかの歴史でもある。

プログラミング言語仕様の中には、一見いらないんじゃないかと思えるような機や、むしろい方がいいんじゃないかと思うような制限があったりするが、多くの場合ミスを防止するためのものである。意に沿わない機や制限を見かけた時に、短絡的に「この言はダメ」と決めつけてしまうのではなく、どうしてそうしなければならなかったのか、逆にそうしないとどういう問題が発生するのかといったことまで考えると、理解が深まるかもしれない(良くない仕様だが互換性のためにそのままにしているというケースも稀にはある)

逆に考えると、入門書を選ぶときに「こういう機があるので、こうできます」ではなくて、「こういうミスを防止するために、こういう機があります」という説明をしているものを選ぶことが望ましい。もっとも、残念なことにそういう視点解説がなされることは稀だし、そもそもメジャーでない限り入門書を選べないことも少なくない。

決してミスを犯さないプログラマであるならば、どの言を選ぼうと関係ない。

関数型プログラミングという潮流

プログラミング言語の選択方法について検索すると「オブジェクト指向は時代遅れだ。これからは関数型プログラミングだ」という記述を見つけるかもしれない。

関数型プログラミングの項目で私見を述べたが、関数型プログラミングがもてはやされるのは、参照透過性があるという点と、高階関数を駆使した抽化が可になるという点が理由になっていると思われる。

参照透過性は、間違いを防ぐために、他の言を使用する場合でも積極的に心がけると良い。

しかし、参照透過性に全性をめると純関数型言語に行き着く。2017年の時点で最もメジャーな純関数型言語といえばHaskell(それでもかなりマイナーである)だが、これを使いこなすには、モナドを初めとする高階関数を駆使した抽化の理解を要する。

高階関数を駆使した抽化というのは、理解するのに数学的素養しかも、単純な数値計算ではなく抽的なものに関する理解・応用められる。根性で使っているうちに体得するという考え方もあるが、それは学習が大変ということに他ならない。

関数型プログラミングという言葉に踊らされて言選択するよりは、関数型プログラミングがどうして有用なのかを理解し、選択した言でそれを実現するよう心がけた方がいいように思う。関数型プログラミングの重要性も2010年代前半には高に叫ばれたが、後半には前半ほどは強調されなくなったように思う。

静的型付け vs. 動的型付け

プログラミング言語の大きな分類に静的型付けと動的型付けという分類がある。動的型付けを決めなくていいので初心者向けとすることが多いが、(前述のように選択の余地がない場合は別として)少々面倒でも静的型付けの言を選択することを勧める。

動的型付けは、動作内容の詳細が日本語2-3行で表現できてしまうような本当に小さなプログラムを組むときには確かに有利だが、少しでも複雑な動作をさせようとすると静的型付けの言チェックが働いた方が有利になってくる。プログラミングをしようというからには、プログラミングを学んでまでコンピューターやらせたい面倒な仕事があるのだと思われる。そして面倒な仕事は往々にして複雑であり、単純だと思っていても繰り返す中に例外的な扱いを要するものが混じっていて複雑だったりするものである。

やりたいことがなく、単にプログラミングを勉強したいというだけの場合でも、静的型付け安全の考え方は学ぶ価値がある。

書きやすい言語 vs. 読みやすい言語

書きにくく読みにくい言語」というのは、どこまでも書きにくく、どこまでも読みにくくすることが可だが、「書きやすく読みやすい言」を追求しようとするとどこかで限界にぶち当たる。

書きやすいということは、複雑な処理を短く書ける記法が多数存在するということである。しかし、それを読むときには短い記法からその裏に隠れている複雑な処理を思い出さなければならない(ということは使用頻度の低い記法も含めて多数のことを覚えていなければならない)ということである。つまり書きやすさを追求すると読みにくくなり、読みやすくしようとして文法を単純化し過ぎると書きにくくなる(やりすぎると読みにくくもなる)[1]ということである。

どこかで、書きやすさと読みやすさの折り合いを付けないといけないわけだが、ベストバランスというのは人によって異なる。すなわち、職業プログラマだという理由で毎日コードを書くのであれば記法は多いほうが良く、趣味などでたまにしかコードを書かないのであれば記法は少なくていい。

従って万人にとって最良な言というものはないと思って良いが、「プログラムを書く時間よりも、(バグ探しや仕様確認等のため)にプログラムを読む時間の方が長い」と広く言われており、言仕様を聞いたときの「書きやすそう」という直感で走るよりも、使用頻度が少なくて忘れてしまいそうな言仕様はないか、書きやすくても読むときに不利にならないだろうか、など冷静に考えて選んだほうが良いのではないかといえる。

巷に出回っている「その言が優れている理由」というのは、たいてい「書きやすさ」を基準に評価されており、「読みやすさ」は評価基準に含まれていないか、あっても後付けかおまけ的に書かれていることが多い。

使わない機は覚えなくていいやと思っても、サンプルプログラムを読む時に知らない言を用いていることがあり、実際に使用していて不便をきたすことは結構ある。

時代はnull安全?

NullPointerException が引き起こすバグを防止するnull安全の考え方が2010年代に入ってからのトレンド。

HaskellにはMaybeモナドがあるが、ScalaOptionJavaOptionalは中身ではなくそれ自身がnullとなりうるのに対し、Maybeモナドはそれ自体がnullになることはないので、上記では区別している。

GUIへの道は遠い

プログラミング言語数にあるが、GUI製作方法が標準化されている言は意外と少ない。GUI製作方法がない場合すらある。標準化されていない部分は書籍化もされず情報も手に入りにくいので、GUIアプリを作りたい場合は、闇に進んで文法を学んだ後に立ち往生しないためにも、事前GUIをどうやって作るかまで視野に入れておきたい。

またプログラミング言語メイン部分はオープンソース化されているが、GUI製作部分はクローズドになっている場合もある。

もう全部Web技術一本でいいんじゃないかな

Webページに用いられている HTML + CSS + Javascript という組み合わせは、E-コマースの発展と共に最も広く用いられているGUIになったとも言える。広く使われると人口に例して発展するのが常で、この分野には多数のライブラリフレームワークが存在するようになった。

また、各種プログラミング言語においてもデスクトップGUIフレームワークはない(GUIフレームワークの構築は言仕様の策定以上に多大な労がかかる)けれど、(商用サイト用途の需要が多いので)Webサーバーを作るフレームワークはあるということも多くなってきている。

こうなってくると、言独自のGUIフレームワークを構築するのはあきらめて、GUI部分はWebサーバーから HTML + CSS + Javascript の形式で出してブラウザで表示させた方がいいんじゃないかなということになってくる[2]

こういった発想で構成されたフレームワークの一つにElectronというものがあり、実際にメジャーになったエディタであるVisual Studio CodeAtomはこれで動作している。

なお、Web技術に依存しないクロスプラットフォームGUIフレームワークとして、Flutterというものがある。

各論

使ってない言のことも書いているので、大きな偏りはある。異論は認める

こうして書いてみると、言が設計された経緯が、特徴として色濃く反映されている気がする。

プログラミングをしたことがある人とない人で感じ方はかなり変わるので、余裕があるならとりあえず適当な言で少しプログラミングを経験した後、ゆっくり本格的に使う言を探すといいのかもしれない。プログラミング言語数学理論(構造化定理型理論カリー=ハワード同型対応チューリングマシンなど)を背景にしているので、まるで違う言に見えても本質的には共通している点も多く、2つ以降のプログラミング言語習得はかなり楽になるからである。一つの言から次の言に移ると強く違和感を感じるのは慣れの問題か。

C言語 / C++

何でもできるが、出来てはいけないことまで出来てしまう。ミスを防ぐという観点からは、あまり良くないと思われる。また、C++仕様が複雑すぎることで悪名高い。

Java

CやC++の反省を元に作られた言。静的型付け。使用人口が多く、情報ライブラリも豊富。

APIドキュメントの書き方が言仕様で規定されている。実際に使ってみるとライブラリの使用方法の調べ方が統一されているというのは大きい。統合開発環境との組み合わせでさらに効果を発揮する。

ソースコード内にコメントを書く機はほとんどのプログラミング言語に備わっているが、たいていは言仕様の策定に終始してドキュメント仕様にまでは手が回っておらず、Javaほど厳密に規定されている言は少ない。

ソースコードが冗長になるという批判が多いが、ソースコードを読むという観点からは黙示的に定義される部分を補う必要がないので読みやすいという見方もできる。

歴史ある言のため古い考え方も残っているが、後発の言に一見駄に複雑と思える仕様が存在する理由が理解できるので勉強にはなる?

2014年Java8でラムダ式Optionalが導入されてから、かなり変化したので、書籍や情報はそれ以降のものを頼ったほうが良い。

GUIの書き方までオープンソースで標準化されたものがあるが、その使用人口はあまり多くない上に、今後は標準のものはなくなるかもしれない。

進歩が遅いという短所は開発者からすれば言仕様変更が少ないという長所であったが、2017年後半にOracleが方針を変更したためリリースサイクルが半年になった。同方針変更により長期サポート版ライセンス料が必要になる懸念もあったが、他社が無料で長期サポートのあるJava仮想マシン提供するようになったので、その点については回避されている。

JavaScript

動的型付けブラウザ上でHTMLインタラティブな要素を加えるために開発されたという経緯がある。そのため、プログラミング言語としてはややいびつなところがある。

GUI構築に関してはHTMLと組み合わせる方法が標準化されている一方で、ファイル読み書きが弱い(ブラウザが勝手にファイル読み書きしたら困るから)。

ブラウザ外の実行環境としてNode.jsがあり、ブラウザを介さずに動作するアプリや、サーバープログラム製作にも使用できる。

Typescript

Microsoft開発した、JavaScript静的型付けにした言JavaScript上位互換JavaScriptコードをそのまま持ってきても動作するのが特徴。今から始めるならJavaScriptよりはこちらか。

JavaScriptとの互換性を保つため、プログラミング言語としてはややいびつなところが引き継がれている。

PHP

動的型付け実行結果がHTMLになる。インタラティブなWebページ製作という観点からは最も手軽に結果を得られる反面、もともとプログラミング言語ではなかったせいか、プログラミング言語としては扱いづらい。

Swift

iPhoneアプリ開発向けにApple2014年に発表した言null安全

オープンソース化されて他のプラットフォームでも動作するが、GUIを構成するCocoaの部分はオープンになっていない。

iPhoneイヤホンジャックに限らずAppleは昔から旧環境を切り捨てることに定評があるが、SwiftObjective-Cを捨てて移行したし、Swift自身もメジャーバージョンアップ時に互換性を保てない変更をしている。2019年バージョン5になるときには互換性が維持されたようなので、そろそろ落ち着いた頃なのかもしれないが、Apple開発しているということを考えると油断はできない

C#

Microsoft開発した.NET Frameworkメイン

Javaに対抗して作られた経緯があるので、Javaに似てJavaより書きやすいと言われている。

有志が作ったオープンソース実装Monoが存在するが、2016年公式からオープンソース化された。

GUI周りに関しては2018年オープンソースになったが、2020年現在Windows.NET以外の実装は存在しない。

Ruby / Python

動的型付けライブラリフレームワークの関係でこれらの言を選択するケースも多いと思われる。

注意点としてはいずれもRuby2.0, Python3.0で互換性のなくなる変更を行っており、区別して検索しないといけない(特にPython)ということがある。

蛇足だが、Ruby開発者は日本人

日本人開発したRubyを推すべきなのかもしれないが、Rubyキャッチフレーズは「書くのが楽しい」なのに対しPythonは「見やすさ」を標に掲げているので、この記事では以下省略

Scala / Kotlin

静的型付け。いずれもJava仮想マシン上で動作するため、Javaで作られた豊富なライブラリが利用可Kotlinnull安全な言仕様が売り。ScalaOptionnull問題に対処しているが、Java8でOptionalが導入されたのでその点ではJavaと差がくなった。

Javaでの反省を元に作られ、Javaよりも短いコードが書けるという触れ込みだが、コードを読もうとすると黙示的動作を内補する必要があり、いきなりこの言から入るのは厳しいかもしれない(特にScala)。

コードを書く頻度が高いなら、これくらい機があった方が便利だと思われる(Scalaはそれでも高機すぎるという意見もある)。

Oracle2018年以降についてJava仮想マシンサポート期間のポリシーを変更したため、これらのJVM言語を受ける可性は不安要素としてある。

なお、のために記しておくとこの記事を書いた編集者大百科Kotlinのサンプルコード(長文)を投稿してしまう程度のKotlinユーザー(Javaからの移行組)である。

Haskell

関数型言語。ちまたに出回っている解説それなりに数学のある人が書いていると思われ、数学に強い自信がないなら易な情報が手に入らないのでやめておいた方がいい。

他の言と同じようなことをする分には言われているほど難しい言ではないのかもしれないが、Haskellならではの使い方をしようとするならかなりの数学が必要。コンピューターの考え方に近いのが低準言人間の考え方に近いのが高準言といわれたりするが、Haskellコンピューターとも(一般的な)人間とも離れた考え方で、数学者的考え方に近い言といえるかもしれない。

私の数学53万ですという人や、職業プログラマーが時間をかけて長く付き合っていくならありかもしれない。

意識高い系うっかり手を出すと、挫折したいせにこんな毒を吐くことになる。

Perl

書きやすく読みにくい言の代表格。どうしても使いたいライブラリがあるのでなければ、今から始める理由はないように思う。

Rust

この記事の読者層にこんなマイナー選択肢に挙げる人は想定されていないのだが、もしかしたら「され度No.1」という評価に釣られる人がいるかも知れないので。

Rustの肝である所有権について公式サイトチュートリアルにわざわざ「難しい」と書かれているくらい(たいていのプログラミング言語は簡単に学習できることを売りにしている)なので、少なくともプログラミング初心者が手を出す言ではないように思える。

最大の特色は高速な並列処理がメモリ安全に書けること。つまり、やりたいことのメイン多数の複雑な並列処理が含まれていない人は骨折り損になる恐れがある。され度No.1」というのは難所を乗り越えるだけの能力と動機のあった人を対象にしたデータである。

逆に並列処理が的の人は、どの言を選択しても並列処理の難所であるメモリ管理の学習に苦しむことは避けられないので、言仕様サポートしてくれるRustは検討に値するかもしれない。ただし、現実の並列処理実装にはGPUを用いることも多いが、少なくとも2020年の時点で言仕様が想定しているのはCPUでのメモリ安全っぽいので、GPGPU当ての人はもう少し深く検討した方がいいと思われる。

メモリ安全の思想を持つ言としては他にV言というものがあるらしいが、あまりにもマイナー過ぎるためお勧めしない。

Julia

やはりこんなマイナー選択肢に挙げる人は読者層に想定されていないのだが、もしかしたら「これからはPythonでなくJuliaだ」という記事を見かける人がいるかもしれないので書いておくと、少なくとも2020年の段階ではあまりお勧めしない。

よくPython代替として引き合いに出されるので、その観点を中心に記すと、

数式をほぼそのままの形でコードにできるという利点はあるので、行列ベクトルを多用した数式を自分で立てて計算する人にはメリットがあるかもしれない。

それ以外の人は、物好きは別として手を出すとしてももう少しメジャーになってからでもいいのではなかろうか。

関連項目

脚注

  1. *単純さを追求したい方は純Lispについて、極限まで追求したい方はLazy Kについて調べてみるとよい。本当に単純な話なのですぐ調べ終わる。
  2. *Web関連技術は使用人口が多いことと商業的需要が中心であることもあって、流行り廃りが激しいexitことも付記しておく。たとえばAngularJSというGoogle様が開発したフロントエンドフレームワークがあり2010年代前半にはトップシェアであったと思われるが、2016年に互換性のない変更をしたためユーザーがついてこず、2020年には(統計のとり方にもよるが)3番手くらいまで落ちているのではと言われている。また、本格的なWebサイト作成に必須とまで言われていたライブラリjQueryも、JavaScript仕様訂で機の多くが標準でカバーされ2016年以降は不要論が出るようになっている。
この記事を編集する

掲示板

おすすめトレンド

急上昇ワード改

最終更新:2024/03/29(金) 19:00

ほめられた記事

最終更新:2024/03/29(金) 19:00

ウォッチリストに追加しました!

すでにウォッチリストに
入っています。

OK

追加に失敗しました。

OK

追加にはログインが必要です。

           

ほめた!

すでにほめています。

すでにほめています。

ほめるを取消しました。

OK

ほめるに失敗しました。

OK

ほめるの取消しに失敗しました。

OK

ほめるにはログインが必要です。

タグ編集にはログインが必要です。

タグ編集には利用規約の同意が必要です。

TOP