この記事は「corp-engr 情シスSlack（コーポレートエンジニア x 情シス）#1 Advent Calendar 2023」4日目の記事です。
私、元々はゲームディレクターになろうとしていたんです。ゲーム会社に入ったら間違って経理に配属されて、さらに間違って情報システム部へ異動になってしまったんですね。
異動してからはものすごい勢いで人がいなくなりました。自分が上司なら手の打ちようがあったのかもしれませんが、赤字というのは大きなインパクトのあるものです。
びっくりする位の勢いで仕事の範囲が広がる中で、どうも急激な変化が起きているのは社内だけじゃない事も分かりました。技術自体の進歩も早く、古くからこの仕事をしていた人ですら、気を抜くとあっという間に進歩へついていけなくなるみたいでした。
学ぶ他に生き残る道はない。そんな風に思ったんですね。
ただ、この学ぶっていうのがどうも思っていたのと違うみたいでした。
情報安全確保支援士って資格を取ったんです。それなりに難関の国家資格で、弁護士資格を取るみたいに、自分の仕事のステージを変えてくれるんじゃないかと思っていたんです。実際に多くの知識を得られましたし、手当ももらえて、周りからも感心されました。
でも仕事が何か変わったかっていうと、これが何も変わらないんですね。どう考えても今の仕事と、問題に出てくるような大企業のインフラとはほとんど関連がありません。セキュリティ上のベストプラクティスはあっても、現状の会社のリソースでどこまで対応すべきかという話には全く別の力学が働きます。
これはセキュリティに限りません。ネットワークもサーバー管理も開発もITサポートも、お勉強によって得られた知識と実際の知識にはとてつもなく大きな隔たりがあります。さらに1つ1つの分野が、その分野のスペシャリストとして食っていけるような深い専門性を持っているようでした。
教科書の知識がいらないわけじゃなくて、それじゃあ足りないんですね。仕事をしていくにはもっとたくさんの知識を得ていかなければならない。そう考えた時に、とても今のペースじゃ必要な知識を得られないと思いました。
ただ、ここで分野を絞るわけにもいきません。なぜなら他の分野を任せられる人はみんな辞めてしまったからです。だからどうやって学習効率を高めるかという所が自分の生命線だと分かりました。
学ぶ効率を最も高めてくれるのは回数です。
集中的に詰め込み学習を行うより、少しずつ何度も学習する方が有効だという考え方は「スペーシング効果」と呼ばれ、1885年に発見されたものですが、今でも学習に関する研究の基礎となる考え方です。
情報をただ読むだけではなく、思い出す事で学習効率を上げる手法は「アクティブリコール」と呼ばれ、繰り返し読む事が効率的だと考える人でさえ、この学習法の方が有意に効率的な学習を行える事が証明されました。
実際に知識を使う場面がある事で情報が長期記憶へ定着しやすくなる事は「テスト効果」と呼ばれ、教育現場では授業だけではなく、テストで知識を使う事も重要だという事を示しています。
これらは全て学びにおける「回数」の重要性を示しています。とにかく回数を稼ぐ事で学習効率を上げていくというのが基本方針になりました。
回数を稼ぐために必要なものは何でしょうか。私は「案件・アイデア・コスト」の3つが必要だと思います。
案件がなければ、そもそも試行錯誤をする必要がなくなってしまいます。案件を成功させるためのアイデアがなければ手詰まりになってしまいます。アイデアがあっても、それを実行するためのコストを払えなければ試行回数を稼げません。この3つが揃って初めて学ぶための回数を稼げるようになります。
ではこれらを得るために、どのような方法があるでしょうか？
案件を得るためには、仕事を任される必要があります。ここで大切になってくるのは、周りの状況をよく見る事です。
最初は仕事を任されるためには実力が必要だと思っていました。案件を達成するための実力があるからこそ人は仕事を頼まれるという考え方です。だから日々の仕事をこなしながら実力を蓄え、然るべき時に大きな仕事を任されると思っていました。
しかし実際には、実力という客観的な指標があるわけではありません。この人には実力があるかも知れないという期待こそが、仕事を任されるかどうかの判断基準になっています。
実力は一朝一夕では変わりません。でも期待というのは自分自身に変化がなくても、環境の変化によって大きく変動するものです。
通常であれば実績のない人に仕事を任せようとは思いません。私も最初の開発を任せてもらうには実際にハードルがありました。でも元々開発をやっていた人と、開発を依頼する部署の人が揉めた時に、ふと私に頼んだらスムーズにコミュニケーションが取れるのではないかという期待をされた事を感じました。あるいはチームの人が辞めた時や、別の担当の人が他の案件で忙しい時もそうです。平常時であれば期待されないような事を、期待してもらいやすいタイミングは必ずあります。
状況の変化を察知し、何かが起きた時に助けてあげられる位置にいる。これを繰り返す事によって、自分の実力に対する評価を超えた期待をしてもらう事は可能です。
案件を得たら、次は案件をクリアするためのアイデアを得る必要があります。
アイデアというのは、独創的で、クリエイティブな何かを指すものではありません。今の段階で試してみたら解決するかもしれないと思える全てを指します。例えばパソコンの調子が悪いから再起動してみようというのもアイデアです。
手に入れた案件が自分の知識や経験を超えたものなら、最初は何から手を付けていいか分からないはずです。最初からどのアイデアが良さそうか判別するだけの知識はありませんし、そもそも1つもアイデアがなく、途方に暮れてしまう事もあります。
自分の中に知識や経験はないので、どこかからアイデアを手に入れる必要があります。アイデアの入手元としては下記のあたりが挙げられます。
概ね後に挙げたもの程、質の高い情報を得られますが、情報を得るために自分自身の理解も進んでいる必要があります。マニュアルは何も考えなくても書いてある事に従えば手順が実行できますが、検索エンジンにはキーワードを入力しないと情報を得られませんし、仕様書を読むには一定の経験や日本語力を有した上で、疑問点を持って読まないと厳しい部分があります。
スタート地点では理解度が低い事を考えると、アイデアをまずたくさん集めるのではなく、実行可能なアイデアが集まったら回数を稼ぎ、自分のレベルを上げる必要があります。アイデアを集めている時点では試行回数は0のままで、自分の理解度は上がっていない事に気をつけましょう。
いくつかのアイデアが集まった時点で、アイデアを実行するためのコストを払う事になります。コストを使ってアイデアを試す事で、学習に必要な回数が稼げます。
リソースには内的なものと外的なものがあります。内的なものは主にモチベーションの事を指し、トピックへの興味や責任感、重圧や恐怖等、様々な要素が取り組みへのコストに関わってきます。一方、外的なものは工数や権限、関係者の意向や予算というものが関わってきます。
そして回数を稼ぐ上での最適な戦略は、コストを支払うためのリソースが豊富なアイデア、あるいはコストの低いアイデアを優先していく事です。
特に重要なのはコストの低いアイデアです。ブラウザの調子が悪ければ、とりあえずブラウザを再起動し、シークレットモードや別ブラウザを試し、拡張機能を確認したり、キャッシュを削除したりする。こういう試行は時に本質的な解決ではなく、事象を深く理解するための行動ではないかもしれませんが、10分もかからずいくつものアイデアを試す事ができ、うまく解決すれば他の案件にリソースも回せます。
コストの高いアイデアに対して、コストを下げられる工夫をするというのも大事です。代表的なのがテスト環境ですね。本番環境で稼働しているものを変更するコストは非常に大きくなります。テスト環境を準備し、最悪ネットワークやサーバー、プログラムが稼働しなくなっても大丈夫な状況を作る。こうした準備はコストを大きく下げ、試行の回数を増やしてくれます。
高額なコストをしっかり払い、価値の高い学びを得るというのは素晴らしい事です。しかし時間と気力という点において、学びを加速させるという観点に立った時、回数を稼ぐ時により重視すべきなのはコストが低い事です。
案件、アイデア、コスト。この3つのバランスが良ければ、回数を最大化させ、学びを加速させる事ができます。逆に今のままでは知識や経験が足りないと思うのであれば、この3つのどこかに働きかける事で改善が図れます。
働きかける順は仕事の流れの逆がいいでしょう。コストを下げてアイデアを試す余裕を作り、試せるアイデアを集め、回数を稼ぐ事によって学びを得て、新たな案件を得る期待を作れます。
この1年での取り組みはまさにこの順での取り組みでした。
当初の私の状況としては、ITサポート業務の案件・アイデア・コストのバランスが取れているものの、全体的に余力のある状況でした。セキュリティやネットワーク、サーバー管理の自習を続けていましたが、肝心の案件がなく、新しい分野へ手を伸ばすチャンスを伺っている状態でした。
あるタイミングで部内唯一の開発担当の異動が内定しました。新規採用や外注が検討されたようですが、話の進捗は芳しくなさそうです。開発を行ってくれる誰かへの期待が高まっている状態でした。開発の経験はありませんでしたが、代わりの開発担当として手を挙げる事にしました。
本来であれば開発を経験した事のない人に、開発業務が任される事はありません。しかし状況的に、ある程度私の開発がモノになるなら、開発を任せようという話へ持っていく事ができました。内製ツールの重要度の切り分けが行われ、社内向けのツールは長期的に私が見るようになる可能性が生まれました。
この段階では開発の事は何もできません。そこで試行錯誤の回数を稼ぐために、既存システムの改修から始める事にしました。
何も理解していない状況では、環境の構築方法も、変数の宣言方法も分かりません。少なくとも変更しなければ動く正解のコードは、試すべきアイデアを獲得する上で必須でした。
何も分かっていない人にコードを触らせられるシステムは限られています。影響が出るかもしれない試行をする度に確認を行っていては、回数を重ねるペースが落ちてしまいます。
そこで影響が少なさそうだと思ってもらうために、運用をこちらでしており、業務影響の少ないアプリケーションへの改修に取り組む事に決め、同意を得ました。
これによってコードを変更する試行錯誤のコストを下げ、かつ既に書かれたコードというアイデアの元を得る事に成功しました。
コストが下がれば様々なアイデアを試せます。扱ったのがシンプルなアプリケーションだった事も幸いしました。Microsoftのチュートリアルをアイデア源にしながら、試行錯誤の末に2ヶ月程度で改修を終える事ができました。
同様に自分が使用者であるツールの改修を行う事で、さらに回数を稼ぎつつ、環境の変化を待ちました。
すると付け入る隙のある部分が2つ見つかります。1つは新規事業の唯一の担当者の退職。もう1つは異動する開発担当と経理部の関係性が良くない事です。
ここに自分が開発へ取り組んでいる事を伝える事で、依頼をしたくなる期待を生みました。様々な調整が行われた後で、私が他部署からの依頼を受けて開発を行う事ができるようになりました、
新規事業は変化が速いですし、経理は自動化を推進しています。ここに期待される事で、継続的に案件を獲得できるようになりました。
後はこのサイクルを回していくだけです。ITサポートがメインの業務なので月に30時間程度しか開発の工数は割けませんでしたが、1年間でインボイス制度や固定資産棚卸、売上集計、VPN切り替え等に関する8つのツールを開発する事ができました。本格的に開発を開始して1年目にして、遅延やバグもなく、割いた工数以上に工数を削減する事に成功しました。
「案件・アイデア・コスト」のどこに問題があるのか、あなたもぜひ考えてみて下さい。見方を変える事は問題を解決してはくれませんが、新たなアイデアを生むきっかけになります。
最も重要なのは、仕事が多すぎる状況を「案件が多すぎる」ではなく「コストが高すぎる」と捉えようとする事です。
案件を減らす事は可能です。上司のいる職場であれば業務調整を依頼できますし、いなくてもしっかり主張すれば、ある程度は新たな案件が来る事を防げます。
しかしこれは諸刃の剣です。案件が減れば、案件を成功させるためのアイデアの量も大きく減ります。試行錯誤の回数が減ってしまうので学習の速度も低下し、知識や経験が得られないので、案件を成功させるコストが下がらない…という負のループに陥ってしまいます。
これをコストが高すぎると捉えてみるのがポイントだと思います。コストが高すぎるなら、コストを下げるためのアイデアを試す必要が出てくるからです。アイデアを試す事で回数を稼ぎ、コストを下げるための学びを得られます。余裕を作れれば新たな案件を入れる事ができ、さらなるアイデアを得る事ができます。
多くの場合、会社には何ヶ月、何年と勤める事になります。長期間の取り組みを行う際には、正のループを回す事がとても重要です。
私は生まれてから一度も景気の良い時代を経験した事がありません。何につけても、今の状態そのものは恵まれていても、今がピークで、これからはどんどん悪くなっていくという世界観を持っています。
年齢を重ねるごとに市場価値は下がり、会社が傾くリスクは増し、出費は増え、仕事は難しくなるという夢や希望に欠けた先行きを見据えています。
それでも世の中には鮮やかに下り坂を駆け下りていく人はいます。時間と共に失われていく身体能力や活力、資金力、市場価値を抱えながら、積み重ねた知識や経験、実績、信頼を駆使し、坂を転がり落ちるのではなく、駆け下りていくのです。
切り立った崖から飛び降りるための勇気と技術こそが学びから得られるものだと思います。