グリーンコーディング
飛び恥
飛び恥、英語ではFlight Shameという言葉があることを知った。環境に配慮して、飛行機での移動を控えようというものだ。ヨーロッパで盛んになった運動で、ドイツでは国が積極的に国民に呼びかけを行っており、フランスでは鉄道で2時間半以内で移動できる距離の飛行機の運行が禁止された。
抜け道があるとか、どこまで二酸化炭素排出量の削減に効果的であるのかという疑問もある。グリーンロンダリングという言葉もあるように、環境に配慮しているというポーズだけではないのかなどの声もあるようだが、このような動きは今後も確実に増えていくだろう。
グリーンコーディング
IT業界でも、グリーンITという言葉がある。IT自体をグリーンにしよう、すなわちIT利用時にできるだけ環境に優しくするという考えと、ITを活用することで環境負荷を減らそうという考えの双方を含んだ言葉だ。
前者はIT機器や環境、利用方法をグリーン化するという考えであり、省エネ型のIT機器の利用などのようなオフィス環境での取組の他、データセンターにおけるエネルギー公立の高い冷却システムの導入や再生可能エネルギーの利用などが挙げられる。
このグリーンITで、ソフトウェアエンジニアにも貢献が求められているのではないかと思い、環境に優しいコーディングの存在について調査してみたところ、「グリーンコーディング」というベタな呼称の考え方があった。
グリーンコーディングは従来までの処理効率を高めるコーディングと共通するところが多い。メモリやプロセッサの使用効率を高めることは無駄なエネルギーを使わないことであり、両者の目的は一致する。
しかし、反面、昨今のコーディングは開発効率も追求する。また、ユーザーへの応答速度の最大化が最優先されることも多い。前者は汎用的な技術の利用を促し、後者は最終的にはシステム的には無駄な処理をすることがあっても、ユーザーへの応答を優先することが良しとされる。
例えば、オープンソースの活用により、開発効率は高くなる。普及しているフレームワークやライブラリーを使うことで、エンジニアの学習コストは下がり、（広く使われているコードを再利用することで）品質も高くなる。他方、オープンソースは多くの場合、自分が必要とする機能以外も含まれている。それはフットプリントの増大にも繋がり、環境負荷を高くする。自分が必要とする機能だけを抽出すれば良いのだが、それは更新の手間を増やし、開発効率を悪くする。更新頻度が下がれば品質へも影響する。
ユーザーへの応答速度改善のためのテクニックとして良く知られたものに投機的実行がある。パイプライン処理などで、使われるかわからない処理であっても、その処理を行い、最終的にその処理結果を廃棄することも厭わないが、使われることになった場合はすでに処理が行われているため、待ち時間が無く、パイプライン処理はブロックされないことになる。これも予測が外れていた場合には無駄な処理を行うことであり、環境には優しくない。
この投機的実行と同じようなことは、プリフェッチやプリロードと呼ばれる処理においても行われている。すなわち、フェッチすることになるであろう・ロードすることになるであろうという予測を元に先んじてフェッチやロードをすることで、全体的な処理速度を高めるというものである。予測はヒューリスティックに基づき行われており、その精度が一定以上のときに「プリ」動作は行われるようになっているが、予測が外れることも少なくない。この処理が行われるのがWebアプリケーションなどの場合には、ローカルデバイスの処理に無駄が発生するだけでなく、無駄な通信を行うことにもなり、環境負荷は高まる。
考えてみると、我々はある課題を解決するために技術を進歩させるが、その進歩は課題解決以上のものとなることが多く、そのあまり余った技術向上を「無駄遣い」する形で消費してきていたのではないか。そして、その消費 - 浪費と呼んでも良いかもしれない - は当初贅沢だったかもしれないが、程なく普通となり、絶えることなく増大した欲望を満たそうとする中で生まれる課題を解決する形で技術は進化する。
しかし、時代は変わった。持続的な成長のために、コーディングも変わらなければならない。
次のIBMの記事の冒頭では、20年前の帯域幅や処理能力の制約の中でコーディングをしていたことを回顧しているが、また我々はその時代に戻るのかもしれない。富豪的プログラミングは過去のものか。
グリーンコーディングの普及により、プログラミング言語の選択にも影響を与えるかもしれない。2017年に発表された"Energy Efficiency across Programming Languages"という論文では、エネルギー効率の良いプログラミング言語を調査した。この論文では27の言語のエネルギー消費、実行時間、使用メモリを様々なベンチマークに対して行って比較している。想像できるように、1つの言語がすべてにおいて有利ということは無く、何を重視するかによってどの言語を選択すべきかというのも異なっている。
なお、この論文での比較については、Elixirでの開発を行っているソフトハウスにCuriosumという会社がブログで「Elixirが含まれていないのは、ElixirやErlangがそもそも対象としていなかった数学的な計算を用いたベンチマークであるからだ」とこの論文の不備を言っているのを見つけたが、確かにこのランキングだけが独り歩きするのは危険だと思う。ちなみにこのブログ記事はグリーンコーディングについて網羅的に説明されていて、参考になる。
グリーンコーディングにどう取り組むべきなのか
我々人類にとって、もはや飛行機という手段での移動を完全に廃止することは不可能である。しかも、冒頭にも書いたように、飛行機での移動を制限したとしても、どれだけ効果があるのかもわからない。
根本的な解決には、SAF (Sustainable Aviation Fuel) を普及させるしか無いかもしれないが、廃食油の争奪戦も激化する中、利便性の飽くなき追求という価値観を諦めなければいけない時代になってきているのかもしれない。
ソフトウェアやITについても、ソフトウェアエンジニアがコーディングという作業の中でできる二酸化炭素の排出量抑制には限界があろう。持続的な成長のためには、利用者含めての価値観を変えることが求められているのだろうか。技術でできるからという理由だけで、ひたすら要求を満たし続けて良いのか。ある技術を使って良いのかどうか、どのような技術を使うべきなのか、その判断に「環境」という条件が加わっていることを我々は忘れてはならない。
プロダクトマネージャーになりたい人のための本
tl;dr
- 私が監修した本が出る。
- 私が顧問をしているクライス＆カンパニーという人材紹介会社のキャリアコンサルタントが書いた本である。
- クライス＆カンパニーはここ数年、プロダクトマネージャーの転職支援に注力しており、日本で一番プロダクトマネージャーに詳しいコンサルタントだ。
- 彼らの書いた本（私も一部協力した）なので、プロダクトマネージャーを目指す人にはお勧め。
＊ はっきり言って宣伝です m(_ _)m
プロダクトマネジメントが浸透した日本の状況
プロダクトマネジメントやプロダクトマネージャーも日本にだいぶ定着してきたと思う。しかし、まだいくつもの課題がある。なんちゃってプロダクトマネジメントを導入して満足しちゃっている企業が多かったり、プロダクトマネジメントの実践を支援するコーチが少ないことなど。中でも最も大きな課題は受給のバランスだろう。
スタートアップから大企業まで、プロダクト担当者不足に悩むところが多く、どの職種も激しい人材争奪戦が続く。企業によっては、ソフトウェアエンジニアの採用のために海外からのインバウンド採用を始めたり、海外にオフィスを開設したりしている。
そのようなプロダクト人材の中でも、特にプロダクトマネージャーの採用難が続く。まだまだ他職種に比べるとマイナーながら、そもそも日本においてプロダクトマネージャーの認知が広がったのが最近であることもあり、経験者そのものが少ない。しかも、他部署は顧客やパートナーとの高いコミュニケーション能力やビジネスドメイン知識が必要とされることから、ソフトウェアエンジニアのようにインバウンド採用に頼れないところも多く、結果、国内人材市場においてのいびつな需給バランスとなる。
この問題の解決のためには、プロダクトマネージャー人材を増やすしかない。プロダクトマネジメントの周辺職種の人や新社会人にプロダクトマネージャーになってもらうのだ。しかし、すべての職種がそうであるように、企業側から強制的にある職種を目指すように指示するのは得策ではない。あくまでも本人に志向してもらうのが良い。
そのためには、プロダクトマネジメントの重要性やプロダクトマネージャーの魅力を発信するのが必要だが、これは最近かなりできているように思う。Twitterを見ると、プロダクトマネージャーの発信が多く見られる*1。
あと必要なのは、具体的にプロダクトマネージャーを目指す方法だ。これにもいくつか方法がある。中でも古典的ではあるが、未だに有効な手法は書籍出版だ。
すでにある良書
今までも世界で闘うプロダクトマネジャーになるための本 ~トップIT企業のPMとして就職する方法~という本があった。これは「世界で戦う」とあるように主に米国企業のプロダクトマネージャーになるための情報が詰まっている。原題の"Cracking the PM Interview"からもわかるように、どのようにして採用インタビューを通過するかに焦点を当てたものであるが、単なるインタビュー対策ではなく、プロダクトマネージャーの本質に迫る良書だ。
しかし、これはあくまでも米国の事情だ。しかも、今から9年前（原著は10年前）の書籍である。やや古い印象は否めない。プロダクトマネージャーは時代によって役割も変わるし、企業によって期待される内容も異なる。日本企業が求めるプロダクトマネージャー像もある*2。
クライス＆カンパニーをそそのかすに勧めてみる
クライス＆カンパニーは私が顧問を務める人材紹介だ。顧問をし始めたころは、技術職の幹部社員の転職支援のような領域で手伝っていた。CTOやVPoEなどだ。その後、私が立ち上げメンバーの一人で、最近まで運営にも携わっていたプロダクトマネージャーカンファレンスのスポンサーを頼んだことから、プロダクトマネージャーの転職支援も開始した。人を右から左に動かすことだけの人材紹介会社も多い中、本当にプロダクトマネージャーの重要性を認識し、この職種が日本に必要との思いからプロダクトマネージャーの転職支援事業を広げてきている。
彼らはすでにNoteやポッドキャストでも積極的に情報を発信しているが、ある定例ミーティングの中で、私が何気なく、「本出せば良いですよ」と言ったことから、書籍企画は始まった。
プロダクトマネージャーの転職支援のノウハウが溜まっているので、それをきちんと言語化して、外に出すことが皆さんの使命でしょう。とお話するとともに、書籍は名刺代わりになりますよ！ これでリード獲得できますよ！という邪な意見も伝えた。ソフトウェアファーストでのアンチパターンで書いたように、私がそれで騙されて*3、書籍執筆まで、とてつもない産みの苦しみを味わったことは伝えずに、書籍にすると良いことだらけだと背中を押した。
冗談っぽく書いてしまったが、本当に日本で一番ノウハウが溜まっているので、これを発信することは多くの人の役に立つはずだ。出版社もプロダクトマネジメントのすべて 事業戦略・IT開発・UXデザイン・マーケティングからチーム・組織運営までの翔泳社で、編集担当者も同じ人になって頂いた。すべては整った。
書籍というプロダクト
執筆がある程度進んだ段階で原稿を見せてもらった。文章としては整っていても、複数名の執筆者がいる書籍にはありがちであるが、全体の整合性が取れていないところがあった。そもそもどんな読者を想定しているかも不明確で、それがぶれている原因でもあった。
そこで、ペルソナは誰で、そのペルソナにはどうなって欲しいかを明確にしようという提案をした。私がプロダクトマネジメント支援で行っているのと同じアドバイスだ。
それ以外にも「書籍をプロダクト」としてプロダクトマネジメントをしようということで、ありとあらゆる提案をした。最終的にはプロダクト責任者であるクライス＆カンパニーのメンバーが決めることであるが、つい執筆を終了させたいという「ビルドトラップ」*4の影が見え隠れする発言があると容赦なく指摘した。
最終的には、私でも、出版社でもなく、彼ら（クライス＆カンパニーの執筆者たち）がプロダクト責任者として悩みに悩んで決めた形で、自信を持って世に出せるプロダクトとしての書籍になったことと思う。
日本において望まれていた「プロダクトマネージャーを志す人のため」の書籍。6月14日に発売だ。プロダクトマネージャーが気になる人には是非読んで欲しい。
Facebookのノート (Notes) を見る方法
Facebookにノート (Notes) という機能があった。通常の投稿とは別に記事のような形で文章を作成し、それを共有できる機能だ。
creating and editing notes will be unavailable after October 31. We know your posts are important, so any published notes will stay published on your profile. However, any unpublished drafts will be deleted.
この投稿にあるように、Notesは昨年10月をもって新規作成ができなくなったが、過去に書かれたものはアクセスできる。
はずである。
しかし、2022年4月11日現在、Notesという機能/セクション名はどこにも見つからず、検索してもひっかからない。アクティビティログから辿れば見つかるのかもしれないが、膨大な中から目を皿のようにして探すのは現実的ではない。
自分も今回、過去に書いたNoteを参照する必要があり、様々な手段で発掘を試みるものの見つけることができずに諦めかけたのだが、英語での情報をもとにどうにか発掘に成功した。
周りくどいことは抜きにして解決策を書くと、以下のURLからNoteの一覧を得ることができる。そこから該当のNoteをクリックすれば表示させることができる。
https://www.facebook.com/[なんでも良い]/allactivity?category_key=notecluster&privacy_source=access_hub&entry_point=ayi_hub
この方法もいつまで使えるかわからないので、必要なNoteは早めにサルベージしておこう。
リリースとローンチ
自分は言葉に気を配るほうだと思う。
単純な質問されたときにも、内容を正確に理解するために、「その◯◯ってどういう意味？」と聞いたり、「◯◯の定義は？」と聞いたりすることも多い。
面倒臭い人間だという自覚はあるが、プロダクトを作り育てるチーム内でビジョンを共有し、ディレクションを合わせるためには、面倒臭くなくてはならないというのが持論だ。日本社会はハイコンテキストな社会、すなわち「阿吽（あうん）」の呼吸で物事を進められるほど、コンテキスト（前提となる知識や価値観）が共有されている社会と言われるが、甚だ疑わしい。そこかしこで、「実は思っていることが違った」ということが起きている。ドメイン駆動開発（DDD）のユビキタス言語が必要なのもこのような現状があるからだ。
このように、言葉の定義にこだわる毎日を送る中、以前から気になっていた言葉がある。
リリース と ローンチ だ。
同じような意味合いであるが、何かニュアンスが違う。気になって調べてみたが、確固たる定義があるわけでも無いようだった。
このStackexchangeの記事では、リリースはソフトウェアを公開すること、またはソフトウェアが完成した状態としており、一方のローンチは最初のソフトウェアのリリースや注目に値するマイルストーンのリリースを指すとしている。
また、こちらのQuoraの記事では、リリースはプロダクトを公開することとし、ローンチはプロダクトをリリースするプロモーションするためのマーケティング活動などを指すとしている。
この他にも多くの解説がある。日本語での説明も多い。しかし、これと言った決め手は無いようだ。ほとんど同じ意味だとか、言い換えも可能と言われていることも多い。
自分ごととして振り返ってみると、以前はローンチということは無かった。いつもリリースだった。
マイクロソフトでWindowsの開発をしているとき、プロジェクトの終了はRTMだった。Release To Manufacturing、つまり工場出荷という意味だ。
これで開発は終了、もう触っちゃいかん！となると、本社でゴールデンマスターと言われるOSをインストールするためのメディア（当時はCD-ROMだった）が用意され、それを工場に引き渡して完了となる*1。
当時使っていた言葉はすべて「リリース」。記憶を辿っても「ローンチ」という言葉を使った覚えは無い。
時は流れて、Web系のプロダクトを開発するようになった。この頃から「ローンチ」という言葉を使うようになった。
違いは何か。
リリースという言葉は、プロダクト以外にも「プレスリリース」などで用いられる。一般的にも釣った魚を逃す場合に用いる。つまり、ものを「解き放つ」という意味合いが強いのだろう。以前のWindowsのように、提供開始になったら、一旦終わりというパッケージプロダクトの場合、長く温めていたプロダクトを世に放つので、まさにリリースだろう。
一方、ローンチという言葉は、船を進水させたりロケットを発射するときに用いる「送り出す」という意味だ。船もロケットも送り出して終わりではなく、その後も対応が必要だ。ロケットが発射されても、目的地点に到達するためにはなんらかの操縦*2が必要だ。このように、ローンチは出した後も丁寧に制御していくものに対して使われる。
このように考えると、「作り育てる」ことが多くのプロダクトやサービスに求められるようになった今の世の中においては、リリースよりもローンチが必要になっていると言えるだろう。
たかが言葉だが、リリースと言っていたものをローンチと言い換えて、育て続けることを意識するようになるだけで、プロダクトづくりに対する意識も変わるのではないか。
従来のモノづくりからコトづくりに転換を進める企業の方には、こんなことから進めてもらっても良いのかもしれない。
小学生のプログラミング教育に必要なことは「（良い体験としての）全能感」を得ることではないだろうか
小学校でのプログラミング教育が開始され、すでに2年が経とうとしている。新型コロナウィルス（COVID-19）による混乱の結果、GIGAスクール構想は前倒しとなったが、プログラミング教育についてはそれどころでは無くなった学校も多かったようだ。そのような実態は特定非営利活動法人みんなのコードが行った「プログラミング教育実態調査」からも垣間見ることができる。
知人のお子さんがちょうど小学校の低学年ということもあり、最近、再度小学校のプログラミング教育について考えることが増えている。「再度」と言ったのは必修化される前に、自宅近くの小学校の公開授業を見学したり、みんなのコードや未踏ジュニアの担当者とも意見交換していたことがあり、そのときにも色々と考えを巡らせたことがあったからだ。そのときの考えは以下のnoteの記事として公開した。
ここで述べているのは、以下の2点だ。
- プログラミング的思考教育とかいうぬるい考えではなく、プログラミングを教えるべきではないか
- しかしながら、今日の小学校の教師の事情を考えると、無理に授業として組み込むと放っておいて貰えれば後々プログラミングが好きになる子を潰してしまうこともあるのではないか
新型コロナウィルスのパンデミック禍で日本がIT後進国であることが国民にも広く知られるようになり、STEM教育の中心ともなるプログラミング教育はもはや待ったなしであろう。
というようなことを最近考える中で、子どもへのプログラミング教育に必要なことは従来の詰め込み型教育とは真逆の子どもに全能感を感じさせることではないかと思うに至った。
コンピューターを自由に制御することができるプログラミングとは、そのコンピューターの支配者となることを意味する。自分が触っているパソコンやスマホなどを、自分がプログラミングをしたとおりに動かすということは、そのパソコンやスマホの支配者となることに他ならない。
私が解説を書いた「Coders（コーダーズ）凄腕ソフトウェア開発者が新しい世界をビルドする」にも同様の指摘がある。
小さいけど、自分が制御できる世界を持つことができる。小世界の支配者になることができるのがプログラミングだ。
この全能感は、しかしすぐに打ち崩される。支配していたはずの世界でのほころびが見つかる。おかしい、こんなはずではない。友達に試して貰ったら、予想外の使い方をされて、止まってしまった。
思い通りにならない現実に打ちのめされながらも、目を皿のようにして探して見つけた間違いを修正する。動いた。やはり私はこの世界の主なのだ。
子どもは、小さくても良いので自分の世界を持ちたがる。誰もが自分の秘密基地を作ったことだろう。あれなどは、小さな世界を所有することに他ならない。
全能感は一般的にはあまり良くない感覚とされている。なので、ここでミスリードされないためには、冗長となるかもしれないが、補足を加えよう。ここで言っている全能感とは「良い体験としての全能感」だ。良い体験とは、何度も何度も挫け、自分ができることの限界を知り、それを再度打ち破ることの繰り返しの体験だ。コーディングとデバッグと読み替えても良い。または、知らないことを知ることと考えても良い。
子どもへのプログラミングでは、このような「良い体験としての全能感」を味わって貰いたい。達成感を得ながらも、挫折を繰り返す中でものづくりの喜びを知る体験だ。
これは従来の学校教育での正解を教える方法とは根本的に異なるだろう。その意味では、プログラミング教育はSTEM教育としての立場だけではなく、自らが考える子どもを育むという今後の教育の重要な一歩となるのではないだろうか。
