これまでSASの欠点を焦点に展開してきた「SASのクソな部分をぶった切る！」シリーズですが、なぜか一部の方に反響がありまして、
いくつか意見をいただいたのでいくつか追加コメントを残しておきます。
一部の記事は追記する予定です。ご意見が来るたびにこの記事も更新します。
ご意見一覧
twitter経由でご意見をいただきました。ありがとうございます。
コメント
全体を通しての総評
まだそんなに意見もらっているわけではありませんが、今のところおおむね同意が多いようです。それよりも同業者の間でこのブログが知られていることがわかり気が狂いそうです。
このブログはGTL関連のキーワードじゃないとなかなかたどりつけないはずなんだけど・・・
ソフトウエア価格について
反論はまあないでしょう。ソフトウエア価格が高額なうえにさらに値上げするなんてユーザーにとって何もメリットありませんから。
twitterからの情報によると、これまでSAS base単体での販売があったそうですが、今はSAS base, stat, graphのセットが最小パッケージとなっているようです。
統計解析だとこの３つは必須なのですが、収集したデータを加工しSASデータセットに変換するだけであればSAS baseのみのほうが都合が良いはずです。なのでbaseのみが必要な団体にとっては
実質値上げです。baseのみの販売は別にSASにとって不利益はないと思うのですが、一部のユーザーのニーズは切り捨てられているようですね。絶対に他の製品に乗り換えないだろうと高を括っているのでしょう。
ヘビーユーザーにとってはコスト面で痛手なので今後SASの利用を最小限にするなどの措置が取られるかもしれません。最近はWPSなるSAS互換のソフトウェアが出てきていますが、まだ完全な互換性があるとは言えません。例えばlibnameのreadonlyオプションはWPSでは使えません（アップデートで対応するかもしれませんが）。
なので場合によってはRへ移行するという話も出てくる可能性もなくはないのですが。。。少なくとも製薬関連はCdiscのフォーマットがxpt形式である以上完全な移行は難しいでしょうね。そもそも過去のプログラム資産をすべて捨てることは結構きついです。
SASはユーザー側の事情を知ってて足元みてると私は思うんですけど、他のユーザーはどう思っているのでしょう？
SASユーザー総会
ユーザー総会で発表することはSASユーザーにとって転職時にプラス評価になるなど、一定のメリットがあるとの意見がございました。聞いた話では異業種転職のケースなのでこの事例が参考になる人は少ないような気もしますが。
まあそのような事実があったとしても私はSASユーザー総会で発表したいとは全く思いませんね。
私のバイオリンプロットのやフォレストプロットの作図事例なんかは発表してもよさそうとは思いますけど、ブログで十分です。コードをコピーできるようにして利便性を向上させているし、ブログ収入がちょっぴり入るのでね。
確かに発表実績はあることに越したことはないでしょうし、勉強にもなりますけど、単純に転職に有利にしたいというのであれば、発表の手間をかける代わりに統計を勉強したほうが効率よいと思います。製薬関連だとCdisc業務経験ですよねあとは、業務機密扱いのはずなのでユーザー総会で発表することは100%ないと思うけど。
少なくとも個人名を宣伝するとか転職や昇進を有利にする目的でユーザー総会に参加するのはコスパ悪すぎだと思います。ユーザー総会はそういう場ではない、ユーザーの交流の場という側面もあるという意見もあるとは思いますけど、個人に実利がないのであれば新規参加者はどんどん減りますよ。ただのSASオタクのオフ会になるだけです。それにユーザー総会よりももう少し知名度のある臨床分野の学会で発表できるよう努力したほうが実績として評価されやすいですよね。個人的には交流するのであればRとかpythonとか別言語のユーザーの話を聞いてみたいです。
それに今は統計検定なる資格もありますし、勉強する優先順位が高いものは他にあります。SASノウハウコレクターになるだけだと後々きついと思います。
あとSASの有用な活用事例は基本的にSAS社が主体で発信するべきだと考えています。何度も言いますけどソースコードはSASが握っているわけだから、自社製品の有用性や活用方法はSASが責任もって発信するべきです。
オープンソース言語の真似事してユーザーに活用事例を発表させるなんて、ちょっと図々しくないですか？
どうしてオープンソース言語ではユーザーが積極的に情報発信しているかというと、ユーザー個人にとって実利があるからです。ドキュメント作成や拡張パッケージの開発を通じてコミュニティの発展に貢献することは自身の技術力の高さの証明になりますし、個人名でアピールできれば執筆や講演依頼、あるいは仕事のオファーがもらえるチャンスもあります。そして何よりも使用言語の開発に主体的に参画することで自身の業務に直接プラスの恩恵を得ることができます。
ではSASの場合はどうでしょう？ソースコードはSASが握っているのでアップデートはSASの匙加減であり、ユーザーが直接貢献できる余地はありません。ユーザー総会で有益な提案があったとしてもそれがSASの仕様に反映されるかどうかはわかりません。そもそもユーザー総会はSAS社が主催なのでユーザーにとってメリットがあることであってもSASにとっておいしくないのであれば、SASは認めないでしょう。ユーザー総会で発表することがユーザー自身にとってメリットがあるかは上で述べたとおりです。
一方SAS側はユーザーに実績というえさをちらつかせてユーザーに有益な活用事例や情報を発表させることで、自社製品の有用性を発信することができます。自社のコンサルタントにやらせるよりも安上がりなのではないでしょうか？辞める理由がありませんよね。実績という報酬は発表者に与えますが、それを活用できるかどうかは発表者次第です。SASには関係ありません。
昔はデータハンドリングに最適な言語がSASしかなく、情報収集の場がユーザー総会しかなかったので、ユーザー総会はSASコミュニティにとって不可欠であったとは思います。総会で情報共有することは技術者個人にとってメリットはあったのは間違いないでしょう。
ですが今は違います。SAS以外の選択肢もありますし、ユーザー総会でなくとも情報収集ができるようになりました。ユーザーが総会で発表する動機も弱まりつつあります。
そこら辺よく考えないとSASコミュニティは衰退するだけですね。
ハッシュオブジェクトについて
実は直近でハッシュを使う業務に遭遇していまして、ハッシュに対する意見が変わりつつあります。twitterでも実際に利用しているとの声があり、意外と海外のブログでも発信されているので活用事例を調査してみてもいいかなと思っています。
ハッシュの長所として実行速度を記事で言及していましたが、速度はおまけだという意見をいただきました。これは同意します。実行速度が重要視されるシーン自体がそう多くはないので、別の側面に注目するべきでした。
一番のメリットはMergeステートメントの代替になる点でしょう。mergeステートメントは変数を上書きするというトンデモ仕様があるので、ハッシュを使えばそういうことが絶対起こらなくなるというのは品質の担保という意味では意味はあると思います。proc sqlでもいけますけどね。
ハッシュについてはもっと考察しても良いかも。
作図環境
まあ作図機能が他言語よりも劣るというのは同意される方が多いと思います。このあたりは予想通り
そして強く主張したいのは一つだけです。
今すぐにgplotとannotationの利用をやめてください！
。。。
GTLは確かにSAS baseとは文法異なりますが、オブジェクトの配置を厳密に指定できるので論文投稿用のFigureを作成したい場合であればsgplotよりも習得は必須だと思います。
だからこそコピペで使えるコードを公開しているわけで。
Rやpythonよりもめんどくさいのは事実ですが、それなりにカスタマイズするとどの言語でもコード量が多くなるのでGTLの設計思想が他よりも劣るというわけではなく、十分使えると思っています。今後もアップデートされればね。。。
拡張性
１レコードごとに処理を実施し出力するという流れを極限にまで突き詰めたものがPDVであり、そういう設計思想を採用しているのがSASです。PDVはその思想の基では効率的な設計なのでしょう。このご意見は当然同意です。
一方PDVを採用することで、他言語とは独特の仕様が生まれ拡張性が乏しくなっているのも事実だと思います。
つまりSASは拡張性よりも特定の処理を優先し、特化した言語ととらえるべきだと思います。拡張性の乏しさは長所の裏返しなわけです。
そのためPDVでは向かない処理（ベクトル演算やRDMSへの接続など）は無理にSASを拡張しないでその処理が得意な言語で実装するというのが正しいのかなと思います。
言語の使い分けをするにもSASの欠点にフォーカスしないと判断できません。なのでSASの欠点について論じた記事は一定の成果はあったのかなとはおもっています。
そして他言語の習得の重要性も理解できるかと思います。
個人的には
データセンタから必要なデータの抽出と前処理はSQL
データハンドリング、統計解析、レポート作成はSAS
行列計算などSASでできない処理はRかjulia
機械学習はpython
のように使い分けるのが鉄板でしょう（RがSASの上位互換になりつつあるのは内緒）
proc ds2
定型処理をds2で作成して業務を効率的に実施している事例があり、一概にメリットがないとはいえないとのご意見がありました。ds2を利用してデータステップ内でSQLを実行している方もいるようです。
確かにオブジェクト指向を採用することでコードが有効活用しやすくなるメリットが当然あるので、ごもっともだと思います。
ですが技術的に有用かどうかと、業務上有用かどうかは別の問題です。
私はSAS言語のメリットは以下のように考えています。
- 歴史が古い言語であり、プログラム資産、業務手順書などの非プログラム資産が豊富である。
- データ型が少なく他言語よりもコード量が少なくすむ。習得しやすい。
問題なのはproc ds2に移行することは上記のメリットを放棄することと同義であり、このデメリットを上回るメリットをSAS社が十分に提案していない点です。
ds2が発表されて10年以上たっているのにもかかわらずds2に関する活用事例が全然共有されていないことが全てを物語っていると思います（活用事例が紹介されていましたらこっそり教えてください）。
過去の記事でも言及しましたが、中の人でさえほとんどのユーザーは乗り換える必要はないといっているくらいなのですから。
SASがds2を普及させる気がないのに、ユーザーが頑張って習得、普及させる必要はないと思います。
proc ds2を習得するのに莫大な時間がかかるとは思っていませんが、他の作業の時間を削ってまでds2を習得するべき理由が正直私には思いつきません。オブジェクト指向でないと業務できないわけではないですし。
他言語の技術者が多い職場だとオブジェクト指向のds2は習得しやすいとの話もあるようですけど、別に既存のデータステップそこまで難しくないと思いますよ。仕様が独特で困惑するのはわかるけどね。
まとめ
すげー長々と書いていますが、結局のところ私の意見は以下のように集約されます。
SASは得意不得意がはっきりしている言語であり、豊富な過去の資産を活用できる長所があるため、SASが得意な部分は過去の資産を有効活用して運用し、得意でない分野は無理にSASに新しい仕様を習得して導入するのではなく別の言語で実施するのが、プログラミング的にも業務的にも最も効率的である。
そしてSAS依存からの脱却、これが私の今後の目標です。そうじゃないとSASに足元みられるもん。
