ウィンバックついて考えてみる

「ウィンバック」という言葉は聞きなれないと思いますが、直訳すると「奪還」ということになります。ビジネスになると、どうしてもチャーン（解約）が起きてしまうことはあり、これをゼロにするのは不可能に近いでしょう。ただ、一度離れた顧客を取り戻すのは不可能ではないと私は思います、顧客を取り戻すのがウィンバックと呼ばれます。以下の記事によると、外資系ITベンダーの営業では、最高の評価を与える会社もあるそうです。

xtech.nikkei.com

顧客を増やすにあたって、どうしても顧客の維持に力が割けなくなる部分はあるでしょう。特にベンチャーであれば、売上を伸ばさなければいけないので、中々そのバランスを考えるのは難しいと思います。ウィンバックを狙うよりも、獲得しやすい顧客にリソースを割いていくのも現実的な選択ではあると感じます。
ただ売上を伸ばせば、チャーンが起きた時の課題が解決するかというと、そうでもない場合が多いと思います。チャーンが発生した以上は、その課題はきちんと修正していく姿勢が極めて大事と私は考えていますが、中々それが出来る会社は多くないように思います。
ビジネスを行う上で失敗は付きものです。成功よりも失敗の方がやはり再現性が高いので、失敗をどう活かすかは大事と思います。amazonはそこら辺を、愚直にやっているかなと私は考えていて、

insight.eisnetwork.co

顧客満足へのこだわり、行動偏重、実験の繰り返し、倹約、直接的なフィードバック、継続的な結果測定を重視する文化だ

という姿勢は、見習うべき点は多いと思います。

顧客に対して、自社の提供するサービスを理解していないと考えてしまうのは、やはりありがちです。以下の記事のように、上手くいかない時は「客が分かってない」というふうに感じてしまうのは、どうしても致し方ないことです。

nikkan-spa.jp

ただ、そういう苦しい時にいかに課題を認識して修正するか。その時に顧客に対する姿勢が問われるし、最終的なウィンバックにつながると私は考えています。

オブジェクト指向についていまさらながら考えてみる

定期的にSNS等で話題になる、オブジェクト指向。オブジェクト指向は今となっては古いみたいな意見もあって、どちらかというと批判的な意見も多いように感じます。
オブジェクト指向と一口に言っても、人によって何のことを指してるか微妙に違うと思うし、そこまで厳密な定義は無いかなとは感じます。とはいえ、定義が無いと論じるにあたってやはりふわふわしてしまう部分はあるので、一旦ここでは以下の記事にある、

e-words.jp

オブジェクト指向はデータと操作手順を一体化（カプセル化）し、外部には処理の依頼方法（インターフェース）のみが公開されるため、ある箇所の変更が外部に与える影響を小さくすることができる。チームでのソフトウェア開発で分担などが行いやすく、大規模開発に向いていると言われる。適切に設計されたコードは他のプログラムで再利用しやすいため、似たような機能を重複して開発することを避け、開発の効率化を促すとされる。

ような設計や実装の手法を、オブジェクト指向とします。
では、オブジェクト指向を導入すると、何が嬉しいのかというと、以下の記事にあるような、

nowokay.hatenablog.com

オブジェクト指向方法論のウリは分析段階で出てきたオブジェクト(といいつつクラス)がコードにそのまま引き継がれるというものでした。

が挙げられると思います。ただ、分析段階で詳細に定義したクラス設計が、そのまま実装で使えるかというとそうでもない感じはして

結局のところスケッチの妥当性というのはコードを書かないと検証ができません。分析・設計段階で見出されたクラスが妥当かというのは、コード書かなければわからなかったのです。

というのはそんな感じはします。
従来オブジェクト指向が主に対象としてたのは、ウォーターフォールでいう詳細設計部分な感じがしていて、ドメイン的な意味合いよりは、実装をしっかり行えるような意図で導入されていた気はします。ただDDDの認知度がそれなりに広がっていくにつれて、詳細設計や実装よりも、もう一段階抽象的なドメインの重要性が上がってきた感はあります。

そうなると、詳細にクラスを設計できる仕組みの重要性が、下がってくるのではと思います。きっちりウォーターフォールをやるような現場でなければ、詳細設計書を作成することが少なくなってることも影響はしているでしょう。アジャイルに近いやり方の現場であれば、詳細設計書を作成することよりも、ドメインの認識をいかに一致させるかが重要視されてくる気はします。以下の記事で述べられてるような、

qiita.com

"それが何であり何でないか"それこそが重要である。設計的な文脈で言えば高凝集であると言えます。そして、高凝集であれば、インタフェースで抽象化せずとも変更に強いのです。これはアジャイル開発という歴史的な学習が教えてくれました。
抽象化は、もはや関心毎ではありません。再利用性が必要になったら、ポリモーフィズムを利用すればよい程度のもの。

という考え方が、広がってきているのかなとは思います。この高凝集を実現するにあたって、ごりごりにオブジェクト指向の機能を使い倒す必要性が、薄くなってきたようには感じます。

とは言え、DDDやアジャイルの考え方に至るまでの過程で、オブジェクト指向が果たした役割は大きいと考えています。実装対象がどのようなドメインで、どのような「もの」であるのか、そのような思考を掘り下げるきっかけになった考え方と思います。おそらく今後は、詳細設計書が書かれることは少なくなってくるかなと感じますし、その時には実装者がコードでいかにシステムの対象を表現するか、そういった設計スキルが求められてくるかなと思います。

分断と知性について

ぼちぼち2022年も12月が近づき、あっという間に終わってしまいそうですね。今年の2月にウクライナとロシアの戦争が始まってそろそろ10ヶ月が経とうとしてますが、今年中には終結しない感じはしますね。なぜ両国の関係が、ここまでこじれてしまったのかとういうと、以前に私のブログで触れた通り、ウクライナの東西の対立が引き金の要因の一つとなっています。

toaruit.hatenablog.com

この対立は、いわゆる分断から始まったものとも言えます。分断について以前に私のブログで触れましたが、価値観等がだんだん多様化している日本でも起こっていることではあり、分断をなくすということは難しいことであるかもしれません。その時は分断が起きてしまうのは、致し方ないことなのかなと思ってましたが、これを放置すると先鋭化する場合もあって、良くない方向にいくのではと最近は感じてます。

toaruit.hatenablog.com

分断を解決するために、価値観が違う他者へ、「寛容性」であったり「尊重」を持つのはもちろん大事なのですが、そんな精神論言われたところでどうすりゃいいんだ、というふうには感じてしまうとは思います。寛容性や尊重が持てるようになる状態になるにはどうすれば良いか、それには「知性」を持つことが重要になってくると私は考えています。知性を持つことはどういう状態かというと、以下の記事で書かれているような、

project.nikkeibp.co.jp

自分の価値観の限界を認識し、あらゆるシステムや秩序は完璧でないという前提に立って物事を見ています。自分の視点を柔軟に転換し、他者の立場や環境の状態など、様々な方向から物事を理解しようとします

というのが、適切かなと個人的には思います。
戦争が起きてしまうことも、知性の欠如が根本的な原因であるように思います。以下の記事にあるような、

logmi.jp

人間っていうのは、放っておいたら戦争する側にかなり寄った生物だということがわかります。しかしながら、ここで、戦争には持ち込ませないぞ、と自己に働きかけるのが「知性」だと思うんですね。

というのは、私もその通りかなと感じます。物事を、暴力や権力で無理やり解決しにいくというのは簡単と言えば簡単なので、そういう方向に行きがちな面はあると思います。ただ、そういった解決が根本的な解決にならないことが多いと考えていて、「分断」の課題は残ったままになるように感じます。どう分断の課題を解決するかというと、やはり知性が必要になってくると私は考えています。
では知性をどう身に付ければ良いのか。個人的な所感ですが、突き詰めると事実を整理するということに行き着くと感じます。感情だけで判断せず、いかに事実を収集して判断を行うかが大事かなと思います。

少し前ですが、行政書士の人がセブンの店内で食事して店員の人に注意される、といったことがありました。その際、店員の注意に対して行政書士の人が「理由を説明しろ」や「セブンイレブンの他店でも言われたことない」といった質問をして、食い下がったそうです。

www.j-cast.com

この件で私が重要と考えてることは、注意されたということではなく、「注意されたという事実にいかに向き合うか」ということです。ルールに違反してしまうことは誰でもありうることだし、注意を受けることもあるでしょう。もちろん、注意をした人が絶対的に正しいというわけではありません。ただ、なぜ注意されたのかというのを思考しないのは、やはり知性的であるとは言えず、自分の行動を正として相手に説明しろと要求するのは、ちょっと違うかなと感じます。
上記のセブンの件であれば「この店舗ではイートインは閉鎖されてる」、「イートイン以外で飲食はNG」という事実をきちんと認識できていれば、店員に食い下がるのはナンセンスな行動なのではという判断もできるでしょう。ただ、この事実を認識していない状態であれば、コンビニの店内で飲食をしても別に問題ないでしょと考えてしまうのは、まぁありうると思っています。

この件に限らず、注意を受けた時はその時点で自分の正当性を主張することをせず、時間をかけて思考することは大事と考えています。思考するということはすなわち、その周辺の事実を情報収集して、積み重ねた事実により、状況を出来るだけ俯瞰的に理解に努める姿勢と思います。事実を積み重ねずして十分な思考は行えないし、その先の知性の獲得へも至れないと私は考えています。

アジャイル開発におけるデイリースクラム

最近はシステムの開発現場で、アジャイル開発をやろうというのが比較的現実的に受け入れられるようになってきた気がします。個人的にはアジャイルっぽい開発の方が好きではあるので、この流れは良いかなとは感じてます。
ただ、一方で下記の記事にあるような、アジャイルをやることで、マイクロマネジメントっぽくなってしまうという気持ちは分かったりします。

yigarashi.hatenablog.com

日々のデイリースクラムなどで議題になるのはやはり進捗だし、そこに遅れが出るかというのは、もちろん確認すべきことではあります。特に思うような成果が出せていない場合は、なおさらマイクロマネジメントっぽくなってしまうのは、致し方ない面はあります。
さて、そもそもアジャイルが目指すところとしては、以下のアジャイルソフトウェア開発宣言に書いてある通りですが、

agilemanifesto.org

その目指すところを達成するために、デイリースクラムでやるべきことは何でしょうか。

デイリースクラムを行う前に、その前段のスプリントが目指すべきゴール「スプリントゴール」について、そもそも設定されてるかは、けっこう重要と個人的には思っています。もちろん各スプリントでやるべきタスクはある程度洗い出されてると思いますが、スプリント毎にちゃんとゴールを設定するのも、大事かなと考えています。スプリントゴールは以下の記事で解説されている通り、

note.com

そのスプリントで自分たちが達成したいこと、なっていたい状態

となります。
タスクの進捗管理は、もちろん大事です。ただ、スプリントゴールに向かって、何を実現すれば良いかというのは、プランニング時点ではけっこう曖昧なことが多いこともあるでしょう。日数が経つことで当初見えてなかったこともあるだろうし、想定通りに進まないこともあるでしょう。

なので、デイリースクラムはゴールをどうすれば達成できるか、というのが議論の主眼に置くべきと感じます。それは、作業の進捗に加えて、具体的なゴールをどこに置くかというのも、メンバー間で認識合わせることが大事と思います。もちろんケースバイケースですが、進捗によってリリース日を後ろ倒しにするのは、個人的にはなるべく避けたほうが良いかなと考えています。私が前に以下の記事で書いたように、まずは終わらせることで心理的な安心感は生まれるし、いつまでたっても区切りがつかないのは、チームにとってあまり良い影響はないかなと感じます。

toaruit.hatenablog.com

株主主義について感じること

少し前にイーロン・マスクがTwitterを買収して、その経営改革が話題になってますね。彼が大ナタをふるえるのは、株式のかなりの割合を取得したからであって、株式を取得すれば会社を支配できるという論理にはなるでしょう。

以前に私のブログで、資金調達について取り上げました。そこでは、いわゆるスタートアップのように、資本を出資してもらい事業を拡大させるのは、やり方として正解なのかということに触れました。

toaruit.hatenablog.com

もちろん、事業の特性によってケースバイケースとは考えていて、VCから出資してもらって成功するケースはあるにせよ、ダメになるケースも多いだろうなという所感です。資金を出す側は、そういった事業特性を鑑みて判断してるのかというのは、気になるところです。

一つの見方ではありますが、下記の記事で触れられているような、

forbesjapan.com

日本の株式市場にリスクマネーは新規投入されていない。過去20年、従業員給与、経営者の収入、設備投資、R&Dは横ばいで、代わりに配当と自社株買いは約20倍に。株式市場では、リスクマネーの供給でなく、株主還元が加速しました

という状況は、やはりよろしくはないとは感じます。ただ、株主主義について私は別に反対ではないです。最終的には、その会社をどうするか決めるのは株主であるべきと思ってるし、経営者と株主が対立したら最後は株主の意見が優先されるべきでしょう。

だから、株主は会社に対して意見を言うなら、その影響に対する責任はちゃんと取るべきであり、株主の利益だけを追求するのはスタンスとしてナンセンスと感じます。つまり金を出して口を出したければ、自分がその会社のサービス・顧客・従業員・将来などに責任を持つ、という自覚を持つべきと私は考えています。金と口は出すけど責任は取らないというのは、やはり不健全ではないでしょうか。
イーロン・マスクはTwitterの株主になって、自分が矢面に立って改革をしようとしています。もちろんその内容については賛否あると思いますが、彼なりにTwitterというプラットフォームを良くしたいと思って株主になりました。金儲けばかり考えてる株主には無い思考と行動は、イーロン・マスクらしいなと思ったし、自分がちゃんと責任を取ろうとするスタンスは称賛されるべきかなとは感じました。

システム開発の内製化について考えてみる

昨今、DXが盛んに取り上げられているように、いかにITでビジネスのデジタル化を進めるかといったことが言われています。前にこのブログでも取り上げましたが、ITの利用がビジネスを行う上で重要性が増している以上、ベンダーの利用の仕方や、いかにエンジニアの雇用をどう進めるかということが、成功のためには大事になってくると感じています。

toaruit.hatenablog.com

最近はまた、システム開発の内製化のトピックも盛り上がっていますが、内製化のトピックはけっこう前から言われては立ち消えるといった感はあります。なぜそうなるかと言うと、内製化をやろうとしたものの上手くいかないというケースが多いと思っていて、以下の記事で触れられているような

comemo.nikkei.com

大企業のシステム内製化は、ほとんどうまくいかない気がします。肌感覚としては、100社あって1社うまくいけば御の字ではないでしょうか？

は、あながち的外れでもない気はしています。

ITエンジニアを採用すれば内製化は実現できるかと言われると、そうではない感じはしています。一口にエンジニアと言っても、色々な人がいます。ITエンジニア自体の間口は、現状でも比較的広い気はしますが、内製開発に対応できそうな人材となると、下記の記事にあるような3万人以下というのも、あながち的外れではないかなとは感じます。

atmarkit.itmedia.co.jp

上記の記事でも書いてありますが、内製化を実現するためのエンジニアには、ビジネスへの理解が求められてくると思います。POやPMが大まかなスコープやスケジュールを決めますが、それだけではプロジェクトは動きません。下記の記事で触れられている通り、

thinkit.co.jp

例えば、設計書を作成する工程では、プロジェクト計画書にある体制図やRACIチャートを使って「誰が何をインプットに設計書を作り」「誰が何をインプットにレビューをし」「全部で何段階のレビューを経て完成するのか」や、プログラミングを行う工程では「コーディングルールに書かれている個別ルールが、実際のプログラムでは具体的にどういった実装箇所として現れるのか」など、計画段階や工程の前段階までに準備した情報を具体的にどのように、どのレベルで運用したいのかを技術者と意思統一しておかなければなりません。

のようなプロジェクトをどう進めるかの準備が必要で、これをPOやPMが全て対応するのは困難でしょう。これらをちゃんと進めるようにするには、ビジネスをある程度理解しているエンジニアが、どのような単位で開発の括りを行い、どの順番で開発すれば効率的かなど、実行にあたりブレークダウンできることが重要と考えています。その際にドメイン知識をベースに置かないと、PO・PMやビジネスサイドの人達と意思疎通が行えないし、適切な進め方かの判断も行いにくくはなると感じます。

とはいえ、こういったスキルがどこで得られるかというと中々難しい問題です。その現場に長くいれば、ある程度勘所をつかむことが出来ますが、ドメイン知識がほぼ無い状態ですぐに適応するというのも、けっこう厳しいかなとは感じます。ただ、ドメイン知識の重要性を認識した上で、以下のfreeeでの取り組みのように浸透させていこうという意識は、大事かなとは思います。

developers.freee.co.jp

昨今（2022年10月）のインフレ・円安についての所感

ここ最近はインフレや円安といったワードを、ニュースで見かけない日は無い気はしますよね。我々の日常生活にも影響がある部分はあるので、やはり関心は高くなるでしょう。インフレや円安は、マイナス面もあるのでそこがクローズアップされてしまうのは致し方ない面はあります。ただ、プラスになる面もあると考えていて、長期的にはこれは日本にとって良い方向にいく可能性があると個人的には考えています。

まず、前提として、バブル崩壊から30年近く日本はデフレの状況になっていました。それを打開するために、ここ数年で金をかなりばら撒くような政策をやってきたのですが、内部留保や貯金といった形で貯め込まれてしまい、なかなかインフレ基調にするのは苦労していた印象はあります。ここにきて、ようやくインフレ基調の傾向になってきたとはいえ、要因としては主に海外の政情や円安によるものが大きい感はあります。インフレへの嫌気が大きくなれば、消費がしぼんでデフレ基調に戻る可能性もあるでしょう。

zuuonline.com

では、そうならないためにどうすれば良いかというと、個人的な所感では、インフレ・円安であるうちに国内の供給を拡大し、最終的な賃金アップにつなげるということが大事だと考えています。実際に円安や海外のインフレ影響で、国内への生産回帰という話も出ています。もちろん、国内回帰はすぐに出来るという話でもないし、成功するかと言われると微妙なのではという、下記の記事のような意見はすごく分かります。

wedge.ismedia.jp

また、日本は人口が減少する中で、国内回帰したものの今後雇用を継続できるかという不安はあるでしょう。すぐに人口を増やすというのは無理があるので、国内回帰を後押しする上で直近の政策としてどのようなものが効果的か、というのは真剣に考えるべきと感じます。一つ参考になるのは以下の記事で、

www.rieti.go.jp

競争力の強化には、研究開発や知的連携に対する政策支援が有効だ。ノーベル経済学賞受賞者のポール・ローマー氏が言うように、その利益は社会に広く行き渡るからだ。米欧が計画する供給網強靭化計画では、供給網の国内誘致に加え、大規模な研究開発支援がもう一つの柱となる。この点は日本も見習うべきだ。

は案として良いかなと感じます。

「研究開発や知的連携」の観点だと、教育への投資も大事になってくるでしょう。この部分の投資が数十年上手くいってなかったと感じるし、デフレ・円高基調の状況において重要性もあまり高くなかった気がします。とはいえ、今になってようやく国内回帰が議論されつつある中で、避けては通れないトピックだと考えています。

研究開発や教育に投資することは、価値の高い人材を生む土壌を作ることにつながると思います。最近だと「人材不足」と言われていることが増えている気がしますが、この人材不足を解消することこそが、国内回帰や賃金の上昇を実現する上で、最重要の課題と私は考えています。