いざ物流センター

KLab×はてな エンジニア応援ブログコンテスト

SIer 時代の思い出シリーズ3部作の最後のブログです*1 *2。

最後は「物流センター」にまつわるお話です。流通業における物流センターとは2種類のタイプに区分されます*3。

• DC (Distribution Center)
• TC (Transfer Center)

簡潔に説明すると、DC とは在庫を持つ物流センターで TC は在庫を持たずに仕分けを行う物流センターです。本プロジェクトの要件の範囲内には DC の業務システムも含まれていました。当社は流通業のチェーンオペレーションシステムの実績とノウハウは持っていましたが、DC のシステムを開発したことがなく、全くノウハウがない中で開発が進められました。新基幹システムのサービスインの初日、私はその DC へ立ち会いに行くことになっていました。

旧システムの仕様書に基づき、見た目は同じような DC のシステムを開発しましたが、本当に大丈夫かという大きな不安をプロジェクトメンバーみんなが持っていました。開発リーダーから

何が起こっても当社は言われた通りに開発したと言え。

と私は指示を受けていました。若いエンジニアは覚えておくと良いと思います。こんな指示は現場へ行ったら当然無視です。

DC の朝は在庫としてストックしている商品を店舗へ出荷する業務から始まりました。センター内のあちこちの棚にある商品を1箇所(PC の前)に集めてきて業務システムを使いながら店舗別に仕分けていきます。先ずこの新出荷システムが全く使い物にならず運用することができませんでした。さらに DC にはセンターにストックする商品の発注と仕入処理、各店舗から送られてきた返品商品をまとめて取引先へ送る返品処理、センター内在庫を確認する棚卸処理、半期に1回の廃棄処理、そして店舗へ仕分けた商品を出荷する処理と一連の機能を要するシステムが求められます。扱う商品が大量になるため、本部や店舗用の業務システムとは異なり、運用を全く考慮せず(知らず)に開発された DC の業務システムは全く機能しませんでした。

とにかく実際の運用を知らなければ新システムの何がどうダメなのかが分からないので、その日は1日中センター内を走り回って、現場の担当者がどのように運用しているのかを見聞きしながら教えてもらいました。帰り際、センター長から言われます。

今週1週間はまぁええわ。来週の月曜日までに出荷処理のシステムだけでも直してや。

経験の浅い私でも不可能だと分かりました。

会社に帰って状況を報告します。

それしか答えようがありませんでした。会社に戻り、十数項目の改修内容を報告したのを今でも覚えています。当社が現場の運用を無視して開発したのも事実ではありましたが、設計から開発までその内容を了承していた顧客の情シス部長にも当然、責任はあります。後で分かったことですが、顧客の関係者を含め誰も DC の旧システムも実運用も知らなかったわけです。

犯人探しはともかく、DC の運用は多くの商品(お金)が動くので、このトラブルを放置すると顧客の業績に大きな影響を与えます。選択肢は運用がまわるように改修するしかなく、、、この思い出シリーズの空気を読めば分かるように一番下っ端だった私が DC の業務システムの再設計、並びに画面の UI 改善を担当することになりました。DC の現場の担当者はとにかく従来の運用にこだわる傾向があり、同じ機能があるかどうかではなく、同じ操作ができるかが重要でした。そのため、画面の UI は現場に直接行ってやり取りできる私しか直しようがなかったというのもあります。

センター長とこんなやり取りをよくしました。先ずは改修した新システムを私が一通り説明します。

新システムではこの運用を、こうやって、ああやって、処理することができます。

従来の運用と違うとすぐに突っ込みが入ります。

あー、もう全然違う。そんなのあかんわ、無理無理。

このぐらいではへこたれません。

従来はどうやって運用していたのですか？

すると、従来の運用をセンター長が説明してくれます。

こうやって、ああやって、、、

機をみて逆突っ込みを入れます。

それは新システムではこうやれば出来るんですよ。

センター長も興味を示し始めます。

こうやれば、、、出来るのか、、、

ちょっと間をあけます。何か適当に違う話題で雑談します。

じゃあ、そろそろ私は帰ります。

センター長も何だかんだと文句を言っても運用をまわさないといけないので、

ちょっと待って。最後にもう一回、操作方法を確認させて。

こんな感じで何とか使ってもらいながら、どうしても運用の使い勝手が悪ければ改修するということを繰り返しました。本当の意味で機能に大差がなければ、慣れれば運用はあまり気にならないものです。次回訪問したときに使い勝手を聞いて、そのままで良いと言われることもありました。

2週間で出荷処理が運用できるように緊急の間に合わせ改修をして、3ヶ月で運用にあわせた返品処理へ作り直し、半年かかって旧システムで行っていたのと同様に運用できるようになりました。何度も物流センターへ出向き、何度もトラブルが起こり、何度も障害報告書を書きました。この期間中は DC のセンター長から頻繁に電話が掛ってきて、本当に電話にでるのが怖かった時期でもありました。

今になって思い返せば、よくやったなと自分でも思います(^ ^;;
SI はコストや納期が厳しかったり、理不尽な状況もあると思います。それでもどうせ作るんだったら使い勝手の良いものを作りたいですね。

*1:日次売上報告書の間違いを直せ - forest book

*2:返品訂正のマイナスって？ - forest book

*3:DC と TC のシステム概要図の例

返品訂正のマイナスって？

KLab×はてな エンジニア応援ブログコンテスト

SIer 時代の思い出*1を続けます。顧客はドラッグストアで、私は SIer で運用サポートを行っていました。基幹システムのリプレースという当社の中では最も大きな開発プロジェクトでした。

「取引先別請求データアンマッチ表」という帳票でちょっとしたトラブルがありました。顧客はドラッグストアなので、ここで言う取引先とはメーカーもしくは卸売業の企業になります。請求データとは、取引先からの顧客が仕入れた商品の売掛データ(顧客から見ると買掛データ)のことです。

取引先別請求データアンマッチ表というのは、取引先から送られてきた請求データと顧客が持っている仕入データ(つまり当社の基幹システム内で管理している)を突合して、伝票明細単位に差異があれば、その差異を出力するという帳票です。顧客が商品を発注し、取引先(仕入先)から商品が届き、その仕入検収を行った後に、顧客は仕入確定データを取引先へ送ります。取引先から送られてくる請求データの根拠は、この仕入確定データに基づくものです。もっと言えば、仕入確定データを裏返しにして請求データを作成すればアンマッチが発生することはありません。実際にそのように対応している取引先もありました。

とは言え、取引先によっては、取引先内のシステムで請求データを作成します。顧客は仕入確定データを取引先へ送っていますが、その仕入確定データは使用せず、取引先内のシステムで管理しているデータに基づいて作成する場合もありました。いずれにしても請求データを決められた EDI 仕様に従って作成するのであれば、請求データの根拠が何であれ、システム的には問題ありません。

請求データの EDI 仕様には、請求区分というフラグがあり、以下の(顧客から見た場合)4つの区分がありました。

1. : 仕入
2. : 仕入訂正
3. : 返品
4. : 返品訂正

さらに伝票明細の数量はプラスとマイナスの数値に対応していたために、取引先によっては、仕入訂正を仕入のマイナス数量で表したり、返品を仕入のマイナス数量を表したりしていました。例えば、当社の基幹システム内で管理している仕入訂正のプラス数量の伝票明細と仕入のマイナス数量の伝票明細とは意味が異なるので、伝票明細のアンマッチとして出力されてしまいます。

結局のところ、仕入訂正のプラス数量も仕入のマイナス数量も、顧客から見た場合、買掛金を減らすことを意味します。つまり請求金額としてはどちらでも辻褄はあうのですが、これが大量のアンマッチデータになると、その差異を人間の目で確認するのが大変になってきます。

後で分かったことですが、旧システムでは、請求区分とマイナス数量の違いを考慮してアンマッチにしない処理もしていたようです。リプレース後の最初の月次処理でこの取引先別請求データアンマッチ表が数百枚出力されて、伝票明細の差異内容を確かめてみると、請求金額はほとんど一致しているという始末です。顧客の営業部長からはこんな一言が。

お宅はうちらに神経衰弱させてるのか。

おもろいこと言うなと思いつつ、、、いや、当時は会議机いっぱいに取り消し線が入った数百枚の帳票を見せられて怒られていたわけで笑える心境ではありませんでした。

実際の対応としては、旧システムと同様に取引先別請求データアンマッチ表の出力には、請求区分と数量のプラスマイナスを考慮してアンマッチ出力するようにして、オリジナルの請求データを別途テキストファイルに保存することで対応しました。

帳票を見ていて、顧客の担当者から質問を受けました。

返品訂正のマイナスってどういう意味ですか？

私はこう回答しました。

返品は仕入れた商品を取引先へ返すので買掛金を減らします。
返品訂正なのでマイナスのマイナスだけど、
そのマイナスだからやっぱり買掛金を減らすことを意味しますね。

すると担当者は、

なるほどー、そういうことですね。よく分かりましたー。

ということはなくて

となるわけですね。こんな伝票明細の差異が数百件もあったら訳分かりませんよね。EDI 仕様としては正しいし、システム的にも問題ないし、請求金額も一致するのですが、ただ1つ問題がありました。

人間の目で帳票を見ると訳が分からない

逆の意味を表す区分がある中で数量のプラスマイナスがあると、現場の担当者は買掛金の確認作業に苦労します。取引先からもこういったデータは(取引先から見た場合)売掛金の増減のどちらになるのか？という問い合わせが当社に度々寄せられました。ややこしいのは、例えば、返品は顧客から見た場合、在庫数が減るのでマイナス数量でも良さそうな気がしますが、請求区分が返品だとそうではありません。さらに差異があると、店舗や取引先の担当者にどちらが正しいかの問い合わせを行いますが、仕入訂正だと店舗は2個仕入れる予定が実際には1個しか届かなかったという意味になりますし、返品だと2個仕入れたけれど1個は返品したという意味になります。事実関係を確認する上での区分というのは重要な意味を持ちます。

当然 EDI 仕様書には、請求データの区分や数量による売掛/買掛金の増減がどのようになるかということは書いていません。

そこで「EDI の請求データについて」という EDI 仕様書の付属資料を私は作成しました。各請求区分における取引先から見た売掛金の増減、顧客から見た買掛金の増減と、基本的にマイナス数量は使うなと明記しました。その付属資料を顧客経由で全ての取引先へ送ってもらうように依頼しました。

その後、当社への請求データに対する問い合わせと取引先別請求データアンマッチ表の枚数が減ったことは言うまでもありません。今になって思い返すと、神経衰弱は笑うところだったのかもしれないですね。

*1:日次売上報告書の間違いを直せ - forest book

日次売上報告書の間違いを直せ

KLab×はてな エンジニア応援ブログコンテスト

SIer で働いていた頃、流通小売系基幹システム(ドラッグストアのバックエンドシステム)のリプレース案件に携わりました。昔の同僚に聞いたお話では、私が開発に携わったシステムが今ちょうど新システムにリプレースされる見通しのようです。その頃を懐かしみながら書いてみます。

その顧客は店舗の1日の売上を集計した帳票を作成し、その帳票を「日次売上報告書」、略して「日報」と呼んでいました。システムとしては、店舗の POS 内(厳密には店舗の金庫へお金が移動することもある)にある現金収支の生データが送られてきて、その生データを集計し、帳票のフォーマットで収支項目を出力、又は合計値を計算するというものでした。

システム的にも複雑な仕組みではなく、帳票に出力する収支項目も一般的なものです。しかし、これが大きなトラブルを引き起こしました。

基幹システムのリプレース後、出力された日報には数値の間違いが目立ちました。顧客は基幹システムで処理が行われた後に出力された帳票と直接 POS が集計出力したレシートを検算して、数値の正当性を確認していました。旧システムでは、帳票の間違いが1日1〜2店舗程度の頻度だったのに対して、リプレース後は1日数十店舗に増加したようです。実際の修正作業はパートタイマーさんが行っていましたが、その業務が追いつかず、日報検算後の経理データへの反映が大幅に遅れ、月次業務の運用に支障をきたしていました。

もちろん当社でも、経理部から間違い内容が伝えられ、プログラムを修正し対応しました。特に「日次売上高」という項目の間違いが目立ちました。名前から判断すると、「収入 - 支出」の金額で良さそうな気がしますが、どうもそうではないようです。間違い内容からある収支項目の加減算を行った結果、今度はそれまで正しかった店舗の数値がおかしくなり、そこを直すと、また違う店舗の数値がおかしくなるという状況が発生しました。それを2回繰り返した後、そもそもの正しい仕様を再確認する必要性に迫られました。調査の結果、以下の内容が判明しました。

• 現在の経理担当者は日次売上高の計算式を知らない
• 検算や修正をするパートタイマーさんは、レシートの数値と比較して検算した結果、間違っていることは分かるが、基幹システムでどのような処理が行われているか分からないので計算式を提示できない
• 旧システムの仕様は分からない
• 旧システムの帳票の開発会社は、開発費削減のためにドキュメントを作成しないという契約で開発したため、仕様はソースコードにしかない(顧客も了承済みだった)
• 旧システムの帳票のソースコードは提示できない

それを踏まえた上で顧客の要件はこうでした。

日次売上高の計算式は分かりません。でも、間違っています。直してください。

当社の開発部の回答はこうでした。

顧客から正しい計算式を提示しない限り一切対応しない。

当時、私は運用部署に所属していて、ユーザ窓口であり、且つ顧客の業務をサポートするのがお仕事でした。仕様は分からない、開発部は動けない、そこで私は以下の提案をしました。

現行システムの帳票が出力する数値と実際に修正された正しい数値を
比較することで計算式は私が作る

○ + □ = 5 で、2, 3, 4 という数字が与えられたら 2 + 3 = 5 ですねと言うことをやろうと考えました。1ヶ月間、経理担当者に120店舗分の日報の修正された正しい数値を調査してもらうように依頼しました。1ヶ月間お願いした理由は、毎日、全ての収支項目の数値が発生するとは限らず(2週間1回しか発生しないとか)、ある程度長期的に見ないと考慮漏れが発生するからです。実際には調査するのも大変なので15日分で勘弁してくださいと根をあげられました。

ここで 1800 個のサンプリングデータが得られました。

120店舗 * 15日 = 1800 個(1店舗あたり20個の収入、20個の支出項目がある)

そこからは当てずっぽうです。A + ( B - C - D) * 0.05 + E のような計算式を適当に作って算出された数値と正しい数値を120店舗分比較しながら考察しました。

• どの店舗にいくら差異があるか
• 差異が出ているのはどの収支項目か
• 同じ収支項目に数値がある別の店舗で差異は出ているか
• POS から送られきた生データの数値と同じか
• 外税か、内税か

旧システムの開発会社や店舗への問い合わせ、当社の関係者に協力してもらい、その結果、以下の誰も知らなかった仕様が判明しました。

• ある収支項目に対する POS のキー入力を店舗の店員さんが誤解して運用していた
• ある店舗では、POS の収入項目に対するキーが物理的に足りないために、支出項目を収入項目として運用していた(旧システムでは特定店舗だけ支出項目を収入項目として扱うように例外対応していた)
• ある収支項目は、本当の意味の収入/支出ではなく別の用途の数値を入れるハコとして使用していた
• T 社製 POS の採用店舗は内税、K 社製 POS の採用店舗は外税でデータが送られてきていた

これらの要因による数値の誤差を考慮に入れて、さらに計算式を当てずっぽうで作っていきました。根拠を説明できない計算式ではありましたが、サンプリングデータの 90% 以上の店舗で正しい数値が得られました。しかし、残りの 10% はどうしても分かりません。ここで一旦、調査を打ち切り、これまでに判明した内容からプログラム修正を行ってリリースし、その後、さらに同様のサンプリング調査を行うことにしました。

リリース後、残りの 10% 程度は私が把握していない差異が発生する可能性がありました。しかし、実際には店員さんが本当に運用ミスをすることもありますし、もともと1日1〜2店舗は何らかの要因で修正していたそうなので問題にはなりませんでした。経理担当者からも問題ないとの回答を得て、日次売上報告書のタダシイ仕様を基本設計書に反映し、このトラブルは収束しました。

この運用サポートは、私の中では大きな達成感がありましたが、顧客からも社内からも特に評価されないものでした。基幹システムの管轄部署は情報システム部なので、経理部が困ってても特に関与しません。社内からもお節介なことをやってるな程度の扱いでした。

それでも経理担当者やパートタイマーの方々の業務が軽減されたことには間違いありません。IT を活用する目的は業務の効率化や生産性の向上なので、評価の如何や正否に関わらず、システムの不備に立ち向かって行く人間の意志が大事だったかなと今になって思い返したりします。

営利活動と社会貢献のはざま

キヤノンマーケティングジャパンさんのhttp://teiki.saiyo.jp/canon-mj2011/contents/dm_2/index.htmlを読みました。当初は、大手企業なのに業績不振で新卒採用の予算がないぐらい厳しい状況なんだなと思いました。もし現在、選考中の学生さんがいたとしてもその選考を凍結、もしくは反故にするのかなと推測したりもしました。私にとってはその程度の認識でした。

そして、たまたまこの発表を見た後に学歴の耐えられない軽さ やばくないか、その大学、その会社、その常識を読みました。その中で「官僚たちの的外れな指摘」というエピソードの中で就職協定の問題に対する著者の見解が取り上げられています。

本当に就活を後ろ倒しにしたら、学生たちは本分である学業にいそしむのか？そんなはずはない、というのが私の見方だ。なぜなら、大手企業に内定が出るような学生たちの就活は短い。彼らの多くは、解禁と同時4月に内定を得て進路が決まる。冠系や準大手企業でも5月にはほぼ採用が確定する。つまり、4、5月に就活が終わる学生は非常に多く生まれているのだ。
(中略)
ところが、内定後は、「これで清々して遊べる」とバイトや旅行、サークル活動に精を出し、残り少ない学生生活を謳歌する学生が多い。つまり、そもそも学業を本分などと思ってはいないのだ。

私も概ねこの内容通りの就活とその後の生活を送りました(^ ^;;
私自身、就活を早くしろとか、現状のままで良いと言うつもりは一切ありません。ただ、就活協定の問題は学生さんにとってあまり影響のないことだと私も思います。

閑話休題。キヤノンマーケティングジャパンさんの発表にある「学生のみなさんから学ぶ機会を奪っているのではないか？」という問題認識自体が意味をなさない内容だと私は思います。そうすると、この発表は何なのかが疑問に感じてきました。

一般的に企業における活動は、営利活動と社会貢献の2つに集約されます。企業において人事部は間接部門であり、人事部が直接的に何らかの利益を追求しているとは考え難いです。また、もし既に選考を進めてしまっていたのであれば、その学生向けにこの内容を連絡して謝罪すれば良いだけの話です。なぜに一般公開する必要があるのか。
ならば、この発表は就活協定の問題に対する1つの回答として社会的な意義や在り方を問う社会貢献なのか。しかしながら、学生さんにとってあまり影響のない就活協定の問題、さらに冒頭で業績不振だからと潔く認めているだけに、社会的な意義を主張するのは弱過ぎる気がします。また、業績が良ければ例年通りにしただろうという意図も読み取れます。

この発表は一体何を目的に行ったのだろうか？

私は甚だそれが分かりません。この発表によって注目が集まり、企業アピールや選考活動に利益があるとすれば、それは営利活動にあたり、就活協定の問題提起は、この企業における本質的な意味で、どうでも良い事項であるように受け取れてしまいます。

つまり、何が言いたいかと言うと、このような目的が曖昧に取れてしまう戦略は企業として良くないと私は思います。さらに勘繰ると、企業内に様々な意見があり、それらを調整した結果、このように落ち着いたようにも伺えます。真剣に考えれば考えるほど分からないし、戦略目標も立てられません。世論的にも賛否両論あるでしょう。結果的に利益につながるかもしれませんし、社会貢献につながるかもしれません。私が面接に行くならば、この発表は何を意図しているのかを面接官に聞いてみたいものです。

リファレンス:
成熟経済を蝕む仮定法の亡霊 - 雑種路線でいこう
キヤノンマーケティングジャパン、業績悪化が原因で新卒採用活動を延期 | スラッシュドット・ジャパン
キヤノンMJの快挙！新卒採用の遵法 :: INSIGHT NOW!
http://d.hatena.ne.jp/ishidaken/20100106/1262793994
http://puff.weblogs.jp/kugi/2010/01/%E6%8E%A1%E7%94%A8%E5%87%BA%E9%81%85%E3%82%8C%E5%AE%A3%E8%A8%80%E3%81%AE%E8%A9%B1%E9%A1%8C%E3%81%AB%E3%81%82%E3%81%88%E3%81%A6%E8%A7%A6%E3%82%8C%E3%82%8B%E6%97%A5.html

学歴の耐えられない軽さ やばくないか、その大学、その会社、その常識

営業と技術のお仕事はどちらが大変？

営業さんと技術さんとの飲み会でのある話題です。

営業は数字があがらないと解雇されることがあるけど、技術はそういう心配がない

営業さんに悪気があったわけでもなく、技術さんが嫌味を言ったわけでもないのですが、飲み会だったので、そんなようなお話になりました。営業は毎月、数字が課せられるので厳しい、技術は開発さえやっていれば一方的に会社から解雇されることはないと言うのです。この側面のみで言えば、確かに営業さんの方が厳しい世界で勝負していて、技術はお仕事してるのかしていないのか、よく分からなくても何とかなりそうな雰囲気がします。

当然、私も技術さんも「いやいやいや」と各々の持論で反論しました。ここで、タイトルにある「営業と技術のお仕事はどちらが大変？」という質問の回答を断言すると、

どちらも大変

だと私は思います。よって、この議論で不毛であり、議論する必要性もなければ、得られる有意義な見解もないと私は思います。しかし、この手の議論は感情論でついつい盛り上がりますね(^ ^;;

数字で評価されることが厳しいというのは1つの側面ではありますが、他にも様々な側面があります。その時、私が思ったことは以下の内容です。

技術のお仕事を評価する(客観的)数字がないのは逆に悩ましい

特に開発は、戦略的な開発(赤字でもノウハウや実績を得るためにする)やパッケージ開発(潜在ニーズの具現化)など、営業さんのように必ずしも短期間に売上のような数値化が難しい場合があります。また、技術レベルやコード品質に個々人のバラツキがあり、納期よりも早く開発したから良いとか、たくさんコードを書いたから良いとも言えません。自分がさぼっていると指摘されない代わりに、自分が頑張っているとも(客観的に)主張できないのです。

以前、勤めていた会社で経営者が技術者に営業努力をするように働きかけてこんな事を言いました。

営業が売ってこなければ会社は倒産するんだ、
技術がいくら良いものを開発してもしょうがないんだ

これはもちろん正しいのですが、経営者や営業さんがこういう事を技術者に言っては絶対にダメな気がします。だったら、経営者や営業さんが、コードを書いたりデバッグしたりするのかという不毛な議論になるからです。要は自分が出来ることに対して、他人が出来ないもしくはやらなかったとしても、その点のみを言及して他人を責めてはいけないと私は思います。

もう1つ私が「あっ」と思った出来事があります。以前、祐川さんのモチベーション研修を受講したことがあります。その際、自分のアピールポイントを書くワークがありました。私は「休まない」と書きました。意図としては、病気に強いとか、運用がどれだけトラブっても逃げないとか、納期に成果物が完成していなくても会社へ行くとか、忍耐力をアピールしてみました。これは全然ダメな例の1つで、平日に会社を休まないのは業務として当たり前のことで、顧客から見たら何もアピールポイントではないのですね(^ ^;;、他にも顧客へ親切に対応するとか、挨拶をするとか、1日50件顧客先に訪問しますとか、たまたま周りと相対的に比べたときに自分の方が出来ることをあげてしまいがちです。

自分自慢は良いけど、それで他人を責めていないかを考慮するようになってきました。

勉強会へ参加しないようにしてくださいと返信する CTO

先日、IT 企業に勤めている友人と勉強会のお話になりました。私が発表した Python Code Reading 10 も知っていて、その友人の同僚のエンジニアが参加されていたそうです。

その友人の同僚は、勉強会にアンテナを張り巡らし、しばしば、社内のメーリングリストへ FYI として情報提供されていたようです。それを続けていたところ、

デブサミや Google Developer Day のような企業がスポンサーになっている勉強会は良いのですが、今後、Python Code Reading のような個人や有志で開催している勉強会の情報は流さないでください。また有志の勉強会には参加しないようにしてください。

と、その企業の CTO が社内メーリングリストへ返信したそうです。その友人が言うには、色んな勉強会へ参加することによって、優秀なエンジニアの流出を怖れているらしいのです。

一般的に、勤めている企業が魅力のある職場であるかどうかは、その企業の人事制度や評価制度、もしくは業務内容によると思います。企業の求心力と、エンジニアが勉強して技術力を身につける事を混同しているように聞こえました。

いずれにしても CTO という立場の人が言うことではないなと呆れてしまいました。

リファレンス:
勉強会も自由に参加できない会社なんて…
shibata616 社外勉強会に参加するような輩は、
Python Code Reading 10 裏話

プロフィール更新

id:kokorosha さんのプロフィールネタに影響受けた id:bonlife さんのブログを読んで、「とにかく書かなきゃ」的な衝動に駆られました。

• プロフィールを修正してみて、自分のことをいかに客観視できていないのかを自覚して愕然とした

修正後のプロフィールです。
id:t2y-1979:about