massa142's blog

くり返す このポリリズム

「新装版 達人プログラマー」を読んだ

新装版 達人プログラマー 職人から名匠への道

新装版 達人プログラマー 職人から名匠への道

数多くの技術者がオススメしている名著「達人プログラマー」を読んだ。

ちなみに絶版となっているほうは読んでいない。

Rebuild.fmでomoさんが話していたように、確かに時代背景をきちんと考慮しないと読者のためにならないような情報も多かった。特に技術に関する箇所はそうだったが、取り組む姿勢・技術の根底にある考え方に関しては今でもとても役に立つ内容となっている。

各トピックに関しては広く浅く、エッセンスだけの紹介にとどまるので、「達人プログラマー」となるためには自分でそれぞれ深掘りしていく必要がある。

今となっては当たり前となっていて意識しないようなことも書いてあるが、17年前にこの本を読んだ「達人プログラマー」たちの努力によって技術・環境が進化して今があるかと思うと感慨深い。

総じて、「古典として素晴らしい」というものだった。

合わせて読みたい

読書メモ

第1章 達人の哲学

第2章 達人のアプローチ

  • 直交性
    • 「直交性」という言葉の意味がよくわかってなかったからスッキリした
    • ヘリコプターの操縦の例がわかりやすい
    • 恥ずかしがりなコード
  • 専用の言語
    • Rebuildで話してたようにDSLの話は歴史を感じた

第3章 基本的なツール

  • デバッグの節がよかった
    • パニックに陥らない心構え
    • バグを直すだけでなく、バグを早期発見できなかった原因を考えて改善する
  • 他の節は古典としては楽しめた

第4章 妄想の達人

  • 契約による設計(DbC)
    • 誰の責任かを明確に
  • 早めのクラッシュ
    • 問題発生時点で早めにクラッシュするほうが問題の早期発見や診断を簡単に行える
  • 表明プログラミング
    • もし起こり得ないというのであれば、表明を用いてそれを保証
      • 副作用があってはだめ
      • 本来のエラー処理に表明を使ってはだめ
  • いつ例外を使用するか
    • 例外とは予期せぬ事態に備えるためのものであり、プログラムの通常の流れの一部には組み込むべきではない
    • 例外は例外的な問題のみに使用する

t_wadaさんの話を聞いてたから、この章は理解しやすかった。

【改訂版】PHP7で堅牢なコードを書く - 例外処理、表明プログラミング、契約による設計 / PHP Conference 2016 Revised

第5章 柳に雪折れ無し

基本的な考え方は、任意のオブジェクトが自分以外（サブコンポーネント含む）の構造やプロパティに対して持っている仮定を最小限にすべきであるという点にある。

// デメテルの法則に違反している
console.log(aStudent.class.grade)

// デメテルの法則に違反していない
console.log(aStudent.getGrade())

Ref: 何かのときにすっと出したい、プログラミングに関する法則・原則一覧 - Qiita

第6章 コーディング段階

  • アルゴリズムのスピード
  • テストしやすいコード
    • ユーザにテストさせない
  • 邪悪な魔法使い
    • ウィザードについて
    • 何やってるか自分でわからないものは使うな

第7章 プロジェクトを始める前に

  • 要求の落とし穴
    • 用語集を管理する
      • glossaryは管理し続けるのが難しいから人気ないけど、ユビキタス言語の整理にもなるし必要最低限のものは作りたい

要求とは拾い集めるものではなく、掘り起こすものである

最終的な目標は、要求どおりのものを作るということではなく、ビジネス上の問題を解決するということ

第8章 プロジェクトを始める前に

  • 誇りと愛着
    • コードへの署名を推奨しているけど、属人性を強めるから好きではない
    • おそらくバージョン管理がないような時代背景のせい

達人プログラマーは責任逃れを潔しとしません。 代わりにチャレンジを受け入れること、技術を発揮することに喜びを感じます。

Regional Scrum Gathering Tokyo 2017 に参加してきた #RSGT2017

はじめに

2017/1/12~2017/1/13 に開催された Regional SCRUM GATHERING Tokyo 2017 に参加してきたので、その参加メモです。

Regional SCRUM GATHERING Tokyo 2017

http://2017.scrumgatheringtokyo.org/

Regional SCRUM GATHERING Tokyoは、スクラムの初心者からエキスパート、ユーザー企業から開発企業、立場の異なる様々な人々が集まる学びの場です。講演やワークショップ、そして参加者同士の交流を通じて、世界最前線の情報から日本の現場での工夫まで多くの知見を得られます。

参加動機

SQUEEZEの今のチームでもスクラムを最近始めたので、

  • スクラムに関して改めて勉強したい
  • 実践的な知見が得たい

という動機から参加しました。

個人的には2015にCertified ScrumMasterを取得して以来のスクラムイベントでした。

印象深かったトーク

※ それぞれのトークに@fullvirtueさんのまとめツイートを紹介させて頂きます。

エンジニアの技術力評価は難しい？ - 5年間運用してきた相互評価制度の改善の歴史

slide: https://speakerdeck.com/player/26ea9ccdcd9344c59a80a16d01c5cee2

  • 評価制度を継続的に改善・見直しできている仕組みが素晴らしいかった。
  • 評価軸から組織文化を作っていく過程は参考にしたい
    • 人というのは評価されることを頑張る
    • 評価するポイントを具体的に明確にすることで、社員をそっちの方向に促す
      • 文化として根付いて欲しいこと - 事業理解 etc.
      • いま重要視したいこと - テスト etc.

この取り組みはとても勉強になりました。SQUEEZEも人が増えてきて評価制度を整えないとという状況なので、こういった視点を取り入れるように提案していきたい。

ただ評価会という制度については、個人的に以下のような違和感が残りました。

  • 評価者・被評価者のコストが大きい
  • 事業のためではなくて、評価のために頑張っている感じを受ける
  • 途中から評価会をうまく回すための改善になってて、本質的な解決になっているのだろうか？
  • いくら気をつけても、プレゼン能力の影響力が大きくなりそう
  • 階級制度はフラットな組織でなくなるので嫌い
    • 新卒採用を広く行うところでは仕方ないのは理解できるが

こういった違和感は残りましたが、このような意見も想定内のはずだと思います評価制度というセンシティブな分野を信念を持って長年取り組んできて、その試行錯誤を発表するという試みはとても尊いなと感じました。

※ そもそもスクラムにはほぼ関係ないトークだったけど、どういった文脈なのだろうか？

Pitfalls of Scrum -- My findings from coaching / スクラムの落とし穴 〜アジャイルコーチが遭遇するよくある問題とその解決方法

slide: http://www.ryuzee.com/contents/blog/7104

アジャイルなやり方でプロジェクトをやろうとしたときの「あるある」な失敗をまとめたものとなっていますので、いま何となく上手く行っていない気がする方はセルフチェックとしてもご利用いただけるのではないかと思います。

@ryuzeeさんによるわかりやすいスクラム診断。

自分のチームをセルフチェックしてみたら、以下のような診断結果になりました。

いつも完成しないスプリント

  • 症状: PBIの一部または全部がいつも終わらない
  • 原因: 実績に基づかない楽観的な見積もり

不安定な品質

  • 症状: バグ報告が多い / 完了していないものや作りかけのものを成果として扱っている
  • 原因: 完了の定義(DoD)がない・守れない

機能しないデイリースクラム

  • 症状: 時間通りに始まらない
  • 原因: 時間軽視の文化（自分の遅刻癖）

教育不足

  • 症状: 既出の症状全般
  • 原因: トレーニングや準備不足

次の振り返りでこれを改善できるよう話し合いたい。現状を把握できるようになるスクラムはやっぱりいいですね。

スライド53ページにある以下のモデルだと、自分たちはまだ「混乱期」だと認識できました。

slide-53.jpg

全体を通しての感想

  • 規模は大きすぎず小さすぎずちょうど良かった
  • 会場みんながフレンドリーな雰囲気で楽しかった
  • 仕事もあって2日間フルでいられなかった
    • 来年はPartyにも参加してちゃんとGATHERINGしたい
  • マネージメントな人が多くてPyConなどの技術カンファレンスとはまた違った感じ
    • 年齢層はちょっと高め
    • 女性比率は高い
    • エンジニア比率は低い
  • カンファレンス運営の収支報告を行なっていて良かった
  • 来年は木・金・土の３日間に増えるかも
    • 同じ会場の仮予約を済ませたらしい
  • 翻訳メンバー陣が推薦していた『ジョイ・インク 役職も部署もない全員主役のマネジメント』を読み始めた
    • 途中までの感想としては
      • XP, アジャイルのエッセンスが詰まってる
      • 「Joy」と「Happy」の違いの指摘が鋭くて面白い
      • 実践に基づいたアウトプットなので親しみやすい
      • 川鍋さんのあとがきが熱い
    • 読み終わったらまた別途ブログ書く

おわりに

スタッフ・スピーカー・スポンサーの皆さま、お疲れ様でした＆ありがとうございました。

すごく楽しくて為にもなったので、ぜひ来年も参加しようと思います！

2016年の振り返り

あけましておめでとうございます。

年末はなにかと忙しくて2017年になっちゃいましたが、2016年を振り返っておこうと思います。 2017年の抱負はまた後で書きます。

massa142.hatenablog.com

エンジニア

Python

2016年はこれまで以上にPythonにハマっていきます。

SQUEEZEに転職してPythonで仕事するようになったし、Pythonにどっぷり浸かることができた。

やればやるほど奥が深くて面白い。自分が苦手なネットワーク周りの低いレイヤに関する知見を2017年は勉強していきたい。

Pythonの各項目別の達成度は以下の通り。

転職前まではPythonの勉強のために読み進めてたけど、春以降はやらなくなった。

転職して英語のドキュメントに抵抗はなくなったし、必要になったもの/興味が出たものを引き続き読んでいけばOKかな。

flake8プラグインを作ろうかなと思ったけど、去年はできなかった。業務で必要になったら作ろう。

  • PyCon JP 2016のスタッフを引き続き頑張る

2016の会場チームは経験があまりないメンバーが多かったので、多少なりとも自分が引っ張ることができてよい経験だった。また寺田さんと一緒になる時間が増えたことで、仕事の進め方・周囲の巻き込み方などを勉強することができた。

PyCon JPのスタッフ活動からは、技術以外の大事な社会人スキルをたくさん学べている。

YAPC::Hokkaidoのあらたまさんのtweetはとてもしっくりきた。

ただPyCon JP 2016に関しては、家庭の事情でカンファレンス2日目に参加できなかったことが心残りで不完全燃焼。

それでトークもキャンセルせざるを得なかったのは残念だった。2017はやりたいことやって完全燃焼できるようにしたい。

転職などでばたばたして休止していたもくもく会を10ヶ月ぶりに再開できた。

mokupy.connpass.com

けど結局2016年はこの1回だけになってしまったので、2017年はなんとか毎月開催を再会したい。

  • PyCon APAC 2016に参加する

初めて海外カンファレンスに参加した。

めちゃくちゃ楽しかったし、Python・カンファレンス運営の勉強になったので、2017年もPyCon APACにぜひ参加したい。

massa142.hatenablog.com

英語

SQUEEZEは公用語が英語なので、英語学習にはとても良い環境だった。

おかげで英語のドキュメント・リスニングに対する抵抗感はほとんどなくなった。

ただ話すほうは挫折した。

日本人比率も下がるしなんとか頑張りたいけど、英語に対するやる気と技術に対するやる気が両立しないのが難しい。どうするのが自分にとっていいのか模索中。

まあ英語な環境を楽しめているんで、焦らず気長に取り組んでいきたい。

アウトプット

ブログ

Qiiita

2015年と同じでAdvent Calendarの時期にアウトプットが集中したかな。これこそAdvent Calendar駆動開発。

量をこなせるようになったので、2017年はもっと質にこだわりたい。

また日報を11月から始めた。

wikihub.io

無理をせずに継続することを大事にしてるので2・3日おきの更新にはなってるけど、

  • 作業ログ
  • 感情の整理
  • アウトプットの練習

としてとても役立ってる。

飽きっぽい性格なんで3日坊主で終わるかと思ったけど、ゆるい感じのやり方が性に合ってたみたい。

この1年間の振り返りと日々の日報の中間的な存在として、2017年は毎月ごとに振り返りをブログでやっていきたい。

ラクロス

2016年のAdvance-Hanglooseは弱かった。

自分がAdvanceでプレーし始めてからチームは上昇しつづけてきたけど、去年ははじめて挫折を味わった。1勝もできずに、入れ替え戦にも破れて2部降格。

自分の反省としては、「幹部に頼ってしまい責任感がなかった」

もっとラクロスに真剣に向き合って取り組まなくては。

今年は久しぶりに幹部もやるので、Advanceが再び強いチームになるための礎を築きたい。

Perfume

2016年参戦記録

2016年はラクロス部とPyCon JPにもPerfumeの輪を広げることができてよかった。

日々の暮らし

  • 心と体を整える

体のメンテナンスがだいぶできた。

体の調子がいいと心の調子も良くなる。

  • 月2万ずつの貯蓄

貯蓄全くできてないけど、月2万の保険に入ったからよしとする。

  • 家計簿をつける

つけてない。けど現金で払うことがほとんどないから家計簿いらないかな。

お金に向き合うための別の方法を考える必要あり。

観に行った映画

今年振り返ってみて

良かったこと

  • SQUEEZEへの転職
  • 尊敬できるメンバーと出会えた
  • 業務外で手伝える会社に出会えた
  • Vue.js・Angular.jsのコミュニティに関わった
  • 技術本をたくさん読んだ
  • Steins;Gateを今更観た
  • ボルタリング始めた
  • 真田丸最高だった

悪かったこと

  • 発表をほとんどしなかった
  • 12月以外でのアウトプットが少ない
  • アウトプットにRockとエモさが足りない
  • 読書ログがない
  • 西武ライオンズが弱い
  • 相変わらず朝が弱い
  • 家族との時間が少ない

情報収集方法まとめ 2016年12月版

はじめに

この記事は、ぼくの情報収集方法 | tsub's blogのインスパイア記事になります。

ちょうど良い機会なので現時点での情報取集のやり方をまとめておこうと思います。

どうやって情報収集しているか

Twitter

ちゃんとした技術的発信をしている人のアカウントは積極的にフォローしてます。
Twitterのタイムラインを追ってるだけで楽しいので、仕事中に身過ぎないようにするのが大事になってきます。

t_wadaさんも言う通り、何気ないつぶやきやRTを「たまたま見かける」ことで情報収集に役立ってます。

現時点でのフォロー数は1140です。これだけのtweet全てをタイムラインでキャッチアップするのは不可能です。 けど自分にとって大事なtweetを見逃したくないのが人の常です。

このためにTweetDeckで、追っておきたいハッシュタグ・ユーザーを登録していって複数のタイムラインにしてます。

tweetdeck.twitter.com

違う対応策として「リストの作成」というのがありますが、リストメンバーの管理コストがめんどくさいのでリストは使ってないです。

はてブホットエントリー

はてブホットエントリーも、今話題になってる情報が詰まってます。

はてなブックマーク - 人気エントリー - テクノロジー

かなりの頻度でここをチェックしてたんですが、いちいちブラウザで開くのが面倒だったので去年CLIツールを作りました。

GitHub - massa142/gotebu: Command Line Client for Hatena Bookmark HotEntry

自分も１年間飽きずにこのコマンド使い続けたんで、はてな民にはオススメだと思います。

HBFav

これもはてな民にとっては外せないツールです。作者であるnaoyaさんには感謝しかないです。

hbfav.bloghackers.net

HBFavは、はてブでお気に入りに登録しているユーザーがブクマした記事が流れてきます。

現時点では、はてブのお気に入りユーザーはTwitterのフォローよりも人数が少なくテック要素が濃いめという状態になっています。なので、タイムラインの流れの速さがTwitterに比べてゆっくりで、かつ内容は技術に関するものがほとんどというSNSを構成することができてます。 Twitterのフォロー人数が膨れ上がってるはてな民にオススメです。

Podcast

Podcastは仕事の行き帰り・仕事中・入浴中によく聴いてます。

rebuild.fm

mozaic.fm

購読しているのはこの2つです。

特にRebuild.fmはサポーターにもなってる大ファンです。好きなゲストはNさんとhigeponさんです。

この前試験的に放送されたPyData JP FMも面白かったです。日本でPython系のPodcastは少ないので、ぜひ継続開催してほしいと願ってます。

pydatatokyo.connpass.com

Github

GitHubのWatchやアクティビティも有益な情報なんですが、GitHubのタイムラインは観測しづらいUIなのが辛いです。

自分は@azuさんが作成したTwitterにGitHubの通知を流すlambdaファンクションをforkして利用してます。基本読み飛ばしてもいい情報なんで、Twitterで眺めるのがちょうどいい感じです。このアカウントをTweetDeckに追加してタイムラインが見れるようにしてます。

このlambdaの詳細は以下のエントリとリポジトリを参照してください。

GitHub - azu/github-to-twitter-lambda: Lambda bot that fetch own GitHub notifications/events and post to Twitter.

AWS lambdaでGitHubのアクティビティをTwitterで読む用に投稿する | Web Scratch

Qiita

Qiitaのタイムラインはフォローするタグのチューニングを正しく行えば有益な情報源になります。というのは、キャズムを超えたタグだとスパムみたいな有象無象の投稿によってタイムラインが埋まってしまうからです。

日本ではまだニッチで投稿数も多くない分野のタグのみをフォローしておくことが、Qiitaを嫌いにならないHowtoかなと思います。

自分が現時点でフォローしてるタグはこの6つでした。

メルマガ

フロントエンド系のメルマガを2つ購読してます。

1週間分の注目記事がまとまってるのは、なにかとありがたいです。

社外Slack

社内Slackはもちろんですが、OSSやコミュニティのSlackにも参加するとよいです。 自分がハマった場合に知見がある人に気軽に質問できたりしますし、他の人たちの技術的雑談をROMってるだけでも勉強になることが多いです。

まとめ

ここまでオンラインでの情報収集方法についてまとめてきました。

ただ、やはりオンラインよりも実際に人と話す・人から聞くというオフラインのほうが情報吸収率は高いと思ってます。機会があれば、どんどん外に行きたいところです。

あと意識したいのは、

  • 黙ってコードを書く
  • 自分からも発信する

ことを怠らないことですね。情報収集厨にならないように気をつけましょう！(自戒を込めて)

2016年買ってよかったもの

この記事は、今年買ってよかったもの Advent Calendar 2016 20日目の記事になります。

www.adventar.org

エアーフロス

フィリップス ソニッケアー エアーフロス ウルトラ 【歯間洗浄器】 HX8332/01

フィリップス ソニッケアー エアーフロス ウルトラ 【歯間洗浄器】 HX8332/01

Rebuild.fmでmiyagawaさんとhigeponさんがお薦めしてたエアーフロス。
今年から矯正もはじめていて、ちょうど歯への意識も高まっていたので購入してみた。

rebuild.fm

フィリップスの取説によると、

歯ブラシ・歯間ブラシではケアしにくい「奥歯と奥歯の間」や、「歯並びの悪いところ」、「矯正器具やブリッジまわり」の歯垢・食べかすを除去してくれます。

らしいです。

使ってみた感想は

  • 使用感が気持ちいい
  • 届きにくいところを掃除できる
  • 水が飛び散って綺麗に使うのがむずい
  • お値段は高い

ってところです。

おわりに

残念ながら、紹介できるのエアーフロスしかなかったです。
振り返ってみると、今年はガジェットにはお金使ってなかったみたい。

2017年はもうちょっとガジェットに投資したい。あと備忘録も兼ねて、買ったものは追記形式で書いてみます。

こんな感じを真似したいところ。

kannnonn.com

まだ見ぬバグゼロを夢見て

はじめに

この記事は、ポエム Advent Calendar 2016 15日目の記事です。

過去

半年前に入社したときのSQUEEZEのコードは、いわゆる不吉な匂いに満ちていました。

  • 重複したコード
  • 長すぎるメソッド
  • 巨大なクラス
  • 長すぎるパラメータリスト

などなど。

ただスタートアップでスピード重視の開発をしていたので仕方なかったのだと思います。

現状

※ まだバグゼロは実現してません。少なからずバグは存在しています。

サービスをよりスケールさせていくために、それに耐えうる品質が求められています。 バグゼロに向けて、現在次のような取り組みを行っています。

  • テストコードを書く
  • エラートラッキング
  • リリースサイクルを短くする
  • 古いコードのリファクタリング・破棄
  • コーディングスタイルの統一
  • コードレビューの徹底

これらに関しては、バグゼロを実現した話とその後の顛末 - Cybozu Inside Out | サイボウズエンジニアのブログの記事をおおいに参考にしています。

ここではこういった取り組み以外に、バズゼロに向けて自分が大事にしているエンジニアの教訓を紹介します。

ボーイスカウトの規則

http://d.hatena.ne.jp/asakichy/20100706/1278377244

アメリカのボーイスカウトにはシンプルな規則があります。「自分のいた場所は、そこを出て行くとき、来た時よりもきれいにしなければならない」というものです。

これは、実装作業にも当てはまります。コードは何度も洗練され続けなければならないからです。

割れ窓理論

http://d.hatena.ne.jp/asakichy/20101217

長期間修理されることのない割れた窓が１枚でもあると、ビルの住人に「投げやりな（ビルの状態など気にもかけないようになる）感覚」が植えつけられていきます。すると、次の窓が割れます。さらに、ゴミが撒き散らかるようになります。落書きもされるようになります。

このようにして、たった1枚の割れた窓から、建物全体に対する深刻な破損が起こり始めるのです。これが「割れ窓理論」です。

ソフトウェアの「割れた窓」、つまり「悪い設計」「間違った意志決定」「悪いコード」を放置してはいけません。ソフトウェアをごく短期間で腐敗させることになります。「割れた窓」が何枚かあるだけで、「残りのすべてのコードもガラクタなんだから、自分も適当に作業してしまえ」という考え方が忍び込みやすくなるのです。

伝えたいこと

つまりこういった日々の小さなカイゼンが、品質の継続的な向上につながっていくのだと。ここに銀の弾丸なんてものはない。

「忙しいからカイゼンできない？」 ちがう、カイゼンしないから、忙しいのだ。 :: by and for engineers

このタイトル通り、カイゼンしないことの積み重ねは未来の自分の首を締めることになる。

カイゼンすべき割れ窓に気がついたら、言い訳せずに見て見ぬ振りをせずに真摯に向き合っていく姿勢こそが、バグゼロ実現のために必要なことなのだと信じています。

Creative Commons Licenses に関するメモ書き

はじめに

この記事は、法律 Advent Calendar 2016 18日目の記事です。

Creative Commons 4.0

Creative Commons Licensesとは

クリエイティブ・コモンズ・ライセンスとは | クリエイティブ・コモンズ・ジャパン にある説明・画像を引用します。

CCライセンスとはインターネット時代のための新しい著作権ルールで、作品を公開する作者が「この条件を守れば私の作品を自由に使って構いません。」という意思表示をするためのツールです。

CCライセンスを利用することで、作者は著作権を保持したまま作品を自由に流通させることができ、受け手はライセンス条件の範囲内で再配布やリミックスなどをすることができます。

nyumon2_gd11.png

左側はいわゆる「All rights reserved」、著作権がある状態を表します。右側はパブリックドメインなどといわれる、保護期間が終了したり、権利が放棄されている状態です。

CCライセンスは先ほど示した左右の状態の中間に存在しており、“Some rights reserved”、限定された権利を主張するライセンス形式を提案しています。

ウェブが普及した世界において、作り手の権利が守られつつ、誰もが平等に作品を共有すること。

わたしたちは、このような中間領域を定義する方法で、作品の共有をスムーズにし、創造性豊かな環境を実現しようとしています。

Creative Commons Licensesの種類

クリエイティブ・コモンズは「表示（BY）」「非営利（NC）」「継承（SA）」「改変禁止（ND）」という4つの条件の組み合わせから6つのライセンスが存在します。

creative-commons-783531_1280.png

表示（BY）

by-large.png

  • Attribution
  • 作品のクレジットを表示すること

非営利（NC）

nc-jp-large.png

  • NonCommercial
  • 営利目的での利用をしないこと

継承（SA）

sa-large.png

  • ShareAlike
  • 元の作品と同じ組み合わせのCCライセンスで公開すること

改変禁止（ND）

nd-large.png

  • NoDerivatives
  • 元の作品を改変しないこと

ソフトウェアにクリエイティブ・コモンズ・ライセンスを付与することができますか？

FAQ　よくある質問と回答 | クリエイティブ・コモンズ・ジャパン

可能ですが、お勧めはできません。

クリエイティブ・コモンズ・ライセンスは、ソースコードとオブジェクトコードについては、適用の対象として考慮していないからです。Free Software Foundationによって公開されているライセンス（日本語参考訳）や、Open Source Initiativeがリストに挙げているライセンス（日本語参考訳）等、ソフトウェアに適したライセンスが既に他にありますので、そちらのご利用をご検討ください。これらのライセンスは、クリエイティブ・コモンズ・ライセンスと異なり、ソフトウェア専用のライセンスとして設計されています。

メモ書き

Creative Commonsはソフトウェアを考慮しておらずお薦めしていないので、GitHubのライセンス選択肢にも出てきていない。

Choose an open source license - Choose a LicenseではNon-Software Licensesにおいて、CC0-1.0・CC-BY-4.0・CC-BY-SA-4.0が紹介されている。

ソフトウェアだけでなくその他のコンテンツを含んだプロジェクトにおいては、該当箇所を明記した上で複数のライセンスを掲げることが推奨されている。

e.g. https://github.com/github/choosealicense.com#license

The content of this project itself is licensed under the Creative Commons Attribution 3.0 license, and the underlying source code used to format and display that content is licensed under the MIT license.

Software Licenses

ソフトウェアに関するライセンスについては、Choose a Licenseまたはその翻訳記事をあたるとよい。