  |
はてなキーワード: ソースコードとは
1時間ぐらいで作れちゃうようなお題ネタを出してプラグインを作成して皆で成果を見せ合うとかさ。
この人はこう作るんだ〜あの人はこういうテクニック使うんだ〜って勉強したい。
オフラインでgithubでソースコードを見て学ぶのもそうだけど、リアルタイムで人と絡み合うスタイルもあってもいいですよね。
こういうのをオンラインでやってるところありませんかね。
http://anond.hatelabo.jp/20160123131828
にてSIerがボロクソに叩かれているので楽しんでいる人間もいると伝えたい。
長時間労働が全社的に問題視されていて、作業効率化しない組織の方が上からも下からも叩かれている。まあ実際は効率化に充てられる時間はあまりないのだが、意識としては部長・課長レベルまで浸透している。
技術力は部署（業界、業務系、web系）によって色がかなり異なるが、自分のところはGit（hubではない）でソースコード管理しているし、Redmineでチケット管理するし、HipChatで会話しながらビルド結果をbotで通知したりもする。
意思決定が遅い等の不満はあるが、大きい組織であれば業界問わずそんなもんだろうと思っている。
20代の数年間SIで働いた。1年以上前に退職して今は別業界にいる。
今日、Evernoteを整理していたら「退職理由、SIの嫌な点」というメモが発掘された。退職直前のかなりストレスがたまっていた時期に書き殴った文章だった。学生の頃の私は絵を書いたりしていて、ものづくりで暮らしたいな〜などと思って始めたプログラミングが楽しかったので安易に受託開発業を選んでしまったが、その後悔が如実に表れていた。
一部自分でも覚えていない話もあったがコンテンツとしては面白かったし、今でもシステムインテグレーター業界で消耗する若者を減らしたいとは思うので公開してみる。
以下、同メモに加筆・修正したものなのでファンタジーだと思って読んでくれ。
受注した時点で売上がおよそ確定するので、後はその予定工数に収めて納品できれば御の字という考え方。よくある話だが、見積がおかしくても顧客と対等な関係が築けていないから追加請求もできない。時間（工数）をかければ良い成果物ができるかもしれないがそれを説明して顧客に嫌な顔をされたくないから、限られた工数の中での最善を尽くす。最善を尽くす、聞こえは良いが要は手を抜く。
つまり、どう頑張っても売上は同じなのだから、良いもの・価値を生むものを作ろうと考えない人が多い。社内で開発者と呼ばれる人間もそうだし、マネジメント層はそういうものづくり志向を持った人をリスク扱いすることもある。
これが諸問題の根源で、いかに述べるような組織・プロジェクトが出来上がっていく。
マニュアル作業の正確さをかたくなに信じてる人だらけで、ITとは何なんだと考えさせられる。
私は定型作業を効率化しようとjsやrubyでスクリプトを書いたりしていた。テストデータを開発用DBに突っ込んだり、テキスト処理して整形したり、Excelからコード生成したりするよくあるやつ。
あるとき上司に肩越しに自分の作業を覗かれて「何やってるの？」と聞かれ、そういうスクリプトを作ってると答えたら、工数とリスクの話をされた。曰く「そのスクリプト作るのに何日かかるの？工数に乗ってないよね？」「スクリプトのテストもちゃんとしないと結果が正しいって保証できなくない？」と。この時はイラッとして「30分でできる数十行のスクリプトだし自分の作業工数内で完結する。むしろ後工程や別の人でも同じことを再現性できて楽になる」とか真面目に説明してプログラムも見せたが、読もうとはせず（読めないので）1時間無駄にした。
前述したようなビジネスモデルだから、営業力と、予定工数で無難にプロジェクトを終えるマネジメント力が大事。IT企業だが開発者は自社で持たない。不況の時に待機コストが発生するリスクがあるし、自社で抱えるより単価の安い開発者が人材派遣系の企業や下請けにいっぱいいるから。
社長があるとき社内広報で「技術は買うものだ」と言っていた。文脈で明らかに技術＝技術者のことだったので、使い捨ての人売り業と揶揄されていることへの自覚が無いと思う。
そういう人が集まっているor残っている組織なので開発者はほとんどいない。20〜30人ぐらいの課に1人ぐらいの割合でstaticおじさんがちらほらいるぐらい。大体20代からプロジェクトリーダーという立場をやり始め、だんだん大型の案件を扱えるようになっていき、後は出世ゲーム。部長のお気に入りが課長になり、部門長のお気に入りが部長になる。その繰り返し。
開発案件でのBP（ビジネスパートナー、委託先、派遣、下請け）比率は自分の周りだと1:5ぐらいが多い。プロパー社員一人が5人の開発を仕切る、みたいな形。案件規模によりだいぶ差があると思う。この比率が高い＝マネジメント力のある組織と考える会社はこの数字を上げようと必死で、比率の低い組織は評価が下がる。
私は開発が好きだったのでエンジニアとして生きていきたい、というようなことを評価面談の度に伝えているが、その度に会社の目指す方向を説かれてモチベーションが下がる。
上述の通り、案件で接する開発者は基本的に社外の人間なのだが、彼らの技術力と意識の高さにはものすごいばらつきがある。言われたものはなんでもこなせる人、何でこの歳まで技術者やれてるんだと疑う人、このプロジェクトはおかしいと良い意味で騒ぐ人、何も意見を言わない人、CっぽくJavaを書く人、人当たりは良いが技術力がいまいちな人、すぐ休む人、バグやミスを隠す人…etc。
まぁ色んな人がいるのはどの業界のどの職種も同じだが問題は質だ。私の主観になるが本当にエンジニアとして尊敬できるレベルの人は1%いるかいないか。というのも、ほとんどの技術者は長年SIやその周辺企業と付き合ってきているので同じ体質に染まっているのだ。顧客が良いといえば良いという態度（この場合の顧客は私が所属する企業）、請負の場合は工数を超えない範囲で手を抜く姿勢、その他諸々。技術力だけをひたすら磨き続けてきたという人はごく一部だけだったし、そんな人でもGitHubアカウント持ってない・ブログやってない・OSSに貢献したことない、といった具合でクローズドな世界で生きている。
そうした技術者とやっていく中で最も厄介なのが教育コストだ。案件のあるなしで人が都度入れ替わり、新しい人が来るたびに同じシステム・技術要素の説明をして何とかやる気が出るようモチベートして、というのを繰り返すのに疲れた。私の会社固有の変なルールの説明はてきとうにしておいて、私は技術が好きな仲間が欲しかったので今のシステムの課題と技術面での改善や展望をよく話す。が、あまり食いつかれることはない。これは私の問題だが、そうした期待と落胆のループも疲弊の一因だ。
ある時、一つの課に6年近くいるというBPと一緒に仕事をする機会があった。その課にはプロパーの技術者が長いことおらず、彼がその課の技術的中心を担っているという話だった。抜けられると途端に色んなものが崩壊するからという理由で、その人の派遣元にはかなり高額の単価を支払っていたと聞いた。課員が口をそろえて「あの人はすごい」「何でもできる」というので初めはかなり期待していた。
だが、拍子抜けした。あまりにも仕事が雑なのだ。コミットされたコードはTODOコメントだらけだし、バグがあまりにも多かった。一度も実行されずにコミットされ、他の人がチェックアウトした時点で判明したバグなんかもあった。それでも声が大きく、プロパーが技術を知らないのをいいことに自分のブランディングに完全に成功していた。客先にも顔を出し、信頼を得ているらしかった。「自分は設計が得意でテスト以降の工程には興味が無い」と言っていた。確かに彼が関わった各システムには独特の概念が埋め込まれた設計があったが、その複雑な設計は保守性が低く、他の開発者が触ると容易にバグを引き起こしていた。
また、彼はJavaの有名なフレームワークであるStrutsを拡張したいわゆるオレオレフレームワークを開発しており、それの出来は悪くなかったと思う。そのフレームワークに欠けているものをうまく補うような形になっていた。だがフレームワークのバージョンを上げると壊れるというのが残念な点で負債になりかけていた。
私は異動したが、彼は今でもそこにいると聞いた。
（最低限のものしか作らないから）安くて早い！という触れ込みで売っているので、テストの工数が異常に少ないことも多い。特にテストコードを書くなんてもってのほか。そういう世界でやってきた人ばかりなので、30や40超えたマネジメント側は「テストコードって何？」状態だ。大型の改修案件が来た時にはコア機能だけでもテストを書いていこうと見積段階から社内で提案したが「顧客に『そんなメリットあるなら何で今までのプロジェクトではやってないの？』って問われるから、絶対言うなよ」と拒否された。
保守案件をやっていた頃、時間を捻出してコソコソとテストコードを書いたりしていた。その案件を離れてしばらく後、ある時リポジトリを覗いたら私が書いたテストコードがばっさり消えていて驚いた。コミットログから課内のstaticおじさん的な人が消したとわかったが、そのコミットコメントが「現在使用していないコードを削除」だった。これはもう問う気も失せて何も言えなかった。
先述したようにテストがそもそもないプロジェクトが基本なのでリファクタできないのだが、たとえテストがあったとしても勝手なリファクタは許されない。ソースコードは顧客の持ち物なので同意なしに改変することはいわば契約違反なのだ。たとえ内的品質が向上してコスト削減に繋がるとしても、そのためにお金を支払う顧客はまずいない。
私がいたどの案件にもコードレビューがなかった。リーダーと開発者数人という構成の場合、まず開発者は全員下請けでリーダーは技術の心得がない場合が多い。そうなると彼らの成果物の良し悪しを図るのは目に見えるシステムの挙動と実施されたテスト結果のExcel報告書だけになる。これが非常に非効率で、少しコードを読めばわかる明らかなバグや仕様理解の齟齬が頻発していた。特に受入試験と呼ばれるリリース直前の顧客側での最終確認や本番稼働中におけるhotfixは全機能をきちんとテストせずにデプロイされることが多く、そのhotfixがさらなるバグを引き起こしたりもしていた。
そもそもテストを書けという話だがテストが無いプロジェクトに足すのはかなり大変なので、レビューサイクルをきちんと回すだけでもかなり変わる。実際、私が入った案件ではすべてのコミットに目を通すようにし、明らかな問題は都度指摘することで品質の向上に繋がった。欲を言えば他の開発者にもレビューしてもらいたいが、下請けの彼らの工数を増やすことは嫌がられる。
無難にプロジェクトをこなすことと新しい技術を試すことの両立こそ技術者の腕の見せどころだと思っているが、ほとんどの場合それは許されなかった。新規にせよ継続にせよ案件を受注する段階で営業やマネジメント層と顧客間で「今回は過去に実績のあるこの技術でやります」という契約が結ばれているからだ。その技術（言語やフレームワーク）がいかに古く、保守性も将来性もないものだとしても受注できればよいし、その技術のサポート切れか何かの拍子で再度リプレイス案件でも受注できればさらにラッキーぐらいの考えでいる。
また横に倣えが加速してさらに悪い事に、同じアーキテクチャ・ネットワークを再利用するために既存のサーバに新システムも相乗りすればよいという発想も珍しくない。「資産の再利用によりコスト削減」という触れ込みだったが、ただでさえスケールしない低スペックのオンプレミスサーバ上で複数のアプリケーションサーバを運用した結果、予想通り耐障害性が下がった。
また、Oracleのライセンスが高いという理由で一つのDBインスタンス上に10数個のシステムが同時稼働しているなんてこともあった。1つのシステムが高負荷なクエリを投げたせいで関連する全システムが共倒れになったこともあったがOracleのバグとして報告していた。
新人の頃にOJTでstaticおじさんの下に付いたことがあった。そのとき担当したのはPerlでデータ連携用のバッチを書くという開発業務だったのだが、最悪の思い出だ。
まずプログラム構造仕様書というのを書かされた。メソッド単位でのモジュールを全てExcel上に記述し、処理の順番と内容を説明するという謎資料だった。あまりに意味がわからなかったので「UMLのクラス図を書けばよいのですか？」と聞いたら「Perlにクラスなんて必要ない。構造化プログラミングを研修でならってないのか」と返ってきた。「俺が前に書いたPerlのバッチがあるから参考にしろ」と言われ、あるリポジトリをチェックアウトして見てみると1ファイル4,000行の.plがいくつか並んでいた。その時の私は何もわかっていなかったのでそういうものかと思ってしまったが後で調べて明らかにおかしいと気づいた。
また、そのプロジェクトのメイン言語はJavaで、Eclipseを使っていたのでPerl用プラグインを入れてコーディング・デバッグをしていたらやめろと言われた。理由は「Eclipse上で動くPerlが信用できない。サクラエディタで書いてプリントデバッグすれば充分だ」と言われた。その時の私は何もわかっていなかったので、プラグインの品質が悪いとかそういう話かと思い「じゃあvimで書きます」と言ったら「サクラエディタにしろと言っただろ！」と一喝され、vim vs サクラエディタという史上類を見ないエディタ論争が起きた。
SI業界の中では高いのかもしれないが決してよくはない。4年目（たぶん25歳）ぐらいで残業込みで年収400万にやっと届いたがそこからほとんど変わっていない。30歳の先輩に聞いたところ「500万前後、残業してない場合の月の手取りは未だに20万切ることがある。残業抜きでは新婚生活が厳しい」と言っていた。いわゆる年功序列がきっちりしていてこのまま続けてもしばらくは給与が伸びないということがわかった。
個人での貢献で差がつくのは±10万程度。その程度ならいっそ無くてもいいのでは、と思う。というかそもそも生産性をきちんと評価する制度が存在しない。これはどの組織でも難しい問題だと思うが、形骸化した評価制度で上司の気に入った人間にS評価を付けているだけならいっそ止めたほうが時間の無駄にならなくてよい。
会社から貸与されるノートPCは低スペックすぎて開発には使い物にならない。なので開発者は基本的にデスクトップを使用せざるを得ないのだがこれもメモリ4G、1.2GHz程度で大したマシンでもない。本当に開発する気がない。
いつの間にかどこかで意思決定がされていて、関与する機会がほとんどない。だがほとんどの社員がそれで良いと思ってる。失敗しても自分が決めたことじゃないから上層の責任だ、そう言えるので楽だから。
情報共有をしない、というか意図的にしないようにしているとまで感じる。連絡はメールと添付ファイルベースで行っているし、共有のファイルサーバなんてのもあったが一部のフォルダは権限を持った人間しか見られない。何で他の部や課が行った過去の見積や提案資料が自由に見られないんだよ。
ソースコードのリポジトリも同様。外部に公開しないのはまだわかるが、プロジェクト外にすら基本は公開していない。別に奪われて困る大した技術もない。
会社が用意した提案資料共有サイトみたいなのもあったが、それに至ってはもっとひどい。課長以上もしくは部長から承認を与えられた者のみ閲覧可能。共有とは。
どうでもいいことを決めるにも承認や根回しや説得が必要になる。それがプロジェクトの利害関係者ならまだわかるものの、まったく関わっていない上長（課長や部長、時には部門長）を通さないと進まないという異常さ。
利益率向上のためにコスト削減ということがしきりに言われており、過剰なコスト削減対応が生産性の低下を招いている。たとえば顧客に見せる資料以外は白黒で印刷しろ、みたいなルール。色がないために情報が伝わりにくい。というかそもそも印刷せずに各自のノートPCで見ろという話だが、先述したようにノートPCは低スペックすぎるので多くの社員がデスクトップを使っている。ITとは。
本当に無駄としか思えない承認・申請フローの煩雑さに加え、使っているシステムの使い勝手も悪く、ひどい日は一日がそうした事務作業で終わる。しかもそのシステムは自社で以前開発したものだというから泣けてくる。こんな作業が定常的に発生するのでいっそ事務員を派遣で雇うべきという提案が何度もされたが、課の予算をオーバーするから無理だという回答しか返ってこない。
表向きは社員の健康促進という触れ込みで残業時間削減を全社的に取り組んでいる。残業減らせと声をかけただけでは誰も帰らないので、勤怠システムと入退館管理システムを監視し、削減できていない組織や人間の評価を下げるようになった。
その結果、サービス残業が復活した。30時間を超えると部長に説明しないといけない、50時間を超えるとその上へ…みたいなループ。表向きの残業時間削減・コスト削減としては成功したかもしれないが、社員の残業時間を管理するとかいう無駄な仕事を増やしたし、管理される社員のストレスとサービス残業に繋がったので下策だと思う。
他人の残業時間をExcelにまとめる仕事があって、そこに給与が発生してると思うと泣きたい。
そもそも無駄な作業や工数至上主義で作業効率が悪いから残業しているので、残業が少ない奴が偉いと一斉に舵取りしただけでは生産性をちゃんと評価できていないことに変わりはない。一昔前の残業多い奴は頑張ってて偉い、というのと本質レベルで何も変わっていない。
いいコードを書くことってのは凄く大事なことなんだって気がついた。
保守性がどうこうとかよくわかんない。動きゃいーじゃんぐらいの気持ちでいたんだ。
今、人の書いたそういうコードを触らなければいけない立場になって痛感している。
どういうコードがクソかっていう話はネットを探せばいろいろ見つかるからここでは書かない。
ただ、設計書と実際のコードが全然一致していないということがザラにある状況のなか、
可読性のあまりにも低いクソコードをソースコードを鼻血が出るほど苦労しておいかけて、
設計書とは名ばかりの「こんな風にできればいいな？」ということが書かれただけのよくわからない書類を解読しながら
作業を進めるというのは、本当にきついことなんだと思い知った。
コードに殺されるかと思った。
http://cpplover.blogspot.jp/2015/11/linus-torvals.html
Linus tovalsがクソコードに対して物凄く切れているっていう記事。
クソなコードは実際に人を殺すまではいかなくとも、鬱に追い込んだりする破壊力があるんだ。
１行のクソならまだいい。でもこのクソはそのうち積み重なりクソの山になる。
クソコードは人を傷付ける。
俺は自分の書いたコードで人を傷付けるようなことはしたくない。
２５歳。
去年までメモ帳君だったけど、Vimに乗り換えてからブログの広告収入で
二年で３５０万貯めた。一度やってみなよ。
初回のみだけど、バトルエディターズの本を買えば3000円以上ののリターンが返ってくる。
稼ぐだけ稼いでアフィに追加投資せずに換金することもできるし、オリジナルのソースコードをgithubで
思い切って公開しちゃえば５０パーセントでブログに誘導できて収入が2倍になる。
金なきゃVimで!sh aplay ~/スネ夫が自慢するときに流れる曲(6h00m).mp3で曲を流せばいいだけ。暇つぶしになる。
他にも:smileとかecho &titleoldでVimから感謝されたりと色々あるのでマジでお勧め。
この話題は過去に２ちゃんに投稿したんだけ増田にも書いておく。
githubアカウントを凍結されたけど、「私はスパムではない」と連絡しても解除してくれなかった。
メインアカウント(以下Mainと呼ぶ)ではissueでバグ報告とソースコードのダウンロードのためにgit cloneする程度に利用。
サブアカウント(以下Subと呼ぶ)はMainとのフォークとプルリクの練習のために作成した。
ちなみにSubを登録してから何もせず、1年以上寝かせてから練習に使い出した。
凍結される原因になったと思われる内容
Subで登録したメールアドレスで、githubサポートにBOTとスパムではない事を伝えたけど、あなたを疑うとメールで返されて結局解除されなかった。
Mainも凍結されるのかと思ったけど、されなかった。ひょっとしたら第三者のリポジトリでissueを書いて貢献してたからだろうか。
githubに連絡をすれば凍結解除してもらえるという記事もあるが100%解除してくれるわけではない。
凍結してから初めて利用規約を読んだけど、無料アカウントを複数作成することを禁止することが明記されていた。
よくgithubで複垢を運用する記事を見かけるけど、これらの記事は規約違反を勧めているってことなんだよね。
わざわざ1サービスのアカウントを凍結されたことを記事にする人なんていないだろう。
有料アカウントと無料アカウントで練習してたら凍結されてなかったに違いない。
凍結されて分かったこと
■背景と問題点
SI業界におけるシステム開発のプロジェクトでは、ソフトウェアの品質が問題になることが多い。
問題点は、知識不足や経験不足な人間が大量に放り込まれたプロジェクトでは低品質なクソコード（※1）を大量生産してしまう事にある。
※1：クソコードとは、可読性の低さ、保守性の低さ、コーディング規約違反、テストが不十分、静的解析の指摘結果が多い、命名の悪さなどが該当するコードである。
■解決方法
真っ先に思いつく品質向上手段としては、レビュー、指導（教育）が考えられると思う。ただ、コストがかかり浸透するまでに時間がかかるのが欠点だ。
そこで、人間の感性に訴える「羞恥心」をうまく利用する方法はどうだろうか？
クソコードの基準を作り、基準に満たないソースコードをコミットした人物を徹底的に「晒す」ことで、
危機意識が高まり、クソコードをコミットする前に見直しする結果、品質が上がると考える。
「晒す」とは、クソコードをコミットした人物の所属会社名と所属プロジェクトと氏名を館内放送するなどプロジェクトメンバーが一目瞭然で分かる公知の事実にすることである。
月末にクソコードコミットワーストランキングを作成し、食堂、トイレ、休憩スペースなどの目に付くあらゆる場所に掲示することで危機意識が生まれるだろう。
人月単価交渉の際にも基準値に満たない数値が出ていることを示すことで、具体的な根拠を持った単価の切り下げ交渉も可能だろう。
朝会・夕会があるのであれば、クソコード作成者を読み上げて周知の事実とするべきだろう。
請け負った会社単位でのクソコードコミットワーストランキングも作成し、会社ぐるみでの取り組みも強化させることで品質が向上するだろう。
■まとめ
プロジェクトメンバの意識が「クソコードをコミットすると恥をかく」を徹底させ、
きちんとしたものを作らなければならないという意識を芽生えさせる事が一番重要である。
ソフトウェアは目に見えないものなので、品質が分かりにくいが、
物作りの現場だとクソな部品を渡されれば次の工程の人間が困るのは目に見えている。
物作りの現場では、誰が不良品を作ったか？を特定されて、詰められるのは当たり前だろう。
だが、ソフトウェアの現場では未だそれを見ない。そろそろやっても良いのではないか？
読者の皆様はいかが考えるだろうか？
if n ＞= 100 then n = 100
条件: n が100以上 結果:nに100が代入される
みたいにソースコードと1対1に対応するように 書けという指示だったので、言われたように仕事をしてた。
テスト工程がある程度進んだ時に、その指示を出した当人がふらっとやってきて「バグ率は3%でないといけないから」と言ってまた去っていくのな。
元受けからバグ件数が0はおかしいって言われたんだろうけど、こんなテスト仕様書、コンパイラがバグらないかぎりバグ率0%にきまってるじゃん。
ソースもテスト仕様書もレビュー通ってハンコもらってるから変更しちゃいけないけど、仕方ないから適当に変更してバグを作って3%に調整したわ。
内心では部下のことをロボット扱いしてるって言うとまるでヒトデナシみたいだけど、違うんだ。
「パソコンが指示した通りに動かない」とか言うと「パソコンは指示した通りにしか動かないよ」とかが、プログラマーあるあるだよね。
バグって止まる時は、もうほぼ間違いなくソースコードに間違いがあったり、仕様にバグが仕込まれてたりするわけで。
そうするとさ、「できる？」と問い合わせると「できます！」が返ってくるプロトコルなんだな、と理解すれば良いわけだよ。
これはまあ、なんというか、とりあえずACKが返ってくるという状況で「通信が成功しました」という意味でしか無いと。
同じようなことで、「間に合わない時や、困ったときは、言ってね」というのもある。
サーバーの異常監視と全く同じなんだけど、異常時にメールを飛ばすシステムってだいたい動かない。
理屈の上では動くはずなんだけど、サーバーが大変なことになると、大抵黙ってリソースを食いつぶしてる。
だから、状態監視は「定期連絡が途切れたらなんか起こった」「定期的に外側からチェックする」の2つになるんだよね。
「遅れてからしか言わない」じゃなくて「遅れる頃にしかチェックしてない」が正しい日本語。
よく忘れがちになるけど、部下がミスったり出来なかった結果は、上司が責任取るのが基本なんだよね。
責任を取るということは、その作業に責任がある。作業にミスが発生したということは、上司に問題がある。
（ミスの原因とミスの責任は別で、原因究明後再発防止策を取るのは責任者のお仕事）
プログラミングとか、チェックリスト作成とか、定期監視とか、デバッグとか、部下に丸投げできるのが上司の醍醐味なんだし。
その代わり、リソース管理は上司のお仕事になるから、振った仕事は当然リストアップして、なんかこのサーバー負荷高くね？と確認する必要はある。
というわけで、部下のことはロボットだと思うと良いんじゃないかなあ。
道具が悪いって当たり散らしてる上司って、やっぱみっともないぜ。
http://www.demap.info/tetsudonow/
確認したところ、今年3月に開通した北陸新幹線が走っているので、今になってもデータはメンテナンスされているようである。
ところで、列車を走らせるにあたり時刻表データが必要なはずだが、そのデータはどこから入手しているのだろうか？
まさか日本全国およそ9000の駅に全て訪問し、時刻表を撮影してデータ化しているわけではあるまい。
誰でも思いつくのは、駅探・ジョルダン・NAVITIME・Yahoo乗換案内など、公共サービスに備わっている時刻表検索サービスを機械的に収集して時刻表を抽出する方法である。
確かにこの方法で日本全国のデータを網羅できる。しかし、このデータをもとにサービスを行ったり、商売を始めるのはNGである。
なぜなら、上記のサービスベンダーは「JR時刻表」と「JTB時刻表」の内容を交通新聞社およびJTBに許諾をもらって掲載している。
https://www.navitime.co.jp/pcstorage/html/help/etc01.html
上記リンク先にある「弘承平成14年82号」という記述は交通新聞社(旧弘済出版社)の承諾済みであること、「(J)02-7」という記述はJTBの承諾済みであるということである。
これが無いということは、少なくとも交通新聞社・JTBのいずれの承諾も得ていないということである。
無断転載でないとすれば、いったいどうやってデータを作ったのか？
=
「鉄道Nowは、時刻表データを直接売買しておらず、広告を掲載することによって間接的に金銭を得ているのだから問題ない」という意見もあるだろう。
確かにその通りかもしれない。
しかし、仮に無断転載禁止のデータをもとに作成したサービスで広告収入を得ているのだとしたら、それはいわゆる「アフィカス」なのではないか？
「時刻表の無断転載有無など誰も知らないから大丈夫」とタカを括られているのであれば、なおさら悪質な部類に入るのではないか？
ソースコードで言うならばGPL違反と同等かそれ以上の悪質さではないか？
私は別に鉄道Nowを潰したいのではなく、あれだけ注目されたサービスなのだから、権利関係について袖を正すこと提案しているのだ。
当たり前だが、時刻表だけがあってもあのサービスは提供できない。なかなか苦労して開発したはずである。
=
ところで、駅.lockyという、「日本全国およそ9000の駅に全て訪問し、時刻表を撮影してデータ化」を地で行くサービスが存在する。
このサービスを端的に表現するなら「時刻表版Wikipedia」である。時刻表データを作成しているのは有志である。
このデータは交通新聞社・JTBが作成したものではないため、駅.locky内で利用する限りにおいては交通新聞社・JTBの束縛を受けない。
ありがたいことに誰でも閲覧できる状態になっている。
しかしだからといって権利フリーではなく、有償、無償を問わず、再配布することは禁じられている。
http://eki.locky.jp/site/about
=
東京メトロが公開したオープンデータAPIでも、時刻表データが入手できる。
https://developer.tokyometroapp.jp/terms.html
=
線路に沿わせて列車を走らせる動きを再現するにあたり、線路形状データに国土地理院のデータを使っているのであれば、これも商用利用NGである。
http://nlftp.mlit.go.jp/ksj/gml/datalist/KsjTmplt-N05.html
=
回答をお待ちしております。
スマホアプリじゃないけど、某フリーソフトですごいモチベあるなあという人がいる。
フリーで、しかも広告もないのに、アプデも頻繁で、ユーザの声も聞きまくり対応しまくりーの人。
本人が対応する気力あるならいいんだけど、傍から見ててちょっとユーザの声聞きすぎじゃないのと思うことが多々ある。
ユーザも言えば対応してくれる、検討してくれると思うから何でもどんどん要望出すし。
ソースコードも全部公開されてるから気になるなら自分でなおしてくださいくらいの突き放し方でいいと思うのに。
こういう人が鬱になるんじゃなかろうかというような抱え込みっぷりで心配になる。
いや、本人的にはほんと片手間でちょちょっとできるレベルだからまったく問題ないのかもだけど。
無料で提供してくれてるだけでも感謝なのにずけずけとあれがおかしいこれが足りないとひっきりなしに。
今はそういういろんな声がモチベにつながってるならいいんだけど。
考え過ぎかな・・・
漫画や小説みたいに頭から順番に読むのは電子書籍でもいいけど、技術書はとばして読んだり前後を行ったり来たりして繰り返し読むからすごい読みにくいわ。
あと、ソースコードが載ってる本は、字を大きくしたらソースがぐちゃぐちゃになるし、小さいままだと本文が読みにくいし、なんとかならんかね。
このまえ読んだ本は、それを考慮してか、字を大きくしてもソースの部分は大きさが変わらないようになっていてソースのレイアウトは崩れないんだけど、それはそれでやっぱ字が小さくて読みにくい。
それと、出版社がPDF版を売ってるときはkindleを避けてそれを買うんだけど、紙と同じレイアウトで固定レイアウトは9.7インチのタブレットでも読みにくい。
年齢的なそれもあってかコードを書くのも、もう潮時かなあと考えていた。実際、離れていた。
最近、案件で少し変わったツールが必要になり、オープンソース辺りで誰か公開してないだろうかと探してたところ
完全に合致するわけではないが、まあまあ使えそうなオープンソースのソフトウェアに出会った。
最初は、動けば良いかな。と。適当に利用出来れば良いかなと思っていたのだが
なんとなくのぞいた変更点の差分のソースコードの美しさに驚いてしまった。
・ 動きが変わらずとも丁寧に関数や変数の名前を修正していること
・ 機能の変更に合わせて、リファクタによる共通化がおこなわれていること。
数名のメンバーで保守されていてメインの開発者がこの辺りをまとめてるようだ。
普通、この規模のソフトウェアの場合、動き優先になってしまう。
というかそもそもメンテがされてないこともあり、ここまで丁寧にメンテされているモノはほとんど無いと思われる。
コミュニケーションも適切に動いていて、投げっぱなしになることなく開発の相談も行われている。
丁寧でありながら忍耐強い。このソフトウェアが支えられている理由で、美しいと思った理由がそこにあるのだと思う。
Wikiを読んでいると、次のメジャーバージョンで大きな機能拡張が控えてるらしく、メンバーを募集していることを知った。
「任務の遂行に必要な権限がメンバーに与えられていないか、重要な位置にいるダメなメンバーの早期排除に失敗すると、そのプロジェクトは破滅する」という事が判った。
・二回は、プロジェクトリーダーが、リスク回避やプロジェクトを終わらせるのに必要な知見を持ってなかった。
・一回は、エンドユーザーの窓口担当者が無力かつブレブレで、期限までにステークホルダーの意思統一をできなかった。
・一回は、クリティカルパスの一部を担当していた協力企業がありえないほど無責任で、すべてのフェーズで作業を遅延させた。
特に、設計フェーズの責任者がダメだと100%破滅したねハッキリ言って。
設計さえマトモならば被害は「設計通りに出来てない部分の修正」の繰り返しで片が付く。
設計がアホだと、「設計通り作ってるのにダメな部分」と「設計に抜け漏れがあったので、実装者が場当たり的に対応した部分」が混在し、
「後から考慮漏れに気づいて口頭で確認・修正したため設計書が古い」「そもそも設計書が足りない」という状態になって、
設計が不合理だと、メンバー毎の理解度の差がプログラムに反映されてしまってソースコードがグチャグチャになるし、
どんなに有能なプログラマーでも、「あるべき形が決まってないアプリ」は作れない。
新人に設計を担当させているウチの上司は死ねばいいのにと思いました。
君たちは今は残業1時間程度で帰れてるけど、4か月後には土日が無くなって、その時期が最低3か月は続くからね。
頑張ってね。
社内SEとして2社ほど経験したけれど、社内SEで必要なのは技術力よりも社内政治力だとつくづく思う。
感じたことをつらつらと書いてみる。新しいことをするには立場と権力がないと何もできないということをつくづく感じた。
社内SEになりたいと思う人は、ちゃんと考えて入った方がいいと思う。
なんでログってのは軽視されがちなんだ？
俺「いいよログファイル寄越せ」
アイツ「ログファイルのうち、エラーの部分だけ抜粋したったたったｗｗｗｗｗ」←死ね
俺「あーそれ俺が昔作ったやつっすね。今はアンタが担当してるんですね。ちょっとログ出力を強化しましょうか。console.log() でブラウザの開発者ツールに出しましょう」
アイツ「うーん、そうですねぇ・・」
別のヤツ「そうですねえ・・」
アイツ「うーん・・」
別のヤツ「そうですねえ・・」
俺「簡単なんで」
アイツ「うーん・・」
別のヤツ「ねえ・・」
そろそろ死ね
