メッセージ。 - diary
2019-07-09
# にゃー
HaskellのNetwork.Curlでめっちゃハマった。セッションCookieが保存されたりされなかったりという現象が出て、サーバー側の仕様が正確に分からずブラックボックスという条件なので、どこで何が起こってるのかさっぱり分からん状況。いったんは要件を実装に落とすことそのものを諦めたんだけど、Network.Wreqに切り替えることであっさり解決。Network.Curlに不具合があると思うんだけど、デバッグする時間が取れないんだよなー。とりあえず、今後Network.Curlは使わないようにしよう…。
2019-07-08
# にゃー
「宇宙人は存在するか?」という設問に対して、最近のぼくの考えはこう。まず、「宇宙人」と「存在」の定義が曖昧で、とくに「存在するか」という部分について、正直なところぼくには答えられない。世界が「存在」するか、自分が「存在」するか、あなたが「存在」するか、ぼくには分からない。なにが「存在」し、何が「存在」しないのかも、皆目見当がつかない。それが答え。
そうすると、「いやいや、それはいいんだよ。普通それは当然私もあなたも世界も存在するという前提で話をしてるんだよ」となるだろう。そうした場合、ぼくの答えは「宇宙人は存在する」となる。だって、ぼくやあなたは存在してるんでしょう?ぼくやあなたは、宇宙人だよね?だったら、もう自明だよね。
そうすると、「いやいや、それはいいんだよ。普通それは、『我々以外の天体に生命が存在するか』という議論をしているんだよ」となる。そうした場合のぼくの答えとしては、「我々」がこの「宇宙」に「存在」している以上、それは存在しうるものであり、他の天体に生命が存在するかどうかは確率の問題である。確率の問題であふのであれば、この宇宙は相当広いことであるし、確率はゼロではない。つまり「存在する可能性がある」「存在しないとは断言できない」となる。
あるいは、ぼくらの持っている宇宙のモデルが、実際とは全然違って、本当は宇宙というものが存在しなかったり、存在の仕方が違うのかもしれない。そうした場合は、やはり設問に答えるにあたって、「宇宙」や「宇宙人」、「存在」の定義が合わないことには話が進まないことになると思う。
いずれにせよ、よくある前提に立ったときには、「宇宙人が存在するかしないか」という設問にはあまり意味がないだろう。それともこの質問は、宇宙人に会えると思うか?という問いなんだろうか。
そうすると、「いやいや、それはいいんだよ。普通それは当然私もあなたも世界も存在するという前提で話をしてるんだよ」となるだろう。そうした場合、ぼくの答えは「宇宙人は存在する」となる。だって、ぼくやあなたは存在してるんでしょう?ぼくやあなたは、宇宙人だよね?だったら、もう自明だよね。
そうすると、「いやいや、それはいいんだよ。普通それは、『我々以外の天体に生命が存在するか』という議論をしているんだよ」となる。そうした場合のぼくの答えとしては、「我々」がこの「宇宙」に「存在」している以上、それは存在しうるものであり、他の天体に生命が存在するかどうかは確率の問題である。確率の問題であふのであれば、この宇宙は相当広いことであるし、確率はゼロではない。つまり「存在する可能性がある」「存在しないとは断言できない」となる。
あるいは、ぼくらの持っている宇宙のモデルが、実際とは全然違って、本当は宇宙というものが存在しなかったり、存在の仕方が違うのかもしれない。そうした場合は、やはり設問に答えるにあたって、「宇宙」や「宇宙人」、「存在」の定義が合わないことには話が進まないことになると思う。
いずれにせよ、よくある前提に立ったときには、「宇宙人が存在するかしないか」という設問にはあまり意味がないだろう。それともこの質問は、宇宙人に会えると思うか?という問いなんだろうか。
2019-07-06
# にゃー
日本人の男にとって、ある意味仕事と人生はリンクしている。「いい仕事」ができたということは、「いい人生が送れた」ということと同義である。そういう価値観を持っている部分がある。念のため、ここでいう「いい仕事」とは、「世の中にとって価値のあることを提供した」ということであって、聞こえがいいとか安定した仕事とかそういうことではない。日本人の男は、あるいは「ある世代やある世界の男たち」は、そういう矜持を持っている。
だから彼らにとって、仕事は苦痛ではない。苦しいこともあるが、苦しみがあることを承知のうえで、それを乗り越えて道を進んでいくことを選んでいる。登山のようなものだ。そこに苦しみがあることは分かっている。当然分かっているが、分かっているからこそ、あえてそれに挑んでいく。「苦しくないことをとにかく避ける」というリアクティブな生き方とは、反対の方向に進む。
昔のことは知らないからこういう言い方になるけど、もしかしたら、昔の日本の女たちにも、同じような矜持があったのではないか。彼女たちも「いい仕事」が「いい人生」を意味するような、そんな矜持を持っていたのではないか。そしていまは、それが見えにくくなっていたりするのではないか。
自然や社会と個人がリンクしているような、人生が仕事(自然的、社会的価値)に仮託されているような、そんな生き方が自然だったのではないか。(ここでの「社会」は「国家」を意味しない。不定形でオーバーラップを持つ重層構造からなる社会のどこかを指す。)
だから彼らにとって、仕事は苦痛ではない。苦しいこともあるが、苦しみがあることを承知のうえで、それを乗り越えて道を進んでいくことを選んでいる。登山のようなものだ。そこに苦しみがあることは分かっている。当然分かっているが、分かっているからこそ、あえてそれに挑んでいく。「苦しくないことをとにかく避ける」というリアクティブな生き方とは、反対の方向に進む。
昔のことは知らないからこういう言い方になるけど、もしかしたら、昔の日本の女たちにも、同じような矜持があったのではないか。彼女たちも「いい仕事」が「いい人生」を意味するような、そんな矜持を持っていたのではないか。そしていまは、それが見えにくくなっていたりするのではないか。
自然や社会と個人がリンクしているような、人生が仕事(自然的、社会的価値)に仮託されているような、そんな生き方が自然だったのではないか。(ここでの「社会」は「国家」を意味しない。不定形でオーバーラップを持つ重層構造からなる社会のどこかを指す。)
2019-07-02
# にゃー
不具合や障害が起きたとき、日本人は「残業でも徹夜でもして直すのが当たり前だ」と考えがちだ。この言葉の背景には、「不具合や障害はないのが当たり前。もし不具合や障害を起こしてしまったのなら、どのような犠牲を払っても、一刻も早く復旧すべき(ユーザーへのリスクなしに)」という論理が含まれる。
たとえばあるプロジェクトで、Aという機能が企画される。一ヶ月をかけてその機能は開発され、本番環境にリリースされた。Aの次はBという機能だ。Bもまた一ヶ月をかけて開発され、本番環境にリリースされる予定だった。しかしここで、本番環境にリリース済みのA機能に障害が起きた。
ユーザーや営業は、一刻も早く復旧しろと言ってくる。開発チームは、何日も残業や徹夜にまみれ復旧を行った。障害対応には数日かかったが、なんとか復旧はできた。しかし、障害報告書の作成や顧客への謝罪行脚、社内説明などで事態の収拾には時間がかかる。一度信頼を失うと、顧客や営業は、倍返しを求めてくる。より厳しいテスト計画、より完全な設計とテストエビデンスが次のプロジェクト以降に課される。
つまり、Bプロジェクトの開発負担は、当初よりもずいぶん重くなる。しかも、障害対応でたくさんの時間が失われている。しかし、それにもかかわらず顧客や営業は、「当初立てた通りのリリース期日」を求めてくる。時間が減っており、仕事が増えているにもかかわらずだ。
なぜかというと、それが日本人の倫理観だからだ。「やると約束したことは何があってもやらなければならない」「たとえ条件が変わったとしても、それは顧客のせいではない。では瑕疵の原因はどこにあるのか?技術の問題なら開発に責任がある。責任を負うものは無償で復旧しなければならない」「プロなんだから、障害を起こらないようにするのが当たり前だろう」「リスクがあるなら、最初からそれを織り込んでおくべき」という価値観。無限責任だ。
では逆に、欧米の人は不具合や障害が起きたときどう考えるのか。もちろん欧米の人も、障害が起きたときは残業したり徹夜したりして対応する。しかしそれは、あくまで限られたリソースの中での範囲だ。
たとえばある開発スプリント中に不具合が発生する。そのとき彼らは、プロダクトオーナーにこう尋ねてくる。「オーケー、不具合チケットを切ったよ。最優先タスクとしてこのスプリントに入れる?それとも、次以降のスプリントに入れる?このスプリントに入れる場合、当然当初このスプリントでやる予定だったチケットはドロップする」。
優先順位の判断を求められる。さらに彼らは、基本的に残業をしない。どれだけ不具合のチケットが溜まってようが、プロジェクトが遅延しようが、残業も休日出勤もしない。少なくとも自分からはしない。もし、マネージャが明示的に指示した場合は、ある程度残業や休日出勤もやるけれど、無理はしない。無理な指示をするマネージャがもしいれば、それは無能なマネージャなので彼らはすぐに会社を辞めてしまうだろう。
「リソースは限られている。そのなかでやれることをやる」。それが彼らの価値観だ。リソースから溢れるなら、多少不具合や障害があっても気にしない。それは想定内であり、リスクが計画に盛り込まれている。一方日本人にとっては、不具合や障害は想定外であり、計画に盛り込まれていない。正確には、計画などそもそも立てていないのだが、とにかくステークホルダーのあいだでゴールの認識がある程度一致している。暗黙の了解がある。
たとえばあるプロジェクトで、Aという機能が企画される。一ヶ月をかけてその機能は開発され、本番環境にリリースされた。Aの次はBという機能だ。Bもまた一ヶ月をかけて開発され、本番環境にリリースされる予定だった。しかしここで、本番環境にリリース済みのA機能に障害が起きた。
ユーザーや営業は、一刻も早く復旧しろと言ってくる。開発チームは、何日も残業や徹夜にまみれ復旧を行った。障害対応には数日かかったが、なんとか復旧はできた。しかし、障害報告書の作成や顧客への謝罪行脚、社内説明などで事態の収拾には時間がかかる。一度信頼を失うと、顧客や営業は、倍返しを求めてくる。より厳しいテスト計画、より完全な設計とテストエビデンスが次のプロジェクト以降に課される。
つまり、Bプロジェクトの開発負担は、当初よりもずいぶん重くなる。しかも、障害対応でたくさんの時間が失われている。しかし、それにもかかわらず顧客や営業は、「当初立てた通りのリリース期日」を求めてくる。時間が減っており、仕事が増えているにもかかわらずだ。
なぜかというと、それが日本人の倫理観だからだ。「やると約束したことは何があってもやらなければならない」「たとえ条件が変わったとしても、それは顧客のせいではない。では瑕疵の原因はどこにあるのか?技術の問題なら開発に責任がある。責任を負うものは無償で復旧しなければならない」「プロなんだから、障害を起こらないようにするのが当たり前だろう」「リスクがあるなら、最初からそれを織り込んでおくべき」という価値観。無限責任だ。
では逆に、欧米の人は不具合や障害が起きたときどう考えるのか。もちろん欧米の人も、障害が起きたときは残業したり徹夜したりして対応する。しかしそれは、あくまで限られたリソースの中での範囲だ。
たとえばある開発スプリント中に不具合が発生する。そのとき彼らは、プロダクトオーナーにこう尋ねてくる。「オーケー、不具合チケットを切ったよ。最優先タスクとしてこのスプリントに入れる?それとも、次以降のスプリントに入れる?このスプリントに入れる場合、当然当初このスプリントでやる予定だったチケットはドロップする」。
優先順位の判断を求められる。さらに彼らは、基本的に残業をしない。どれだけ不具合のチケットが溜まってようが、プロジェクトが遅延しようが、残業も休日出勤もしない。少なくとも自分からはしない。もし、マネージャが明示的に指示した場合は、ある程度残業や休日出勤もやるけれど、無理はしない。無理な指示をするマネージャがもしいれば、それは無能なマネージャなので彼らはすぐに会社を辞めてしまうだろう。
「リソースは限られている。そのなかでやれることをやる」。それが彼らの価値観だ。リソースから溢れるなら、多少不具合や障害があっても気にしない。それは想定内であり、リスクが計画に盛り込まれている。一方日本人にとっては、不具合や障害は想定外であり、計画に盛り込まれていない。正確には、計画などそもそも立てていないのだが、とにかくステークホルダーのあいだでゴールの認識がある程度一致している。暗黙の了解がある。
2019-06-24
# にゃー
「それは(いい意見だから)、もっとみんなに言ったほうがいいよ」と言われることがたまにあるけど、そう簡単には言えないんだよね。会話というのは、こちらだけで成立するわけではないから。
相手が聞く心を持ち、理解する力を持ち、聞きたいという気持ちを持たなければ、言葉を届けることはできない。言っても伝わらないし、言葉での殴り合いになったり、ネグレクトされるだけだ。
それは、スポーツみたいなもの。お互いのレベルがある程度高くなければ、いい試合にはならない。だから逆に、いい試合をしたいなら、お互いやチームが強くならなければならない。
そのために必要なのは、いい意見を言う人ではない。チームがお互いを尊重し、心から議論をし、汗を流し、成長できるための土壌だ。
相手が聞く心を持ち、理解する力を持ち、聞きたいという気持ちを持たなければ、言葉を届けることはできない。言っても伝わらないし、言葉での殴り合いになったり、ネグレクトされるだけだ。
それは、スポーツみたいなもの。お互いのレベルがある程度高くなければ、いい試合にはならない。だから逆に、いい試合をしたいなら、お互いやチームが強くならなければならない。
そのために必要なのは、いい意見を言う人ではない。チームがお互いを尊重し、心から議論をし、汗を流し、成長できるための土壌だ。