UXエンジニアになりたい人のブログ

転職活動はじめてすぐやめた

オンラインホワイトボードコーディングテストの心得

転職活動でオンラインホワイトボードコーディングテスト(zoomでつなぎながらテキストエディタ共有サイトでコードを共有するパターン)をやったので、その心得を書いていきます。

ちなみに結果は、超簡単な問題だったにもかかわらず、テンパってしまい面接官の言われるがままコードを書いてなんとか完成させるもののもちろん落選というもので。

結構行きたかった企業の1次面接だったので、だいぶ落ち込みました。ということなので、心得というか、失敗談ですね。

 

いきなりコードを書き始めない

あとになって思い返すと、これが全てだったかな。お題が与えられたときに、どういう雰囲気で解こうとしているか、どういう処理をして、結果がどう変化していくと想定しているのか、説明すべきだったと思う。

多分ホワイトボードがあれば、配列とか集合とかの絵を描いて雰囲気説明するんだろうけど。

 

これをしないと面接官となにをどうやろうとしてるかの意思共有ができなくて、(自分からすると)的外れなツッコミを受けて混乱することになります。

あと、多分「物事を論理的にとらえてるか」とか、「人にわかりやすく説明できてるか」とかの採点指標になってる気がします。知らんけど。

最悪、説明がうまくできてれば多少コードがあれでも通るのではないかとかも思ったり。ま、面接官じゃないんで知らないですけど。

 

面接官のプレッシャーに慣れておく

コーディング中は、面接官がかなりサポートしてくれます。あれ?そこ〇〇が抜けてない?とかそういうことを言ってくれる。すごく親切。

 

親切…なんですが、これはめちゃくちゃプレッシャーになります。特にどうコーディングするかをうまく共有できてない状況だと、「あれ?なんか言われてるけどなんのこと?どこのこと?よくわからない。スルーするのもおかしいし。とりあえず直すけど、あれ?ここをこうすると全体はどうなるわけ?なんだ?なんだ?」となります。

 

そもそも、相手方だけが一方的に「答え」を知っていて、即座に口出しはしてくるけれども正解を教えるわけでもない、という状況はわりと特殊です。実務上、経験したことがない人もおおいとおもいます。

ペアプロだったら「一緒に考える」が出発点だし、わかんなかったらわかる方が書いてから解説しますからね。そもそも、コーディング複数人でやったことある人自体も少ないですよね。

 

このシチュエーション、練習しようがないのが特にアレなんですが、ともかくそういうことが起こるという心構えは必要でしょう。これ、面接官本人が親切のつもりでやってるのがさらにたちが悪い。正直、だまっててほしかったです。

 

競技プログラミングサイトで練習すべきかどうかは微妙

就職転職の面接だと、AtCoderやLeetCodeみたいな競技プログラミングサイト(以下競プロ)チックな実技試験もあります。この手のサイトで練習しといた方がいいという意見もよくみますが、ちょっと微妙です。

 

理由の1つ目は、ホワイトボードテストの問題は競プロの問題と比べて多分かなり簡単であろうということ*1

その場でロジック考えて説明して、話しながら改良して、という性質から考えると、広がりはあるものの書ききること自体は簡単な問題が出ると考えるのが妥当でしょう。

なので、競プロで練習しまくっても本番が簡単すぎて練習の意味がなくなる可能性があります。

 

2つ目は、競プロとホワイトボードテストは作業手順が異なること。競プロは、コンパイルもテストも通す必要があるけども、1人で黙々進めることができます。ググることもできるし、とりあえず書いてみてからテスト通すことを目的にバグつぶししていくこともできます。

わたしも今回初めて気付いたのですがこのタイプのコーディングをしてます。ザクっと雰囲気で書いてからリファクタしていく、という。

 

対して、ホワイトボードでは、まず概要を説明してからツッコミに耐えながら描き続けなければなりません。コンパイルが通る必要は全くないですが、コードで正しく意図を表現できる必要がありますし、要点だけをコード化しなければなりません。

AtCoderで難しい問題が解けるようになっても、それより遥かに簡単な問題の、要点部分だけを書いて、それをわかりやすく説明しなければならないですし、そもそも書き始める前に概要を言わなければなりません。

その辺意識して競プロで(たとえばコード書く前に口で説明してみるとかそういう手順を入れて)練習するなら良いのですが、ただ単にドリル的にサイトの問題を解きまくると本番で思わぬ落とし穴が来るかもしれません。

 

結局どうすればよいか

あまり答えは出てないですが、面接時の状況としてはペアプロがいちばん近いのかなあと。スーパープログラマーに簡単な問題出してもらって、横でつっこまれながら書いていって慣れる、とか?

まあ、あとはホワイトボードテストを依頼された時点でその会社はご縁がなかったとして諦めるとか。自分はいまはこの気持ちですね。あまりに出来が酷かったので、面接直後に落ち着いて書き直したら5分で完成できましたし。いまだになぜできなかったのかよくわかっていない。ただただ苦手意識だけが植え付けられてトラウマです。

参考になれば。

 

 

*1:n数1であれですが

スクラム開発批評

最近スクラム開発をやってみてるのでその感想を。スクラム開発って何?って方は以下の図をごらんください。

 

f:id:uxlayman:20200916190500p:plain

via スクラムの概要を1分で理解できるイラスト【2018版】 | Ryuzee.com

 

…すこし本題とは逸れるのですが、この絵は実際に社内のスクラム推進派の人に見せられた絵です。なんですが、、、あのさ、、、これでなんなのかわかんなくね?

この絵に限らず、スクラム開発 - Google画像検索で出てくる画像はほとんど、スクラムの構成要素をただ書いていて、結局何が良くなるのか、つまり効果がわからないのです。この時点ですでに割と不信感ありますよね。良さをわかってもらおうという気があんまりみえない。わかってる人がわかってる人のために書く図。

閑話休題。

ま、単純に言ってしまうと、スクラムはバックログという要望集を、スプリントと呼ばれる固定時間(1〜4週間程度で選択)内で、リリース可能なレベルの成果物として実現することで、素早い価値提供を可能にするための方法論です。

続きを読む

AWSはOracleみたいだから嫌い

そもそもAWSがOracleみたい、って感覚伝わるのかな。

 

どんどん新しいサービスがでてきてよくわからないとか

ベストプラクティスが日進月歩で新しくなるとか

なのに古いベストプラクティスに囚われてるマンがいたりとか

古いプラクティスを経緯や根拠を取っ払って〇〇は使うなっていうルールにして形骸化させちゃったりとか

資格がパスポートのような役割を果たしてるとことか

そのくせ資格ホルダーが使えなかったりとか

使いこなすこと(手段)と目的を混同してるマンが大量発生するとか

一般概念とベンダー固有概念の区別がつかないマンが大量発生するとか

サービスについて公式文書を見るとすごくフレンドリーそうな文面なのに結局なんだかわかんないとことか

すっごい簡単です、とか今すぐ始められますとかいう話がちゃんとできた試しがないとか

なんだかんだエバンジェリストのブログとか講演とかで超重要情報が明かされたりとか

特に性能面とか肝心なとこがブラックボックスなとことか

サポートに問い合わせると、原理上は正しく動作するはずですがあなた方で十分にテストしてください、とか平気で言われることとか

おま国とか

GUIがあるのに結局最後はCUIになったり、GUIとCUIのできることの差が激しかったりとか

胡散臭いパートナーが多いとことか

 

伝わります?まあ伝わらなくてもいいですけど。

続きを読む

「みずほ銀行システム統合、苦闘の19年史」が普通に称賛案件だった件について

各所で話題になってたみずほの本の話。

 

現システムは「大成功」

この本は3部構成になっていて、1部は稼働中の新勘定系システムMINORIの説明です。

 

本件、直接は知りませんでしたがネット上では「関わったら負け」と言われるほど悪評高く、また延期も2度行っていたので、勝手に「既存システムに〇〇を追加せよ、的な"阿吽の呼吸"の要求を元に開発して、レビューの名の下にしょっちゅう要件が追加されて、テストに入っても『運用が回らないから』とか言って要件が追加されて、出来上がったものはなんとか動いてはいるものの柔軟性のないそびえたつクソ」っていうよくあるパターン、銀行っぽいパターンなんだろうなと思ってました。

この本にもきっと「動き出しはしたものの3回目の大規模障害は時間の問題」的な裏事情が書かれているのだと思っていました。

 

しかし、第1部は予想に反してMINORIは「大成功」という体で話が進みます。

ハハッわろすと読み進めていたのですが、どうやらSOAの思想で構築された疎結合のシステムで、それゆえ機能追加時のテスト工数が減少でき、従来システムに比べて(そして競合他社に比べても)圧倒的に柔軟であるとのこと。実際たしかに本の記載を見るととても"良さそうなもの"が出来上がった感じがします*1

 

そして、読むにつれてプロジェクトの様々なことが「正しく」行われてるのがひしひしと感じられてくるのです。

驚きだったのは、要件定義にあたってasis(従来どおり・従来システムを踏襲)を全面禁止して、ユーザー部門に本来あるべき本質的な業務フローを1から考えさせてツールで表現させたというところ。

SOAはサービスやコンポーネントをいかに独立性/再利用性高く切り出せるかが鍵なので、正攻法ではあるのですが、本当に驚きでした。だってそんなことできた試しがないですから。

受託システム開発は「自分の業務すら正しく把握できない要求元が、システムを通じて浮かび上がってきた業務上の不整合を誰のせいだと揉める時間が大半を占める」というお約束で進むものであって、要求元の責務を果たそうとすること自体が珍しいのです。そして、よしんば本腰をいれてやる気があったとしても、そもそも現状と切り離して本来論を検討するというのはなかなかスキルが必要で、底力がないとできないことなのです。

しかもこれ、ちゃんと粒度や記載にばらつきがないようにみずほ側がガバナンスとってやってたらしいです。マジか。

考えてもみてください。「今の業務とはべつに自業務のあるべき姿を考えて謎のツールで表現してください。監査役からもろもろコメント入るかも知れないので対応してください。現行の業務システムから処理を書き起こすのは禁止です。」などというめんどくさい依頼を飲ませるだけでも相当大変ですよ?どれほどの苦労があったことか…

そしてSOAのサービス粒度はこの「あるべき業務」によって適切に決められたはずで、その事実だけでかなり"強い"システムが構築されたことがうかがい知れます。

 

その他プロジェクト運営に際しても痒いところに手が届くような施策をことごとくやっていて、圧倒的に「正しいこと」を頑張ってやったのが伝わってきます。またもや称賛。

例をあげるなら「最初に用語を統一する」話。さらっと書いてありますが、大企業で様々な部署がひしめく中、統一した辞書を作るだけでも超大仕事です。でもそれをしないとそのあとあらゆるところで困るので「正しい」です。そういう細かいことの積み重ね、間違った方向に行かないようにする施策がすごくたくさん出てきてだいぶスタンディングオベーションしたい気持ちになってきてました。

 

2回の延期も場当たり的に延期したのではなくて適切な時期に適切に見積もりを再評価した結果の延期で、うまくガバナンスが効かせられてたことが伺えます。

 

ひとつだけ、大丈夫か?と思ったのは「コードはすべてツールから自動作成」という記述。バグ修正などで正しい挙動を実現するコードはわかってるのに、それを自動生成させる手段がわからない、なんてことにならないかなあと。でもまあきっとそれを上回るメリットがあったのでしょう*2

 

ともかく、第1部を読み終わる頃にはなんか想像と違ったけどすごく良い本だな、という気持ちでした。

 

余談ですけど、第1部には新システムの操作教官として一般職から有志を募って教育にあたらせた話が出てきます(ちなみにこの人達が困らないようにバッチリフォロー体制もあった旨も記載あり)。その人達の現在の肩書がなんかすごいんです。出世した感が肩書きからもわかって、サクセスストーリー感がわくわくします。

みずほ経営陣は「人が育った」ことを大きな成果として認識してるとの記載がありましたが、さもありなんといったところ。

 

圧倒的クソな過去事案のせいで今がより輝く

第2部と3部は2011年の東日本大震災直後に起きた2回目の大規模障害と、2002年の合併直後に発生した1回目の大規模障害に至る軌跡の解説。

これはね、まごうことなきクソです。

 

2011年は(合併後のごたごたがあったにせよ)ずっとなあなあで動かしてきて、異常発生時のリハーサルしてないどころか異常発生時の例外フローすらない、なんならデータフロー図さえないシステムで障害起きて、非常時にもかかわらず全くリーダーシップを発揮できなくて解決まで10日もかかったという、想定以上のクソ事案。

 

2002年は、IT投資増加のために合併するというふれこみだったのに、CIOも配置せず担当レベルに検討を丸投げして、ベンダーと組みながら新銀行の主導権争いに奔走し、システム統合方針さえ二転三転した挙げ句、システム開発会社のできますやれますを鵜呑みにして見切り発車で大障害を起こすという、半沢直樹みたいな話ってほんとにあるんだな、と謎の感動すら覚えるほどの救いようのないクソ事案。

 

でもこれ、最終的に成功に終わることがわかってるので、これらの事案がマイナスに働くより、こんな文化の会社でようやったよな、という気持ちが止まらなくなるんですよ。

ほんの一年前までデータフロー図すらなくて平気だったような文化背景で、ゼロベースで本質フローを書き起こさせるだなんて、ようやったよなと。

合併先の片方にシステムを寄せる「片寄せ」すらまともにできず右往左往する文化背景だったのに、SOAで疎結合なシステムをスクラッチ開発とか、ほんとにようやったよなと。

よくこんなマイナスからのスタートでやりきったなと。

 

やっぱり合併前後くらいで入社して10年間くらいずっと「みずぽ(笑)」とか言われてた人たちが心を一つにしたのだろうか。

ぐうたらな社員でも「3度目やらかしたらマジでやばい」という危機感が共有できて一体感が醸成されたのだろうか。

いろんな想像をかきたてつつ、クソな過去が今をより輝かせるという胸熱な展開です。

 

でもホントのところも知りたい

まあでもちょっと出来すぎてるとも思うわけですよ。ホントのところはどうなんだと。実はみずほ主体じゃなくて裏でコンサルが暗躍してたんじゃないかとかさ。SOAなんて掛け声だけで実は従来通りのスパゲティ・モノリシックなんだとかさ。ただSOAは話半分だとしてもレガシーシステムと比べれば雲泥の進化だからなあ。

そもそもネット上の超悪評はいったいなんだったのかと。すくなくとも2011年以降は「正しい」ことを根気よくやってるようにみえて、ではなにをもってどんな視点でそこまでdisられてたのかと。

まああと最近できてるネット専業銀行とかに比べてアドバンテージはどうなんだろうな、とかは気になる。

 

なにはともあれ、とても良い本でしたし、無事やり遂げられたこと、心の底から称賛いたします。こういう話は元気が出るし、たしかに2025年の崖を乗り越えるヒントになるね。

ブラボー!

*1:というか旧来システムレガシーすぎるだろとビビる

*2:生コードは様々なスタイルで記載できるので、データとその扱い、異常時のポリシーのようなコーディングルールで縛れないような設計上の制約を均質化できるのはメリットかなと。

手段の目的化がなぜ起こるのかいまだに理解できない

 

はてぶにコメントした。 

提案が通らない人が抑えるべきビジネスパーソンの思考パターン3つ | BtoCマーケティング支援の株式会社ホジョセン

普通これ全部考えるもんじゃないの??例えば承認者にあわせてWHYを最重視しました、なんて提案が通るわけがない

2019/08/09 06:16

 

こんなツイートもした。

 

コメントやツイートはしたものの、しかしよくわからない。

そもそも元記事がよくわからない。どうして3つ全部必要なものを「〇〇の人」などとセグメンテーションしたのか。WHY&WHAT→HOWのことをなぜ書かないのか。

 

ツイートで書いた「手段の目的化」はもっとよくわからない。事例は多い。とても多い。ものすごく多い。たとえば、ちょっと前なら「クラウド化」とか。いまなら「IoT対応」とか「機械学習活用」とか。手段(HOW)にのみ着目する事例はとても多い。「いや、それでなにを解決するための機械学習がなんで必要なんですか?」と毎回突っ込む。

 

事例は多いが、でも全然わからない。どういう思考ロジックだといきなりHOWを考えるようになるのだろうか。

そして「いや、それでなにを解決するための機械学習がなんで必要なんですか?」て聞くと答えられないひともかなり多い。意味がわからない。なぜ答えられないのか。目的もなくいきなり手段を考えるなんてことあるのだろうか。

世の中の流れをみて、まず手段を抽出して、そこから目的を逆算することはあるだろう。しかし「ご提案」してる段階なのに目的を言えないなんてことがどうして起こるのだろうか。

客にこんな提案しても話伝わらないな、とか思わないのだろうか??

 

社会人なりたてのときは、なにかのギャグなのかなと思うようにしていたが、そこそこ社会人生活が長くなってもいまだにわからない。そして見聞きする事例だけには事欠かない。

どういうことなんでしょうか。だれか教えてください。 

3D Touchを採用すべきだったたった1つの領域

 

概ね同意だけれども、3D Touchにはもっとふさわしい使いどころがあったと今でも思っている。

3D Touchが導入されたのはiPhone 6s/6s Plusからで、その前機種である6/6 plusの世代から画面が大型化された。

6/6 plus時点ですでに画面の左上に配置されたiOS伝統の「戻る」ボタンに手が届かないという操作不整合が発生しており、さらに「ホーム」と「戻る」を別々に備えるAndroid陣営に対して操作感で遅れを取っていた(そして今でもそれは解消されていない)

 

この時点で、3D Touchをシステム操作として導入すべきだったのではなかろうか。例えば、画面の左下を強く押し込むと「戻る」になる、画面の下1/3を強く押し込むとホームに戻る、とかそういうやつ。「強く押し込む」機能はアプリでコントロールできず、全アプリ共通のシステム操作としてだけ利用できると制約すべきだったのではないだろうか。

 

ますます複雑化するシステム操作

3D Touchの導入から時は流れ、iPhoneXs系列でディスプレイは全面表示が主流となった。その結果、ますます「戻る」に手が届かなくなり、上端から下に下ろす通知センターやコントロールセンターにももちろん届かず、ホームボタンはなくなって画面下端での不安定な操作を強いられている。少なくとも片手操作は破綻していると言ってよい。

Android陣営が指紋センサーへのジェスチャーという新発明で通知アクセスなどのシステム操作を改善しているのに対し、iPhoneはシステム操作に関しては使いにくくなる一方である。

 

もし、システムとして3D Touchを管理していれば、これらの状況にもかなり対応できたのではないか。機能が増えてもプレス感知領域を増やせば良いだけなのだから。もちろん、ユーザーはそんなプレス領域に気付くべくもないが、そこはお得意の広告戦略で「iOSの革新的操作」とか吹聴すればそれで良い。

しかし、実際にAppleが行ったのは、この知覚性が無に等しい機能をアプリに自由に開放するという愚策だった*1。結局ほとんどのユーザーはアプリ毎に「どこで3D Touchが有効なのか」を発見できなかった。それに加え、3D Touchで実現できる機能はほとんどがどうでもいい機能で苦労して発見する価値もないようなものばかりだった*2。廃れるのも当然だ。

 

3D Touchはハードウェア機能なので、それを使ってシステムを制御できれば、ソフト部分のみを提供するAndroid陣営が一律的に模倣するのは難しい。

そのような可能性があって、実際にハードウェア開発して量産にまでこぎつけたのに、愚策によってすべて台無しにしてしまったという印象が強い。

なにはともあれ、RIP,3D Touch*3

 

関連エントリー


 

*1:iOS初期のころに「直感的操作」として導入したフリック操作が非常に知覚性が低く、気の利いた誰かがフリックインジケータを発明するまで「どこでつかえるかわからない」機能だったことを忘れたのだろうか

*2:唯一に近い例外は、キーボードをプレスすると文字カーソルを自由に移動できる機能。あれ、超便利。ただしあの機能があることをよく忘れてしまう。それほどまでに3D Touchは知覚性が低い機能である

*3:実際はiPhoneXRにないだけで、その他現行ラインナップにはすべて実装されているので全然廃止ではないけれど、縮小傾向にあることは間違いないだろう。。。

サマータイムを導入しないにしても日時をすぐ文字列にする悪習をやめるべきではないか

「サマータイム導入はコンピュータシステム的に難あり」は本当か (1/2)

サマータイムは簡単、という記事があまりにあれな件 - novtanの日常

タイムゾーンを考慮した日時の扱いのベストプラクティス - エムスリーテックブログ

サマータイムの話。

結局のところ「データ」としてローカル日時を持ってしまっているシステムが多数あり、それらがどれくらい影響するかわからない、ということが皆が反対する理由。

対策としては結局3つ目のブログに書いてあることがすべてで、システムの内部では一貫してオフセット付きの日時またはUTCでデータを持つべきで、システム境界を超える場合も可能な限り(ユーザーに不要な手間が増えるといった例外を除き)オフセット付きで時刻を扱いましょう、というだけの話。

 

それで、「ローカル日時を持っているデータ」って十中八九文字列ですよね?2018/08/19 23:00とか、201808192300みたいな文字列ですよね。それをDBに入れたりファイルに書き出したりしてるってことですよね?そういうの、もうやめませんか?そもそもなんのためにそんな事するの?っていうお話です。

 

なぜわざわざローカル日時でデータをもつのか 

java:OffsetDateTime (Java Platform SE 8)

.NET:DateTimeOffset 構造体 (System)

db:timestamp with timezone

文字列書式:ISO 8601 - Wikipedia

 

上記あげた*1ように、各プログラム言語でも絶対日時を持って便利に使える型が用意されているし、文字列書式も国際規格があります(もちろん文字列⇔オブジェクトの変換も一意的に行える)。にもかかわらずどうしてオレオレ文字列書式を考案してシステムに組み込んでしまうのでしょうか。

 

違いまーす。コンピューターが用いているのは、「データ」と「システム時刻」です。データには時刻の関連項目がありますね。みなさんに一番身近なのはファイルの更新時刻とかですね。ブログの更新時間なんてのもデータで持ってますよね。表示されるでしょ。まさかこれをずっと「内部時間で刻んている」わけないよね。X時間前、という更新時刻は当然XX:XX時というデータと今の時刻の比較をしているので、システム時間をバーンと変えたらX時間前との相対関係が変わって表示変わっちゃいますよね。

サマータイムは簡単、という記事があまりにあれな件 - novtanの日常

説明のためかもしれませんが、さも当然のようにブログの更新時刻をXX:XXデータでもってると言い切ってるあたり、サマータイム云々関係なく、またレガシーシステム云々も関係なく、日時を文字列で持つのが当然という意識が蔓延してることを示してますよね・・・(というかこの説明に関してはいろいろ・・・)

 

日本国内限定のシステムだから201808192300って書式のほうが誰が見てもわかりやすいから?

とはいえ連携するシステムやクラウドサービスなど、まともなシステムは絶対日時で日時表現してくるのであっちこっちでオレオレ書式に変換しなければいけませんよね?それに、文字列書式のままでは時刻演算(n日足すとかn時間足すとか)が困難なので、その度にParse/Serializeしなきゃなりませんよね。

正直これまわりでプログラマーもどきが「なんだかわからないけど9時間ずれるんです」とか言われたの1度や2度ではないのです。いったいなんのために確立した形式があるのにオレオレ方式を考案してバグや混乱を生み出すのでしょうか。

諸悪の根源は「ともかくわかりやすいから文字列にする」という風潮や単なる昔からの流れであると思われ、そういうわけのわからない悪習はもうやめてほしいと思うのですがいかがでしょうか。

 

おまけ 

中小企業向けの会計ソフトを手がけるITベンチャー「freee(フリー)」(東京)の社内SNSでは、政府のサマータイム検討方針が報じられた6日、エンジニアや営業担当者らから疑問を投げかける投稿が相次いだ。

(中略)

 エンジニアの浅越光一さんは「対応に1カ月かかるのか、半年かかるのか、やってみないとわからない。その対応にかける時間があれば、新サービスの開発がどれほどできるかと思うと、もったいない……」とため息をつく。

サマータイム、IT業界に拒絶反応 よみがえる苦い記憶:朝日新聞デジタル

レガシーシステムを多数抱える会社ならともかく、さすがに2012年創業の会社で、海外進出をめざしてるクラウドサービスの会社がこの感じはかなりイメージダウンだとおもうのですがいかがでしょうか(好意的にみれば自社サービスは大丈夫で連携システムのつなぎを心配していると取れなくもないですが)

 

*1:ここにあげた仕様は比較的新しいものが多いが、しかしコンピューターの日時表現の基本は絶対日時であるUNIX timeであり、伝統的なプログラミング言語の日時型はそのラッパーなので、古い言語であっても絶対的な日時を保持するのはそれほど難しくない