投稿

ソフトウェア開発の世界には、その品質を評価する基準となる品質特性がある。機能性，信頼性，使用性，効率性，保守性，移植性が、国際規格で決められていて、開発時の指標になる。

こうした品質特性の考え方は、政治や経営の文脈でも考えることができそうだし、むしろ人の考えや概念を扱うのがソフトウェアだとしたら、とてもフィットするのではないだろうか。

機能性は、企業としてのパフォーマンスを示す指標であり、顧客への価値を高めることで売上や成長率といった数字に繋がる。

信頼性は、企業を存続させるためのリスクマネジメントしているかどうかで、トラブルなく続けられるかどうかに繋がる。

使用性は、社員にとってのUXを高めることで、働き方の柔軟さや働きやすい制度などを用意することで採用や離職に繋がる。

効率性は、そのまま業務効率のことであり、無駄なコスト構造を解消し、生産性を高めることで、より多くの利益に繋がる。

保守性は、企業が成長していくにつれて、体制や制度の見直しが求められる中で、変化し続けていけるかどうかに繋がる。

移植性は、企業のサステナビリティを高めるために、後継者の育成や適切な権限委譲などを進めていくことに繋がる。

これら品質特性は、売上だけ見ててもダメなように、どれか一つだけでは持続しないので、うまくチューニングしていくことで、良い状態を作ることができる。

こうした品質の観点をもって経営に取り組むことで、よりバランスの良い健全な企業経営が実現できるように思う。

ビジネスである限り、結果はとても大事だけど、結果だけを求めると、たまたま運が悪くうまくいかないときに辛いことになる。結果は大事にしつつ、そこに至る過程も大事にしたい。

もし仕事自体が楽しくできれば、少なくとも得るものはあったと思える。成功しないことは失敗ではないのかも。幸せになるまでは不幸であると思わない方が幸せという話に似ている。

旅をするときは、目的地があるけれど、目的地に辿り着くことだけをしている訳ではない。旅の途中で得た経験も財産になる。登山も自分の足で登るから頂上からの景色も一入になる。

過程を楽しむためには、健全な人間関係は欠かせない。むしろ、それが全てとも言える。気のおけない仲間となら、たとえ失敗してもフォローして、許し合えば一緒に笑い話にできる。

甘い話かもしれないが、仲間と共に楽しくやれている方が結果は後からついてくる気がする。現場が楽しく働いていれば結果が自ずと出るようにするのが経営かも。とても難しいけど。

チームに入ってすぐは、周りに相談するばかりで、良いチームほど助けてもらえるけれど、まるでお客様扱い。チーム内で人間関係を築いて相談できる相手を増やすことは大事だけど、それよりも周りの人たちから相談される存在になることの方が本質。チームとは、背中を預けられる同士の集まりでありたい。

一方的に相談したり助けたりする関係でなく、互いの強みを活かして相談しあうことで、チームとしての成果を出せる。そのために出来ることは、飲み会したり仲良くすることだけではない。チーム内で困ったことが起きたときに、声をかけてもらえるようになるには、自ら発信をして存在感を出していくこと。

例えば、チーム内で他の人には負けないと思えるような特定のスキルを身につけ、それに関するノウハウを発信して周りに知られれば、頼られるようになる。もしくは、スキルに自信がなくても、どんな仕事も前向きに受けることを伝えるだけでも、チーム内で困ったら相談しようと思ってもらえるようになる。

チームの一員だから貢献すべきと考えるより、チームの人たちから頼られる存在になれば本人にとって嬉しいし、それに応えて喜ばれると、さらに仕事も楽しくなると考える方が健全だし長続きする。自分に出来ることを探すのではなく、周りから頼ってもらえるようにする。チームワークに対する発想の転換。

プログラマの成長ステージにも 、仲山 進也さんの加減乗除の考え方が適用できそう。加のステージでは、コードを書いたり読んだりする絶対量が必要。書くほどに速くなるし、経験するほど設計と実装の引き出しが増える。ある程度の要件なら、タスクばらしと見積もりできることを目指す段階。

作りたいものが作れるようになったら、減のステージ。いかに効率的に成果を出せるようになるかを意識する。コスパが上がれば、時間に余裕ができるようになり、新しい技術に挑戦できるようになる。また、チームのメンバーとうまくコミュニケーションして、苦手なことを減らし得意なことに集中する段階。

乗のステージでは、ゼロからフルスクラッチで作れる設計・実装・運用の全般的な開発力に加えて、専門的な技術領域を持ち、その分野でリードできる。チーム内でも他の人を助ける場面が増え、多くのプロジェクトで頼られて、複数の案件に関わりつつセルフマネジメントして並列で価値を出していける段階。

技術領域でなく、バイネームで存在感が出せるのが、除のステージ。仕事はプログラミングだとしても、組織で言えば経営の視点や視野を持ちつつ、自分で考えて成果を出す。自分の趣味嗜好でやっていることと、仕事で成果が出ることが一致しているから、使役される労働ではない。「遊ぶように働く」段階。

いかにチームで「問題 vs 私たち」の構図をつくることが大事で、心理的安全性は結果に過ぎない。問題や成果に向き合えさえできれば、対立でなく協力になる。

率直なフィードバックや意見の対立も、相手を負かすためや、自分の意見を通すためではなく、問題を解決し成果を出すことのためという共通認識をつくること。

心理的安全性のような新しいキーワードを自社に取り入れるためには会社や上司に対し「提案より相談」をすること。提案は現状に対する否定と取られかねない。

味方をつくるには相談から入ること。相手に意見を通すのではなく、相手に相談を持ちかければ、共通の問題に一緒に向き合う構図になり、味方になってくれる。

これも「問題 vs 私たち」の構図のつくり方。ものごとをうまく進めたいならば敵を作らない。そもそも敵などいない。向き合うのは解決したい問題だけなのだ。

私たちがしていることは戦争でも競争でもない。問題を解決すること、成果を出すこと、社会を良くすること。その共通認識が心理的安全性の第一歩ではないか。

「納品のない受託開発」だったり、オフィスなくして全社員リモートワークとか、管理ゼロとか、何かをなくしたり、やめてしまうことで、生産性や創造性を高めてる。

「ない」ことは、メディア受けするインパクトがあんまりないし、アワードなどで良さを伝えるのも難しい。ビジュアルに見せられないし、一言で伝えにくい。

「ない」ことは、装飾がなくてゴチャゴチャしてないシンプルな状態だから、本質だけを捉えてるとも言える。どんなことも、本質的であることは大事にしたい。

増やすより減らす方が美しい。いかに増やさずにいられるかを維持したい。これって、メンテナンス性を高い状態に維持するというアジャイル開発の話と同じなのかもしれない。

誰の言葉か「筋肉はお金で買えない」確かに最後は自分で努力しなければ得られない。そんな、お金（だけ）で買えないものは沢山ある。スキルとか信用とか。それらは誰かに奪われることはないし、いずれお金になるかもしれない。お金より技能を持っている方が、生き残れる。お金で買えないものを貯める。

今、この決断は正しいのかどうか、不安になることも少なくない。だが、何が正しかったのかなんて、後になってみないとわからない。いや、どんな決断だったとしても、後になってから振り返って、ifを考えても仕方はない。だから、今出来ることは、なるべく後悔しないような決断をしていくことだろう。

ウェブの記事も良いんだけど、それでも本の方が優れているなと感じるのは、どこでも中断して、またいつでも続きから読み始めることができること。ブラウザだと、ページにブックマークはできるけど、読んでる途中に栞を挟むことができない。本なら、隙間時間をうまく使えるし、読みたければ長く読める。

セルフマネジメントの話。自分をコントロールして、きちんと仕事をしていくことがセルフマネジメントだと思われているが、それだけではない。きちんと休みをとっているか、ストレスを溜め込まないようにしているか、適度に同僚と雑談したり、家族との時間は取れてるか。それこそがセルフマネジメント。

採用の話。人付き合いや異性と付き合う時に、最初に自分を偽って相手に合わせていても、いずれ辛くなってうまくいかなくなる。会社に入るのも同じではないか。会社の望むように自分を偽り、無理をして入ったとしても、結局は長続きしない。素の自分のままでいても、互いに合うと思える方が長続きする。

適材適所の話。特に若者だと、本人がやりたいと言っていることよりも、外から見て適切だと思うことに配置する方がうまくいくことも多い。若いうちは、自分のことをわかっておらず、自分の理想と現実の自分に違いを認められない場合も多い。そこを導き、力を発揮できるようにすることも、経営の一つだ。