TAMINIF’s blog

京都在住のWebエンジニア。iOSアプリもやってます。勉強会にも参加してます。最近はマネージャー色強め

マネージャーになったら身に付けたいファシリテーションスキル

この記事は、Engineering Manager vol.2 Advent Calendar 2019 2日目の記事です。

この記事は、エンジニアのマネージャーになって1年ほど経験した私が、マネージャーに必要なスキルの中から今自分が一番足りていないと思うファシリテーションについて書きます。
まだまだ若輩者のため、この記事へのご指摘はいつでもお待ちしております。

ファシリテーションとは

会議において、段取り・進行など会議を円滑に進めることや、参加者の意見の促進など相手の内面を引き出すことです。
MTGにおける司会者のような役割で、その役割を担当する人のことをファシリテーターと呼びます。
おそらくビジネス用語だと思うのですが、私は最初に聞いた時は全くわかりませんでした。(近くの同僚から聞いた)

なぜ必要か

マネージャーに就任して、当たり前ですがエンジニア内外関わらず人と関わる機会が多くなりました。
その中で、人とのやりとりでリードする立場を期待されることが多くなり、相手とのやりとりの中で最適解を見つけていくためには効果的なファシリテーションが必要だと感じるようになりました。
ファシリテーションスキルがあれば、MTGでも1on1でもディスカッションでもより早くゴールに進めることができます。

ファシリテーションスキルとは

ファシリテートとは「容易にする・楽にする・促進する」という意味です。

ejje.weblio.jp

そして、この言葉は「人は主語にならない」となってます。つまり、モノやコトに対して容易にする・促進するということです。

つまり、ファシリテートするとはただ司会の立場で場を回すのではなく、相手に対して「何か」を促進することです。「何か」というのは、その場によります。
イデア出しのMTGであればアイデアを出させること、目標を設定するのであればその人の内面を引き出してあげること、といったように、です。
前置きが長くなりましたが、ここからファシリテーションのスキルについて書いていきます。

ファシリテーションを意識する

スキルかと言われれば微妙かもしれませんが、一番重要なのは意識することだと思います。
ファシリテーションMTGの場で必要というのは自明ですが、1on1も席での会話も、広義で言えばMTGです。
その時、ただ会話するのではなくファシリテートを意識することで、普段の会話が1段階レベルアップすると思います。ましてや、マネージャーになったからにはあらゆることの調整をする必要があり、
そのための普段のコミュニケーションはとても重要で、どこにでも情報は転がっています。
それらの情報を見逃すことなく拾い上げていくことは、マネージャーにとって重要なスキルだと考えています。

知識を共有する・要約する・噛み砕く

主に相手から意見を出してもらいたい時、意見が出てこないのは質問の投げ方の問題かもしれません。
何より、相手は自分に何を求められているのか、理解していない可能性もあります。
なので、ファシリテートする際には、まず前提をお互いが理解しているかを確認し、もし前提が違う場合は相手に求めている情報を要約し、理解するまで伝えてあげることが大事です。

いきなり意見を求められて、自由に発言できるのは体感でおよそ1割程度です。
残りの9割の人たちは、正解がわかるまで話をしようとはしません。なので、正解があるものを出してあげる必要があり、そのために正解があるというように相手に要約して伝えてあげると、相手もその正解に沿った回答を出してくれて、その後のMTGがスムーズに進む傾向があります。

言われたことの意見を受け止める

相手が言ってくれた意見が、自分の意図したものではなかった場合でも、相手は何かしら自分の考えを持ってその発言をしているはずです。
ただ頭ごなしに否定するのではなく、自分の中に一度落とし込んで、その意見を話した意図を考えることで新しい発見があるかもしれません。
もしかしたら、間違っているのは自分で相手の発言の方が正しいかもしれません。受け止めたことで次の展開が良いものになる可能性は、常に意識する方が良いと思います。

最後に

自分もまだまだできていないですが重要だと思うことを書きました。
マネジメント系のAdventCalendar初参戦なんですが、こんな記事で良いのか不安ですが誰かの参考になれば幸いです。
他にもこういう点もスキルだというものがあればぜひ教えてください。

「ゆとりの法則」読んだ

ブログには書いていないけど、以前にピープルウェアを読んでいて、ピープルウェアとセットだと認識していたので読んでみた。

ゆとりの法則 ? 誰も書かなかったプロジェクト管理の誤解

ゆとりの法則 ? 誰も書かなかったプロジェクト管理の誤解

ピープルウェアが組織の中で仕事をするための本だったのに対して、こちらはプロジェクトを進める手法が書かれた本である
なぜゆとりを持つことが必要なのかと、ゆとりを持たないことで何が起きるのかが書かれている、いわば注意喚起のような本でいくつか印象に残ったところをあげる

本当に早く仕事をするには

この章では仕事を早く終わらせるための間違った方法を解説する

ゾンビ

仕事に執着しやがて燃え尽きてしまった社員のことをゾンビと総称し、ストレスのかかるプロジェクトを見渡すとゾンビになっている人が多いことに気がつく。
ゾンビとなった社員は辞めることが多いが、組織に残り続ける人もいて、そういう人が増えることでプロジェクトは停滞し続けてしまう。
この現象は心当たりがあるがこの見方をしたことがなく、ゆとりを表すバロメーターになるものだと思った。

人員過剰のパラドックス

人手が足りないことはチームのストレスの原因になるが、かといって間に合わない納期に人員を追加して解決する問題でないが、往往にして管理者はそのことを理解しない。
さらに管理者は人手を増やしたことで達成できる挑戦状を叩きつけ、結果恐怖の文化が生まれる。

契約にもゆとりを持つ

ゆとりを持つことは問題が発生した時に対応できる余裕を持つことである。そしてそれはプロジェクトだけではなく、契約の場合も同様である。
二つの契約を並べた時、一方が安ければゆとりを削っている可能性があり、トラブルによって訴訟に発展する可能性がある。自分が売り手の時は容易に想像できるリスクを盛り込んでおく。

誤った目標管理

目標管理は二つの面で誤りである。 - 目標管理はある状態が続くことを前提にしているが、物事は常に変化する。 - 目標の指標は必ず単純化されたものであり、その値を最大値に近づけようとして結果的に企業の貢献度が下がることになる。(ディスファンクション)

変化と成長

全く変化できない人は成長もできない。これは自明だが、変化できないのに成長を求める組織を多く見る。この章では組織の変化と成長を実現するというテーマに目を向ける

リーダーシップとフォロワーシップ

意志を生み出すのがリーダーの仕事である。
リーダーは一部のエリートが担うものであり、それ以外の人はリーダーについていくべきというのは、リーダーシップではなくフォロワーシップを植えつけているだけである。
リーダーシップは全員の任務であり、名案を思いついた人に従うのも任務である。リーダーシップは交代制で担うものである。

変化は中間管理層から

変化がトップから起きるというのは間違いである。重要な変化には再生が伴う。企業の再生のためにはトップにはわからないような日常業務との深い関わりが必要である。
変化が底辺から起きるのも間違いである。底辺の人々は再生するための願望もなければ、再生計画を遂行するための力もない。

変化は中間管理層から起きるのである。
変化には再生のためのゆとりと、有意義な変化を計画し実現するための協力が必要である。

まとめ

リーダーシップとフォロワーシップの話が一番印象に残った。自分がリーダーシップだと思ってやっていたことはフォロワーシップだったかもしれないし、リーダーシップはチーム全員が持てるようフォローするのもリーダーの仕事だと認識した。
ゆとりを持つことを、自分の手の届く範囲で周りに伝染させていければと思える内容だったので書評を書いたとともに実践していく。

HARD THINGS読んだ

働くことについて別の視点をいれてみたいと思って読んだ。

HARD THINGS

HARD THINGS

この本は筆者が体験したことを元に、倒産する時が見えているときに何をしないといけなかったを解説してくれてる本で、
最初の3章で会社が倒産するところから売却するところまで実際に何があったか書いてある部分で、それ以降の章は会社で起きたことをよかったこと悪かったことを合わせて書かれているのが読めてよかったと思える部分だった。

必ず起きてしまうネガティブな事象に上手に取り組むための本

良い製品マネージャ、悪い製品マネージャ

この章で良いマネージャとは、悪いマネージャとはが多く書かれている。

良いマネージャは素晴らしい製品を最適な時期に出すために必要なこと全てに責任を持つ。
悪いマネージャは山ほど言い訳をする。

良いマネージャは「WHAT」を明確にし、「HOW」ではなく「WHAT」が実現するまでを管理する。
悪いマネージャは「HOW」を思いついたときに最高の気分に浸る。  

ここにあげた内容は一部だが、この章だけでも読む価値はあると思った。マネージャの良い悪いはわかりづらいと思っていたが、ここに書かれている内容だけでおおよそ見分けはつくのではないかと思う。

大企業の幹部が小さな会社で活躍できない理由

一例では、大企業の幹部は、メール・電話・ミーティングと基本的に待つ体になっている。部下からの報告を待つのである。ベンチャー企業で働くにはミスマッチが起きるからである。
この章で、どの企業でも合う合わないはあるのだと思った。ミスマッチの検出という章で「仕事に就いて最初の一ヶ月に何をしますか?」という質問で自分がどう回答するかはどこで働く場合でも考えるようにしたい。ここでは「勉強」を強調しすぎる人は要注意とある。おそらく何があるかわからないが前提にきているのかもしれないが、わからなくても動いて解決していけるタイプを目指したい。

正しい野心

幹部を採用するときは「正しい野心」を持つ人を採用する。人は世界を見るときに何らかのメガネで見ている。そのメガネが「自分メガネ」なのか「チームメガネ」なのかで、「正しい野心」を持つ人とは「チームメガネ」で見ている人のことである。
過去の経験を話すとき、「自分の職務経歴にプラスになった」というような話をしたとして、状況を自分の経験に結びつけてしか考えられない人は全ての事象を自分本位でしか考えていないことが垣間見える。過去の経験で「自分」を主張しない人はチームを第一に考えていることがわかる。
一般社員の場合は自分のキャリアパスの充実を考えても良いが、経営に携わる幹部の場合は動機が重要である。

最近は実績を積んで自分の話を増やしたいと考えていることが多かったが、そのときに自分がどう成長したかを今までなら話していたと思う。
確かに個人で何をやったかは今でも話すことはあるが、チームにどういう実績を残したかを話せる人は少ないと思うのでそういった話をできるような実績を残すことを意識したい。

まとめ

目標設定の章で「チームに実現不可能な目標を与えれば士気は下がる」とあったが、ここでも孫子が引用されていたことには驚いた。孫子を読んだから気づくことかもしれないが、多くの人が参考にしているのだと思えた。
最後にあった「苦闘を愛せ」という言葉がもっとも印象に残った。世界中の助言と知恵を集めても、困難は困難である。その困難に立ち向かうことこそが困難を解決する唯一の方法なのだと考えた。
辛いと思うことは多くあるが、その辛さを解決するのも自分だけなので、嘆くより動くことをやっていきたい。

「サボタージュ・マニュアル」1時間で読んだ

サボタージュ・マニュアル:諜報活動が照らす組織経営の本質

サボタージュ・マニュアル:諜報活動が照らす組織経営の本質

東京出張の新幹線の中で読んだ。タイトル通り1時間程度でサクッと読めたので気になった人はぜひ読んでみてほしい。

この本を読んだきっかけ

サボタージュ・マニュアル自体は下記のブログで読んだことがあって知っていた。

chikawatanabe.com

会社の人がこの本を買っていて、軽く読めそうだなということで読んでみることにした。

どういう本か

CIAの前身であるOSS(米国戦略諜報局: Office of Strategic Services)が、敵国に対してスパイ活動を行うために作られたマニュアルがサボタージュ・マニュアルであり、それが公開されていて解説されている本である。
物理的な破壊工作の方法から、組織のコミュニケーションの際に行うことで混乱を引き起こす方法まであり、その中でも組織のコミュニケーションを焦点に、何をすることで組織は停滞するのか具体的な事例と合わせて説明されている。

読んでみて

「会議に必ず5人以上出席させよ」や「チーム内で衝突させろ」など、実践することで組織が悪くなる内容が書かれているので、アンチパターンとして参考にするべき本だった。

この本は組織を停滞させる手段が書かれていることから組織運営の本のように見えるが、実際には組織を作る人ではなく組織に所属する人にできるだけ読んでもらいたいと思った。
その理由は

  • サボタージュ・マニュアルはスパイ活動のためなので、組織の中にいる人がやることである
  • なので、自分一人が意識しても限界があり、各個人が意識してやらないようにしないといけない
  • チーム内に一人でもこのマニュアルの内容をやってしまうとそれだけで影響が出る

ためである。

以下の二つは、わかっていても特にやってしまいそうなことをまとめた。

集団は個人の活動を封じ込める

「三人寄れば文殊の知恵」というが、「三人集まってから課題を解決する」よりも「それぞれが解決策を考えてきてから集まる」方がより的確に課題を解決できたという研究結果が出ている。
また、集団になることで以下のマイナスのメカニズムが発生する。

  • 社会的手抜きの法則
    • 自分一人で仕事をするときはその評価が自分で確認できるが、集団で仕事をするときは個人の成果が見えにくいので人は手を抜きがちになる
  • 評価懸念による発言の抑制
    • 会議の場面では、人は課題解決よりも自身の評価を気にする。そのため、ベストな解決方法を知っていても、自分の意見が間違っていたら、間違っていることで上司から悪い評価をつけられたらと考えてしまい、自由な発言ができなくなる。
  • 沈黙の螺旋
    • A案とB案があった時に、自分はB案が良いと思ったがA案が多数を占めている場合、多くの人はB案の素晴らしさを主張するよりも黙る傾向にある。そして、A案の素晴らしさの主張はハードルが下がる。
  • 同調
    • そうして会議では多数派の意見しか発言が出なくなり、腹の探り合いが発生してしまう。
  • 調整損失
    • 会議で一番時間を使うのは、発言のタイミングを伺うことになっていないか、これは会議の人数が多くなるほど発生し、個人の時間を奪ってしまう。

そうして集団は個人の能力を封じ込める。
みんなで決めるという民主主義が、チームのスピードを遅くする。

「黒い羊」効果を生じさせよ

黒い羊効果とは、自分たちの所属する集団にとって都合の悪いものを阻害して排斥するような現象をさす。これによって組織内のいじめなどが発生しやすくなる。黒い羊を意図的に作り出すことで、集団内に問題を発生させることができる。
また、排斥されたメンバーが集団の活動を阻害するための攻撃を自発的に仕掛ける場合がある。これも組織内で大きなリスクになりうる。
組織のパフォーマンスが低下、場合によっては崩壊する可能性もある。

まとめ

本を読んで、こうやって書評を書いたことで特に意識してアンチパターンとして扱わなければならないと思った。
この内容を知らず、やってしまっている人はスパイになってしまっていることになるので、やっている場合は止めないといけない。
組織に所属する人は、一度手にとって読んでもらえるとチームが阻害される可能性が少なくなるので、
すぐ読めるものでもあるのでぜひ読んでみてほしい。

起業のファイナンスを読んだ

たまたま同じ日に読んだ記事の中で同じ本が紹介されていて、興味を持ったので読んだ。 まだ私の知識レベルでは全部を理解することはできなかったけど、とっつきやすくて面白かった。

最も印象に残った「計画する」ということ

第3章「事業計画の作り方」にあった、必ず計画を立てる話について書き残しておきたい。

未来を予測することは不可能

事業計画は事業がうまくいくように計画を立てることである。どれだけ計画を立てようが未来を予測することは不可能だが、それでも計画を立てる必要がある。
それはなぜか、計画を作ることができるということは計画を作れるレベルまで考えがまとまっているということであり、その事業を説明することができるためである。
エレベータ・ピッチと呼ばれる、エレベータの15秒で事業の魅力が語れるようにしておいて、常にチャンスを逃さないようにしておくことが大事である。

事業計画書はパワーとなる

  • 事業計画に要点がきちんと考えられていれば、それを読んで興味を持ってくれる人が出てくる。
  • 事業計画は事業に関係する人たちをやる気にさせられる「パワーの源」になる。
  • 根性や情熱で事業を始めることはできるが、継続させられる保証はない。

計画を作ることでリスクに立ち向かえる

計画が「いける!」というものになっていれば、それが「勢い」になる。「勢」というのは、すなわち、状況に応じて臨機応変な対応が行えるということ
孫子「計篇」参照

孫子では、戦を行うときに相手と自分を見てどちらが各方面において準備ができているか、戦力差を理解できているか、勝つ見込みがあるかを判断する。
勝ち目があると正しく判断できているのであれば、不思議と勝てるものである。
二ヶ月くらい前にたまたま孫子を読んでいたこともあってこの章はよく理解することができた。

事業計画は投資家へのコミットメント(約束)の一部を形成することにもなりえる

  • 「こうやれば100%成功する」なんて道筋はないから、状況に応じて変化することは必須で、事業計画が進捗を縛るものであってはならない。
  • 「絶対成功する」事業計画が立てられる訳ではないけど「明らかにダメ」な計画はわかる。
  • 計画が間違っていたり成功する可能性が低いことが見えているなら、その計画は成功する可能性は低いのでやらない方が良い。

まとめ

近いうちに一度事業計画を書いてみたいと考えていたこともあって、この章だけでも読む価値はあった。
今まで会社のことを勉強したことはなかったので、会社員でいる間でもなぜそうするのかを理解するためにも勉強してよかったと思う。
理解できていないことも多いので、他の事業計画を読んでみて事例を元に勉強したい。

ピープルウエアを読んだ感想と書評を書くことについて

トム・デマルコの「ピープルウエア」を読んだので、書評を書いて残しておくことと
今までは読んだ本全部で書評を書いてなくて、今回書くかどうか迷った時に考えたことを残す。

ピープルウエア 第3版

ピープルウエア 第3版

読んだ感想

組織の問題の解説とどうすれば良いかについての本で、以前からお勧めされていたのをようやく読んだ。
結論としては読んでよかった。エンジニアが働きやすい組織は昔から変わってないんだなと思った。
特によかった点を詳しく書く。

生産性の高いチームを育てる話

チームを殺す方法

チームを結束させる方法をあげることができないから、逆にアンチパターンをあげて
それだけはやらないようにすることが書かれている。
具体的にはメンバーに対してマイクロマネジメントをすることや、マニュアル通りに動かすこと、チーム内で競争させること、複数のチームに所属させることで、この中では競争させることがアンチパターンというところは驚いた。

共同作業でチームを結束させる

本の中ではチームメンバーでスパゲティディナーを行い、その中でマネージャーは何も手伝わないという例で書かれていた。
マネージャーが指示しなくても、メンバー同士で考えて動くことでチームワークは出来上がるという話で、
チームでやることは別に開発に限ったことでなくても、一緒にやることでチームを良くすることができるので、
一度こういうこともやってみたいと思った。

目標を提示してメンバーに任せる

マネージャーはメンバーを画一的にするのではなく、メンバーの個性に寛容になりながら
目標意識を植えつけて、任せてやることで特別意識を持たせて活動的にさせるものということが書かれていたが
特に印象に残ったのは、「いずれにしても部下はコントロールできるものではない」というところで、これは強く認識していきたい。

文化を醸成する話

メソドロジー(方法論)は悪

メンバーのやり方を決めて動かすことは、メンバーに責任を持たせないこととなり
責任を持たないメンバーは自分の意識で動かなくなる。
これはマネージャーが崩壊する未来しかないので絶対にやってはいけないと思った。

変化を嫌う人は成長できない

変われない人は進歩できないと書かれていて、自分も他人から与えられる変化には敏感になることがあったと思って
自分の進歩を止めるような行動ややらないようにしたい。

仕事を楽しくする

コミュニティ

自分の場所を楽しい場所にするためには居心地の良いコミュニティが必要で、コミュニティは仕事だけで生まれないので、自分で作り上げなければならない。
今まで意識して作っていたことはなかったけど、確かに自分から動いて出来たコミュニティは楽しいと感じることが多いので、仕事をする中でコミュニティについても意識するのは良いのかもと思った。

問題はみんなで共有すればみんなの問題

一人で行動しても変化はほとんど起こらない。でも問題をみんなに共有して共感してもらえばそれはみんなの問題になるということは、チームで働く上で本質だなと思った。
問題と感じているところはオープンに共有して、一人で解決するのではなくチームで解決していきたい。

書評を書くことについて

今回も書評を書こうかどうか迷ったときに、「明日の自分に書く」ということを考えた。
コードを書くときは必ず「明日の自分は他人で、他人はそのコードの意図がわからないかもしれないから明日の自分のためにコード(コミットコメント)を書く」と言っているのに、書評は書かないは矛盾しているんじゃないかと思った。これは未来の自分が読んだことを忘れた時のための書評だ。
なので今後も読んだ本で覚えておきたいものは書評を書くようにしたい。

まとめ

いきなり全部やることはできないしこの本にもおそらく一つだけしかできないだろうと書かれていたので、まずは一つやっていくことから意識していきたい。

WordPressの管理画面にログインできない問題の原因がDBだった

WordPressの管理画面にログインできない問題が発生し、解決まで完了したのでブログに書く。正確に事象を説明するとログイン画面は表示されて、正しいログイン情報を入力してログインボタンを押した場合にリダイレクトが発生しログイン画面が表示されるという無限ループが起きた。
調べても出てこないケースの問題だったのと、なかなかに怒りが発生したのでそれをモチベーションに今書いている。

動作環境

WordPress4.7(バージョン関係なし)
AWS EC2
MariaDB

TL;DR

ディスク使用量が100%になるとDBに書き込みできないので、ディスクに空きを作る。

どう調査したか

まずは画面で調査を行い、何が起きているかを確認したところ、ログインボタンを押した時に
POST wp-login.php 302->GET wp-admin/admin.php 302->GET wp-login.php 200
とリダイレクトしていることを確認した。

wp-admin/admin.phpのどこでリダイレクトしているか調査したところ、auth_redirect()wp_validate_auth_cookie()でfalse判定になっていることでログイン状態の判定がされないことがわかったので、なぜfalse判定となるのかを調査。

https://github.com/WordPress/WordPress/blob/master/wp-includes/pluggable.php#L1044

ここからが長かった。
$manager->verify( $token )がfalseになっていることはわかったが、これがなぜfalseになるのかがわからない。

https://github.com/WordPress/WordPress/blob/master/wp-includes/pluggable.php#L675

このセッションがどこに保存されているか、このセッションがどういう情報が入っているのかも知らない状態から調べ始めたのでこれが何もわからない。
ようやくwp_usermetaテーブルにセッション情報が入っていることまで確認したが、もともと入っているデータがどうなっているのかもわからない。
そもそもいつ更新されるかもわからなかった。
これを一つずつ調べるのにすごい時間がかかった。

wp_usermetaテーブルが更新されない

$manager->verify( $token )はwp_usermetaに入っているsession_tokenから、Cookieに格納されているトークンを使って一致するキーから情報を取得するのだが、ここにトークンと一致する情報が存在しないからログイン判定がなされない。 ここに一致する情報がないと絶対に解決しないことがわかったので、どうやって格納しているかを調査する方向に転換した。

調査をしたところ、ログイン成功時にトークンを発行し、それをセッション(DB)とCookieに格納していた。

https://github.com/WordPress/WordPress/blob/master/wp-includes/pluggable.php#L877

Cookieが格納されていることは開発者ツールで確認している。なのでセッションに格納されないことが原因だと判明。

https://github.com/WordPress/WordPress/blob/master/wp-includes/class-wp-session-tokens.php#L151

トークンは生成時にセッションに格納している。

https://github.com/WordPress/WordPress/blob/master/wp-includes/class-wp-user-meta-session-tokens.php#L98

この処理でセッション(DB)に格納している。
update_user_metaを調査。

https://github.com/WordPress/WordPress/blob/8f5d82df7b0b5b2fbaed8ca4c2ad49876f8175df/wp-includes/meta.php#L268

DBにQueryを実行し結果を返している。まさか。
update_user_metaの実行結果を出力してみる。
falseが返ってきた。

DBの更新処理が失敗している!!!

原因が判明。あとはなぜDBの更新が失敗しているかを調査し、実際にDBに入って更新処理を実行してみたところ同じように失敗 Disk Full 〜と出力されたので、DBを抜けてdf -hを実行、100%となっていることを確認。。。

解決方法

容量を圧迫しているファイルを探し、今回はログファイルを圧縮することでログインできるようになった。

怒りポイント

ソースコードを読むのが辛い

とにかくソースコードを読むのが辛い。ログイン処理とかどこで書き込みしているのかわからない。

https://github.com/WordPress/WordPress/blob/master/wp-login.php

そして、一つの関数の内容が多すぎる。どうみても一つの責務だけを担当していない。
関数のコードが大きいということは、関数内の何で問題になっているかから調査しないといけないので、その労力がすごく大きい。

DB処理失敗時に何もしない

今回の原因となったDBの更新処理について、失敗した場合にfalseを返すだけなので、ログも残らないし処理も終了しない。
DBの更新に失敗ってWordPressだと致命的だと思うので、せめて例外を投げて処理を終了してほしい。
解決したあと、そりゃわからないわと思ってしまった。

まとめ

多分ここで愚痴るよりPR投げた方が早いが、多分WordPressは大きくなりすぎてしまったんだと思う。
自分もこのブログにWordPressの記事を書くことになるとは思わなかった。
もう少し平和に過ごしたい。