暗黙知ははたして悪なのか？
”暗黙知”という言葉はたいていネガティブな文脈で使われます。
”暗黙知”でGoogle検索すると、対義語の”形式知”について触れつつ「どうすれば暗黙知を形式知に転換できるか」についてのノウハウが書かれた記事がたくさん出てきます。
暗黙知（個人が持つ知識・ノウハウ）を形式知（文書・マニュアルなどに落とし込んだ他者が共有できる形のもの）に変えるメリットとしては、属人化の防止やスキルの伝達などがよく言われます。
しかし逆に暗黙知のほうが優れている点については語られているのは見たことがありません。
今回は『暗黙知を形式知化するのが常に正解というわけではない』というテーマについて書きます。
============
※ 形式知の代表例として、社内共有された社内制度・業務ルール等のドキュメントを想定して書きます
形式知化するとコストがかかり続けます。
初めにドキュメント化するコストはもちろんですが、その後ドキュメントを現実に合わせてずっとメンテナンスし続ける必要があります。
このメンテナンスが中途半端だと、内容が誤った”ゾンビドキュメント”が増えていきます。
誤った知識が伝わってしまう上、正しいドキュメントですら信用できない状態になってしまうため、「コストをかけているのに恩恵が得られない」むしろ害が大きい状態になってしまいます。
また形式知は読む方にもコストがかかります。
近年は透明性という意味で社内のあらゆる情報をドキュメント化する企業が増えましたが、読む方としては膨大なドキュメントに圧倒されていざ何から読んでいいかわからないのも事実です。
透明性という意味で『あらゆる情報にアクセスしたければアクセスできる』ことはとても重要なことですが、一方で『本当に知っておくべき情報が埋もれてしまったり、重要な情報を斜め読みしてしまう』問題も起きます。
一方悪く言われがちな”暗黙知”ですが、メリットもあります。
業務を属人的に行うことによる業務スピードの上昇度合いは凄まじいものがあります。
形式知化して複数名で作業するより、一人が属人的に仕事を進めたほうがスピードも質も圧倒的に高いケースはプログラミングにおいては非常によくある話です。
情報共有や議論などのあらゆる間接業務を排除し、属人的に行うことで10x（10倍）のパフォーマンスを出すことができるという話は以前ブログにも書きました。
============
ここまで一方的に暗黙知の良さについて書いてきましたが、もちろん形式知化することは大事です。
ただし常にそれが正解ではないということがあまり語られることはないので、今回テーマとして取り上げました。
形式知化に頼りすぎるとむしろ害になりえるようなものの例としては以下のようなものがあります。
- 0から何かを始める場合のように、立ち上げスピードや柔軟な方向転換が求められるもの。
- 変化しやすいもの。
- コンテキスト含めきっちりと理解してほしいもの。人により理解度に差が出ると困るもの。
そういった場合、暗黙知を形式知化するのではなく、暗黙知を暗黙知のまま伝達するという方法もあります。
例えばソフトウェアエンジニアだとペアプログラミングと呼ばれる、ペアで作業する方法があります。
設計パターンやコーディングルールについて変に形式知化（ドキュメント化）しても、読まれずメンテナンスもされないドキュメントが量産されてしまいがちなので、むしろ暗黙知のまま継承する仕組みがあるほうがいい場合もあります。
他の例としては、業務に必要な業界知識の伝達があります。ドキュメント化しても人により理解度に差が出るので、ドキュメントと合わせて丁寧な口頭説明を行うなどもしたほうがいい場合もあるでしょう。
============
以上、「暗黙知ははたして悪なのか？」についての話でした。
暗黙知が悪いケースはありつつも常に悪とはいえず、『暗黙知はなくすものではなく、組織としてうまくマネジメントするもの』ではないかという話でした。
ドメインエキスパートとどれだけ議論しても、完璧なドメイン理解にはたどり着けない
自分がこれまでSaaSを開発してきた経験の中で、「ドメイン領域に対する自身のモデリング精度が低かったゆえに、機能リリースからある程度時間が経ったのちに仕様をガッツリ見直した」ことがよくありました。
特に投資の計算指標などドメイン知識が複雑なものも扱っており、そういったものについて専門用語の定義やコーナーケースにおける計算ロジックを見直した経験がよくあります。
あるときチームメイトと雑談で「自分の過去の仕様検討不足で、今になり結構修正が必要になってしまって大変だった」と話したところ、「むしろ単に、仕様の考慮不足に気づけるだけドメイン理解が深まってきたということではないか」と言われ、なるほどと思いました。
その会話の中で『ドメインエキスパートとどれだけ議論したとしても、完璧なドメイン理解にたどり着けない』という気づきを得たので簡単に書いてみます。
++++++++++++++++++++++
開発者によく知られているノウハウとして「機能の開発前に、ドメインエキスパートと開発者が議論をすることで適切なモデリングができる」というものがあります。
有名なドメイン駆動設計（DDD）においても、ドメインエキスパートと開発者が同じ用語（ユビキタス言語）を使い議論をする方法が推奨されています。
このノウハウの有用性には100%賛成するのですが、「どれだけ手を尽くしてもはじめから完璧なドメイン理解にはたどり着けない」というのが個人的考えです。
なぜならドメインエキスパートは全てを見通す神ではないからです。法的なルールなどについては当然詳しいですが、実態として全てのユーザが現場で現在どのように業務を行っているかを完璧に把握している人はいません。
また仮に全知全能の神だと仮定し、全てのユーザの現在の業務フローパターンを全て把握していたとしても、それはあくまで現在の業務フローについての知識であり、プロダクトを通じて実現したい理想の業務フローではありません。
モデリングは現在の業務フローに対してではなく、プロダクトを通じて提供する理想の業務フローに対して行うものなので、理想の業務フローがわからない限りは適切なドメインモデリングはできません。
++++++++++++++++++++++
ここまで『ドメインエキスパートとどれだけ議論したとしても、完璧なドメイン理解にたどり着くことはない』理由について書きましたが、前に書いたとおりドメインエキスパートと議論することを否定しているわけではありません。
むしろかなり良いことであり積極的にやるべきだと思っています。
ただし最初のモデリング作業に労力をかけすぎるのではなく、『当初のドメイン理解は時間の経過とともに間違ったものになる』という前提で考えておき、間違っていることがわかったタイミングで早めにモデルの修正を行うことのほうが大事だと思います。
（特にSaaSのように様々なユーザのニーズを汎用化して捉えないといけないプロダクトを開発する場合や、スタートアップ企業のように作るべきものが頻発に変わる環境においては、強くそう感じます。）
世の中の事例を見ていると、事前のモデリングに心血を注ぎ図や文書などの資料を作ることに傾倒しているケースもありますが、事前にどれだけ時間をかけても間違いは必ずあるということを理解した上でどの程度労力をかけるか考えることが大事だと感じます。
スクラムは積極的にカスタマイズして使うべき
有名な開発フレームワーク”スクラム”が、現代のアジャイル開発にもたらした貢献は多くの人が認めるところだと思います。
私自身も、スクラムの思想である「経験主義」「リーン思考」に強く影響を受けた人間の一人です。
私はスクラムの考え方自体はかなり好きですが、唯一賛成できない点があります。
それは『スクラムの一部を変えたものはスクラムと呼ばない』というルールです。
スクラムガイドには以下のように記載されています。
最後に
スクラムは無料であり、本ガイドで提供されるものである。ここで概要を述べたように、スクラムフレームワークは不変である。スクラムの⼀部だけを導⼊することも可能だが、それはスクラムとは⾔えない。すべてを備えたものがスクラムであり、その他の技法・⽅法論・プラクティスの⼊れ物として機能するものである。
おそらくスクラムガイドの著者は「正確な”スクラム”の定義とはなにか？」を示すためにこの記載を入れたのだと思います。
しかしこの記載があることで、スクラムの理論を熱心に勉強した人やスクラムを教えることを飯の種にしている人が、いくつかのプラクティスが抜けているだけで「それはスクラムではない」と指摘しているケースを見かけることがあります。
たいていの場合スクラムは杓子定規にそのまま守るより各現場にフィットするようカスタマイズしたほうが効果を発揮すると思います。
スクラムの定義を厳密に守るのに傾倒することは本質から外れており、エンジニアリングプロセスの創造性を阻害する行動です。
米国生まれの流行りのフレームワークに盲目的に乗っかるのではなく、開発プロセスは自分たちの頭で考え改善していくべきです。
この記事では『スクラムは積極的にカスタマイズして使うべき』だと考える理由について説明します。
厳密なスクラムの利点・欠点
厳密なスクラムについて一言で個人的感想を言うと、『現場目線というよりは経営陣などマネジメント層が喜ぶフレームワークだな』です。
スクラムはマネジメントフレームワークとしては非常に優秀で、一連のプロセスを守ることで、「属人性排除」「人的トラブル低減」「新人教育」「精度高いプロジェクト管理」などが勝手に実現されます。
運用に時間がかかるという大きなデメリットはありつつも、開発組織が非常に管理しやすくなりスケールもしやすくなるため、マネジメントに喜ばれるフレームワークです。
なぜなら組織として開発を「安定的に」「トラブルなく」「見積もり精度高く」遂行し続けることができ、チームメンバーの入れ替わりにも強く、また組織拡大によりチーム数を増やす場合でも（同じフレームワークで運用していれば）スケールしやすいためです。
一方で現場目線（イチ開発者目線）で言うと、スクラムの運用に時間が取られすぎだと感じます。
スクラムでは透明性を担保するためにスプリントゴールやバックログアイテムの定義・見積もり・実現方法などについて、チームメンバーでガッチリ詳細まで合意する必要があります。
そのため長いMTGが必要だったり、仕様や受け入れ条件などドキュメントをきっちりと整備する必要があるため、とにかく時間がかかります。
特にコードをガッツリ書きたい人やスピーディに機能開発をしていきたい人にとっては、間接業務ばかりしてコーディングという直接的な生産活動に携われないことは、自身の手足が縛られているような感覚でしょう。
また現場目線でいうと、スプリントゴールまでの詳細な進捗を毎朝どんなときも事細かに共有し続けるのは、少し息苦しく感じます。
皆がゴールにコミットし進捗を日次で詳細に共有するスタイルは、ムダなくゴールに向かうことができるスタイルではあるのですが、創造的な試みや日常の細かな改善がおざなりになりやすい点に注意が必要です。
長期的に続けるのであればゆとりが欲しいなと個人的には感じてしまいます。
個々人の裁量である程度は自由に使える時間があり、その中でちょっと気づいた箇所をリファクタリングしたり、イノベーティブな試みを検証したり、調べものをじっくりしたりといったスプリントゴールから外れるようなこともしていいんじゃないかと思っています。
こういったゆとりは、仕事の緩急という意味でのメリハリにもつながり、体調のコンディションをいい状態に保ち続けるのにもつながります。
例えば私がいるチームでは『20%ボーイスカウトルール』というものがあり、最大20%程度であれば自己裁量でリファクタリング・テストコード・ドキュメント整備・ライブラリアップデートなどに時間をかけても良いルールがあります。
本家のスクラムに厳密に従うと、こういったゆとりは入れづらいのではないかと思います。
※ コード含めあらゆる環境をクリーンにリファクタリングし続けることで生産性を高く保つ考え方については以下記事でも紹介しました。
おわりに
というわけで「厳密なスクラムを実践するのではなく、スクラムライクなオリジナルの制度を皆それぞれのチームに合った形で考えればいいじゃないか！」というテーマについて書きました。
スクラムを構成する諸要素はすごく効果的なものが多く、またスクラムの背景思想も素晴らしいので、初めの一歩としてスクラムをまず初めに原典にそって厳密に実践してみること自体は悪いことではないと思います。
しかしスクラムの基本的な型を学んだのであれば、それを厳密に守り続けるのではなく、どんどん応用していったほうが生産的で創造的なチームになるのではないかと思います。
技術的負債が返済されない理由と返済する方法
ITエンジニアにはおなじみの『技術的負債』についての記事です。
技術的負債の定義は「最善ではない設計や実装により内部品質が低下し、将来的な保守性やシステム性能としてのスケーラビリティに影響を与えるような課題」とこの記事内ではします。
コードを書くと多かれ少なかれ必ず負債が生まれます。そのため負債が生まれること自体は悪いことではないです。しかしその負債が返済されることなく溜まっていき、大きな問題として表面化してから対処することが多いため、よく開発現場では問題になるトピックです。
語り尽くされた話題ではありますが、負債が返済されない理由と返済する方法について改めて考えてみました。
負債が返済されない理由
負債が返済されない理由についてはいろいろな意見があると思います。例えば「品質よりも納期を優先しなければいけないから」というのは1つの大きな理由です。他に思いつく理由だと、、、
- 仕様や品質要求は変化し続けるため、負債は気づかぬ間に自動的に生まれているから
- 負債を認識するにはそのコード箇所への理解だけでなく技術力も必要なので、表面化するまで認識されていない負債がよくあるから
などなど、理由は色々あります。
しかし私個人の意見としては、突き詰めると負債が返済できない最大の理由は『負債は数値で管理できないから』だと思っています。
納期・予算・品質・スコープという開発プロジェクトでトレードオフになる4要素のうち数値などの見える形で管理できないのは品質だけです。納期は「日付」という形で見え、予算は「人件費（人数）」という形で見え、スコープは「機能ボリュームや機能数」という形で見えます。
『品質だけは数値で管理できないため、技術的負債の規模や返済価値が認識できず、その結果返済の着手はいつも遅れてしまう』というのが個人的な見解です。
返済するための方法
良し悪しはひとまず考えず、どんな方法があるのかについて考えてみました。
なおこれらの方法は複数組み合わせることも可能です。
1. 技術的負債がたまり問題が表面化してから着手する
よく行われている方法です。例えば新規事業のように立ち上げ当初は生きるか死ぬかの世界なだと、こういった判断にならざるを得ないことも多いです。
ただし技術的負債が簡単に返せないレベルまで貯まると、プロダクトの将来性を大きく損なうので、負債が返済可能なレベルの段階で着手する判断能力が求められる方法です。
2.品質に関わる間接的な指標を数値として管理する
品質自体は数値化できませんが、品質に間接的に関わるような指標（例えばテストカバレッジ）を数値として管理する方法です。例えば「このモジュールのテストカバレッジをX％以上にする」といった目標を定めるなどです。
あくまで直接的に品質を改善する試みではなく、また目標設定が適切でなければ効果的ではないなどの欠点はありつつも、最低限の品質改善に向けた行動を促すことができるため成果はあります。
3. 一定割合は継続的に品質改善活動に投資することを決めておく
「スプリント内のタスクのうち平均20%は技術的負債やデザイン負債の改善タスクにする」などを決めておくスタイルです。
エンジニア的には安心の方法ですが、杓子定規に20%の時間を使い続けると、ビジネス的に緊急度が高い開発タスクがあるときに80%の時間しか使えずチームの成果が少なくなるので、パーセンテージは状況に応じて柔軟に変えたほうがいいでしょう。
4.品質向上につながるような文化を醸成する
品質向上につながるような行動を良い行動だとみなすよう、皆で合意しておき、チームの文化にしてしまう方法です。
例えばリファクタリングなど、ビジネス成果が出ず地味だけれども重要な試みについて時間を使うことを積極的に推奨・称賛するなどが上げられます。
個人的にはソースコードに限らずあらゆるものをリファクタリングすることを推奨する文化があると良いと思っています。（過去に以下記事でその考え方について紹介しました）
==================
以上4つの方法を考えてみました。私がいるチームでは3, 4の方法を常時実行し、1, 2の方法を必要に応じて行っています。
状況に応じて最適な方法は異なるでしょうし、他の方法もあるかもしれませんので、是非技術的負債を返済し続ける方法について考えてみてはいかがでしょうか。
スマホを物理ロックして生活が捗るようになった話
1年前にスマホを物理ロックするアイテムを買い、以来ずっと愛用し続けています。使ったことで平日も休日もすごく捗るようになり、個人的神アイテムなので紹介します。
物理ロックって？
写真のようなボックス型のアイテムです。スマホを入れてタイマーをセットしてロックをかけることで、タイマーの時間が切れるまでは箱を開けられずスマホが使えないというパワーあふれるアイテムです。
↑は自分が実際に買ったアイテムです。お値段は3,600円でした。（Amazonの商品ページはこれ）
『タイムロッキングコンテナ』と呼ばれているので、そのキーワードで検索をかけるともっと安いものも色々出てきます。
上で紹介したアイテムのようにロックがかかっていても必死こいて頑張ればスマホを操作できるタイプのものもあれば、安いものだと下の写真のようにロックがかかっていると操作不可能なものもあります。
何がいいの？
ロック中は『スマホが使えなくなる点』がメリットです。スマホ依存を強制的に断ち切れます。
意外かもしれませんが、スマホは使っているときだけでなく、スマホが使える状態で近くに置かれているときにも集中力を奪います。ベストセラーになった『スマホ脳』という本にも書かれていたのですが、学生に試験を受けさせる際にスマホをカバンに入れて持ちこんだ人と教室の外に置かせた人では、後者のほうが成績が良かったそうです。
この研究結果は自分の体感ともかなり合うなと思いました。なにかの仕事をしていて集中力が切れそうになったタイミングでスマホが近くにあると、すぐに触りたくなるんですよね…。
というわけで、このアイテムは自分が集中したいとき、娯楽の塊であるスマホを自身から遠ざけるために使えるアイテムです。
ロックすると支障あるんじゃないの？
意外と日常生活に支障ないです。
気になる方は1日スマホの電源オフにするなりして試してみるのがいいと思います。自分の場合は「スマホを触りたいな」とふと思ったタイミングのほとんどは、「ちょっと時間空いたからTwitter見たいな」とか娯楽を求めるタイミングがほとんどでした。
ただしロック中も頑張れば触れるようなタイプ（1つ目の写真で紹介したタイプ）を個人的にはお勧めします。
緊急の電話がかかってきたときに取れないのも困りますし、あとは二段階認証のための認証アプリなど業務に必要なアプリをスマホに入れていた場合にどうしようもなくなるからです。あと超必死に頑張ればLINEの返信も一応できます笑
アイテムによってロック時間にも違いがあるので、そこも購入する際には気にしてみて良いポイントかもしれません。自分は最大24時間のものを買い、普段は8時間とかでロックをかけていますが、最大1時間しかないものもあるので注意が必要です。
最後に
というわけで、スマホ依存に悩んでいる方は是非使ってみてはいかがでしょうか？
「スマホアプリの利用時間を計測・制限するためのアプリ」などが世の中にはありますが、それよりもずっと強力ですし、意外と日常生活に支障をきたさないです。
なおスマホをロックするのは平日だけでなく休日もオススメです。「スマホを眺めていて知らぬ間に時間が経ってしまった」ということがよくあると思いますが、そういった事態を減らせます。
今の時代スマホを通じて、プライベートではLINEなど、ビジネスではSlackなどでチャットでずっと人とつながり続ける時代です。それに抗うことは難しいですが、チャットのうちすぐに返信しなければいけないものは少ないです。1日1時間だけでもいいので、ロックなどを使い定期的にシャットアウトする時間を個人的には設けたほうがいいと思います。
（ちなみに似た話として「仕事においてチャットツールは、定期的に落として良いのでは？」という話は昔、以下記事でも書きました。）
自分の時間や集中力を取り戻すきっかけとして、是非今回紹介したようなアイテムを使ってみてもいいかもしれません。
ラバーダック・デバッグから考えるセルフレビューの方法
プログラミングにおいて、『プルリクエストのセルフコメントを書くのはオススメ！』という話を以前別の記事でしました。
プルリクエストは本来他の人にレビュー・コメントしてもらうために作るものですが、それを人に見せる前に自分自身でレビュー・コメントするという方法です。このセルフコメントの工程を挟むことにより自分の成果物（コード）を客観的に見ることができ、コードのクオリティがグッと上がるため個人的にイチオシしている方法です。
（過去に以下記事で紹介しました）
この話を公開すると「ラバーダック・デバッグと似てますね」というコメントをいただきました。ラバーダック・デバッグが何か知らなかったので調べてみたところ、たしかに似ており面白い共通点もあったため、その内容について書いてみます。
ラバーダック・デバッグとは？
Wikipediaの説明がわかりやすかったのでそのまま引用します。
ラバーダック・デバッグ（英語: Rubber duck debugging）とは、ソフトウエア工学におけるコードのデバッグ手法である。ラバーダック・デバッグは、アンドリュー・ハントとデビッド・トーマスの共著によるThe Pragmatic Programmerという本で紹介された、プログラマーがラバー・ダック（アヒルちゃん）を持ち歩きアヒルちゃんに向かってコードを1行ずつ説明することによりデバッグを行うという話が由来である。この手法には、他にも多くの別名があり、しばしば様々な無生物が用いられている。
プログラマーの多くは誰かに問題を説明した経験があり、その相手はプログラミングの知識が全くないこともあり得るが、問題を説明している過程で解決策を思いつくことがある。目的とするコードと、実際のコードの挙動を観察して、説明することにより、その違いが明白になるのだ。一般化するならば、あることを説明することによって、異なる見方による評価をする必要が生じることとなり、それがより深い理解へとつながる。無生物を用いることにより、プログラマーは、他人を煩わせることなく目的を達成できる。
プルリクエストのセルフレビューにはアヒルちゃんは使わないですが、確かに「自分が書いたコードを1行1行読み、それにコメントをつける」作業は「コードを1行1行読み、アヒルちゃんに説明する」のと似てますね。
他の似た方法
他にも似た方法があります。ベア・プログラミング（テディベアメソッドとも言います）はご存知でしょうか？
設計や実装などで困ったことがあるときに、部屋の中にあるテディベア（熊のぬいぐるみ）に困りごとを話すという方法で、これをすると悩みが自己解決すると言われています。自分の考えを独り言として話すことで、自然と考えが整理されるためです。
また、ラバーダック・デバッグやベア・プログラミングはプログラミングに閉じた話でしたが、他分野でも似た話はあります。
- 新聞など原稿を書く仕事の人が、その原稿を紙に印刷して読みあげ、読みやすい文章になっているか確認する
- プレゼン資料を作るとき、読み上げてみることでストーリーとしてキレイにつながっているかどうか確認する
- 仕事の1on1ミーティングにおいて、1on1を行う人は1on1を受ける人が話すのを邪魔せず傾聴する（1on1を受ける人が自分自身の考えを自分の力で言葉にすることが大事であるため）
- ブログも投稿する前に、軽く声に出して読んでチェックする（このブログのことです）
共通点
結局のところ「アウトプットする過程を通じて考えが整理され、セルフレビューになる」というのが共通点になります。アウトプットの形式は声でも文章でもどちらでもいいのですが、アウトプットをすることで自身の成果物を客観的に見ることができ、クオリティをあげることができます。
つまりプログラミングにせよ何にせよ、一人で作成したものの成果物のクオリティを上げたければ、じっと成果物を眺めているよりも声に出すなりしてアウトプットするのが効果的です。自身の分野でこのテクニックが適用できないか考えてみてもいいかもしれません。
OSSにコントリビュートしたことで身についた力
OSSへのコントリビュートは業界への貢献であり、また個人の挑戦にもなるためオススメです。
実益もあり、よく言われるものとしては以下のようなものがあります。
- 他人のコードを読むことで、自身の引出しにない設計・実装に触れられ、技術力が向上する。
- 個人の技術力を示す実績としてアピールできる
私は一時期よくOSSへのコントリビュートをしていました。その時これらのメリットを感じつつも、別の大きなメリットも体感しました。
それは『プロジェクト・コードのコンテキストを読む力』、そして『理解しやすいコンテキストを作る志向性』が身についたことです。これらの力についてはあまり語られることはありませんが、個人的には”技術力”の要素の中でも重要な要素だと感じています。
今日はOSSコントリビュートでそれらスキルが身につく背景について説明します。
==================
『コンテキストを読む力』は『空気を読む力』とも言いかえられます。
OSSは国も文化も全く違う人間が集まって作っているものです。またコントリビュータになりたい人とOSSの作者とでは、そのプロジェクトの対象領域に対する前提知識の深さが大きく異なります。
さらにOSSでは普段の業務と違い、気軽に対面で質問することはできません。大抵はPR・Issueベースでの質問になり回答に数日かかるか、あるいはチャットがあったとしてもOSS作者は忙しいので満足な回答はすぐには来ないでしょう。
そんな何もかもの前提が普段のプロジェクトとは違う中、空気を読みつつ適切なコード修正を行う必要があるのがOSSコントリビュートです。
色々な人がコントリビュートしているようなプロジェクトでは、そういったコントリビュータと作者との前提の違いを埋めるため様々な工夫がなされています。ソフトウェアの動作についてのドキュメントの用意、コントリビュータ向けにコントリビュート指針を文章として公開、分割されたモジュール、テスタブルな設計、適切な粒度のコードコメントなど、工夫は様々です。
こういった属人性を排除するための工夫が、OSSでは普段業務で作るソフトウェア以上に強く意識されているでしょう。なぜなら属人性が高いOSSはコントリビュータが集まらないからです。
私は色々なOSSにコントリビュートしていたおかげで、自然とコンテキストを読む力がつきました。おかげで初めて読むコードベースを抵抗なく読めるようになりました。こういったスキルは自分が利用しているライブラリを深く理解できたり、新しく参加したプロジェクトにおいて早期に活躍できることにつながります。これらのスキルは自身が今いる職場ではひょっとすると役に立たないかもしれませんが、「どこででも誰とでも働けるスキル」という意味で、社外に出ても通用するスキルになります。
またコンテキストを読みやすくする様々な工夫に触れることで、普段の業務でもコンテキストの読みやすさに対して敏感になりました。新しくチームに入った人がすぐにコントリビュート（活躍）しやすいようなコード・ドキュメントはどういうものだろうという思考が強く働くようになりました。
また属人性の排除は、他人に対してだけではなく未来の自分にも有益なので（人間は数ヶ月経つと忘れる生き物なので）、コンテキストを読みやすくすることはチームのみならず自分自身の生産性の向上につながります。そのためコードのみならずあらゆるものをキレイに整理するメンタリティが身につきました（以下記事でも少し紹介しています）。
==================
以上、OSSのにコントリビュートしたことで身についた力についての記事でした。
まぁ何が言いたいかというと、OSSコントリビュートにチャレンジしたことない人は、チャレンジオススメです！！！
在宅勤務のオフィスレイアウトの工夫
ここ3年ほど、仕事は在宅から行うことがほとんどでした。
在宅勤務にあたり特別な工夫はあまりしていないのですが、部屋のレイアウト関連でやや珍しい工夫を2つしています。この記事ではそれについて紹介したいと思います。
==================
1つ目が机の配置です。社長室みたいな机の置き方にしています。
自室は4畳強ほどの部屋ですが、以下画像のようなレイアウトにしています。
配置のポイントとしては以下のとおりです。
- 自分の顔が扉の方向を向くようにする（扉に対し自分の背を向けない）
- 窓に対し垂直に机を置く（窓に顔や背を向けない）
- 机は壁に接するようにする
このレイアウトは集中できるという噂を聞き試してみたところ、実際集中できたため続けています。（余談ですが風水的にも良いらしいです）
集中できる原理としては以下のとおりです。
- 背を向けると背後から来る身の危険に対処できず心理的に安全ではない。一方、扉に顔を向けることで安心できる。
- 窓から来る光は、机の正面が窓では直接目に入るし、机の背後が窓であればディスプレイに反射し眩しい。垂直にすることで眩しくなくなる。
- 左右のスペースが空いているより、閉じたスペースのほうが心理的に安心感がある（身の危険に対処しやすいため）。
==================
2つ目がホワイトボードの配置です。壁に貼るタイプのホワイトボードをパッと見える位置に貼り、そこに中長期目標のような重要な内容を書いています。
壁に貼るタイプのホワイトボードは『ホワイトボードシート』などで調べると出てきます。接着剤が裏についており剥がすときもあまり壁紙を傷つけないので、賃貸でも気にせず使えます。また自由な大きさに切って使うことができます。
マグネットが貼れない、書いた内容を消すのが面倒くさいなど、通常のホワイトボードのほうが機能性では優れていますが、「大きく文字が書け、書いた内容をしばらく残せる」という用途では充分活用できます。
ホワイトボードの位置は下図の位置です。
顔を上げればホワイトボードが見え、また左を向いてもホワイトボードが見えるようになっています。
仕事の四半期目標や個人的な抱負のように中長期的な目線で重要な内容を書くことで、大事なことを忘れることなくいつでも見える位置に書いておくことができ、重宝しています。
==================
以上、在宅勤務でのオフィスレイアウトの工夫の紹介でした。
育児のため休暇を2週間とってみた
先日初めての子供（娘）が産まれ、かなり短いですが2週間育児のための休暇をとりました。
自分の価値観が変わる体験だったため、休暇取得のため考えたことや休暇中に感じたことについて書いてみたいと思います。
休暇取得のタイミング
出産後1ヶ月後時点から2週間（正確には休日込みで17日間）、休暇をとりました。
出産直後は奥さんが1ヶ月実家に里帰りしており、出産1ヶ月後に自宅に帰ってきて、その時点から2週間の休暇をとった形になります。
普段の仕事内容
スタートアップでCTOをしており、普段はマネジメント・採用・開発・コーポレートITなどを担当しています。たった2週間とはいえ準備なしで抜けるとまずいので、自分なしでも日常業務が回るようチームとしての準備を進めました。最近では特にスタートアップを中心に経営メンバーが育休を取る例が増えてきていることもあり、チームからの理解もスムーズに得ることができました。
休暇の種類
育児休暇ではなく有給休暇を使いました。有給休暇が十分に余っており、育児休暇を使うメリットがあまりなかったためです。ちなみに取得こそしませんでしたが育児休暇制度については色々と調べ、とても素晴らしい制度だと感じました。
まず雇用保険のおかげで休み中も賃金の67%（休暇取得後半年経過すると50%に低減）も支払われる点が素晴らしいです。またこれは会社ではなく国から支払われる金額であるため、会社に気兼ねをしなくていいのもありがたい点です。
また期間も1年間取ることができますし、他にも条件を満たすことで追加取得もできます。
さらに、会社は育児休業の取得を原則拒否することができないよう、法律で従業員の権利として定められています。
どうやら日本の育児休暇制度は世界で最高クラスだそうで、世界でもっとも父親に育児休業期間が長い国だそうです。（ただ残念なことに取得率は最低クラスのようです）
参考：男性育児休暇の現状｜パパ特有の制度紹介と取得率を上げるための対策
2週間という期間について
会社として大事な時期だったため休暇期間は短く2週間にしました。ただ「仕事に影響を与えることなく育児にじっくりと慣れることができる」という意味では2週間は充分な長さだったと思います。
個人的には「育休を取得するかどうか迷っている」という人のミニマムな取得単位として2週間という単位はオススメです。2週間程度の休暇であれば事前に調整すれば、大抵の方は問題なく取れるかと思います。また2022年10月から『産後パパ育休』という制度ができ、産後8週以内で一度育休を取得後、後日再取得もできるようになったので、まずは2週間育休というのはお手軽で良いと思います。
（↓『産後パパ育休』の詳しい説明はこちら）
【2022年10月〜】「産後パパ育休」と「育児休業の分割取得」のポイントを社労士が解説 - SmartHR Mag.
ただし奥さんの育児負担を減らすという意味では、2週間では当然短いため、夫婦の生活に余裕を持ちたい人は1ヶ月ぐらいは取得したほうがいいと思います。ただし育休終了後も育児はずっと続いていくわけなので、育休の期間が長いことよりも育休終了後に育児を頑張っていくための準備をしっかりできることのほうが重要ではないかと思います。
そのため育休の目的は『産後の一番大変な時期のサポート』と『今後自分が育児に参加する上での作業を覚えること』と考えていました。
個人的には、育休の長期一括取得はせず、奥さんが大変な時期（例：奥さんの復職タイミング）に小分けで取得するようなイメージを今の所予定しています（ちなみに前述の「産後パパ育休制度」もそういった設計になっています）。
日々の過ごし方について
日中はリビングにベビーベッドを動かして、娘と同じ部屋で過ごしていました。1時間おきくらいに娘が起きたり泣いたりするので、その都度オムツを変えたりミルクをあげたりしつつ、自分はのんびり過ごしたり家事をしたりしていました。
自分も奥さんも休暇を取りフルに時間があり育児・家事は分担できたおかげで、日中は比較的余裕を持つことができました。日中に時間があったおかげで、オムツ替え・ミルク・お風呂の入れ方を調べたり、必要な物資の買い出しを行ったり、娘の顔の湿疹や便秘症状（生後すぐだと一般的だそうです）について調べる時間がゆっくり取れました。
ただ赤ちゃんは起きているときは四六時中動いたり唸ったりするので、その都度大丈夫か気になって見てしまうため、なにか並行して作業に集中することは難しかったです。また自分か奥さんが外出するときには、もう片方が家にいて娘を見ていないといけないため、ふらっと近所にでかけたりすることはできなくなりました。
日中よりも夜が大変でした。赤ちゃんは夜寝るサイクルがまだできていないので、2時間おきぐらいで泣くからです。夜は申し訳無いながらもほとんど奥さんに頑張ってもらっていますが、数回だけ夜中3時ぐらいまで自分で体験してみたところその大変さがわかりました。寝かしつけたあとも、2時間おきぐらいで起きるため、連続して寝る時間がなく常に寝不足になるようなイメージです。
生後1ヶ月の育児の負担度合いとしては「仕事よりは軽いが、仕事より圧倒的に長いのがきつい」といった感想でした。突発的な忙しさという意味では大変ではなく育児以外のことをやる時間的余裕はありますが、育児は朝も夜も深夜も24時間年中無休で続くのでそれが大変でした。
休暇明け後、奥さんのサポートを仕事と並行して頑張らなければいけないなと思いました。
2週間振り返ってみて思ったこと
とにかく準備は大事だと感じました。
特に奥さん・娘が自宅に帰ってきた直後が大変な時期になるので、事前準備をしておかないとキツイことになります。赤ちゃん用品などの事前準備や、オムツ替え・お風呂の入れ方など覚えることが一杯あるため、事前にやり方を覚えておくといいと思いました。
特に出産後2ヶ月ぐらいは、役所の申請や出産祝いへの内祝い返しなど、他にもやることがたくさんあるので、バタバタしないという意味でも準備は大事だと思います。
また2週間だけでもフルタイムで娘と一緒に過ごしたことで、価値観も変わりました。子供が産まれた直後は正直あまり実感がなかったのですが、自分でオムツ替えやミルクをあげたりすることで子供が産まれた自覚がでてきました。
また諸々の育児に関わる作業が一通り自分の手でできるようになったことで、積極的に関与しようという意思がうまれました。働きながら空き時間にちょっとずつ関与する方法だと、どうしても「自分ができるところだけ手助けする」という形になってしまうため、育児が一部他人事になっていたんじゃないかと思います。『出産と授乳以外はパパでもできる』という言葉があるそうで、実際そうだと感じたので一通りできるようになることは育児に積極的に関わる上で大事だと思いました。
そういった意味で、短い期間でいいので育児のための休暇取得、個人的にオススメします👍
当事者になることで見え方が大きく変わる
ここ4年で転職・引越し・結婚・出産・祖母の死去など、ライフイベントが色々ありました。また3年前からコロナ禍により、平日はフルリモート勤務で休日は外出自粛するライフスタイルへと大きく変わりました。さらに3年半前に転職したとき、会社には2名しかいなかったのが現在20名強まで増え、その過程で仕事内容も大きく変化してきました。
そういった大きな変化が何度もあった中で、今まで当然に考えていたことの前提が崩れ価値観が変わることが何度もありました。そして『当事者になることで見え方が大きく変わる』ということを学びました。
今日はこのテーマについて、実際の例を引き合いに出しつつ書いてみます。
==================
最初は多くの人が経験しているであろう『リモート勤務』を例に出します。リモート勤務をすることで仕事スタイルだけならずライフスタイルまでについても価値観が変わったという人は私以外にも多いのではないでしょうか？
コロナ禍が来る前から、リモート勤務や時差出勤のような柔軟な働き方は、女性が働きやすい社会の実現や満員電車問題解消の解決策ともなるため注目はされていました。しかしいざ導入となると強固に反対する人（主に会社上層部）がいるため、導入が進むことは一部の若い企業でしかありませんでした。しかし実際にコロナ禍でリモート勤務をせざるを得ない状況になったところ、その良さ・悪さを体感できるようになりました。
私も元々はリモート勤務は賛成ながらもフルリモート勤務（＝毎日リモート勤務）には反対だったのですが、フルリモート勤務をせざるを得ない日々を実際に体験したことで、「定期的にリアルで会う場さえ設けられるのであればフルリモート勤務のほうがいい」という考えに変わりました。またリモートだと属人性が高かったり情報がクローズな組織だと円滑に回らないため、業務の標準化や情報のオープン化などを強く意識した仕事スタイルに変わりました。
またフルリモート勤務になったことで住みたい土地についても価値観が変わり、都心から千葉のベッドタウンへと引っ越しもしました。（私のような人は多いらしく、東京23区が2014年以降で初の転出超過になったというニュースもありました）
『育児』も当事者になることで価値観が大きく変わった例の一つです。先週ブログで書いたように、第一子が産まれ育児のため休暇を2週間とりました。
休暇中にじっくり育児を経験して感じたのは、育児・家事両方をやると一般的な仕事よりずっと大変だということでした。瞬間的な忙しさとしては仕事のほうが大変なのですが、育児は24時間年中無休で続く点で精神的なきつさがあります。
上述のブログ記事にも書いたのですが、2週間の休暇をとったことで育児の当事者としての自覚が産まれ、休暇明け後に具体的に何を手伝うかの話し合いを積極的に妻ともするようになりました。
またこれは妻の妊娠中からそうだったのですが、近所にある保育園が驚くほど目に入るようになりました。妊娠前は近所に1件あることは知っていたのですが、妊娠がわかったあとになると近所を散歩している最中に途端に目に入るようになり、実は6件ほどあることに気づきました。自分が当事者でなかったときには、保育園の前を何度も通っていながらも、認識することなく素通りしていたのです。
さらに子供ができてから殺人・事故・虐待・パワハラ・わいせつ行為などの世の中の痛ましいニュースについて、今までよりずっと強く共感するようになりました。育児を経て、一人の子供を無事に成人させることの大変さが想像できるようになり、そういった一人の人間の尊厳を踏みにじる行為が関係者をいかに悲しませるかを、自分と自分の娘の立場に置き換えることでより具体的に想像できるようになったためです。
『当事者になることで見え方が大きく変わる』と似た考え方として、『お金を投じることでその分野に興味・関心を持ち続けられるようになる』という考え方を何度か聞いたことがあります。しかし私の個人的感覚としては、お金を投じるより実際に当事者になるほうが圧倒的にその分野への興味・関心が生まれます。
元々私は自分が興味がある業界の会社の株を買ったりNPOに寄付をしていました。例えば病児保育・障害児保育などを手掛けているフローレンスというNPOに継続寄付をしていました。しかしニュースレターが毎月届くのですが正直そこまで深く入り込めないという気持ちでした。なぜなら”保育”が具体的な毎日の作業として何をどうやるものなのか（オムツ替えやミルク）、解像度高くイメージが持てていないため、必然的に病児保育・障害児保育という課題に対する解像度も高く持てなかったためです。
しかし実際に育児を経験したことで、この問題の重さについてとても詳細に感じられるようになりました。お金を投じていただけでは感じられなかったことが、当事者になったことで感じられるようになったのです。
仕事においても当事者になることで見え方が大きく変わる例はいくつもあります。
『マネージャ・リーダーになる経験は早いほうがいいし、一度はなっておいたほうがいい』というよく言われる考え方はまさにその一例です。やはりどれだけ日々視点を高く持とうと意識していたとしても、実際にその役割を演じることにまさる練習はありません。組織図上のチームのマネージャ・リーダである必要はないので、短期のプロジェクトででもいいのでそういった役割を演じる機会をなるべく得たほうがいいと思います。
他の例だと、新規事業やスタートアップに興味がある人が最近は多いですが、読書や自分の個人プロジェクトでは学べることに限界があるため、本当に興味があるのであればそういったことができる場所に転籍・転職すべきです。新規事業のノウハウなどは最近はフレームワークとして（例：リーンスタートアップ）世の中に広く公開されていますが、やはり実際にやってみるとそれをいかに自分たちの状況へ合うよう応用するかが大事だとわかります。
私の場合は「大企業の新規事業立ち上げ」と「スタートアップの立ち上げ」の両方を経験しましたが、両者は異なるということも当事者になったことで気づきました。ヒトモノカネが充実している大企業の新規事業立ち上げは自分の職種（例：開発）としての役割をいかにレベル高く果たすかがポイントですが、スタートアップではヒトモノカネが不十分なことが通常なのでその状態で最適な意思決定・行動を行うための事業視点・経営視点が身につきます。
というわけで以上、『当事者になることで見え方が大きく変わる』という話でした。
